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

Started by
13 comments, last by leiavoia 19 years, 4 months ago
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.
Jetblade: an open-source 2D platforming game in the style of Metroid and Castlevania, with procedurally-generated levels
Advertisement
Re: Derakon.

That pretty much sums it up.

Languages; C, Java. Platforms: Android, Oculus Go, ZX Spectrum, Megadrive.

Website: Mega-Gen Garage

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!
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?
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.

This topic is closed to new replies.

Advertisement