This is my experience so far on making and releasing your own game. There's more to it than just writing code. It's about how you write it and what not to write. And it's about having a good base to stand on to save time. We want to reach the finish line some day. You have a finite amount of time in this life, why waste it? It's the only resource of which you cannot get more.

Get shit done

A very important principle is getting shit done. That means that you focus on the goal of getting your game released instead of creating vast structures that will be able to host whatever game within it. Start small! ONLY add support for stuff that you need. You NEVER know if you will need it in the future or if you really need it in the form you're thinking of right now. Everything evolves and your thoughts evolve alot. Write list of all of your known issues and what you need to do to get the game done. And try to estimate every point on that list. Then tripple the estimation :) ... Know you know what to expect. This can save you from getting bored or frustrated that it'll never get done. 

Start small and escalate

We all have that magnificent game we want to make that is so epic. There's a reason big game studios have hundreds of employees and it is that it takes time. And to embark on a bigass project directly ain't good. I've tried it so many times, got bored and lost my entusiasm. Having alot of half-finished games in my bag. Start on a small game, add support for stuff, make a bigger, add more support and refine the last framework. And do this again and again. Soon you will have a really good base to stand on for the bigger games.

Wrappers

I like having modules in my framework. Something that handles Content, a common way to handle elements in my UI, etc etc. Often I just create a class for the module which just forwards calls from another module. Like the ContentManager in Xna. It loads various resources from the disc with Load<T>(assetName). Let's say you don't really need any fancy resourcehandling right now or just want to get started fast on your game and "get shit done". Then just make a class that wraps that wraps the other class and forwards the calls. And make an interface for all the methods aswell. Why would you make this? It just slows the game down with the extra calls. Well, it's because you just made a layer between the calls of the ContentManager and you main game logic. If you want to load and unload resources, merge textures or whatever, you can manage this within your wrapper in the future and don't need to hassle to rewrite all the code you've put into the main game logic. And if you need to extend your game ot multiple platforms, it's easy to create a new class implementing the interface. This is very useful for storage scenarios and sql on different platforms. Like iPhone, wp7 and android. Examples

• Texture manager
• Sound manager
• Storage
• Scene management
• General highscore module
• Graphical UI game components
• Text management
• Particle system
• Popups, alerts, controls

Scenes views and overlays

A scene can be described as a view. The main manu of a game is a view. And the stage in a platformer is a view. Or in my words, a scene. This is nothing new, but it still is revolutionary if you havn't thought of them before. I think of the view as a main view, which can contain a various amount of overlays. Let's say you're at the main menu. You click highscores and a board pops up. This is a scene overlay. It blocks all touches from triggering stuff on the main menu since you should only be able to interact with the highscores. So we add an highscore overlay. Well, we can only see the local highscores. To see your friends, we must query the server. We decide we want a button that checks at what place we are compared to out friends. When we click the button, we add a new overlay which displays this number. So now we have a scene, with two overlays. Each overlay blocking the previous from handling touches. Get scenes, they simplify sooooo much. You always start making your game logic, testing it and when you come far enough you start noticing the need for a main menu, high score, game over view, lan game view, etc.

UI Controls

Ahh, a very fine component this is and to be fair, it's not trivial at all. Unless you make it trivial. This is an area where alot of time can be put in and nothing will come out at the other end. You want the panels, scrolling panels, textboxes, labels, buttons bla bla bla. I can't stress this enough for this component, KEEP IT SIMPLE and EVOLVE SLOWLY :) ... Get shit done! There's so much dependencies possible to implement. Margins, padding, justification, alignments, etc. If you calculate positions every frame, it will always be drawn correctly, but you might get performance issues on platforms that aren't very powerful (i.e Mobile platforms). No use wasting clockcycles. I would recommend you implement some sort of life cycle with intialization, positioning, etc. And if you change the layout at runtime, Invalidate() the structure and calculate new positions and sizes. Once :) A good post about building game engines: Built here? No, thanks by Bernat Muñoz

Tags: Tips on making your own game