This past semester the whole Silver Asterism team took a Computer Game Design course. It was so awesome, but so much work. I thought a good way to ease back into posting after a hellish semester would be a small retrospective on things learned over the course of the semester. The course was set up so that we did three month-long games. Each was on a different platform, beginning with Android (using AndEngine), XNA, and either Unity or Unreal (all of us picked Unity). We worked in three-person teams and had a short list of requirements from the instructor (like having AI or implementing gravity). So here's a few things I learned in the course of the semester, in no particular order:
1. Don't bite off more than you can chew
This is a really hard one to get as a beginner. You have so many cool ideas and things that you want to do with the game, but the reality is, maybe you don't have the know-how. Or, like in our case, maybe you don't have the time.
 |
| They told me I could be anything I wanted... |
Yes, this is somewhat contradictory to #1, but bear with me. Likely, it was some of the major titles that got you interested in game design. (I'm fascinated by fantasy RPGs like Skyrim and Dragon Age and cool mechanics like in Portal, personally.) Maybe you've been fired up by a grand idea that you've had (we've got a neat one in the pipeline that I can't wait to make...). That's great! Don't let go of it! Maybe you're not ready to program it yet, but that doesn't mean that you can't plan. Maybe you're ready to hack together a prototype in your spare time. Whatever it is, don't let that dream game die, because that's what got you into this, and that same passion is going to keep you in the game.
3. Scoping is hard
My two points above really come together in one thing: scoping. Understanding the feasible scope of your project is really important. It's also really hard. And I don't think that it's something you can get without practice. My first group had more planned than we could code in a month (partially due to AndEngine's lack of documentation, but that's another story...) and my second group, in reaction to that, wasn't ambitious enough. Our school's student game development club has seen many projects fail because the director(s) didn't know what was possible in a semester. Which brings me to...
 |
| "You know, not everybody likes onions. Eh, cakes! Everybody loves cake! Cakes have layers!" |
For incremental development, you divide the project into sub-projects and order them based on necessity. Then code in that order, so that at any point in development you have a complete, playable game. For instance, the first sub-project would be to get the basic graphics and mechanics working. The next level may add on a more advanced HUD, or keys that open doors. This also lets you easily debug as you go, and if you run out of time, you'll have a complete project. It's also called the onion model, and it works well for small projects. Give it a shot, and it can help you get a better handle on scoping while still creating a complete game.
5. Learn art, or make friends with an artist
This is a smaller, less important point, but once you've laid down all the code, you're going to want your game to look nice. If you're someone like me, with some artistic ability, then maybe you're set. If not, go make friends with someone who is. It's a small touch that's nice. Try out Photoshop or Gimp to make pixel art - it's not very hard and rather fun! 3D stuff is a little more daunting, but it can be really rewarding when you get something right. Give Blender a shot, a free, open-source editor with plenty of tutorials available (www.blender.org). At the end, your game will look better for having original assets, and you'll be prouder of it.
 |
| Fun fact: That weird clef on the left there is the movable clef. In that position, it's called the alto clef. Music nerd, out. |
On that note, find some good background tracks, or someone who can make them for you. www.freesound.org is a pretty good spot to find simple loops and such. For dialogue and sound effects, I recommend recording them yourself. It's a lot of fun, and you can probably find some friends to lend their vocal talents to your characters. Again, having original assets can really help you feel proud of your game.
7. Learn from every project
I'm not jumping up and down to show off two of the games I made this semester (the last one was pretty nifty). But that doesn't mean that I'm just scrapping them. The first one wasn't very original, but I learned from it. The second could still use some work, and I may yet go back to it. Even if a project fails, which can be frustrating and embarrassing, don't just delete the code and never look at it again. There may be things to learn there, or even useful pieces of code. Take some time away from it, then go back and see how much you did accomplish.
 |
| Google thought this picture would be useful. |
Honestly, this one's mainly on the list for me. I have a tendency to underestimate myself, which holds me back in things like this. Never programmed a game before? Just try. You start to figure out how to handle updates smoothly or how triggers work in Unity, but only if you start messing around. (Okay, the tutorials might help, but I never have the patience to read through all of them.)
9. Play indie games
Thanks to Jeremy and Steam sales and Humble Bundles, I've gotten really into indie games as of late. They tend to be smaller in scope and revolve around one or two core mechanics or ideas. These are the kinds of games that you can start out programming, and they may give you a start for more realistic scoping than just working off of AAA titles. Besides, they may give you some ideas and inspiration.
10. Have fun
It seems obvious, but it's really important: make sure you enjoy what you're doing. If one engine or game style is frustrating you, find something different. Hit your stride and get used to programming games, then return to the things you're less happy with. If you're working in a team, try to find something that everyone can get excited about. My most successful project this semester involved a team that was universally excited about the idea. If you're enjoying it, working on it will seem less like a chore, and you're more likely to wind up with a finished game.
 |
| Oh, the lies... |
The first game I ever did programming for was on AndEngine. It wasn't a good idea. Don't do it. I still have no idea what on earth we were doing. XNA had more documentation available, which made it a lot easier to get started in. Working in Unity or Unreal was a little different, and personally I'd try something a little less elaborate at first, since the larger engines take care of a lot of the small things for you. Just don't start with AndEngine, or anything similarly terribly documented. You'll thank me for it.
And there you have it, my thoughts after a semester of a programming course. Some of them are kinda obvious, but hopefully they're helpful nonetheless. Now I'm off to do some more planning on my game project for this coming semester... :-)
No comments:
Post a Comment