Thanks. Makes me feel more comfortable 
One thing I’ve been pondering is how do you measure “snappyness”. Like, if the app can maintain 30fps than doesn’t this imply it should work well? Ie why would a game maintaining 30fps on an iphone 4 and iphone 5 not appear to be just as good? And then whatever the answer is to this, how would you measure it?
Good question…
Frames per second is inherently an averaged value. At 30 frames per second, each frame should take 33.3 milliseconds. If your FPS drops to 28, it can mean a couple different things. It may mean that each frame is taking 35.7 ms instead of 33.3. This would still appear smooth and snappy because it is consistent. But in reality, you are far more likely to encounter a situation in which most of your frames are taking 33.3 ms, but a few here and there are taking much longer. These longer frames will occur when a lot of action is happening onscreen, filling the user experience with very short but noticeable slowdowns.
So, Im thinking a good definition of snappiness would be “having a consistent framerate.” A good way to measure snappiness would be to output the longest frame per second. If it often strays from 33.3 milliseconds, the experience probably isn’t snappy. I haven’t tested this myself, though, so snappiness may have to do with other factors as well.
It’d be simple enough to modify MTE’s debug output to do this. It might actually be more useful to print each frame’s duration to the console so you can scroll back through and look for spots where it changes.
excellent - thanks for helping me understand
Regarding the error I have been experiencing with the TMX maps, I have made a simple demo map separate from my project but also has the same error, the map is very simple and the main file just loads it, just a simple change from .json to .tmx will produce this error.
Thanks Abiz, that was very helpful.
At the moment only XML encoding is supported. Your map’s layer data is encoded in base64. I’m working on adding additional encoding support in the near future.
Ahh I see, thanks for telling me that, it wasn’t obvious to me. Everything is working now.
I’ve added base64(uncompressed) and CSV support to the TMX parser, and I’ve improved the performance of the XML parser. Unless there are other factors I’m not aware of, using CSV layer data in your TMX maps would seem to be the best choice. The resulting files are a similar size to Json exports and load almost as quickly.
The test map is a 100x100 map with 9 layers, completely filled with tiles. Tests were run in the simulator.
Type: Size: Loading Time:
Json 273 KB 103ms
CSV 182 KB 126ms
XML 1.7 MB 264ms
base64 482 KB 383ms
Tomorrow I’ll be finishing up the current work on TMX support and moving on to PhysicsEditor support.
Hopefully this isn’t a terrible question but I am just now getting into the engine and I am still relatively new to Corona.
I know that with the Sonic and Basic project’s your player is constrained to only jumping once etc. based on isJumping I believe (Sorry from memory, looked today). In the Basic (and Angled) physics examples, the player’s can jump over and over again.
I am interested in making a side scrolling game similar to Zelda 2 where velocity is constrained after an initial pace with the camera in a fixed position following the player. My problem so far with understanding the examples is mainly how the physics examples could be modified to only allow the character to jump once while also constraining the velocity etc… Just a little lost here
Does it even make sense to use Physics in a game like that? - the non-physics examples seem to perform much more closely to that type of game but there seems to be a lot more to consider when not using physics.
Hopefully those aren’t stupid questions but I am still learning and want to get past the roadblocks
Thanks!
Physics goes so very far and asks so little of developers who use it, provided they can bend its mysterious black-box simulation to their will. It’s plain to see how very complicated 2D platforming movement can be to code on your own, and you have to take into account the possible need to add more functionality in the future. The Sonic Finale example has no wall collisions, for example, and you would have to code those in yourself. It is not a trivial task. Hand-coded physics can run a lot faster than using Corona’s Physics implementation, but that is a benefit you have to weigh against the difficulty of programming your own system.
I did some tinkering today and came up with two ways to constrain the movement speed of a physics body. The first is to set the body’s linearDamping property to something other than zero. Higher values cap the sprite at a lower top speed. The downside of this is that the vertical (jump/fall) speed is also constrained, so it isn’t quite ideal.
A better solution is to check the linear velocity of the sprite, compare it to a user-defined limit, and set it to the limit if the sprite is moving too quickly.
Generally, preventing the player from jumping repeatedly in mid air requires that you detect when he is standing on the ground. There are probably many ways to do this, but the one I threw together works by calling the Physics’s queryRegion function and testing a region encompassing the bottom (but not sides or top) of the player. That is to say, checking for objects inside a box not as tall or as wide as the player, positions against the bottom of the player’s physics body. You then iterate through the objects inside the box, ignoring your player object, and if any are present your player is probably standing on something.
You can modify Platformer - Angled PHYSICS thusly to try these out yourself.
local grounded = false local jump = function(event) if event.phase == "began" then display.getCurrentStage():setFocus(event.target, event.id) event.target.isFocus = true if grounded then player:applyLinearImpulse(0, -500, player.x, player.y) end end if event.phase == "ended" or event.phase == "cancelled" then display.getCurrentStage():setFocus( event.target, nil ) event.target.isFocus = false end return true end --ENTERFRAME---------------------------------------------------------------------------- local gameLoop = function(event) local hits = mte.physics.queryRegion(player.x + blockScale / -2 + 8, player.y, player.x + blockScale / 2 - 8, player.y + blockScale) if hits then for i = 1, #hits, 1 do if hits[i] ~= player then grounded = true elseif #hits == 1 then grounded = false end end end local limit = 1000 local velocityX, velocityY = player:getLinearVelocity() if velocityX \> limit then player:setLinearVelocity(limit, velocityY) elseif velocityX \< limit \* -1 then player:setLinearVelocity(limit \* -1, velocityY) end mte.debug() mte.update() player:applyForce(acc \* 2400, 0, player.x, player.y) endWe do this for our game
Just as dyson said, you can use acceleration and then set the linear velocity after some threshold. One thing you might want to look at is old interviews and documentation about super Mario brothers on the nes by Shigeru Miyamoto. He goes to great length how they spent the most time getting the player/camera/controls to work and **feel good**.
One thing we did in our game was to completely separate the camera entity from the player entity. Doing this allows the camera to react to the player movements and perform its own movements. We found, once we did this, all camera and player movements felt more natural and responsive
Wow, thank you dyson for that explanation and example! It works like a charm in the Angled Physics example and I tested it out and it works perfectly - thank you for taking the time to put that together!
jqualls, thank you too. You mentioned separating the camera from the player entity. I am guessing that you would set the camera’s initial position and when the player entity moved you would move the camera based on some rules inside the game loop? For example, when the scene loads the camera and player are set at specific positions in the map. Then, when the player moves say to the right, the game loop could recognize this and say delay a second before adjusting to the player’s movement?
Thank you both for your help - There really is a lot to take in with Physics and you have been very helpful!
That is what we do
We also have logic in place where the player and camera move at different velocities and constrained differently when level constraints are hit.
Having the camera *catch up* to the player allows for smoother experience. For example you do not want the camera moving quickly when the player is making a difficult jump while running.
Excellent that sounds great - Thank you both again for all of your help - it helped me tremendously!
This is amazing work! Incredible stuff, making the purchase soon. I have a question about it’s compatibility with other LUA - engines. If I were to port a Corona made game into something like say, Löve, what features from the MTE library wouldn’t transfer over easily? I imagine the Corona specific APIs and libraries. I apologize if I’m not terribly knowledgable on the process, still deciding if I should fully invest in Corona development and wondering about porting games to Mac/Pc.
Hello jpwilliams,
I’ve mused occasionally about porting MTE to other LUA-based frameworks like Love! I would have done so already if I had the time. The engine’s mostly a colossal collection of arithmetic and if-then statements which wouldn’t need much in the way of modification. I can’t think of any real show stoppers to converting it over to Love, and such a thing could probably be done relatively quickly by someone familiar with both frameworks.
Off the top of my head, MTE relies on API calls to the Corona display library, it makes use of display groups, it uses Corona’s built-in json library for decoding maps, and it employs Corona’s event framework here and there. I’m sure Love has it’s own versions of all these things.
This is great! Awesome work just bought a copy. I noticed you had videos of a lighting effect test. Will you be including this sometime in the future? Looks like a great feature.
Looking forward to the update!
Thanks Czepta!
Which video are you talking about?
Oh! Yes, that one. The video shows an unfinished game of mine predating MTE, from which I adapted the current engine. I do love lighting of this type, and exploration/cave games in general, but at the time of the MTE BETA release people seemed less interested in it than a speedy BETA release.
I haven’t given the lighting system much thought since then. I’ll have to look into it, see what kind of work it would involve. I had no immediate plans to bring it over, but of course that will change if there’s demand for it!
Cool well its got my vote. Particularly liked the day/night transition. The lighting effects really make a huge difference in your video. Everything suddenly comes alive. Really looking forward to diving into MTE as it looks like it solves many of the issues I was having with designing my game from my limited knowledge. Being able to layout nice big levels will be great. I’m an artist and looking forward to having a go making some tile sets.
Thanks again!