How to create a clean application entry point

int main()
{
// Implement game here
}



OK, OK, that's a bit snarky.

What you're after has nothing to do with an entry point; you want a complete game framework. I suggest looking at existing frameworks (XNA's a decent one) for inspiration.

The real problem with your request is twofold. First, we know nothing about the requirements of your actual game. Second, you're asking for a general solution when you don't even have any specific solutions to generalize from.

Don't make the mistake of trying to solve a general problem without knowing how to solve specific cases. Start with an architecture that makes sense for one game. Then do the same thing in isolation for a second, and third, and maybe fourth game. As a wise man (Neil Kirby) is fond of saying: you cannot generalize until you have at least three examples to look at.

After you've solved this problem specifically a few times, you'll start to recognize general patterns and repeated ideas between your implementations. It is at that point - and that point only - that you should start thinking about writing generalized frameworks for building new games.


And even still, I bet you a dollar you'll build a general framework, start a new game in it, and immediately find at least one serious shortcoming in the framework that demands that you make some fundamental change. It's the way of things. Make games, not engines ;-)

Hi again,

Thank you for answering my question. I'll start planning a game and build my game's framework for my specific game. And I now realize entry point was a bad choice of words lol.

The specific game I'm making is a 2D top-down space shooter game similar to asteroids but with some other things like AI and upgrades.

I realize my mistake is probably that I've been spending most of my time studying other people's frameworks rather than building my own and experimenting. I've been studying C++ for about 2 years and other game engines for about a year as a hobby but I still haven't created anything notable.

Thanks again!

So... why do you feel like your solution is a "mess"? What would you like to change about it?

Do you have any concrete ideas about what needs improving, or just a gut feeling? (It's fine to have gut feelings about design issues by the way - but it's much more useful to turn them into action points.)

Without seeing some actual code it's hard to think of any specific advice I could give you; except maybe this: if you feel like something could be improved, save off a copy of your code (or use a branch in your version control system; you are using a version control system, right?) and go experiment with fixing it. If you like what you end up with, throw away the old version and consider it a good learning experience. If on the other hand you don't really care for the new version, throw it away instead and consider it a good learning experience. Either way, you win!

I'd say it's more of a gut feeling, maybe that just comes with inexperience though. I feel like my code is messy (not my actual style as I'm careful with that, but the design) compared to other people's I've observed and I always feel like the code I'm writing is bad and not proper design, but again I think that may be my inexperience with actually writing my own code.

Another question I have is how do I really plan a project? Past attempts were in a notebook and ended up looking ugly and unorganized. I'd love to be able to plan my projects and then implement them with a clean style and not get overwhelmed.

And I'm not using a version control system as this is pretty much one of my first projects I'm actually writing myself, and I'm not planning to really release it but it's more of a learning experience for me. Do you have any suggestions on a good version control software?

I'm fond of Mercurial. There's no need to make your source available or release it in general; you can (and should!) still use version control for private projects.

As for planning... it really just boils down to experience. Once you've written a certain critical mass of software, you'll start to have enough experience to draw upon to help guide your decisions and know what kinds of challenges to anticipate. Until then, it's really hit or miss, because sometimes you can predict what's going to crop up, but most of the time you'll be blindsided by stuff partway through.

Unfortunately, the only way to get better is to practice :-)

Could you suggest any tools for planning to me if you have any? I've just been using a notebook and drawing out hierarchy diagrams and method lists.

I've never personally used any tools beyond a pen and paper myself.

Alright. So when you're planning what kind of things do you write out and plan?

Sorry for so many questions, I'm very motivated to learn the ways of proper game development!

It really depends on what I'm working on. There's actually very little that I sit down and plan in detail anymore; at most I'll write down some requirements and maybe - maybe - sketch out some simple flow diagrams of how I expect different pieces of the system to interact. But that's about it, and only on the really complex/tough stuff.

I've been doing this for so long that I can intuitively put together pretty good designs for just about anything I need to work on, just in my head; and then I do some implementation, decide if I like what I came up with, and generally end up tweaking or refactoring pieces a few times until I like the results. I have enough software under my belt that I more or less just feel out the likely challenges and sticking points, and when I can't see them immediately, I experimentally play with the possible implementation routes - again all in my head - until I feel like I have a good sense for where things are going.


I'm afraid that this isn't particularly useful to you, though :-/ Honestly, the best advice I can give is to just do what feels right until it starts to come naturally, and make sure you course-correct along the way so you don't get off into the weeds doing weird stuff just because it's convenient. Do that for long enough, and you'll hopefully be in a similar position :-)

Ok, thanks for taking your time to reply to my questions.