Jump to content
  • Advertisement
Sign in to follow this  
Codejoy

Embarking on a new game...2d platformer pitfalls?

This topic is 5063 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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??

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!