Dev-corner: You don't know it, but your FOSS game project has a deadline.
How soon is the deadline on your FOSS game project?
You're probably thinking that you don't have one. And in the sense that a commercial developer would use the word deadline, you don't. There's no date looming above you on your calendar, no boss asking for updates at your next staff meeting, no investor threatening to pull their funding for your project if you don't finish on time. As a FOSS developer who is writing games as a hobby, you have the luxury of taking your time, right?
Nope. Rather, your "deadline" is like the bandwidth limit on one of those cheap "unlimited" web hosting services. It's sooner than you think, but it's not set in stone, so it's easy to not think about it until you're already past it. The deadline for your FOSS game project is when any of these things happens for the first time:
Now, there are projects out there like Flare and Battle for Wesnoth that have broken the one year mark, but what these two projects both have in common that most lack are that they've attracted multiple developers beyond the original teams. As such, when one developer burns out for a while or has family obligations, other people are continuing to work on and improve the code base, which keeps the code up to date and interesting so that your project continues to gain momentum and attract interest from potential contributors. As such, your real deadline isn't to finish your project by the one year mark, it's to get it far enough along that it's playable, so that it attracts other developers who want to add on to it.
If you want your project to get to this point, there are some things you can do that will help immensely.
Understand that you're on your own until you can produce real, compelling gameplay.
Almost every FOSS developer who gets into writing games does so because they have a personal vision of their own ideal game. Maybe you're lucky enough that there are two or three of you with a shared vision at the start of your project, but regardless of whether you have a small team or you're all alone, you probably aren't going to attract too many more developers to your project without an appreciable amount of gameplay already in place. Your project might sound great on paper, but there are thousands of other projects that sound great on paper as well, but never got anywhere. If a developer is looking for something to do, they're not going to notice your project with no real gameplay; they're going to go for an established project that is already playable and has real momentum.
The way to attract developers to your game is to harness the 'itch' that people always talk about in relation to open source software. For that to work, you need someone to play your game and decide they want to add their own pet feature to it, and for that to happen, you need a playable game.
And, since you probably aren't going to have real gameplay right out the door, the first key to a successful FOSS game project is understanding that, just because you made it open source, it doesn't mean that developers are going to start coming out of the woodwork wanting to help you. Be prepared to spend long hours working on your own, getting to the point where you have real gameplay. (Oh yeah, and I don't mean just a terrain engine. People need to be able to play your game, and have fun doing it.)
Keep your ambitions in check.
This is a big one, but it's something I've covered at great length in the past, so I'll keep this short and sweet. If you've never completed a game project before, or you've never written any real networking code, that awesome idea you have for an MMO that's going to totally be better than World of Warcraft isn't going to happen
Here, I'll show you something. Check out this SourceForge search for MMORPGs in the planning stage. At the time of this writing, there are 22 pages of results, and everything after half way down the third page hasn't been updated in at least a year. Only around 10% of MMO projects in Sourceforge ever make it to production status, and a lot of the projects that do make it that far are engines as opposed to full games. If you really want to make a huge game and you think you can code fast enough to do it before you burn out, try making a really small game first, as an exercise. If you can do that, it'll give you a good sense of scale to determine how ambitious your big project idea really is.
Ugly hacks really aren't all that bad.
This one is from personal experience. I'm a reasonably good developer. I've worked on enough projects that I have a pretty good intuitive understanding of the scope of the projects I take on. My own main problem is that when I see a new feature I'd like to add, I get tempted to re-architect my code to make that new feature as clean as possible, rather than hacking it in.
There is, of course, a lot of merit to clean code. Ugly hacks aren't a good thing. They make your code harder to read and maintain. On the other hand, if you've put a year into your pet project and it's nearly playable, now is not the time to rewrite it so you can add in some snazzy new feature or optimization. If the feature is unnecessary for making your game playable, leave it out. If you absolutely need it, hack it in.
For some of us, this is a pretty tall order. I personally worry about what people might think of my code. I'm confident that I can handle most projects, but I'm always worried that there will be some gap in my knowledge that causes me to do something stupid or miss something really obvious. When there are entire blogs out there devoted to poking fun at bad code (not knocking the Daily WTF, by the way -- it's hilarious and highly educational), it can be pretty scary to release hastily written, hackish code into the wild.
But when you do, remember that a lot of projects never see a playable release at all. That hackish code you put in there will probably be replaced eventually. You may even trip over it and curse it later on. But if it's the difference between a project that never gets finished because you burned out while trying to do things 'right', and a completed project that attracts the attention of other developers because it has legitimate gameplay, your ugly hack was ultimately for the best.
Try some FOSS game project necromancy.
Maybe you already missed the "deadline" on a FOSS game project several years ago, and you've got a bunch of code languishing on your hard drive. If you find yourself thinking of starting up a new project, you might also want to think about resurrecting that old code and finishing it instead. The deadlines I listed above aren't absolute. Even if you burned out on a project at one point, the code is still there, and there's nothing stopping you from picking it up again. Most projects stay dead, but yours doesn't have to.
In conclusion...
Your number one duty to your pet FOSS game project is to get it into a playable state without giving up. If you miss your deadline, whenever that may be, you're consigning your idea (and your time) to the graveyard of projects that never saw the light of day. Make your project playable and get it out there, and it has a much bigger chance of succeeding in the long run.
Bart K,
OpenGameArt.org
You're probably thinking that you don't have one. And in the sense that a commercial developer would use the word deadline, you don't. There's no date looming above you on your calendar, no boss asking for updates at your next staff meeting, no investor threatening to pull their funding for your project if you don't finish on time. As a FOSS developer who is writing games as a hobby, you have the luxury of taking your time, right?
Nope. Rather, your "deadline" is like the bandwidth limit on one of those cheap "unlimited" web hosting services. It's sooner than you think, but it's not set in stone, so it's easy to not think about it until you're already past it. The deadline for your FOSS game project is when any of these things happens for the first time:
- You realize you've bitten off more than you can chew, and lose interest.
- Changes in your life (getting married, having kids, getting a new job, going to school, etc) prevent you from spending an appreciable amount of time on your project.
- The game engine you're working on that was "feature rich" when you started it is now so badly obsolete that it's pointless to continue development on it.
- Any other random circumstance I haven't thought of that might cause you to stop working on your project.
Now, there are projects out there like Flare and Battle for Wesnoth that have broken the one year mark, but what these two projects both have in common that most lack are that they've attracted multiple developers beyond the original teams. As such, when one developer burns out for a while or has family obligations, other people are continuing to work on and improve the code base, which keeps the code up to date and interesting so that your project continues to gain momentum and attract interest from potential contributors. As such, your real deadline isn't to finish your project by the one year mark, it's to get it far enough along that it's playable, so that it attracts other developers who want to add on to it.
If you want your project to get to this point, there are some things you can do that will help immensely.
Understand that you're on your own until you can produce real, compelling gameplay.
Almost every FOSS developer who gets into writing games does so because they have a personal vision of their own ideal game. Maybe you're lucky enough that there are two or three of you with a shared vision at the start of your project, but regardless of whether you have a small team or you're all alone, you probably aren't going to attract too many more developers to your project without an appreciable amount of gameplay already in place. Your project might sound great on paper, but there are thousands of other projects that sound great on paper as well, but never got anywhere. If a developer is looking for something to do, they're not going to notice your project with no real gameplay; they're going to go for an established project that is already playable and has real momentum.
The way to attract developers to your game is to harness the 'itch' that people always talk about in relation to open source software. For that to work, you need someone to play your game and decide they want to add their own pet feature to it, and for that to happen, you need a playable game.
And, since you probably aren't going to have real gameplay right out the door, the first key to a successful FOSS game project is understanding that, just because you made it open source, it doesn't mean that developers are going to start coming out of the woodwork wanting to help you. Be prepared to spend long hours working on your own, getting to the point where you have real gameplay. (Oh yeah, and I don't mean just a terrain engine. People need to be able to play your game, and have fun doing it.)
Keep your ambitions in check.
This is a big one, but it's something I've covered at great length in the past, so I'll keep this short and sweet. If you've never completed a game project before, or you've never written any real networking code, that awesome idea you have for an MMO that's going to totally be better than World of Warcraft isn't going to happen
Here, I'll show you something. Check out this SourceForge search for MMORPGs in the planning stage. At the time of this writing, there are 22 pages of results, and everything after half way down the third page hasn't been updated in at least a year. Only around 10% of MMO projects in Sourceforge ever make it to production status, and a lot of the projects that do make it that far are engines as opposed to full games. If you really want to make a huge game and you think you can code fast enough to do it before you burn out, try making a really small game first, as an exercise. If you can do that, it'll give you a good sense of scale to determine how ambitious your big project idea really is.
Ugly hacks really aren't all that bad.
This one is from personal experience. I'm a reasonably good developer. I've worked on enough projects that I have a pretty good intuitive understanding of the scope of the projects I take on. My own main problem is that when I see a new feature I'd like to add, I get tempted to re-architect my code to make that new feature as clean as possible, rather than hacking it in.
There is, of course, a lot of merit to clean code. Ugly hacks aren't a good thing. They make your code harder to read and maintain. On the other hand, if you've put a year into your pet project and it's nearly playable, now is not the time to rewrite it so you can add in some snazzy new feature or optimization. If the feature is unnecessary for making your game playable, leave it out. If you absolutely need it, hack it in.
For some of us, this is a pretty tall order. I personally worry about what people might think of my code. I'm confident that I can handle most projects, but I'm always worried that there will be some gap in my knowledge that causes me to do something stupid or miss something really obvious. When there are entire blogs out there devoted to poking fun at bad code (not knocking the Daily WTF, by the way -- it's hilarious and highly educational), it can be pretty scary to release hastily written, hackish code into the wild.
But when you do, remember that a lot of projects never see a playable release at all. That hackish code you put in there will probably be replaced eventually. You may even trip over it and curse it later on. But if it's the difference between a project that never gets finished because you burned out while trying to do things 'right', and a completed project that attracts the attention of other developers because it has legitimate gameplay, your ugly hack was ultimately for the best.
Try some FOSS game project necromancy.
Maybe you already missed the "deadline" on a FOSS game project several years ago, and you've got a bunch of code languishing on your hard drive. If you find yourself thinking of starting up a new project, you might also want to think about resurrecting that old code and finishing it instead. The deadlines I listed above aren't absolute. Even if you burned out on a project at one point, the code is still there, and there's nothing stopping you from picking it up again. Most projects stay dead, but yours doesn't have to.
In conclusion...
Your number one duty to your pet FOSS game project is to get it into a playable state without giving up. If you miss your deadline, whenever that may be, you're consigning your idea (and your time) to the graveyard of projects that never saw the light of day. Make your project playable and get it out there, and it has a much bigger chance of succeeding in the long run.
Bart K,
OpenGameArt.org
Comments
Post a Comment