How to create a Platformer

Solar2D General Questions/Discussion
#61

I tried that Dusk demo but it didn’t work, an error in one of the functions. Probably not hard to fix but likely not worth it as you can see the code from the link you posted. It looks like it is just a check for crossing (vertically) a tile boundary - if you do and the tile below is solid, then it returns a collision and moves you back up out of it. Not actually very different from what I suggested above. But it is similar to raycasting in that it will detect a collision along a line rather than being a single point check (but his appears to be a general check, and since it is just line VS line (one line being the player line of movement, the other being the top of the tile), it doesn’t translate to slopes and undulating terrain very well. Before I switched to a pixel-base collision routine I tried something similar using pure trig and stuff, but there are a few annoying gotchas and bugs that are hard to crush, and in the end it ended up being less flexible and harder to set up than my current system anyway :frowning:

As for the thick map, as mentioned it is to test a lot of stuff. I’d envisage a real level probably containing maybe 6 layers max, although it does depend on how many graphical niceties you have (for example, parallax layers or not, and how many you use for the ‘player’ layer - I’ve used anywhere from 1 to 4 for that in the past). But the basics would be:

  • Level graphics

  • Collision tiles

  • Object positions

That’s far more reasonable I think :slight_smile:

#62

Excellent responses @rakoonic. I’ve finally found another true custom-physics-engine enthusiast! :smiley:

@jerejigga:

I am currently using Dusk to build a very large-scale metroidvania platformer RPG hybrid. I’ve rolled my highly flexible physics engine, and use a lot of Dusk’s methods to implement complex functionality. Dusk is great for quickly getting a map loaded for prototyping, but is still extremely scalable and very fast.

Here’s a little of what I’m using Dusk for:

  • Physics. For this I query tiles based on the pixel position of the object and check for properties imported from Tiled to decide whether the player should collide. My physics engine even works offscreen seamlessly via some of Dusk’s core methods.

  • Custom objects. I’ve created an extensive registry of object types (custom objects that are built when their associated object comes onscreen) and mixins (modular code that adds functionality to object types) and can swap them around and combine them. I use Dusk’s addObjectListener function to tell me when an object goes onscreen or offscreen and build and create the custom objects based on that. I can now do ridiculously random things like create a ladder (object type) which displays an icon when you move near it (mixin), moves on its own with AI capabilities (mixin), and damages you when you touch it (mixin).

  • Camera movement and parallax. This is a big relief not to worry about. Dusk does all this internally. You just have to specify the parallax ratios and tell Dusk to track the player, and Dusk handles the position of the camera, tile, and object culling.

I find Dusk to be really useful for being a stable base on which to code the rest of my engine. Dusk lets me avoid worrying too much about the map and functionality related to it and worry more about getting the actual game to work how I want it.

(As I read over my post again, it sounds a lot like an ad - I am the developer of Dusk, after all - but believe me, it’s not intended to be one. It’s intended to be a post to detail some ways in which Dusk helps greatly with coding a metroidvania. I definitely wouldn’t code a whole new tile engine because it might be better tooled to platformers - that’s Dusk’s point. It’s not geared towards any particular type of game. It just provides the base on which any type of game can be built.)

  • Caleb
#63

Heya Caleb :smiley: Great work on the engine, but I didn’t manage to get the examples that jerejigga posted earlier - is there a newer version I’m not aware of or something?

I do kinda re-iterate that I don’t consider my own stuff a physic engine, just a collision engine. I think it is a useful distinction so people have an idea of the capabilities and don’t go asking for angry-birds-in-a-platformer. Bluergh!

And don’t worry about selling your own engine, and you can probably clear up any misrepresentation I did above as I’m not fully up to speed on your engine :slight_smile:

I do find your comment about Dusk having an addObjectListener function to be a bit odd, but then I never fully embraced the whole event-driven model for gaming, particularly simple games like these, as it seems clunky and imprecise. I much prefer a simple, linear game engine that handles everything in a specific, guaranteed order.

From what I gather, your ladder example is that it creates the icon *as part of the engine*. That also seems strange to me, as I’d have that abstracted away from the core engine. I guess I compartamentalise more than you. My set up is, from top to bottom, something like this (so the game engine sits on top of the seperate collision engine which sits on top of the seperate level data:

Core game:

  • Game engine - including movement code (which uses the collision engine, but the collision engine does not handle actual movements itself)

  • Collision engine

  • Loading level ‘engine’ - really by this I mean the container for the level data

Visuals:

  • Game-specific drawing ‘engine’

  • Level drawing engine

Note how the two things are entirely seperate. Things like the icons etc are dealt with in the game-specific drawing code. I myself have handled these sort of things in different ways (although the ladder for me has so far just been part of the normal movement code, there are ladder ‘tiles’, not a ladder entity). The icon could either be a normal sprite-based entity which, in its update code sets visibility based on proximity to the player entity, or (which I prefer) is a data-only entity based on rectangles set up in Tiled (I prefer this for accurate sizing, I use the same thing for doorways etc). The icon would appear when my ‘zone’ entity registers the player is inside it.

At the end of the day we may well have very similar set-ups, just with different names.

I’m curious though, do you generally have collision data tied into the *visual* tiles or, like me, have an entirely separate invisible collision layer?

Also, does your collision code support slopes etc?

One thing that is causing me headaches is proper lift behaviour. It is one thing to have a simple horizontal slab that moves around in a space where you don’t touch anything, but I want lifts that are basically just a mobile sub-set of tiles (so can have slopes etc), and that can move across other parts of the normal level, resulting in you being pushed around and potentially crushed - I’m mean like that :slight_smile:

I haven’t quite found an optimal solution as it often requires recursing through the various collision layers :frowning:

I should add, your final comment about creating a new engine per game-type simply shows why making the visuals seperate from other modules (particularly the collision code) is the way to go. In the demo link I posted above, the drawing engine is exactly the same regardless of whether it is the side-on or top-down part of the demo, only the control and collision changes (there’s just a seperate module for side-on and top-down collision).

#64

My game engine is completely separate from Dusk. Object types and mixins are abstracted away from the actual map code. I really sort of have two engines - one is Dusk, for the map loading, culling, properties, etc., and the other is the actual game, for the movement, behaviors, objects, etc. All the object type code is part of my secondary game engine, not part of Dusk. Dusk only handles drawing the tiles and telling me when events like object drawing or erasing happen. I then hook into the Dusk base to do what I like with my code.

I do add collision bodies straight to tiles - it makes for a much cleaner result IMO, and it’s easier to build maps with. For example, I might have a wall tile which the player should collide with. I set the “has a solid on the left side” property in Tiled, then I’m assured because of my physics engine that every time there’s a wall tile, the player should collide with the left side. My physics engine even handles flipped tiles, so you can use say that objects collide with the left side a tile, flip it, and objects will automatically collide with the right side. I understand that everyone will have their own approach to things like this (and I have used separated collision and display layers before), but for me, automatic physics tiles that I can just paint onto the map and be assured that will work every time is my personal favorite approach. My collision code doesn’t currently support slopes, but only because I haven’t needed them so far. The capability is there, though, as I use a pseudo-raycasting kind of technique.

I think your statement about similar setups may be correct. Your 7th paragraph (about your approach to what I call object types and mixins) is just about exactly what I’m doing, just instead of using separate objects for added functionality (like your data-only “zone” object), I have object types to create the basic object (the graphic, for example) and mixins which add added functionality. Mixins add directly on to my objects (so, say, a doorway with added “zone” functionality to tell when the player is near) and work in a “stacked functionality” way. So as I mentioned, I can have a ladder (which is an object type for flexibility - “ladder” is a bit of a misnomer; a “ladder” in my game engine just means something the player can climb vertically, so vines, grating, etc. It was the simplest word for what I was looking for) with a lot of added functionality that may not even be related to the object. Though that seems useless, it makes complex objects easy to make. For a real example, my context-sensitive-sign object uses the “sign” object type combined with a proximity icon [displays “press context sensitive button now” prompt], the dialog mixin [add a method to the object to display a dialog on demand], and the context-sensitive-action mixin [call a method on the object when the player is near and the context-sensitive button is pressed]. The result is a nice context-sensitive sign which displays a floating icon and displays a dialog when the context-sensitive button is pressed. By separating the code like this, the engine remains modular and really quite awesome.

  • Caleb

P.S.

and don’t go asking for angry-birds-in-a-platformer. Bluergh!

Oh… man… nightmares will haunt me now. :blink:

P.P.S.: Having read a couple of posts above again, I think we may be using the same approach to physics… I ripped my approach directly from this Sonic guide!

#65

Yeah I think we are both on the same wavelength really, it was just terminology differences.

I don’t know if that is the exact sonic article I read, but I’m guessing it could be, there can’t be that many detailed docs about our favourite blue hedgehog!

#66

Lots of good stuff here.

To speak briefly to mixins, these also go by the name “components”. A good (and influential, I believe) article on the same can be found here: Evolve Your Hierarchy

(There was a question elsewhere on the forums about components in Corona, looking for examples, though I forget where…)

#67

That was a nice article, thanks StarCrunch. The only area I think components breaks down, and this is mentioned in the article itself, is that when components require access to others, there’s no point in going through the component manager as it causes slow down, so in the end components end up having direct access to each other.

This suggests to me one of two approaches:

A generic ‘properties’ component, that is simply a container for all object values (naturally you only add in values as needed), so each component can reach in and find what it needs, or (and?) a dependency list of components, should it be necessary.

I do like the idea, and I already tend to break my code up much more than having a lumbering set of heirarchies, so I’m going to see how closely my own mess approaches this, and if I can move to it. I’m a big lover of libraries, so having more just for entities etc seems like the kind of thing I’m down with.

#68

I have been following this thread all weekend. Wow! This is a whole lot of great reading material and food for thought!

Rakoonic, I love your ideas about separating the game UI from the game world such that the game world is actually a fraction of the size of the corresponding UI. The first several games I developed were all written for TI graphing calculators, specifically the TI-80, TI-85, and TI-92. They were limited in both speed and memory but by leveraging matrices, basic math, and pre-rendered graphs I made the UI so fast that the kids playing my games never knew there were performance limitations. I spent over four years, though, fine-tuning my skills. I didn’t start out doing things so fancy and so I was limited initially to a dice game and a simple maze game. My final TI game was a top-down dungeon crawler / RPG that included lots of fancy animations.

I am still in the process of writing my first Corona SDK game, a puzzle game, and although it’s coming along very well I still have a lot to learn. That said, here is what I am thinking now in regards to the first platformer that I will make (eventually). Although I have been playing with MTE more than Dusk, I will now switch to Dusk since it’s obviously working well for Caleb. I plan to use Tiled to define my worlds/levels and store the physics data in object layers. I plan to draw the “physics bodies” in Tiled so I can see them (like how Rakoonic does it), as opposed to storing them as tile properties (like Caleb does it). As a long-time Java developer I am very familiar with event-driven programming, so I really like and plan to use Caleb’s method of creating and destroying objects (e.g. enemies, ladders, doors, etc.) as they enter and exit the viewable area (or near the viewable area). Here is a screenshot of a POC I did using MTE a while back. The player and the physics bodies were generated by my code based on placeholders in the Tiled map.

That covers a lot of things but I am still unsettled about the collision handling. I read a good chunk of the Sonic article and looked at the Sonic demo in MTE that uses the techniques described in the article (for the most part). I think I would have to do a lot of research and trial and error to create a “collision engine” that behaves the way I want/need. Caleb, would you be willing to share your platformer framework code? I watched your CoronaGeek interview from a while back so I know you don’t want to be stuck maintaining your work for the public. I would be totally okay, though, getting an archive file that provides just enough functionality for me to get going. I have no problems digging into the code and making changes myself as needed. (In fact, I have made some changes to my local version of your awesome CBE library to better meet my needs.) I am just looking for a jump start.

Rakoonic, at some point in the future, it is highly likely that I will use the approach you described. In fact, at some point I plan/hope to create a multi-player game and I will absolutely need to use an approach that is at least similar. I am just going to need to work my way there. :wink:

#69

haven’t followed and read everything here, but here are my two cents: Do not work with existing physics! Write your own movement, collision detection instead. This will save you a lot of trouble and you have 100% control over all aspects regarding movement and collisions.

#70

@d.mach That seems to be the prevailing advice. Thank you for contributing to that!

I have been asking around the forum in other places and some people have pointed me to the following two non-Corona tutorials on creating platformers. I haven’t been able to sink my teeth into them yet but I wanted to share them with the rest of y’all so you have them. The Youtube link is to a complete series on creating a platformer using Java. The developer who provided the link says he used it as the basis for his Corona SDK collision engine.

http://www.wildbunny.co.uk/blog/2011/12/20/how-to-make-a-2d-platform-game-part-3-ladders-and-ai/

https://www.youtube.com/playlist?list=PL-2t7SM0vDfcIedoMIghzzgQqZq45jYGv

#71

@rakoonic Correct me if I am wrong, but don’t you need Corona physics bodies in order to use Corona raycasting? Does that mean you do use the bodies but just don’t use them for collision detection?

#72

@jerejigga - I do my own raycasting. Basically if you have a single pixel-perfect collision detection routine, you just run it in a line (ray!) until it either reaches the end of its distance, or at the first (solid) collision it detects. It isn’t massively fast to do this, which is why you limit using it a lot for the player character (which requires 3 or more for decent effects).

Enemies just use a couple - left / right and down. You could probably even limit this to one, by having them alternate their rays between frames, although naturally you lose accuracy. Actually you’d probably always want a down ray, otherwise it’d look funny going over slopes, but you could cycle the horizontal rays between all enemies, as left and right values don’t change really (although you’d need to make sure you check far enough ahead for the missed frames so it can’t go through walls, and also with any biggish vertical height change you’d have to do a fresh horizontal check).

So say you have 20 enemies, and you check horizontal and vertical each frame - that’s 40 rays per frame just for the enemies. Might be a lot, dunno :slight_smile:

But now say you have 20 enemies, they always check down, but each enemy only checks horizontally every 5 frames, cycled accordingly (so only 4 enemies check each game frame) - now you’ve dropped from 40 rays to 24 - almost a 50% drop.

Mostly though, I’d just get a game up and running, and then work out what (if anything) needs to be optimised.

#73

Regarding collision detection - if you are just going to use squares, IE a tile is either fully solid or not, then the collision detection becomes extremely quick and trivial to write - you can make a loooot of assumptions and shortcuts.

I’d probably start with that, as at its most basic it differs somewhat from collision detection using slopes:

  • Tiles are solid / nonsolid completely. Apart from the assumptions, the collision code works with rectangles / squares (IE the player is a rectangle, colliding against square tiles).

  • With slopes, it makes more sense that you move to a simple axis-aligned raycasting model. This method often does have certain anomolies for collision detection, and certain cases you’ll want to avoid, unless you want to end up with super bloaty/slow collision detection.

However, nearly all of these odd situations are easily avoidable by level design, and in fact most of these odd situations won’t actually crop up under normal design situations, as they represent extremely bizarre set ups (one common example is a flat floor, and a ceiling that slopes down gradually to the ground - you’d likely never want *collision* data set up like this, although visuals is entirely seperate of course, because once you get to the part where the ceiling is closer to the ground than the height of the player, you wouldn’t be able to enter it anyway. Essentially you should never be able to crush yourself to death simply by walking along the ground into a narrowing corridor).

#74

Hi there!

I’m going to be brief: everything you need to know when programming your own tile based platformer (without Box 2D) is in the attached pdf!

Happy reading! :slight_smile:

#75

Hi @jerejigga:

In a bit I’ll be releasing Dusk 1.0, and there will be some more complex non-Box2D physics samples (Link in a platformer, anyone?) in it. My physics engine was a commission from a Corona developer that I was paid for, so I don’t really feel comfortable sharing it with everyone at this time. When the Dusk samples come, though, there will be plenty of physics behaviours to hack and examine.

Also, @thomas6’s guide looks good!

  • Caleb
#76

Hi!

Always willing to share my platform physics code. Been wanting to do a tutorial for a loooooooooooooong time about that.

#77

@CalebP

I totally understand!! As a side note, I think it’s awesome that you are doing paid work already! My first paid development work was in the area of $1 per game. I imagine you are getting a lot more than that! :slight_smile: You do great work and totally deserve it.

Regarding Dusk 1.0, I am very much looking forward to it! Like I’ve said already, most of my focus so far has been on MTE. Presently though, I am soaking up general information on Tiled based games including the amazing info in this forum topic. Once Dusk 1.0 comes out, I plan to jump right in! I am very much looking forward to the revised API, improved documentation, and the “physics” samples you just referred to.

@thomas6

Thank you for sharing the PDF!! Obviously it’s based on Flash, but DANG! This PDF contains the best documentation on creating a tiled-based game that I have ever seen! I just read the first few pages so far and scanned the rest but it looks quite thorough. I am primarily a Java developer and have done lots of JavaScript. Flash’s ActionScript looks very similar so I should have no problem adapting this to Corona/Lua. Awesome stuff!

#78

Hi Caleb (and others),

Yes, that PDF is pretty awesome, I know :wink:

#79

@thomas6 You mentioned sharing your platforming physics code. Is that something you could do right now or is that in regard to writing a tutorial and, presumably, doing some clean-up/refactoring first? If it’s something you can share now, I for one would certainly love to have access to it, tutorial or not. I love looking at other people’s code to see how they do things. I am sure that many other people in this community would really enjoy and appreciate seeing such code too.

#80

Hold on. I just posted my code, but decided to delete it because it was way too chaotic (and the code formatting was all over the place). Let me do a quick clean up first. Be right back.