Allegro Vivace – Epilogue
Well done for getting this far. But now, the bad news: reading only this tutorial won't be enough!
Firstly, we'd recommend messing around with the code you assembled in this tutorial (far more than you've been urged to do already); try to make it your own. Things learnt by experience aren't easily forgotten!
This wiki also has several more in-depth tutorials & guides. Give the ones that interest you a read.
Additionally, Allegro's example programs are a great resource for learning how to use the library, as they tend to each focus on one detail and give you a working example in a straightforward way. As with this tutorial, you should absolutely mess around with their code, seeing what else you can make them do.
Start small. For goodness sake, start small! Don't aim to create a complete game at first; begin with the parts that make up a game, like making things move, responding to user input, etc. just like we've done in this tutorial. You'll note the huge amount of code that went into making even a simple space shooter!
So, moving forward: the games you go on to create should be simple, but they don't necessarily have to be clones of Pong or Tetris (though implementing either of those games is another fantastic exercise for beginners). Otherwise, try to think of a fun game mechanic and implement that - and when the core gameplay is done, only then should you focus your attention on the details and polishing.
A common mistake is to try to create an RPG (or worse, an MMORPG) as your first serious attempt at a game. Don't do this! We've seen countless examples of novice programmers buckling under the weight of these genres in the forums. Massive projects are often just too hard to take on by yourself without a good degree of experience; the newbie's eyes are too often bigger than his stomach, and even if you've got the motivation to keep going when the sheer scale of your project becomes apparent, you could end up rehashing your game again and again until you land yourself in development hell. If you don't believe us, ask Phil Fish.
This is a big issue when writing games. Trivially, if you can't think of something to write, then you can't write it. At first you'll probably either come up with nothing, or you'll have so many complex and colorful ideas that you'll struggle to commit them to paper - yet alone consider how you might implement them.
If you can't think of anything - relax, drink some water, go for a walk (yes you, heave yourself out of your mother's basement and up into the outside world). Don't demand that you come up with the next Super Mario Bros here and now. Heck, maybe even re-read this tutorial; use the example programs as a base, add new things to them and personalise them more. You'll get a better idea of what can and cannot be done.
Look at commercial games, too - while you play, consider how each mechanic might be implemented. Even better, think about how they could be improved! Don't assume it's completely out of reach; as you gain experience, you'll be able to see different ways of doing things. Remember, the authors wrote it somehow; it must be possible. Even without a Nintendo-sized studio to hand.
If your ideas are too many and complex, the above point still stands: the more games you write, the better you'll become at writing them. Just start simple and get a working game early on, then build upon what you've got. Try implementing bits of the gameplay you've imagined, and see whether they're enjoyable; even better, refine them as you go, and get feedback from people you know. You don't have to treat your original ideas as sacred, and it'll normally become apparent pretty quickly when a mechanic is boring or confusing when you've got a second pair of eyes.
Last of all, never forget the F word: fun. Games are supposed to be fun; that is, generally speaking, their purpose. You'll find it very difficult to write a fun game if you're not enjoying writing it.
Good luck!
- Your friendly neighbourhood wiki writers