I'm an Extreme Programmer, no make that a Goddam EXTREEEEEEEME Programmer. Yee haw. etc.
'Extreme Programming', for those of you who don't know seems to stand for, 'Extreme-ly sensible combination of the last thirty years lessons in software development. Programming'. Fortunately, it's got a catchy and GODDAM EXTREEEEEME marketing name, otherwise y'know it might sound a little dull.
What it boils down to are a few sensible principles designed for building software, rather than trying to crowbar software into a system used to make bridges or circuits (ie Software Engineering).
The principles are:
Test First, Code Second - AKA Test Driven Development. Simple one this, all programmers want to get stuff working as the first thing they do. And the second. And the third. Pretty soon you've got a very complex system going, at which point it starts to break. And you fix it. And it breaks somewhere else. Bums. If only you'd written some tests to check the code was working. You can't do it now, where would you start? So you fall back on a combination of manual testing, and crossing fingers.
Test driven development demands that you write the tests a little at a time, for a bit of code before you code it. This makes you nicely disciplined into doing it, and gives you a great batch of tests that'll tell you if your new changes have broken anything. Believe me, this is a great relief. As a nice side effect, structuring code to be testable generally forces you to have a clean design.
Keep it simple - Only write the code you need to pass the tests. If you need more code, write more tests. This saves you writing code to solve problems you might never come across.
50% now is better than 100% never - Get something working as quickly as possible. Use placeholders, simplification, whatever, just get it playing. This way you can see if it's any good as quickly as possible, and you haven't wasted effort over-desiging something you're about to ditch.
The design is wrong and the customer is right - And if you've got something working, get players to play it, see if it's what they want, and if not, change it. Do not have a fixed plan for your destination or you may end up building a lovely white-elelephant that nobody wants to play.
Two heads are better - Get two people to work together on everything. This not only reduces bugs by about 60-odd percent, it also stops you wandering off down pointless paths and lets you bounce ideas off your partner. Ideally, one of you writes a test and the other implements the code (then vice versa) so you don't prejudice the implementation. I'm obviously not going to do this, because there's only me.
Monday, 18 May 2009
Wednesday, 13 May 2009
Stand by for Action!
Confirmation received that my own spare time work does not clash with my day job...
Anything can happen in the next half-hour!
A nice cup of tea, for example.
Anything can happen in the next half-hour!
A nice cup of tea, for example.
Take Art
You'll notice I haven't said anything about pictures (or music) yet. Well, I'm not going to do these myself and I shall be throwing myself onto the mercy of some artist and musician friends later, but how do we get by for now? We use placeholders, and there are two traditional ways to get them.
1) Theft
2) Programmers
Both have the advantage of speed, so we don't waste too much effort on something we aren't ultimately going to use.
Theft
Well, piracy. Simply use somebody else's graphics (sounds, fonts) from someone else's game, or the Internet. Very quick, and you get good quality results straight away. You can get away with it, as nobody will ever see (hear, read) these 'borrowed' assets. There is one major drawback, however.
You will forget.
You will forget to remove something from the final game, and then you can be in hilarious* legal trouble with your finished game. Not good. For this reason, I'm completely going to avoid this route and go with...
Programmers
Programmer art! It's great! Or not! Yes, programmers can do pretty much anything as long as all you want are some correctly formatted data files. We're spending no time here, so doubly bad. Programmer assets do have a big advantage though: they're noticeable. You aren't going to accidentally leave your enemy marines as bright pink rectangles. With any luck, they'll be so bad that artists will replace them on sight. Bonus.
*Not hilarious.
1) Theft
2) Programmers
Both have the advantage of speed, so we don't waste too much effort on something we aren't ultimately going to use.
Theft
Well, piracy. Simply use somebody else's graphics (sounds, fonts) from someone else's game, or the Internet. Very quick, and you get good quality results straight away. You can get away with it, as nobody will ever see (hear, read) these 'borrowed' assets. There is one major drawback, however.
You will forget.
You will forget to remove something from the final game, and then you can be in hilarious* legal trouble with your finished game. Not good. For this reason, I'm completely going to avoid this route and go with...
Programmers
Programmer art! It's great! Or not! Yes, programmers can do pretty much anything as long as all you want are some correctly formatted data files. We're spending no time here, so doubly bad. Programmer assets do have a big advantage though: they're noticeable. You aren't going to accidentally leave your enemy marines as bright pink rectangles. With any luck, they'll be so bad that artists will replace them on sight. Bonus.
*Not hilarious.
Monday, 11 May 2009
And The Bodies of Your Enemies Will Float By
The annoying thing about the Internet is that whenever you try and do something, a quick Google search shows that you might as well not bother, as it's already been done.
The great thing about the Internet is that whenever you want to do something, a quick Google search shows that you don't need to worry, as someone's already done it for you.
I've been practicing the great art of achieving lots while doing nothing. If you remember, I can't write any code until some contractual issues are resolved, but that doesn't stop me making progress.
I've sorted out the map editor, and all my developmental foundations: the low-level graphics and sprite system, the memory and string handling, and a maths library, and all without doing a single thing. These are all things I've had to write from scratch in the past, often slowly and painfully, but which can now be had for the price of a little research due to the generosity of programmers, and easy communication over the Internet.
First off, I've downloaded and compiled the Allegro SDK. This provides all the basic functions I should need, and being a venerable framework will have many years of nice bug testing behind it. It's free and it has no restrictive licence at all. As there's source code, if I find any problems I can fix them and pass the fix back to the main development community too. Although it supports 3D, it was originally 2D based which will be perfect. 2D is very much the poor cousin to 3D these days. DirectX 8 for example did away with it almost completely, making you use a sort of odd, flat 3D, but the outcry was so bad (and people stuck to DirectX 7) that they had to bring it back for DX9. Nobody, of course, will touch DX10 unless forced, as you can merrily wave good bye to any customers using Windows XP or earlier. A quick glance at the Steam hardware survey shows that as of today less than 30% of systems can run DX10, and that's gamers not just general users. Still, looks like it's up 4% since last August, so it'll be viable real soon now! Honest!
Anyway, backing me up in the tools department is respected tile map editor Mappy. There are several tile map editing programs around, but at a quick glance it looks like is the one for me. It covers both top-down and isometric views, as I haven't decided which to use yet, and joy-of-joys it even has source code for integrating it with Allegro applications. Ace.
All this means that I don't have to faff around builing the structure to let me make a game, and that I can get on to actually making one.
The great thing about the Internet is that whenever you want to do something, a quick Google search shows that you don't need to worry, as someone's already done it for you.
I've been practicing the great art of achieving lots while doing nothing. If you remember, I can't write any code until some contractual issues are resolved, but that doesn't stop me making progress.
I've sorted out the map editor, and all my developmental foundations: the low-level graphics and sprite system, the memory and string handling, and a maths library, and all without doing a single thing. These are all things I've had to write from scratch in the past, often slowly and painfully, but which can now be had for the price of a little research due to the generosity of programmers, and easy communication over the Internet.
First off, I've downloaded and compiled the Allegro SDK. This provides all the basic functions I should need, and being a venerable framework will have many years of nice bug testing behind it. It's free and it has no restrictive licence at all. As there's source code, if I find any problems I can fix them and pass the fix back to the main development community too. Although it supports 3D, it was originally 2D based which will be perfect. 2D is very much the poor cousin to 3D these days. DirectX 8 for example did away with it almost completely, making you use a sort of odd, flat 3D, but the outcry was so bad (and people stuck to DirectX 7) that they had to bring it back for DX9. Nobody, of course, will touch DX10 unless forced, as you can merrily wave good bye to any customers using Windows XP or earlier. A quick glance at the Steam hardware survey shows that as of today less than 30% of systems can run DX10, and that's gamers not just general users. Still, looks like it's up 4% since last August, so it'll be viable real soon now! Honest!
Anyway, backing me up in the tools department is respected tile map editor Mappy. There are several tile map editing programs around, but at a quick glance it looks like is the one for me. It covers both top-down and isometric views, as I haven't decided which to use yet, and joy-of-joys it even has source code for integrating it with Allegro applications. Ace.
All this means that I don't have to faff around builing the structure to let me make a game, and that I can get on to actually making one.
Friday, 8 May 2009
Time to Develop
No, I haven't started yet, but from my previous post I thought I'd outline some of the constraints I'm working with to give some better context. They boil down to time and money.
Time
Phone me up at any time and chances are you'll catch me either at work, looking after my children, or asleep, sometimes all three. In any case, I'll be grumpy.
Take a throw at the dartboard of my life, and you'll have to be in the big points. There's the double-top of evenings when I'm not doing something else, or the treble-top, very special occasions when I actually get an afternoon or morning to myself (like now - the family are at a friends house, hence the posting binge) . Any greater length of time would be the elusive quadruple top.
This means that I have to be able to pick up work again quickly, possibly after a very long period of inactivity.
What I'm looking for then is the absolute minimum of administration and fuss, not even 'just a bit', none at all. Once something is set up, it needs to stay set up.
Familiarity is also of great concern, as I can barely remember the controls for Tetris for more than a week, so don't expect me to remember your keyboard shortcuts, handy application.
I will also need code that's as clear as a windowpane, so when I come back to it I don't have to spend an hour just trying to understand the crazy world of my previous self. Fortunately, after many years of wishing to be able to go back in time and assassinate my former self, this is how I program anyway.
Money
As time is money, apparently no time is no money. No money is what I have to spend on this project. Actually, that's not strictly true. What I have is hobby money, which is a lot less than company money. For example, I'd gladly use Slickedit to speed up my editing if it was £30, but as it's £200 it can whistle, and I'll waste a months worth of free time setting Visual Studio up to use the right buttons instead, providing my own whistling. Surely it's worth buying it to save those evenings? No, because it's not like I can use the time saved to actually generate £200. If I could do paid overtime on demand, it might be different, but it isn't. Sorry.
So there we go, I've no time or money to make my game, and I'm hopefully going to show how this can be to my advantage, but best not hold your breath waiting for it to come out, eh.
Time
Phone me up at any time and chances are you'll catch me either at work, looking after my children, or asleep, sometimes all three. In any case, I'll be grumpy.
Take a throw at the dartboard of my life, and you'll have to be in the big points. There's the double-top of evenings when I'm not doing something else, or the treble-top, very special occasions when I actually get an afternoon or morning to myself (like now - the family are at a friends house, hence the posting binge) . Any greater length of time would be the elusive quadruple top.
This means that I have to be able to pick up work again quickly, possibly after a very long period of inactivity.
What I'm looking for then is the absolute minimum of administration and fuss, not even 'just a bit', none at all. Once something is set up, it needs to stay set up.
Familiarity is also of great concern, as I can barely remember the controls for Tetris for more than a week, so don't expect me to remember your keyboard shortcuts, handy application.
I will also need code that's as clear as a windowpane, so when I come back to it I don't have to spend an hour just trying to understand the crazy world of my previous self. Fortunately, after many years of wishing to be able to go back in time and assassinate my former self, this is how I program anyway.
Money
As time is money, apparently no time is no money. No money is what I have to spend on this project. Actually, that's not strictly true. What I have is hobby money, which is a lot less than company money. For example, I'd gladly use Slickedit to speed up my editing if it was £30, but as it's £200 it can whistle, and I'll waste a months worth of free time setting Visual Studio up to use the right buttons instead, providing my own whistling. Surely it's worth buying it to save those evenings? No, because it's not like I can use the time saved to actually generate £200. If I could do paid overtime on demand, it might be different, but it isn't. Sorry.
So there we go, I've no time or money to make my game, and I'm hopefully going to show how this can be to my advantage, but best not hold your breath waiting for it to come out, eh.
Tools, Tools, Tools
Practical games development isn't just a case of sitting down with STOS, or whatever you modern kids call it, and banging out an animation of a walking penis one afternoon, oh no. You need tools and support, or after a few weeks work, your pride and joy will hit a wall, which in this case would be painful. No, you can get away without a proper, structured approach ('hacking', as we call it) for a while, but you'll soon find that walking penis bites you in the ass.
You will need the following:
A Compiler - Well duh. Actually, you don't need a compiler as such, just some way of turning your idea into a running game. However as I AM HARDCORE, we're looking at some kind of C++ compiler. I'm going for the excellent, and free Microsoft Visual C++ 2008 Express Edition which is a full IDE, and only trivially different from the paid-for version. I'm also familiar with it, having used it extensively just a few years ago, so very little learning curve there. You have to register your copy with Microsoft, but hey! It's genuinely great.
Why am I using C++ rather than some modern-fangled alternative, such as Flash or Multimedia Fusion, C# or Java? Well, I'm avoiding game makers such as Flash and MMF, as I like to have everything in a nice set of text files where I can see it, thank you very much. These systems with boxes and lines are all very well providing you want to do what they do, don't mind being mouse-centred, and (usually) don't want to come back and modify it too much later on (ie they're good for creation, not so hot on editing and debugging).
C# and Java are both fine languages that I've used in the past, but C++ comes out the winner due to, well, being the winner. It's the most globally popular language and so comes with a whole supporting range of tools from profilers to static code checkers such as Lint. It also has a range of excellent supporting SDKs and libraries that I can use to save me time (more on that later), so although it's far from perfect it's powerful, and has the most support from the outside world. It wins.
An Editor
Editor and compiler are of course potentially separate things and a powerful editor is a thing of joy. I'd prefer to use the excellent and powerful Slickedit editor, which I'm familiar with from work, but the damn thing costs £200. If you're doing commercial development, this is a drop in the ocean and it'll save you at least £200 of time easily. However, this is spare time development, and I don't have £200, so I shall stick with the perfectly adequate editor in Visual C++, and remap the keyboard shortcuts to match the ones programmed into my fingers.
Source Control - Yes, even if there's one of you working on one machine you will still from a decent source control system - it stops you having to remember to keep backups, and allows you to easily throw away a disasterous session of work if needs be. If there is more that one of you its even better, as it allows you both to work on the same project at the same time without ballsing everything up.
I'm using Perforce as it's good, quick, I'm familiar with it and a two user licence is free.
Other respectable options I've used are the free CVS and Subversion, and the paid-for Alienbrain, but these all have niggles that make Perforce the winner.
Alienbrain costs serious money, so that's out of the window straight away. CVS and Subversion are both free, but require more setup and administration (not a lot, but some) to get them working, so it boils down very simply to Perforce having a better installer. You will of course need the Perforce server running somewhere, and the Perforce client (P4Win, in my case) to check in and out.
Bug Tracking
Using your memory and little bits of paper don't cut it with this one. Without this, bugs won't get remembered, and so won't get fixed. In the past I've used Bugzilla, Test-Track and an Access spreadsheet I wrote myself for tracking, but none of these quite fit the bill. Similar thinking to source control, as above. Test-Track costs money, Bugzilla is free but needs setup and administration. An Access database kept under source control could work, but I don't have Access and OpenOffice's copycat database seems to be appallingly slow and crash prone. I've gone with Fogbugz trial on the same terms as Perforce (up to two users free). I've no previous experience with it, but it's remotely administered (no work for me) and I've heard a lot about it via the excellent Joel on Software Blog.
SDKs
What, you write software in a vacuum? I've got the DirectX SDK as I can't imagine it's not going to be used. I've also cast around for helpful SDKs, of which more later.
Cygwin
Damn useful as it lets me run all the gnu utilities and create my own useful bash scripts. That should allow me to run automatic test and release builds, set up a robo-tester and more mundane tasks like parsing data files easily.
Ticked the 'make' option in the 'develop' section, and bunged gcc, gdb, automake, autoconf and (what the hell) Subversion in for kicks.
You will need the following:
A Compiler - Well duh. Actually, you don't need a compiler as such, just some way of turning your idea into a running game. However as I AM HARDCORE, we're looking at some kind of C++ compiler. I'm going for the excellent, and free Microsoft Visual C++ 2008 Express Edition which is a full IDE, and only trivially different from the paid-for version. I'm also familiar with it, having used it extensively just a few years ago, so very little learning curve there. You have to register your copy with Microsoft, but hey! It's genuinely great.
Why am I using C++ rather than some modern-fangled alternative, such as Flash or Multimedia Fusion, C# or Java? Well, I'm avoiding game makers such as Flash and MMF, as I like to have everything in a nice set of text files where I can see it, thank you very much. These systems with boxes and lines are all very well providing you want to do what they do, don't mind being mouse-centred, and (usually) don't want to come back and modify it too much later on (ie they're good for creation, not so hot on editing and debugging).
C# and Java are both fine languages that I've used in the past, but C++ comes out the winner due to, well, being the winner. It's the most globally popular language and so comes with a whole supporting range of tools from profilers to static code checkers such as Lint. It also has a range of excellent supporting SDKs and libraries that I can use to save me time (more on that later), so although it's far from perfect it's powerful, and has the most support from the outside world. It wins.
An Editor
Editor and compiler are of course potentially separate things and a powerful editor is a thing of joy. I'd prefer to use the excellent and powerful Slickedit editor, which I'm familiar with from work, but the damn thing costs £200. If you're doing commercial development, this is a drop in the ocean and it'll save you at least £200 of time easily. However, this is spare time development, and I don't have £200, so I shall stick with the perfectly adequate editor in Visual C++, and remap the keyboard shortcuts to match the ones programmed into my fingers.
Source Control - Yes, even if there's one of you working on one machine you will still from a decent source control system - it stops you having to remember to keep backups, and allows you to easily throw away a disasterous session of work if needs be. If there is more that one of you its even better, as it allows you both to work on the same project at the same time without ballsing everything up.
I'm using Perforce as it's good, quick, I'm familiar with it and a two user licence is free.
Other respectable options I've used are the free CVS and Subversion, and the paid-for Alienbrain, but these all have niggles that make Perforce the winner.
Alienbrain costs serious money, so that's out of the window straight away. CVS and Subversion are both free, but require more setup and administration (not a lot, but some) to get them working, so it boils down very simply to Perforce having a better installer. You will of course need the Perforce server running somewhere, and the Perforce client (P4Win, in my case) to check in and out.
Bug Tracking
Using your memory and little bits of paper don't cut it with this one. Without this, bugs won't get remembered, and so won't get fixed. In the past I've used Bugzilla, Test-Track and an Access spreadsheet I wrote myself for tracking, but none of these quite fit the bill. Similar thinking to source control, as above. Test-Track costs money, Bugzilla is free but needs setup and administration. An Access database kept under source control could work, but I don't have Access and OpenOffice's copycat database seems to be appallingly slow and crash prone. I've gone with Fogbugz trial on the same terms as Perforce (up to two users free). I've no previous experience with it, but it's remotely administered (no work for me) and I've heard a lot about it via the excellent Joel on Software Blog.
SDKs
What, you write software in a vacuum? I've got the DirectX SDK as I can't imagine it's not going to be used. I've also cast around for helpful SDKs, of which more later.
Cygwin
Damn useful as it lets me run all the gnu utilities and create my own useful bash scripts. That should allow me to run automatic test and release builds, set up a robo-tester and more mundane tasks like parsing data files easily.
Ticked the 'make' option in the 'develop' section, and bunged gcc, gdb, automake, autoconf and (what the hell) Subversion in for kicks.
Make Sure You Own What You Do
So, first lesson this and it's important. It's not technical, it's legal.
For many people this isn't going to be a problem, but if your day job involves developing games (or possibly any software) it could well be.
Developing games and coming up with designs is what I get paid for, and what I produce belongs not to me, but to my employer. Although you can't copyright ideas, you can claim copyright on many areas of game development, not least source code. Work I do out of work hours is in something of a grey area, as I have quite resonably agreed not to do anything that will create a conflict with my day job. So, before doing any development work I have to get a letter from my employers stating that this will not conflict, and they will not make any claim on the work.
Which I don't have, yet.
So I haven't written anything at all, until that's settled.
Why do I need this clarification? Well, obviously I don't want to conflict with my contract, and start anything that I might have to give up later on.
What will I do if I don't get clarification? Well, nothing. Literally. There'd be no point in carrying on, but at least I wouldn't have started. I'll probably be grumpy for a while, though.
What do I do until I get clarification? Well, nothing that could possibly conflict with my work, so no development at all. However, there are tools to be gathered, compilers, source control and bug databases to be set up, infrastructure to be put in place.
I can do a lot of useful work by doing no work at all, for example an evening spent finding an exisiting tool or library that does something I'd otherwise have to write myself is in one sense not doing anything, but also gets the game closer to existing. These are all useful things that can be done before a single line of code or item of design are set down, don't involve any contractual issues, and apply to every development project, so I'm going to outline them for the benefit of future generations...
For many people this isn't going to be a problem, but if your day job involves developing games (or possibly any software) it could well be.
Developing games and coming up with designs is what I get paid for, and what I produce belongs not to me, but to my employer. Although you can't copyright ideas, you can claim copyright on many areas of game development, not least source code. Work I do out of work hours is in something of a grey area, as I have quite resonably agreed not to do anything that will create a conflict with my day job. So, before doing any development work I have to get a letter from my employers stating that this will not conflict, and they will not make any claim on the work.
Which I don't have, yet.
So I haven't written anything at all, until that's settled.
Why do I need this clarification? Well, obviously I don't want to conflict with my contract, and start anything that I might have to give up later on.
What will I do if I don't get clarification? Well, nothing. Literally. There'd be no point in carrying on, but at least I wouldn't have started. I'll probably be grumpy for a while, though.
What do I do until I get clarification? Well, nothing that could possibly conflict with my work, so no development at all. However, there are tools to be gathered, compilers, source control and bug databases to be set up, infrastructure to be put in place.
I can do a lot of useful work by doing no work at all, for example an evening spent finding an exisiting tool or library that does something I'd otherwise have to write myself is in one sense not doing anything, but also gets the game closer to existing. These are all useful things that can be done before a single line of code or item of design are set down, don't involve any contractual issues, and apply to every development project, so I'm going to outline them for the benefit of future generations...
Welcome!
Hello, what's this all about, then?
This blog aims to keep a record of the things you have to do to get yourself properly set up to develop a game. It'll follow my spare-time development of my own game, provisionally titled Boarding Party, an extremely niche interest turn-based tactical combat game. If you know who Julian Gollop is, you'll know what I'm aiming for.
I'm not going to mention anything about learning programming, as I know how to do that and I assume you do to, no this is about the practical nitty-gritty that takes you from 'I know how to program' to 'I have made a game'.
Who am I to give you this advice? Good question. I'm Andy Krouwel, a professional games programmer/designer* currently working at Fuse Games on a game for Nintendo (no link, I assume you've heard of them). I learned programming at primary school in the mid ninteen eighties, and have carried on ever since. Although I've also worked in educational software, mobile communications and space systems, games have always been my main interest and I've always had something on the go at least in my spare time. I've worked on games for the ZX81, Commodore 64, Spectrum, Atari ST, Amiga, PC, Playstation 2, Nintendo DS & Wii, some published others not, and written for both Retro Gamer and Edge.
My spare time is where we are now. While part of my job is coming up with game ideas and pitches, here we are looking at my own project. As I say, it's hyper-niche and so not commercially viable so doesn't conflict with my day job.
And so we move on to post number one...
*So don't ask me to do music or art.
This blog aims to keep a record of the things you have to do to get yourself properly set up to develop a game. It'll follow my spare-time development of my own game, provisionally titled Boarding Party, an extremely niche interest turn-based tactical combat game. If you know who Julian Gollop is, you'll know what I'm aiming for.
I'm not going to mention anything about learning programming, as I know how to do that and I assume you do to, no this is about the practical nitty-gritty that takes you from 'I know how to program' to 'I have made a game'.
Who am I to give you this advice? Good question. I'm Andy Krouwel, a professional games programmer/designer* currently working at Fuse Games on a game for Nintendo (no link, I assume you've heard of them). I learned programming at primary school in the mid ninteen eighties, and have carried on ever since. Although I've also worked in educational software, mobile communications and space systems, games have always been my main interest and I've always had something on the go at least in my spare time. I've worked on games for the ZX81, Commodore 64, Spectrum, Atari ST, Amiga, PC, Playstation 2, Nintendo DS & Wii, some published others not, and written for both Retro Gamer and Edge.
My spare time is where we are now. While part of my job is coming up with game ideas and pitches, here we are looking at my own project. As I say, it's hyper-niche and so not commercially viable so doesn't conflict with my day job.
And so we move on to post number one...
*So don't ask me to do music or art.
Subscribe to:
Comments (Atom)
