Sign in to follow this  
Codejoy

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

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
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
My personal attitude towards music is that it should be worth listening to, but ignorable as necessary. That is, with some games I'm quite willing to stop what I'm doing and let a track loop a few times so I can enjoy the music; however, it doesn't get in the way when I just want to play the game. Some music, though, is irritating (generally, high-pitched or with bad instruments, and very repetitive) and I can't ignore it no matter how hard I try. Unfortunately, it's the latter that tends to get stuck in my head.

So to sum up, grand compositions are fine. It's the piddly little 15-second jobs that are annoying.

Share this post


Link to post
Share on other sites
In all honestly and experience, common pitfalls arise when developing games on your own engine. If you start to notice that you have to keep on changing aspects of the engine so you can get it to do what your game needs to do, don't fall into the trap of modifying the engine to meet the needs for your specific game. Either modify the game to go with the engine or modify the engine itself so the new code can be used generically for any game. I say this because I'm working on my own engine as well, and will start making games with it. I've ported some very simple examples over to it already and discovered additional features I needed. Instead of simply adding in the features I need, I have to take into account how I can make it so the code is reusable, so the engine doesn't turn into a simply cut-and-paste piece of work. If you can pull off keeping your engine as robust as possible, it will definitly be more useful in the future. I hope this helps and goodluck!

Share this post


Link to post
Share on other sites
Thanks again for the info. Ive pretty much decided that I will probably develope the core game code over two phases:

The level editor, for ripping building levels, attributes AND adding objects and other encounters to each level.

And then that will be read in by the game engine, and all the objects etc will be created, spawned etc..according to whats in the level file.


Then all that has to be done is defining the ai and behavior of all the enemies, player character, and objects in the game. This will be nice cause the game engine im using does away with state machines and uses function pointers for all this, quite nice. very slick.

Thats of course an abstract plan of attack, it dosnt take into consideration the tweaking of the UI, the objects later in test phases, the levels etc.. and then the final phase (polish phase) is where I will inherit from the game objects to handle things particular to this device for zing: like blended sprites where needed, and the drawing of scaled sprites etc.

Sound like a good plan of attack?

Share this post


Link to post
Share on other sites
I would get a working model first before you get a level editor going. I mean if your editor is based on certain principles of the design and the design changes, you then have to change the editor accordingly. So i would get a hardcoded working model with a little art, a little sound, a little UI, and little AI, and a little input. If it works, then scale up. If you do all of the, say, art first, and the game changes ("Guess what, we're only using 32x32 tiles now!"), you might throw out a lot of art. That's true with any of the aspects of the development. Just a warning in advance.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this