YES! i want to make a mario-like game,how?

Actually, the game design document shouldn't involve classes unless the technical innovation is integral to gameplay. Game design is just the rules of the game (mario can jump, kills turtles he lands on, breaks bricks with his head, etc.).


More generally, if you don't know where to begin, you definitely don't know how to finish. Start smaller.

Start with being able to load an image and display it on the screen.
Here is an excellent resource.

I don't know that you need a GDD for such a small project. The primary goal of one is to communicate your game with other people. You should write down your ideas, yes, but a GDD is more formal than I'd think you'd need right now.

Of coarse there's always the technical design document... but I've actually never seen one.

Platforming Game Basics

Make a design similar to this one.

ive already made a tetris.. so i think il now go for a mario game..so where will i plan the classes?? when coding??? when??

Quote:

Original post by macmoy so where will i plan the classes?? when coding??? when??

Well, how did you do it when you wrote Tetris?

If you're not sure how to proceed with Mario, try scaling back. In fact, there's probably no reason to do anything more complicated than Tetris; instead of trying to create something more elaborate, you can just focus on creating something of similar complexity to Tetris, but with improvements in coding and overall design. (How about Space Invaders? That would be - IMO - considerably less involved to implement than a Mario-type game.)

Or maybe asteroids, since that typically involves vector based position/velocity and circle-to-circle collisions, both of which are not very hard concepts, but neither are present in Tetris. Both are very useful for a broad range of games.

I actually just registered in the forum guys, but i want to thank you for all the advice your giving the poster, as I'm going to use it too! I've been stuck in a rut of not proceeding due to overly complex projects, and i had forgotten about KISS.

Only problem with mario is that you get into what has turned out over the years to be a big problem for new game-developers [programmers at least], which is taking up projects that rely on content volume. Lets face it, us programmers hate to make the sprites for our games [which is why we so often team with artists]. A game like tetris has very little content that needs to be created. A game like space invaders has very little content. A game like 'Mario' has all those levels/tile sets/animations/characters/sounds/etc, which represent a point of frustration for many.

Mario really isn't a tough game if you can focus all on the code portion of the project. It's a pain in the butt though to make all those levels, at least for us programmers, which is exactly why low-content games make such great projects for programmers looking to sharpen their skills.

As far as a game document is concerned, it's usually a bit more a multiple-tiered thing. 'design document's, at least in my experience, rarely have any code-relevant information in them, instead having a very detailed specification of exactly how everything in the game works [logically, for example, the equations that will dictate mario's jump height limits and how his jump height is determined]. There is usually a separate document dictating the layout of structure with respect to how the code will be layed down. Both are pretty important, and the logical game design is definitely going to be needed to write anything technical. I'd recommend that the game design be completely finished before anything technical is done on the game, since changing something in that document will likely result in huge changes in technical descriptions/code.