Admirable effort, but punts badly on collision detection (in part 2 if one follows the link). One really needs at least some basic physics engine in even the simplest platformer. Hopefully that’ll be in a future post (box2d?).
Author of the article here. The future post won’t use a physics engine. Physics engines are bad for 2d platformers which aren’t necessarily physics based. I mean if the goal is to make a physics based game (think Angry Birds) then sure, but if the goal is snappy controls like Super Mario, then you’ll fight the engine more than it helps imho. Sliding platforms, elevators and similar things are quite the pain for 2d physics engines. Can’t speak for 3d though.
The next post will be using box colliders with raycasts. Once you have a 2d raycast (might even be enough to just have horizontal/vertical raycasts) you can do even stuff like slopes fairly easily, but the 3rd part most likely won’t get into that. I’ll probably cut it off when gravity/jumping works with static platforms.
Any tips are welcome though.
edit: Just to react to the comment :P
but punts badly on collision detection (in part 2 if one follows the link)
You’re right, I’m not really that happy with the state where its at. Initially I thought I’d make it a one big article, but keeping all the code in sync ended up being a nightmare, which is why I decided to split it up, cut it off at a point where something works, and do the next part in a more conscise manner.
Regarding keeping the code organised, for a multi-part article, why not create a git or mercurial repository - on github, bitbucket or gitlab for example. The code for each article can be in a separate branch which you can link to directly. You’d still need to manage changes made to an earlier stage but that’s pretty straightforward.
That’s not a bad idea, I thought about having a Gist of the finished code in each article. But the issue I was hinting at is with code snippets within a single article, not spanning multiple ones.
My approach to these articles is to have incremental samples with JSFiddle along the way, but all of those are separate snippets, and if I decide to change one thing I have to re-write a lot of the article. I mean the solution to this is easy, not to have 10 copies of the code in each post, but I feel like that’s just making it more difficult to follow along. I guess I should probably figure out the whole code first before I start writing to minimize the changes.
The next post will be using box colliders with raycasts. Once you have a 2d raycast (might even be enough to just have horizontal/vertical raycasts) you can do even stuff like slopes fairly easily, but the 3rd part most likely won’t get into that. I’ll probably cut it off when gravity/jumping works with static platforms.
This sounds great, I’d love to read that. It would be valuable addition to material already out there.
My issue with fixed time step is that you either multiply everything with a constant anyway (at which point dt isn’t any more difficult to use), or you specify velocities in unnatural units, such as pixels per frame (which is super unintuitive to think about). Or am I missing something?
At least dt will always be 1000/60. With variable (and unconstrained) dt, every game logic code part should be able to handle any values of it. For example colision detection should be able to handle large dt caused by long frame skips: you no longer can just pos += dt, then check if entity collides with something — entities may pass through walls, etc.
One of options is to limit dt to some maximum value instead of making it fixed.
Admirable effort, but punts badly on collision detection (in part 2 if one follows the link). One really needs at least some basic physics engine in even the simplest platformer. Hopefully that’ll be in a future post (box2d?).
Author of the article here. The future post won’t use a physics engine. Physics engines are bad for 2d platformers which aren’t necessarily physics based. I mean if the goal is to make a physics based game (think Angry Birds) then sure, but if the goal is snappy controls like Super Mario, then you’ll fight the engine more than it helps imho. Sliding platforms, elevators and similar things are quite the pain for 2d physics engines. Can’t speak for 3d though.
The next post will be using box colliders with raycasts. Once you have a 2d raycast (might even be enough to just have horizontal/vertical raycasts) you can do even stuff like slopes fairly easily, but the 3rd part most likely won’t get into that. I’ll probably cut it off when gravity/jumping works with static platforms.
Any tips are welcome though.
edit: Just to react to the comment :P
You’re right, I’m not really that happy with the state where its at. Initially I thought I’d make it a one big article, but keeping all the code in sync ended up being a nightmare, which is why I decided to split it up, cut it off at a point where something works, and do the next part in a more conscise manner.
Regarding keeping the code organised, for a multi-part article, why not create a git or mercurial repository - on github, bitbucket or gitlab for example. The code for each article can be in a separate branch which you can link to directly. You’d still need to manage changes made to an earlier stage but that’s pretty straightforward.
That’s not a bad idea, I thought about having a Gist of the finished code in each article. But the issue I was hinting at is with code snippets within a single article, not spanning multiple ones.
My approach to these articles is to have incremental samples with JSFiddle along the way, but all of those are separate snippets, and if I decide to change one thing I have to re-write a lot of the article. I mean the solution to this is easy, not to have 10 copies of the code in each post, but I feel like that’s just making it more difficult to follow along. I guess I should probably figure out the whole code first before I start writing to minimize the changes.
This sounds great, I’d love to read that. It would be valuable addition to material already out there.
In case someone finds this via search, here’s a followup thread https://lobste.rs/s/ptucvb/let_s_write_2d_platformer_from_scratch to the next post
I would use fixed time step for simple games. Making everything depend on
dtmay be more complicated for beginners, IMHO.My issue with fixed time step is that you either multiply everything with a constant anyway (at which point
dtisn’t any more difficult to use), or you specify velocities in unnatural units, such as pixels per frame (which is super unintuitive to think about). Or am I missing something?At least
dtwill always be 1000/60. With variable (and unconstrained)dt, every game logic code part should be able to handle any values of it. For example colision detection should be able to handle largedtcaused by long frame skips: you no longer can justpos += dt, then check if entity collides with something — entities may pass through walls, etc.One of options is to limit
dtto some maximum value instead of making it fixed.Lots of large AAA games are ok with variable timestep, however. AFAIK, Quake uses it. Seems that bug with impossible mission in GTA 4 on fast PCs is related to this. Quake III, however, has only rounding issues due to variable time step.
In this case variable time step will not make things more complicated, I think.
(I’m not an expert in games and I never written even finished platformer, just tried to do that).