How to layout the code of a simple game?

Question

I'm coming from a background mostly developing websites, and maybe some simple form-based apps. MVC works well for that, but I don't quite see how that's applicable to a game. So how do you guys do it?

I'm developing with Qt and OpenGL, if that's relevant. I have a QGLWidget which I'm basically using as a central hub at the moment. Should it pass off input to a Player object so that it can handle it, or should it control the player directly? Should objects draw themselves, or should there another handler for that? Basically, what goes where? Who handles what?

Links to relevant articles, answers to some of these questions, tips, or file structures are all appreciated. I don't really care about how to program it, just how to modularize nicely.

Thanks :)

Answer 1

Well, the cliche starting point for game development seems to be gamedev. There are a number of tutorials and articles to start from, there. It also has quite an active forum. There is also book, "Programming Linux Games" (I assume through Qt that you're using Linux), but I believe it costs money. A number of books, however, can be found on the internet, and that may be one of them.

There's also the "black art of game programming", a wiki with truly terrifying chapter titles. Here is a link to a particularly relevant chapter, though of course you can view the whole thing: Chapter 2.

Hope this helps, - Agor

Answer 2

It's probably more basic than you are looking for, but I have been learning with pygame, and their is a book by apress about it that teaches basic gamedev if others are interested.

Answer 3

Look at this tutorial:

http://ezide.com/games/writing-games.html

It is written for python and explains MVC for games very good.

Good Luck!

Answer 4

I almost want to scream duplicate of my question but that would be lame. :)

Anyway look through those answers. I think if you don't have much experience in game dev, jump into it. Don't think so much about the planning stage, just worry about getting something on the screen, get something working, then refactor and mess with your code (without changing your output) and you'll figure out what works and what looks best.

I am a big fan of writing something that works, then going back and refactoring. You can learn a lot that way, and you spend less time going in hypothetical circles trying to figure things out in your head and getting nothing done. (And not to say that that's what you'd end up doing, maybe you're an excellent planner, but I personally have done that plenty of times.)