Embarking on a new game...2d platformer pitfalls?
Author
Okay so my little dev team wants to attempt a platformer game next, we already successfully pulled off a puzzler (tetris clone) and an action puzzler (game like zoop). now we want to attempt a platformer. We are all very skilled, and the team itself consists of two programmers, and an engine programmer...in fact its his engine we will be using for a 2d sidescrolling platformer.
Before we start this project, id like to ask what are some common pitfalls to watch out for in programming/designing a 2d, side scrolling platformer, if any can be named that is. Just like to know what im getting myself into (i have a good idea already, and our engine is pretty tight and handles side scrolling games, though i ported it to a mobile device and will have to fix up my port errors other than that, the technology should be tite)
so perhaps this belongs in another forum as what im asking isnt just programming, its almost management, how do you handle the production process etc...though this is with a small team (one graphic designer, one 3d artist, three coders (engine, lead, and support)
So any thoughts/comments/suggestions/questions/links would be great,
thanks.
Shane
The questions I see here most frequently are about motion (including the affect of gravity). The usual answer is to make all motion time-based -- units/second rather than units/frame.
I would agree with JohnBolton. One of the hardest parts is getting the movement right. That includes physics with time based movement and gravity and all that. Proper world interaction is tricky too. The problem i currently have with my platformer is how to know when the player is on the "ground", what constitutes "ground", and how to make him walk, run, and jump on/off of sloped terrain. If everything was a square tile, it would be simple.
The other major gotcha is collision detection. You'll have a variety of object types and a large open space (probably). You'l have to come up with clever ways to sort out collisions between spaces, types, and then react. It's a very messy system no matter how organized you make it. If you are really clever, you can put your collision detection and response inline with the movement code and do both at once. Also, strive for time-independent collisions, or detecting collisions with movement involvedl, otherwise you'll skip and miss fast objects.
Eventually you'll run into a production problem with adding content from artists and designers. You'll have to make things flexible enough that you can drop in graphics from the artists at a whim and they should not have to rely on the programmers to do it for them. Along the same lines, you should probably create a simple world-editor for the other members to work off of.
The other major gotcha is collision detection. You'll have a variety of object types and a large open space (probably). You'l have to come up with clever ways to sort out collisions between spaces, types, and then react. It's a very messy system no matter how organized you make it. If you are really clever, you can put your collision detection and response inline with the movement code and do both at once. Also, strive for time-independent collisions, or detecting collisions with movement involvedl, otherwise you'll skip and miss fast objects.
Eventually you'll run into a production problem with adding content from artists and designers. You'll have to make things flexible enough that you can drop in graphics from the artists at a whim and they should not have to rely on the programmers to do it for them. Along the same lines, you should probably create a simple world-editor for the other members to work off of.
Author
thanks for the response guys, this is the kind of stuff i was lookin for.
Keep em coming.
The tools we have now is:
A level editor, which lets me specify the layers of a level (layer 0 being the attribute map) the other layers are the main play layers, and various scrolling layers. It can load them in as .bmp, rip them and spit them out as our own binary level file. Works well.
The sprites can be dropped into the code almost, i still have to code the objects and tell them to ->Load("Sprite.obj"); which loads the graphics and attributes, bounding boxes etc...
for a platformer, im thinking the only other editor I might need is a level designer, which actually lets us populate the worlds we make with the level editor with enemies and objects etc... sound right am i missing something??
Keep em coming.
The tools we have now is:
A level editor, which lets me specify the layers of a level (layer 0 being the attribute map) the other layers are the main play layers, and various scrolling layers. It can load them in as .bmp, rip them and spit them out as our own binary level file. Works well.
The sprites can be dropped into the code almost, i still have to code the objects and tell them to ->Load("Sprite.obj"); which loads the graphics and attributes, bounding boxes etc...
for a platformer, im thinking the only other editor I might need is a level designer, which actually lets us populate the worlds we make with the level editor with enemies and objects etc... sound right am i missing something??
Maybe you should integrate the sprite and trigger placement into the level editor. This will not only prevent difficulties with having to maintain two separate set of tools integral to the game, but also allows for a quick preview.
Author
I could proably extend the level editor to do that, I have to really bone up on my MFC.
Quote:Original post by Codejoy
I could proably extend the level editor to do that, I have to really bone up on my MFC.
Ever considered using .net? It's really nice for UI intensive apps. Unless you cannot use it due to engine issues (I also use MFC because it's a pain in the butt to get interop with C++ working, esp. without the monkey work of creating managed wrappers...) it's really worth a look.
Good luck,
Pat.
At the recent Game Developers Conference Luis Barriga produced a cracking little presentation on 'The Anatomy Of A Side-Scroller'. I'd reccomend you read that.
I got it from the archives at http://www.gdconf.com/archives/2004/index.htm
I got it from the archives at http://www.gdconf.com/archives/2004/index.htm
Audio (music and sound effects) is an important part of most games. Normaly, the player will notice a lack of sounds, but not realize anything when sound is part of the game.
I would like to also mention music.
I learned in my last game to make sure the music doesn't dominate the game. It should be a nice steady beat in the background, something to get the player in the mood for dancing!
Its usually best to stay away from anything that distracts the player - such as mindless head-banging music. If the player is forced to switch the music off - your efforts are wasted. Also, to prevent repetition, go for a play length of roughly 2-minutes. For any fast paced "boss" fights, you can drop to 1-minute.
For good examples, listen to the music from Super Metroid, the RPG-CastleVanias or even adventure games such as Monkey Island.
And remember - keep your tracks simple!
I learned in my last game to make sure the music doesn't dominate the game. It should be a nice steady beat in the background, something to get the player in the mood for dancing!
Its usually best to stay away from anything that distracts the player - such as mindless head-banging music. If the player is forced to switch the music off - your efforts are wasted. Also, to prevent repetition, go for a play length of roughly 2-minutes. For any fast paced "boss" fights, you can drop to 1-minute.
For good examples, listen to the music from Super Metroid, the RPG-CastleVanias or even adventure games such as Monkey Island.
And remember - keep your tracks simple!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
