This is part one of two posts I plan on making...although who knows when I'll get around to the massive second part :P
I've noticed something in the software world that annoys me... No one can seem to come to a clear definition of what release types mean. What exactly is an "alpha", "beta", "release candidate", etc...?
To me these namings have always had a clear cut meaning, why don't they to everyone else? I'm not going to be ridiculous enough to propose that mine are the be all end all and everyone should conform to these standards, but it certainly needs to be discussed and standardized at some point.
First off we have the elusive "alpha" release. I've always thought of the alpha stage in development to mean a work-in-progress...ie, new features are still being developed and added. The code base is at a state where you can start testing it to some extent and it's somewhat usable, but there are still new features being added, and the currently implemented ones may very well be completely rewritten depending on how tests and such go. So let's just say alpha means: The software in question is usable, but still under active development, not all features have been implemented yet, and the code is still subject to radical change. If a user is feeling really adventurous they can go ahead and give it a shot, but stability is most certainly not guaranteed.
With that definition, let's take a step back to the rarely used "pre-alpha." To me this would mean the same as alpha except it's not even usable yet, and there's no point in trying to test the software as whole yet, although specific classes and functions may be complete. Also with this definition there's no reason to really ever offer up a public release dubbed a pre-alpha. The only way an end user should ever get their hands on pre-alpha code is if they're compiling from CVS/Subversion/etc.
Next onto another commonly used term that rarely has the same meaning from project to project; "beta" releases. What defines a beta release seems to have almost no contention between different developers. To me, a beta release means that all features have been implemented and from this point on all subsequent releases will be to fix bugs and tighten up the code. It always drives me crazy when developers release their programs with a so called beta release, yet all the features are not there yet, this just isn't a beta...it's still alpha! Not only should all planned features be implemented upon the first beta release, but there should have been a reasonable amount of testing to make sure there are no major, commonly found bugs in it. A beta doesn't have to be completely stable, but it should certainly be more stable than an alpha. Now of course, this is hard to define as the beta phase is there strictly to find new bugs, but like I said, it should at least be as stable, if not more than the alpha release(s) were. Perhaps another way to look at it is that alphas are almost exclusively for developers to test, but betas are for the end users to start testing. The beta cycle of development should probably be the longest of them all as well. Sometime it takes time to find all the major bugs in your code, and there's no sense in releasing a release candidate until you've had an adequate amount of time and testers to find any show stoppers. So, to sum up my definition of beta: all features have been implemented, some testing has been done, there are no known critical bugs in the code at the time of release.
Next we have the "release candidate" or sometimes simply referred to as the "rc" for those who just can't handle typing that much. Not all projects even release a release candidate, but I think it's a good idea. Your release candidate comes after you've been in beta for a decent amount of time and all the known bugs have been found. The main purpose for the release candidate is to grab a larger group of testers than you had for your beta. As some users are too paranoid to run beta software, and many times for good reason, a release candidate is more acceptable to those who need absolute stability. Your release candidate phase doesn't have to last very long, but it should probably be more than a week (I'm looking at you Ubuntu!). Once again you should have zero bug reports open upon release of your first release candidate, as this release should..in theory...be just as stable as your final release. Of course, hopefully a few will be found before you let loose that final release, since that's the whole point of this phase. And if you're saying to yourself "what if my code doesn't have any bugs in it?" you're just kidding yourself, everyones' code has bugs. If no new bugs have been reported since your first release candidate you probably still don't have enough users testing your code.
Once the RC has been out there for a while, and you have absolutely no bugs left, then you release your final version. Now of course all development teams will have this version, but not all of them call it the same thing. Some will call it "gamma" as it's the next letter after "beta" in the greek alphabet, and many of the game developers will call it the "gold" release because of the color of the old CD-R masters they used to send off to their replicators. Of course today most of them will use the same silver-ish CD-Rs everyone else does, but the name remains. And for many developers, especially in the open source community, their code never touches a physical disc. So no matter whether you call it gold, or just "final," it's the last release you should ever make for this version number. The only complaint/suggestion I'd have here is don't rush to get to final, there's no shame in having a lengthy beta phase if that means your final is rock solid when it finally hits. Just as with the rest of this, we really should agree on one name that we all use, I prefer the simple "final" myself.
So to recap my definitions:
Pre-Alpha: code almost unusable, in heavy development, definitely not for end users
Alpha: code still in heavy development, but somewhat usable; not all features have been implemented yet, don't expect stability end users
Beta: all features have been implemented, code is fairly stable, okay for users to test at their own risk
Release Candidate: all known bugs have been irradicated, safe for all to test
Final: super stable, well tested, safe for mission critical use
In my next post I'll discuss an even sloppier area: version numbering.
2007-05-15
2007-04-05
A quick thought
Like many other poor souls, I'm still forced to deal with Windows everyday at work. So, I end up using it much more than I would like obviously. Anyway, I just had a thought today and that is: Why hasn't anyone created a package manager for Windows? If I could just do an apt-get install firefox on these Windows machines with all updates being automagically handled by the PM life would be so much simpler. Well, obviously I'm not the first to have this idea as there seems to already be a couple projects under way to do just this. The first one I found is simply called WinPackMan (or the Windows Package Manager), although I've yet to have a chance to try it yet. It appears to still be in an alpha state at the moment though...
If there were a reliable, open-source package manager for Windows, this could really help people transition to the Linux world much easier down the road too. Package installation/management is one the first things new Linux converts will find to complain about when they attempt to make the switch. And it's not really their fault, nor is it the Linux community's fault...we simply do things differently. So, once again... if Windows users started using package managers akin to Apt, Pacman, Yum, Portage (yes Portage can be used for binaries in addition to compiling from source), etc... then things would probably feel alot more natural to them when they make the switch.
Perhaps a more modular/extensible package manager like SmartPM needs to be ported over to Windows? I think it would very much be worth it.
If there were a reliable, open-source package manager for Windows, this could really help people transition to the Linux world much easier down the road too. Package installation/management is one the first things new Linux converts will find to complain about when they attempt to make the switch. And it's not really their fault, nor is it the Linux community's fault...we simply do things differently. So, once again... if Windows users started using package managers akin to Apt, Pacman, Yum, Portage (yes Portage can be used for binaries in addition to compiling from source), etc... then things would probably feel alot more natural to them when they make the switch.
Perhaps a more modular/extensible package manager like SmartPM needs to be ported over to Windows? I think it would very much be worth it.
2007-03-18
Thinking Out Loud: Episodic Gaming
If you spend much time reading all the game sites about new concepts and ideas, probably one of the biggest buzz terms you'll hear is "digital distribution." The ability to provide your content directly to the end user and skip all the middle men is an interesting prospect to many developers, especially the smaller independent developers who's chances of ever getting their games carried in the Walmarts and Best Buys of the world is slim to none. The concept of digital distribution is appealing to many, although most of the publishers and retail distributors are probably scared to death of it. With the cost of development rising it could be a major benefit to the industry as a whole even though it could kill some of the juggernauts that currently run the show. Not only does DD make the thought of self-publishing your own games much more realistic than ever before, but it also offers to the actual gamers the possibility of getting their fix at cheaper prices.
Another concept that builds on top of DD is the idea of "episodic content." The idea is that rather than buying a big epic game all at once, the gamer buys it in smaller segments, thus making their gaming experience more akin to a TV show than a movie. Very few companies have actually tried realizing the concept so far, but it's fairly inevitable that it will come to be a normal occurance in the future.
Now I will try to offer some of my ideas on how to successfully pull off this idea that I have yet to see fully realized in our industry. Now of course being that I'm a fledgling game designer/developer myself, some might ask why give away these ideas if they could be your own big break? Well, I see it as a much greater benefit to the industry as a whole rather than to keep to myself. The method of delivery isn't nearly as important as the real meat of the game, AKA: content.
So, first off, episodic gaming requires your users to have a broadband internet connection. This is a little bit of a problem as still not everyone has one. In fact, according to recent surveys and statistics you'll find that in the United States (where I reside), only about half of Americans have broadband at their homes. In fact, from my own personal experience, it's even less than that if your in the rural south (also where I currently reside). Since America is so spread out, the further away you live from a major city the less your chances are of having anything better than dial-up. So this presents a major bottleneck in the concept...but, not as huge as it may sound at first. Just as with regular television shows, you can offer offline versions of your episodic content if you're popular enough, and have the distribution channels to support you. Once you finish a "season" in your game, you can bundle it all up on a DVD or 2 and sell it through traditional retail means (once again, if your game is popular enough to have retail distributors behind it). So, this means, that some smaller companies might find themselves online-only for a couple years, but after they're audience hits a certain point, they might find the big boys come beg them to let them publish the offline version. Sound like delusions of grandeur? Perhaps, but I'm merely trying to get an idea across...I'm not saying it will be easy nor happen to many.
So, where do we begin.... first off, let me say that if you want to make any money off your game you have to give it away for free. Sound crazy? It's not... In the television industry all new shows start off with a "pilot" episode. Then in the game industry many games will offer a "demo." What I'm proposing here is simply to combine the two. It's not that new a concept either, it's what made shareware titles like Doom take off to where they are today. So, here's what you do: Offer up the entire first episode of your game 100% free to everyone. You build a digital distribution/update service into that initial release, and so when you release episode two, the gamer simply starts up the same game they've already downloaded for free, and do all their purchasing and downloading from within it. Now of course, there might be a third party mechanism you want to use, like Steam for instance. That's fine, but once again... I say give away your first episode for free. Give the gamers something to play. Let them see just how good your series will be.
Now of course, this puts alot of weight on your first episode. If you're giving it out for free, and no one likes it, you're going to have a hell of time selling them your next one. Sorry, that's the price of such a service. And speaking of price, if you're a small company trying to do this all by yourself, the bandwidth to host that first free episode is going to be monstrous. Of course, you could always look for investors/partners to help carry that load, but then that means you have to give them a cut of your profits once you start making a return on your investment...and you may not want to get into that situation if you can help it. There's also things like bitTorrent to help lighten the load, but unfortunately alot of ISPs (especially those offered on college campuses) are trying to block it out of existence for potential piracy uses.
Then of course there's always advertising, whether it simply be on your site, perhaps displayed during the download process, or actually in your game. All I have to say about that last one is be careful, gamers will put up with it to a certain extent, but if you over do it or do it wrong (like putting a big Mountain Dew billboard in the middle of an ancient medieval world), there will be a backlash. Also it's important to remember that since you intend on selling subsequent episodes after the first one, people will probably feel pretty angry with you if they are paying for it and seeing ads at the same time. Once again, there's a small window where you can get away with it, but eventually your users are going to catch on. Be careful...
Another good idea may be to go ahead and prepare the first 2 or 3 episodes before you ever release that first one for free. That way, if people like they can go ahead and download the next episode or two right away, and you can start paying off that bandwidth debt right away too. Some may even feel compelled to finish the entire season before "airing" the first episode, but once again...this is somewhere you need to be careful on. If your audience realizes that you've completed the entire game and are simply slipping it out bit by bit to them simply so you can charge them more in the long run than you would have to have sold it all at once, they're not gonna be happy.
And now we come to the next aspect you need to consider... price. Luckily digital distribution offers you a beautiful thing called scalability. The bigger your audience, the more money you make and thus you can afford bigger bandwidth too. I would suggest to you to sell your episodes as cheaply as you can afford to. The cheaper they are, the more likely someone will be willing to pay for them, and thus you can potentially make a lot more money by selling them at a lower cost. Then some may choose to sell their new episodes at a higher price point the first week or two of their release, and then lower the price gradually over time. For example, you may charge $20 for your episode at first, then a few weeks later, you drop it to $10, then later on down the road, you drop it to $5. Now, of course that could just as easily be 5 then 2 then 1 depending on your business model.
When deciding how much to charge for each episode, you need to really look at how big each one will be, and how many you plan on releasing over the course of your season. If each episode only consists of a single level that will average out to about an hour or two of gameplay, but you plan on releasing 20 of them, I'd suggest selling them for about $5-10 if not less even. If you plan on releasing 5 or 6 episodes with about 6-8 hours of gameplay each, you'd probably want to charge around $10-20. These are all factors you need to look at when deciding all these things.
Lastly there are a few more small things to take into account. Do you even want to have seasons? Perhaps you just want to start with episode one and never stop until your ready to end the series. If you do go with a season model, perhaps you should give away the first episode of each subsequent season for free just as you did with the first one in case someone wants to start from there? Do you want to let your audience pick and choose which episodes they buy, or do you force them to own all the prior episodes first? (ie...you can't buy episode 4 unless you already have played through and completed 1,2 and 3) These are all tough, and very important questions you need to consider. Since you're giving away the first episode for free and merely selling the content of the subsequent episodes, perhaps it would be more beneficial for you to use an open source model with your actual game engine and digital distribution service? Maybe you might even want to build a general purpose engine that multiple "shows" can be purchased through, rather than just your own? There all kinds of options out there for you, and even more factors than I have covered here. Episodic gaming offers a potentially, very compelling experience for gamers and developers alike.....but when will anyone be ready to really pull it off? Are you?
Another concept that builds on top of DD is the idea of "episodic content." The idea is that rather than buying a big epic game all at once, the gamer buys it in smaller segments, thus making their gaming experience more akin to a TV show than a movie. Very few companies have actually tried realizing the concept so far, but it's fairly inevitable that it will come to be a normal occurance in the future.
Now I will try to offer some of my ideas on how to successfully pull off this idea that I have yet to see fully realized in our industry. Now of course being that I'm a fledgling game designer/developer myself, some might ask why give away these ideas if they could be your own big break? Well, I see it as a much greater benefit to the industry as a whole rather than to keep to myself. The method of delivery isn't nearly as important as the real meat of the game, AKA: content.
So, first off, episodic gaming requires your users to have a broadband internet connection. This is a little bit of a problem as still not everyone has one. In fact, according to recent surveys and statistics you'll find that in the United States (where I reside), only about half of Americans have broadband at their homes. In fact, from my own personal experience, it's even less than that if your in the rural south (also where I currently reside). Since America is so spread out, the further away you live from a major city the less your chances are of having anything better than dial-up. So this presents a major bottleneck in the concept...but, not as huge as it may sound at first. Just as with regular television shows, you can offer offline versions of your episodic content if you're popular enough, and have the distribution channels to support you. Once you finish a "season" in your game, you can bundle it all up on a DVD or 2 and sell it through traditional retail means (once again, if your game is popular enough to have retail distributors behind it). So, this means, that some smaller companies might find themselves online-only for a couple years, but after they're audience hits a certain point, they might find the big boys come beg them to let them publish the offline version. Sound like delusions of grandeur? Perhaps, but I'm merely trying to get an idea across...I'm not saying it will be easy nor happen to many.
So, where do we begin.... first off, let me say that if you want to make any money off your game you have to give it away for free. Sound crazy? It's not... In the television industry all new shows start off with a "pilot" episode. Then in the game industry many games will offer a "demo." What I'm proposing here is simply to combine the two. It's not that new a concept either, it's what made shareware titles like Doom take off to where they are today. So, here's what you do: Offer up the entire first episode of your game 100% free to everyone. You build a digital distribution/update service into that initial release, and so when you release episode two, the gamer simply starts up the same game they've already downloaded for free, and do all their purchasing and downloading from within it. Now of course, there might be a third party mechanism you want to use, like Steam for instance. That's fine, but once again... I say give away your first episode for free. Give the gamers something to play. Let them see just how good your series will be.
Now of course, this puts alot of weight on your first episode. If you're giving it out for free, and no one likes it, you're going to have a hell of time selling them your next one. Sorry, that's the price of such a service. And speaking of price, if you're a small company trying to do this all by yourself, the bandwidth to host that first free episode is going to be monstrous. Of course, you could always look for investors/partners to help carry that load, but then that means you have to give them a cut of your profits once you start making a return on your investment...and you may not want to get into that situation if you can help it. There's also things like bitTorrent to help lighten the load, but unfortunately alot of ISPs (especially those offered on college campuses) are trying to block it out of existence for potential piracy uses.
Then of course there's always advertising, whether it simply be on your site, perhaps displayed during the download process, or actually in your game. All I have to say about that last one is be careful, gamers will put up with it to a certain extent, but if you over do it or do it wrong (like putting a big Mountain Dew billboard in the middle of an ancient medieval world), there will be a backlash. Also it's important to remember that since you intend on selling subsequent episodes after the first one, people will probably feel pretty angry with you if they are paying for it and seeing ads at the same time. Once again, there's a small window where you can get away with it, but eventually your users are going to catch on. Be careful...
Another good idea may be to go ahead and prepare the first 2 or 3 episodes before you ever release that first one for free. That way, if people like they can go ahead and download the next episode or two right away, and you can start paying off that bandwidth debt right away too. Some may even feel compelled to finish the entire season before "airing" the first episode, but once again...this is somewhere you need to be careful on. If your audience realizes that you've completed the entire game and are simply slipping it out bit by bit to them simply so you can charge them more in the long run than you would have to have sold it all at once, they're not gonna be happy.
And now we come to the next aspect you need to consider... price. Luckily digital distribution offers you a beautiful thing called scalability. The bigger your audience, the more money you make and thus you can afford bigger bandwidth too. I would suggest to you to sell your episodes as cheaply as you can afford to. The cheaper they are, the more likely someone will be willing to pay for them, and thus you can potentially make a lot more money by selling them at a lower cost. Then some may choose to sell their new episodes at a higher price point the first week or two of their release, and then lower the price gradually over time. For example, you may charge $20 for your episode at first, then a few weeks later, you drop it to $10, then later on down the road, you drop it to $5. Now, of course that could just as easily be 5 then 2 then 1 depending on your business model.
When deciding how much to charge for each episode, you need to really look at how big each one will be, and how many you plan on releasing over the course of your season. If each episode only consists of a single level that will average out to about an hour or two of gameplay, but you plan on releasing 20 of them, I'd suggest selling them for about $5-10 if not less even. If you plan on releasing 5 or 6 episodes with about 6-8 hours of gameplay each, you'd probably want to charge around $10-20. These are all factors you need to look at when deciding all these things.
Lastly there are a few more small things to take into account. Do you even want to have seasons? Perhaps you just want to start with episode one and never stop until your ready to end the series. If you do go with a season model, perhaps you should give away the first episode of each subsequent season for free just as you did with the first one in case someone wants to start from there? Do you want to let your audience pick and choose which episodes they buy, or do you force them to own all the prior episodes first? (ie...you can't buy episode 4 unless you already have played through and completed 1,2 and 3) These are all tough, and very important questions you need to consider. Since you're giving away the first episode for free and merely selling the content of the subsequent episodes, perhaps it would be more beneficial for you to use an open source model with your actual game engine and digital distribution service? Maybe you might even want to build a general purpose engine that multiple "shows" can be purchased through, rather than just your own? There all kinds of options out there for you, and even more factors than I have covered here. Episodic gaming offers a potentially, very compelling experience for gamers and developers alike.....but when will anyone be ready to really pull it off? Are you?
Subscribe to:
Posts (Atom)