I'm currently a student game programmer working on an indie project. We have a team of eleven people (five programmers, four artists, and two audio designers) aboard, all working hard to help design this game. We've been meeting for months now and so far we have a pretty buffed out Game Design Document as well as much audio/visual concept art. Our programmers are itching to progress on our own end.

Each person in our programming team is well versed in C++, but is very familiar with C#. We have enough experience and skill that we're confident that we will be successful with our game, and we're looking to build our own game engine in XNA as it seems like it would be worth our time and effort in the end.

The game itself will be a 2D beat 'em up style game to be released over xbox live and the PC. It's play style will be similar to that of Castle Crashers or Scott Pilgrim vs The World. We want to design the game engine to allow us to better implement our assets into the game as well as to simplify the creation of design elements/mechanics.

Currently between our programmers, we have books such as "XNA 4.0" and "Game Coding Complete, Third Edition," but we'd still like more information on both XNA and (especially) building a game engine from scratch. What are any other good books, websites, or resources we could use to further map out and program our game engine?


closed as primarily opinion-based by MichaelHouse Jul 19 '13 at 14:35

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ There's no question in your post. Start hacking together a codebase and post when you have a specific question. Between your books and the MSDN site, you should have all you need to get started \$\endgroup\$ – michael.bartnett May 17 '11 at 3:27
  • 4
    \$\begingroup\$ You don't even have a playable prototype and you have been working for months? :/ \$\endgroup\$ – AttackingHobo May 17 '11 at 4:03
  • \$\begingroup\$ We don't meet often but we do meet consistently. Not everyone started with us at the beginning, but we have a lot of design work to show for it. \$\endgroup\$ – Glasser May 17 '11 at 4:34
  • \$\begingroup\$ -1, there's no real question here. \$\endgroup\$ – Tetrad May 17 '11 at 16:07

What you need to do is actually start writing your game!

You don't need more resources. It's time to start producing - learn by getting your hands dirty.

Write the lightest-weight engine you can. If you follow this tutorial series until #9 (and since it's written for XNA 2 or 3, translate it in a couple of places to XNA 4.0 using this cheat sheet) you'll have a fully working component framework that gets out of your way. What I just described took me a few hours a day for a week and a half on my own.

Then you can get on with your game. You'll have an engine that takes care of rendering and updating for you so long as you provide an update/draw method on each component you write, so just focus on making your game's content. As you require, go back and hack the engine to bits and make it your own. Among the improvements, I'd recommend replacing its JigLibX physics with Farseer Physics since JigLibX is a dead project.

Reading stuff and writing your game design doc are both helpful but what you need to know is if your game is fun and if it works and a hacky prototype built in a week with a minimal feature-set and rectangles for graphics will tell you more about that than even the nicest game design doc.

Ever played Super Meat boy? It never even had a design doc! To quote the Super Meat Boy postmortem from Gamasutra:

Super Meat Boy is Super Mario Bros. if Tommy and I made it. If we had made a design doc, it would have been as simple as that.

  • \$\begingroup\$ I'm not entirely sure I agree with this. Might be because I swear by the ScientificNinja games not engines post. \$\endgroup\$ – The Communist Duck May 17 '11 at 8:21
  • \$\begingroup\$ I do too. However, the engine tutorial I linked is basically a component framework that gets out of your way, plus component examples to show you the ropes. Consider that this makes my job easier, and now that I'm making my game, I'm taking steps back to make the engine my game's engine. I recognise the issue here though: I don't mean to tell him to write an engine, he just needs something to enable him to finally just make the damn game. \$\endgroup\$ – doppelgreener May 17 '11 at 9:58
  • \$\begingroup\$ Now that link is actually working for me (originally I assumed it was just another 'here's some code for a half crap engine'), I can see your point. So +1, for that link :) I reckon it'll help me too. \$\endgroup\$ – The Communist Duck May 17 '11 at 10:40

I think this post needs to appear.

If you have all your game docs organised, what is stopping you making the game? Why bother with a game engine if you already know exactly what you need to do?

Build the game, and then when you start writing another you'll be able to pull out the reusable bits.

Give it a bit of polish, and you have several decent indie games AND an engine/codebase that does what you want, rather than what you think it should.


Write your game, and you will have your engine.

I'm in the same position as you and your team, I just bought these with the certain thought that they would help us out in our endeavour:

Check them out, and see if they contain solutions to problems you might meet!

(For a complete Table of Contents for the GPG series, look here)


I'd say the team you have is considerably more than resources that most have setting out to do an indie project. If your programmers are itching to get started, then do so! Start implementing the design plan you have now. The best way to learn more is to start doing! You'll get so many more ideas just by working out the finer details.

  • 4
    \$\begingroup\$ I'd argue that 11 people is about 7-8 people too many for a small indie game. 5 programmers means 5 different coding styles, and 5 people adding code, and tons of communication required to keep everything sane. 4 artists means 4 different art styles to coordinate. And 2 audio guys are going to get bored once they've made sound effects and music. Not to say it's impossible to make an indie game with 11 people, but it requires a project manager and leads and good leadership and direction. \$\endgroup\$ – thedaian May 17 '11 at 16:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.