this looks awesome! what about NPC and all, enemies? Do you think tha’ts an easy thing to add?
congrats again!
Indeed, great work 
Weird indeed. Here’s the file. Exported from fireworks.
Okay, this is actually a hilarious coincidence! The white background is not part of the image, it is coming from the rects DpadUp, DpadDown, DpadLeft, and DpadRight created after loading the Dpad image. In CastleDemo the Dpad image is merely a nonfunctional cover and the white rects are the control inputs.
You can add the following code after creating the rects to hide them while maintaining touch control:
DpadUp.isVisible = false DpadDown.isVisible = false DpadLeft.isVisible = false DpadRight.isVisible = false DpadUp.isHitTestable = true DpadDown.isHitTestable = true DpadLeft.isHitTestable = true DpadRight.isHitTestable = true
So the SETUP D-PAD section should like something like this:
--SETUP D-PAD ------------------------------------------------------------ local controlGroup = display.newGroup() local DpadBack = display.newImageRect(controlGroup, "dpad.png", 200, 200) DpadBack.x = 120 DpadBack.y = display.viewableContentHeight - 120 local DpadUp = display.newRect(controlGroup, DpadBack.x - 37, DpadBack.y - 100, 75, 75) local DpadDown = display.newRect(controlGroup, DpadBack.x - 37, DpadBack.y + 25, 75, 75) local DpadLeft = display.newRect(controlGroup, DpadBack.x - 100, DpadBack.y - 37, 75, 75) local DpadRight = display.newRect(controlGroup, DpadBack.x + 25, DpadBack.y - 37, 75, 75) DpadUp.isVisible = false DpadDown.isVisible = false DpadLeft.isVisible = false DpadRight.isVisible = false DpadUp.isHitTestable = true DpadDown.isHitTestable = true DpadLeft.isHitTestable = true DpadRight.isHitTestable = true DpadBack:toFront()Very nice - I had a sonic demo going, had him running, sprinting, jumping, spinning, ducking, skidding etc, now I have an easy way to do the parallax scrolling and level design
You are awesome sir! thank you!
Well, SegaBoy, I wasn’t originally planning on adding physics support at all, but after working on the platformer samples it occurred to me that physics could simplify some of the tasks particularly where different game genres cross. It makes sense to do your own calculations to control Sonic because he doesn’t necessarily act in a physically accurate way, for example he sticks to sloped ground rather than running into the air at high speeds. However if someone just wants to, say, bounce a ball around a room in an RPG in a freeform manner- not locked to the grid- it would be a hassle for them to have to program the whole state engine just for that sideshow.
@Ninja Pig Studios; SegaBoy has it down. I don’t have access to my files right now, but collision detection basically boils down to calculating the future position of your sprite, checking for tiles there, and checking for whatever tile property you use to determine whether a tile is solid or not. For RPG type games where the sprites are fixed to a grid like CastleDemo, this is pretty straightforward. You just add or subtract 1 from the sprite’s locX or locY parameter and check that location for solid tiles. Collision detection in a platformer is more or less the same but with per-pixel accuracy. You figure out where the “feet” of the sprite will be and check to see if they’re within a tile. If they are you adjust the velocity so they land ontop of the tile. The feet in this case are points you define in your code relative to the sprite. Platformer collision detection can be a little tricky, but I’m hoping Physics integretion will make this easier for people.
@dingo; The hardest part of Sonic movement in my opinion is getting him to stick to and land on the ground. Once that is taken care of the rest is relatively easy because it only interacts with the code you already have. The ground collision code would work for enemies without changes if I remember right. All you’d need for the enemies is their own velX, velY, etc 2D movement variables. Flying enemies would be quiet a bit simpler. Jumping on an enemy would be as easy as checking for a distance threshhold between the Sonic sprite and the enemy, checking whether Sonic’s isJumping variable is true, and if so adding to his Y velocity for the characteristic post-baddy-destruction hop. Spinning, spindash, ducking, etc, would all involve finagling with the control inputs and setting up a bunch of boolean flags, but the annoying part- the ground detection- would need little modification.
@Danny; Thanks Danny! Kudos are much appreciated.
@nick_sherman; Thanks nick_sherman! I’d been itching to do something Sonic related for a while now.
Anyone know why you would get these black lines on your tiled map when you put it in the game? When I look at my map in Tiled - it doesn’t have the line artifacts, but when I load it in game it does. Weird!
MTE is an amazing Engine thank you for your hard work on it!
Can’t say for sure but those artifacts look to be because:
-
You’re using Corona’s default filtering method
-
You’re not using the workaround for proper tiles while using default filtering
The workaround is tedious (to say the least), so I would generally suggest just getting your project’s filtering to nearest neighbor. It ensures that everything (all of your assets and graphics) are pixel-crisp.
-- Enter this somewhere near the beginning of main.lua display.setDefault( "magTextureFilter", "nearest" ) display.setDefault( "minTextureFilter", "nearest" )
The only downside to this approach is that easing methods apart from the default are going to have gaps, because there is no “inbetween” tiles anymore.
Thanks for update 0.8 dyson122! Performance improvements anywhere are always good to hear
EDIT: So im wondering how to make the player “stop” when trying to walk over certain tiles. In your examples you used Solid:true, but that doesnt work on my tiles.
Creating extruded tilesets can be a tedious process, but it is still the safest way to move forwards in that it allows the most flexibility while maintaining proper functioning of the easing methods.
I may be able to provide an option for automatically slightly oversizing tiles to eliminate both the need for extrusion and the irregular appearance of the easing functions with nearest-neighboring filters. I’ll have to look into the code and see if it breaks anything difficult to fix or severely adversely effects the appearance of a map. That’ll be something for when the camera constraints are finished.
Richard9 your solution solved it, thank you very much for that code snippet. I wasn’t aware of Corona’s filtering methods.
Congratulations, this looks like one of the coolest things to be offered in the Corona community for some time.
Insta-buy…even though I’m not currently in need of a tile engine I’ve purchased to show support of your efforts. Well done sir.
Collision detection comes down to reading tile properties and checking for a property you’ve defined for that purpose. When creating your maps in Tiled you will have to add the relevant properties to your tiles. I look for solid:true because I added a solid property to some of my tiles and set it to true.
Thanks, DeadPixelStudio! Your support is appreciated.
I’ve added flipped and rotated tiles to the list of features I would like to add. I’m talking about tiles which have been flipped or rotated from within Tiled itself and stored that way in the tile map. It’ll be some time before I get around to working on these.
Work continues on map constraints. Implementing them has proven more difficult than I thought, so the update will probably land sometime next week instead of this one. It seems two weeks always become three for me. In the future I’ll probably stick with a minimum of three weeks between updates.
We just bought MTE for use in one of our games. It looked excellent and much more efficient than writing our own. Unfortunately we’ve discovered it doesn’t support flipping or rotation of tiles which means we need to duplicated rotated or flipped tiles in the tile set itself.
We’ve been told it’s coming but it may be several weeks away. Just wanted to let people know in case it affects them as we couldn’t find reference to it being included/excluded until it was too late.
Seems great other than that :-).
Dyson, please let us know when you have more info. Thanks!
Prospective buyers can now download non-functional versions of the MTE sample projects to look at. They include all required assets except for the MTE engine file.
Platformer - Basic:
https://docs.google.com/file/d/0B8zoywKO40aiS0xUYWU1TEdxTlE/edit?usp=sharing
Platformer - Angled Floors:
https://docs.google.com/file/d/0B8zoywKO40aicEZDMzhBQklKc00/edit?usp=sharing
Platformer - Sonic Finale:
https://docs.google.com/file/d/0B8zoywKO40aiTE1obmRBQTAyVDg/edit?usp=sharing
CastleDemo:
https://docs.google.com/file/d/0B8zoywKO40aiUXpVTFhjVGd2Z1k/edit?usp=sharing
Good catch; I’ve added flipped and rotated tiles to the list of limitations in the OP.
This is something we definitely need. If you’re planning on adding it in the next few weeks then we’re happy to wait patiently. If not then we need to look at other engines or do it ourselves. Please just let us know and thanks for the speedy response.
I looked into it. I’m happy to say that tile rotation will be included in the next update. This was made possible by the excellent BinDecHex lua library by Time Kelly of Dialectronics. You can see it here: http://www.dialectronics.com/Lua/
Future releases of MTE will include BinDecHex, unmodified, as a seperate lua file alongside MTE. I believe this is legal to do, but if I’m wrong someone please let me know so we can work the problem out.
Tile rotation must be enabled before the map loads. This is done by calling mte.enableTileRotation(true). The performance impact is limited to map loading and will depend on how heavily you use rotated tiles. The in-game performance, so to speak, should be unaffected by the presence of rotated tiles, however the memory load will be increased by some degree again depending on how heavily you use rotated tiles.
Tile flips are impossible. The Corona SDK graphics API does not support image flips, only rotation. Corona Labs’ Graphics 2.0 release will probably fix this in the coming months, but it is out of my control.
Tile rotation AND flipping is coming in the next update! Thanks nick_sherman and richard9 (below) for clueing me in!