2005-08-11
GPL'd BSD?
I might be completely off base here, but from my understandings of the BSD license it would be pretty easy for someone to redistribute a BSD distro under the GPL wouldn't it? How come no one has done this? If there were a GPL/LGPL fork of BSD I'd be willing to bet it would explode and grow up to be much more well known than the other guys. This could help prove whether or not my views on the BSD license are true or not ;)
2005-08-06
Gamepark3D Ideas...
Everytime I see a product I want, but it's lacking features or design aspects I really wanted, I get the urge to come up with my own version. The Gamepark 2 or GPX2 was just announced recently, and while it looks great...don't get me wrong, there's still a few more features I'd like to see in perhaps the next version a couple years down the road from now.
The GPX2 that was just announced features dual ARM9 processors, 32MB of RAM and runs on embedded Linux.
It'll be a great little system for 2D gamers and indie developers, but I just wish it was a little more like the recently canned Tapwave Zodiac feature-wise :/
The GPX2, as it's currently code named, has almost everything I'd want in a handheld except for a couple things. First, I'm not an expert on handheld processors, so I have no idea what the best situation here is...but if the dual ARM9's aren't already, I'd like a CPU that's comparable to something in between the Nintendo DS and the Sony PSP. Since we're upping this imaginary model up to the Gamepark 3, lets go ahead and double the RAM too. Next, I'd like to see an nVidia GoForce 3D 4500 graphics chip added in. I would love for it to have a touch screen and a stylus too. Not only for PDA like functionality, but also for DS like gameplay options. While I'm at it, I'd like to bump the screen up to a 640x480 OLED screen instead of the 320x240 backlit LCD the GPX2 has. As while this may not be feasable right now, in a year or two it should be.
The photos of the GPX2 shows what looks like it could be an analogue pad, but might not be. The flat analogue pad of the PSP is probably it's coolest feature in my opinion, so of course I'd want it on this dream machine as well. I'd also like to see the L & R triggers given a little bit of analogue sensitivity. While we're at it, I'd like to see them angled down a little more as all the current handheld triggers are awkward to use.
I'd also love to have a built in Lithium-Ion battery instead of just using 2XAA's like the GPX2 will. The GBA SP's Lithium-Ion battery lasts way longer than the average alkaline will get you and it's rechargable. There's really no excuse for any handheld device not to have this.
And I think that's it, everything else on the GPX2 is great. Here's an illustration of what I'd like to see this new version look like ;)
The only feature in this illustration I haven't gone over is the "home menu" button found right above the analogue pad. This of course would pause the game and goto a main menu where you can choose between PDA functionality, media player, and the games. Another feature not listed that seems to be lacking from most handhelds is a brightness control. It could just be a menu option within the PDA environment, and it would let you play your games on a dimmer mode to conserve battery if you're getting low ;)
PS. If you haven't already heard, there's a contest to come up with a new name for the GPX2 running till the 15th of August at the official site ;)
UPDATE: I just discovered another system by Gamepark called the XGP that should be being announced pretty soon. It's much closer to the specs I wished for in this article, but it's still lacking the touchscreen and a couple other things. There's a teaser site at gamepark.com and more detailed info here.
The GPX2 that was just announced features dual ARM9 processors, 32MB of RAM and runs on embedded Linux.
It'll be a great little system for 2D gamers and indie developers, but I just wish it was a little more like the recently canned Tapwave Zodiac feature-wise :/
The GPX2, as it's currently code named, has almost everything I'd want in a handheld except for a couple things. First, I'm not an expert on handheld processors, so I have no idea what the best situation here is...but if the dual ARM9's aren't already, I'd like a CPU that's comparable to something in between the Nintendo DS and the Sony PSP. Since we're upping this imaginary model up to the Gamepark 3, lets go ahead and double the RAM too. Next, I'd like to see an nVidia GoForce 3D 4500 graphics chip added in. I would love for it to have a touch screen and a stylus too. Not only for PDA like functionality, but also for DS like gameplay options. While I'm at it, I'd like to bump the screen up to a 640x480 OLED screen instead of the 320x240 backlit LCD the GPX2 has. As while this may not be feasable right now, in a year or two it should be.
The photos of the GPX2 shows what looks like it could be an analogue pad, but might not be. The flat analogue pad of the PSP is probably it's coolest feature in my opinion, so of course I'd want it on this dream machine as well. I'd also like to see the L & R triggers given a little bit of analogue sensitivity. While we're at it, I'd like to see them angled down a little more as all the current handheld triggers are awkward to use.
I'd also love to have a built in Lithium-Ion battery instead of just using 2XAA's like the GPX2 will. The GBA SP's Lithium-Ion battery lasts way longer than the average alkaline will get you and it's rechargable. There's really no excuse for any handheld device not to have this.
And I think that's it, everything else on the GPX2 is great. Here's an illustration of what I'd like to see this new version look like ;)
The only feature in this illustration I haven't gone over is the "home menu" button found right above the analogue pad. This of course would pause the game and goto a main menu where you can choose between PDA functionality, media player, and the games. Another feature not listed that seems to be lacking from most handhelds is a brightness control. It could just be a menu option within the PDA environment, and it would let you play your games on a dimmer mode to conserve battery if you're getting low ;)
PS. If you haven't already heard, there's a contest to come up with a new name for the GPX2 running till the 15th of August at the official site ;)
UPDATE: I just discovered another system by Gamepark called the XGP that should be being announced pretty soon. It's much closer to the specs I wished for in this article, but it's still lacking the touchscreen and a couple other things. There's a teaser site at gamepark.com and more detailed info here.
2005-07-30
Gaim's A Bad Name
Quick Rant here...
Gaim, pretty much the most popular open source instant messenger, did something really silly. It's something that a lot of open source projects do, and that's picking a bad name. Well, I'm not saying the word "Gaim" is actually a bad name, but it's origins are. Now, I'll be upfront with you and tell you that most of this is an assumption, but it's a pretty easy one to make.
If you goto Gaim's FAQ, there's the question "What does Gaim stand for?". Their responce is to tell us that it stands for nothing and that the only proper ways to spell it are gaim and Gaim. Then they put particular emphesis to never call it "GAIM". And this is where my obvious assumption comes from. It's pretty clear that the original developers wanted to make a version of AOL Instant Messenger (AIM) for Linux. So, like a lot of other guys, they just tacked a 'G' on the front of AIM and they had GAIM. Now what the G stood for beats me, it could have been for Gnome, GTK, GNU, or something else...it doesn't matter. The point is, they made this mistake, and now they're trying to ignore it ever happened.
Developers, think harder on your program names! Just because you don't see it really being anything more than a hobby, doesn't mean it won't become hugely popular down the road by some chance. Now I'm not saying everyone needs to get delusions of grandeur here, but you just need to be a little more forward thinking. Then again, if you really know your program is crappy, don't waste a perfectly good name on it (your always free to rename it at a future release) :P
As for Gaim, I'd just suck it up and come up with a new acronym to better cover your mis-stepped tracks. How about "GTK-based Advanced Instant Messenger?" ...or if you want to be silly, you could go with "Grade A Instant Messenger"..heh.. I'm sure there are tons of ideas for it already out there though.
Look, if I see another open-source application that starts with 'YA' and stands for "yet another" I'm going to scream...well, I won't actually actually scream. I'll just post more and more rants like this... Seriously though, if you can't find a decent name for your application, ask some of your more creative friends.
PS. No more "something's not something" names either. I don't care how funny Stallman thinks it is :P
Gaim, pretty much the most popular open source instant messenger, did something really silly. It's something that a lot of open source projects do, and that's picking a bad name. Well, I'm not saying the word "Gaim" is actually a bad name, but it's origins are. Now, I'll be upfront with you and tell you that most of this is an assumption, but it's a pretty easy one to make.
If you goto Gaim's FAQ, there's the question "What does Gaim stand for?". Their responce is to tell us that it stands for nothing and that the only proper ways to spell it are gaim and Gaim. Then they put particular emphesis to never call it "GAIM". And this is where my obvious assumption comes from. It's pretty clear that the original developers wanted to make a version of AOL Instant Messenger (AIM) for Linux. So, like a lot of other guys, they just tacked a 'G' on the front of AIM and they had GAIM. Now what the G stood for beats me, it could have been for Gnome, GTK, GNU, or something else...it doesn't matter. The point is, they made this mistake, and now they're trying to ignore it ever happened.
Developers, think harder on your program names! Just because you don't see it really being anything more than a hobby, doesn't mean it won't become hugely popular down the road by some chance. Now I'm not saying everyone needs to get delusions of grandeur here, but you just need to be a little more forward thinking. Then again, if you really know your program is crappy, don't waste a perfectly good name on it (your always free to rename it at a future release) :P
As for Gaim, I'd just suck it up and come up with a new acronym to better cover your mis-stepped tracks. How about "GTK-based Advanced Instant Messenger?" ...or if you want to be silly, you could go with "Grade A Instant Messenger"..heh.. I'm sure there are tons of ideas for it already out there though.
Look, if I see another open-source application that starts with 'YA' and stands for "yet another" I'm going to scream...well, I won't actually actually scream. I'll just post more and more rants like this... Seriously though, if you can't find a decent name for your application, ask some of your more creative friends.
PS. No more "something's not something" names either. I don't care how funny Stallman thinks it is :P
2005-07-23
Alternative Funding For Game Development
I have spent the past few years thinking a lot on how to fund my game development in the future. This is the way I currently plan on doing business, and I would suggest all other independent developers move to a similar model if we are to continue making our own games, the way we want to make them. As a little background info, I'm working on my very first game right now, but it follows a slightly different approach since we have almost no budget to speak of and have not established ourselves in the industry yet. You may be quick to say "what does he know?" now, but I have been studying development practices and business models in the game industry for the past 10 years in preperation for now.
The current business model in the game industry promotes publishers to extreme realms of power even though they tend to have little to do with the actual games' production. It's a good bit like the model "old Hollywood" used before the 50's or so... Like game publishers now, the studios made the vast majority of the profits and the people who actually made the films got very little in return. Now a studio performs a much smaller role. They provide an investment budget (along with producers) and then help promote and distribute the films. It is fairly common for many of the actors and the production crew to make royalties in addition to their initial paycheck. My plan is very similar.
The first thing we have to do is put publishers in their place. They expect too much control over the games we make and the large number of crappy games released lately is a direct result of that. These people know about money, not art. And so that's all they should be concerned with and allowed to control. Many times the publisher will go as far as to buy the rights and trademarks to the game, its characters and name too. The developer tends to almost sell their soul to their publisher just to be allowed the privilege to make their game and then have it taken from them. This is not always the case, but it happens far far too much. The publisher should do just what its name implies, publish...and only publish. They should only concern themselves with the promotion and distribution of the games they publish. They may also want to invest money into the development of the games they publish, but this is optional and I'll discuss it more later. Once a game has been pitched to the publisher and the contracts are signed there should be little to no involvement from them in the development of the game. All they should be concerned with is publishing. And also since they are taking a much smaller role now, they will not get nearly as large a cut of the profits. The majority of the profits will go to the developers. I know you're thinking "no publisher will agree to this". And you are right if you speak of the current "big guys". The only way they will conform to such a model is if the entire development community rises up and forces them. Luckily, there are a few new publishers getting into the game these days that already agree with this model. Companies like O3 (On Our Own) Games are already out there ready to simply publish and not meddle with the development process.
Ok, so where does the money come from? Games are getting more and more expensive to create each year... What I propose is an distributed investment model. Think of it almost like shareholders and a corporation, but just for each individual title. We, as the developers, will have to have a little money flowing in already (or borrowed) to do this, but what you do is create a very basic prototype of the game. You draw up some initial story boards and game ideas; pretty much everything involved in preproduction. Then you come up with a budget. It is very important that this be a realistic budget. Now you start spreading the word that you need investors. You can pitch it to publishers if you want, but you must make clear that they are only investors and will have to give you the freedom to create your game the way you see fit. So what if no one wants to fund your game, but you think it's a winner? Fund it yourself. This may sound unreasonable, but by the end of this rant it shouldn't seem that far fetched. Most likely though you would want to do a mixture of the two. And here is the core of this model. The investment money acts like a deposit. Once that money has been paid back to the investors you split the profits 60/40 from that point on (60 being the developer cut). Why 60/40? Well, if you look at it from a utilitarian point of view, the game would not exist if you had not made it, so clearly the developer deserves a larger cut, but you wouldn't have gotten to make it if it weren't for the investment money. You may even want to split profits 50/50, but I think 60/40 is a very fair ratio.
This brings me to the third crucial part of the argument. The developer is now getting a rather nice cut of the profits (if we luck up and there are any), so how do you divide it? Ideally I would suggest only paying on-site staff royalties and set flat fees for any subcontracted/outsourced work, but you may find it better to split a little bit with them for a price cut. And this is where it all comes together. In the same way, you give your team a price cut. Your team gets paid a substantially smaller portion than the average developers upfront. If you have a programmer who would normally make 60-70 thousand at a traditional house, they will only get paid 30-40 thousand (maybe a little more, but it depends on your situation). BUT, by taking this smaller salary, your guys are also guaranteed a direct cut of the profits. Traditional publisher/developer houses could do this too, but they'd rather just pay their employees more, rather than give them a cut because it's usually less money that way. Because of this we only need around half the budget or so of what a normal company would. And so, because there is less investment risk, you now have a stronger control of the profits and creative freedom. Your developers make less up front, but have the potential to make much much more than they would have, depending on how successful your game is. Of course, you have to decide for yourself, but you will tend to want to divide your profit sharing by the basis of how much work each person did and how important their role in the development was. This also has another positive effect. Because the development team's pay is directly affected by the games sales, it will be more important to them that it is successful and they will feel like they own a larger portion of the game. This is very good for company morale. Now comes the other tidbit I mentioned earlier. If members of your development team invest money into the initial budget for the game then they not only get their royalties from making it, but also a cut of the investor profits. The whole point here is to make development a more personal process and keep as little money as possible tied up in abstract businesses. This also means you'll want to be very smart with how you spend your money during development. I would advise you to invest in using open source development tools (and contributing back to them when you can) and not buy the most expensive, be-all-end-all workstations. The less money your company has to spend on development, the better your chance for finding enough investors.
Yes, this business model is a little risky, but that's why it's called business. Especially in the entertainment industry, you are never guaranteed to be successful no matter how much you play it safe. Of course the situation I described is an ideal, so you'll need to be flexible; just don't let your publisher break you ;)
The current business model in the game industry promotes publishers to extreme realms of power even though they tend to have little to do with the actual games' production. It's a good bit like the model "old Hollywood" used before the 50's or so... Like game publishers now, the studios made the vast majority of the profits and the people who actually made the films got very little in return. Now a studio performs a much smaller role. They provide an investment budget (along with producers) and then help promote and distribute the films. It is fairly common for many of the actors and the production crew to make royalties in addition to their initial paycheck. My plan is very similar.
The first thing we have to do is put publishers in their place. They expect too much control over the games we make and the large number of crappy games released lately is a direct result of that. These people know about money, not art. And so that's all they should be concerned with and allowed to control. Many times the publisher will go as far as to buy the rights and trademarks to the game, its characters and name too. The developer tends to almost sell their soul to their publisher just to be allowed the privilege to make their game and then have it taken from them. This is not always the case, but it happens far far too much. The publisher should do just what its name implies, publish...and only publish. They should only concern themselves with the promotion and distribution of the games they publish. They may also want to invest money into the development of the games they publish, but this is optional and I'll discuss it more later. Once a game has been pitched to the publisher and the contracts are signed there should be little to no involvement from them in the development of the game. All they should be concerned with is publishing. And also since they are taking a much smaller role now, they will not get nearly as large a cut of the profits. The majority of the profits will go to the developers. I know you're thinking "no publisher will agree to this". And you are right if you speak of the current "big guys". The only way they will conform to such a model is if the entire development community rises up and forces them. Luckily, there are a few new publishers getting into the game these days that already agree with this model. Companies like O3 (On Our Own) Games are already out there ready to simply publish and not meddle with the development process.
Ok, so where does the money come from? Games are getting more and more expensive to create each year... What I propose is an distributed investment model. Think of it almost like shareholders and a corporation, but just for each individual title. We, as the developers, will have to have a little money flowing in already (or borrowed) to do this, but what you do is create a very basic prototype of the game. You draw up some initial story boards and game ideas; pretty much everything involved in preproduction. Then you come up with a budget. It is very important that this be a realistic budget. Now you start spreading the word that you need investors. You can pitch it to publishers if you want, but you must make clear that they are only investors and will have to give you the freedom to create your game the way you see fit. So what if no one wants to fund your game, but you think it's a winner? Fund it yourself. This may sound unreasonable, but by the end of this rant it shouldn't seem that far fetched. Most likely though you would want to do a mixture of the two. And here is the core of this model. The investment money acts like a deposit. Once that money has been paid back to the investors you split the profits 60/40 from that point on (60 being the developer cut). Why 60/40? Well, if you look at it from a utilitarian point of view, the game would not exist if you had not made it, so clearly the developer deserves a larger cut, but you wouldn't have gotten to make it if it weren't for the investment money. You may even want to split profits 50/50, but I think 60/40 is a very fair ratio.
This brings me to the third crucial part of the argument. The developer is now getting a rather nice cut of the profits (if we luck up and there are any), so how do you divide it? Ideally I would suggest only paying on-site staff royalties and set flat fees for any subcontracted/outsourced work, but you may find it better to split a little bit with them for a price cut. And this is where it all comes together. In the same way, you give your team a price cut. Your team gets paid a substantially smaller portion than the average developers upfront. If you have a programmer who would normally make 60-70 thousand at a traditional house, they will only get paid 30-40 thousand (maybe a little more, but it depends on your situation). BUT, by taking this smaller salary, your guys are also guaranteed a direct cut of the profits. Traditional publisher/developer houses could do this too, but they'd rather just pay their employees more, rather than give them a cut because it's usually less money that way. Because of this we only need around half the budget or so of what a normal company would. And so, because there is less investment risk, you now have a stronger control of the profits and creative freedom. Your developers make less up front, but have the potential to make much much more than they would have, depending on how successful your game is. Of course, you have to decide for yourself, but you will tend to want to divide your profit sharing by the basis of how much work each person did and how important their role in the development was. This also has another positive effect. Because the development team's pay is directly affected by the games sales, it will be more important to them that it is successful and they will feel like they own a larger portion of the game. This is very good for company morale. Now comes the other tidbit I mentioned earlier. If members of your development team invest money into the initial budget for the game then they not only get their royalties from making it, but also a cut of the investor profits. The whole point here is to make development a more personal process and keep as little money as possible tied up in abstract businesses. This also means you'll want to be very smart with how you spend your money during development. I would advise you to invest in using open source development tools (and contributing back to them when you can) and not buy the most expensive, be-all-end-all workstations. The less money your company has to spend on development, the better your chance for finding enough investors.
Yes, this business model is a little risky, but that's why it's called business. Especially in the entertainment industry, you are never guaranteed to be successful no matter how much you play it safe. Of course the situation I described is an ideal, so you'll need to be flexible; just don't let your publisher break you ;)
Open Source and Commericial Videogames
As development costs continue to rise the question raises of how do we cope with it? Some have suggested raising retail prices and letting gamers pay for the increases. Others want to outsource portions of their games to small countries where workers are paid much less. I believe the true answer lies in open source.
If you're not familiar with what open source is, then this isn't really the place to learn about it, but to put it briefly... With open source software, all users of the software are given the complete source code and are allowed to tweak it how they need to and even redistribute it depending on what the licensing conditions are. By having the source code open to the public, it encourages a community to build around it. This promotes two things, it give users the freedom to alter their software as where most EULA type agreements strictly prohibit it. And it allows developers to reuse code instead of recreating the wheel. Another thing it allows is for software longevity that a single company would not be able to provide traditionally. By companies who use this software contributing back code to the project or even just monetary donations these communities can thrive on less money than it would normally cost to either buy software or create your own tools. One more great benefit is that because there are so many programmers examining the code, bugs and filtered out at a very rapid rate while development of new features is usually much faster than traditional methods as well. But do keep in mind that not all open source software is free of charge.
Now lets look at how this can benefit you and your games... This will probably be the most helpful to independent developers, but it can be beneficial to just about any company really. There are two portions to this argument. The first is the most obvious, use open source content creation tools. Almost every tool we use to create our games has a free, open source alternative to it. I'm not going to be naive here and tell you they can directly replace your current tools, but many of them are reaching a level of maturity where they're ready for you to start migrating now. A few of the better free projects out there are:
Programming:
Anjuta (General IDE for Linux)
Dev C++ (C/C++ IDE for Windows)
GCC (Command line compiler)
Graphics:
Blender (3D modeller/animator)
The GIMP (2D raster image editor)
Inkscape (2D vector image tool)
Audio:
Audacity (Audio editor, multitrack)
Rosegarden (Music sequencer, synthesizer, and composition tool)
There are also numerous open libraries you can use for your game. I'm sure you've heard of OpenGL before. Well there is also OpenAL for audio. And if you're looking for something similar to Microsoft's Direct X, SDL is a very nice package. If you don't want to pay for a license to use MP3s in your game you can use an open format like Ogg Vorbis. In fact with vorbis you can even encode your audio in 5.1. There are numerous video formats too. Xvid and Ogg Theora are probably the best ones though.
At this point you may be thinking...that's great for development tools, but it's not feasible for my actual game...We need to get paid! Which brings me to my second point. What is a videogame? What makes each one unique from the others? I don't think anyone could honestly say the graphics engine. What about the physics engine? Nope...those are starting to become a dime a dozen these days too. The entire game engine? Not really...the Quake 3 engine has been used for many different games, some of which aren't even shooters. It's the content that matters. It's the levels, the characters, the story, the music, etc... That's what's really valuable in your game, the game engine is merely a platform on which to build your game.
Why not make your game engine open source? Unless you think you'll be able to come up with a better engine than Epic's Unreal 3 engine or Carmack's next creation, then there's really no point in keeping it to yourself. If you're not comfortable releasing your entire engine to the public then at least consider releasing portions. Release just the rendering engine, or just the audio engine. By releasing them to the public you have much more to gain than lose. If any other developers use this engine and you have released your code under a LGPL style license, they will be required to release any changes they make to it. You couldn't quite get your normal mapping looking right? Oh, well these guys over here did, and now you're free to use it too. It may be hard to swallow, but the technology behind your game does not make it special, and if we all work on it together we all benefit and you can spend more time tuning your levels and timings. Your complete game can be released under a more restricive licence that prevents people from legally distributing your entire game of course, but the engine(s) are released under a different license. Also as I said before, this give your users a much higher longevity as when they switch to a new/different operating system, they're free to port it over themselves and can allow them to play their game for decades rather than the regular 5 year span. Most DOS or even some Windows 95 games are a royal pain to get running under Windows XP, and now the community of players can work together to bring your game up to date, free of charge.
There are a few good open source engines already out there and ready for you to use. Ogre's probably the best one I've seen so far, and Crystal Space is pretty nice as well. Need a physics engine? Try OPAL which is built upon ODE. If your looking to build a MMORPG the guys at Nevrax have released their engine from Saga of Ryzom too. Oh, by the way all of ID Software's engines, Quake 3 and older, are open sourced now too. There are tons of options already out there, but if you still want to make your own engine from scratch...releasing it as open source can benefit both you and the community down the road.
What are the drawbacks to this method of development? Well one major concern to some is that players will be able to hack and cheat easier, but has traditional closed source licensing prevented this either? Hacking and cheating are problems no matter which way you go. Luckily many resourceful security experts have had to deal with similar issues in the past on other open projects. You end up just having to be smarter than the hackers. Through clever algorithms and standard encryption and authentication methods you can make your public code even harder to crack than the normal hidden code.
Once the engines and development tools of games become more standardized and open we will all be free to explore more new types of games. Your development time will be cut dramatically and you can focus more on perfecting your games. The price and gamble of developing risky titles can drop greatly, especially when combined with my alternative funding/payment ideas.
If you're not familiar with what open source is, then this isn't really the place to learn about it, but to put it briefly... With open source software, all users of the software are given the complete source code and are allowed to tweak it how they need to and even redistribute it depending on what the licensing conditions are. By having the source code open to the public, it encourages a community to build around it. This promotes two things, it give users the freedom to alter their software as where most EULA type agreements strictly prohibit it. And it allows developers to reuse code instead of recreating the wheel. Another thing it allows is for software longevity that a single company would not be able to provide traditionally. By companies who use this software contributing back code to the project or even just monetary donations these communities can thrive on less money than it would normally cost to either buy software or create your own tools. One more great benefit is that because there are so many programmers examining the code, bugs and filtered out at a very rapid rate while development of new features is usually much faster than traditional methods as well. But do keep in mind that not all open source software is free of charge.
Now lets look at how this can benefit you and your games... This will probably be the most helpful to independent developers, but it can be beneficial to just about any company really. There are two portions to this argument. The first is the most obvious, use open source content creation tools. Almost every tool we use to create our games has a free, open source alternative to it. I'm not going to be naive here and tell you they can directly replace your current tools, but many of them are reaching a level of maturity where they're ready for you to start migrating now. A few of the better free projects out there are:
Programming:
Anjuta (General IDE for Linux)
Dev C++ (C/C++ IDE for Windows)
GCC (Command line compiler)
Graphics:
Blender (3D modeller/animator)
The GIMP (2D raster image editor)
Inkscape (2D vector image tool)
Audio:
Audacity (Audio editor, multitrack)
Rosegarden (Music sequencer, synthesizer, and composition tool)
There are also numerous open libraries you can use for your game. I'm sure you've heard of OpenGL before. Well there is also OpenAL for audio. And if you're looking for something similar to Microsoft's Direct X, SDL is a very nice package. If you don't want to pay for a license to use MP3s in your game you can use an open format like Ogg Vorbis. In fact with vorbis you can even encode your audio in 5.1. There are numerous video formats too. Xvid and Ogg Theora are probably the best ones though.
At this point you may be thinking...that's great for development tools, but it's not feasible for my actual game...We need to get paid! Which brings me to my second point. What is a videogame? What makes each one unique from the others? I don't think anyone could honestly say the graphics engine. What about the physics engine? Nope...those are starting to become a dime a dozen these days too. The entire game engine? Not really...the Quake 3 engine has been used for many different games, some of which aren't even shooters. It's the content that matters. It's the levels, the characters, the story, the music, etc... That's what's really valuable in your game, the game engine is merely a platform on which to build your game.
Why not make your game engine open source? Unless you think you'll be able to come up with a better engine than Epic's Unreal 3 engine or Carmack's next creation, then there's really no point in keeping it to yourself. If you're not comfortable releasing your entire engine to the public then at least consider releasing portions. Release just the rendering engine, or just the audio engine. By releasing them to the public you have much more to gain than lose. If any other developers use this engine and you have released your code under a LGPL style license, they will be required to release any changes they make to it. You couldn't quite get your normal mapping looking right? Oh, well these guys over here did, and now you're free to use it too. It may be hard to swallow, but the technology behind your game does not make it special, and if we all work on it together we all benefit and you can spend more time tuning your levels and timings. Your complete game can be released under a more restricive licence that prevents people from legally distributing your entire game of course, but the engine(s) are released under a different license. Also as I said before, this give your users a much higher longevity as when they switch to a new/different operating system, they're free to port it over themselves and can allow them to play their game for decades rather than the regular 5 year span. Most DOS or even some Windows 95 games are a royal pain to get running under Windows XP, and now the community of players can work together to bring your game up to date, free of charge.
There are a few good open source engines already out there and ready for you to use. Ogre's probably the best one I've seen so far, and Crystal Space is pretty nice as well. Need a physics engine? Try OPAL which is built upon ODE. If your looking to build a MMORPG the guys at Nevrax have released their engine from Saga of Ryzom too. Oh, by the way all of ID Software's engines, Quake 3 and older, are open sourced now too. There are tons of options already out there, but if you still want to make your own engine from scratch...releasing it as open source can benefit both you and the community down the road.
What are the drawbacks to this method of development? Well one major concern to some is that players will be able to hack and cheat easier, but has traditional closed source licensing prevented this either? Hacking and cheating are problems no matter which way you go. Luckily many resourceful security experts have had to deal with similar issues in the past on other open projects. You end up just having to be smarter than the hackers. Through clever algorithms and standard encryption and authentication methods you can make your public code even harder to crack than the normal hidden code.
Once the engines and development tools of games become more standardized and open we will all be free to explore more new types of games. Your development time will be cut dramatically and you can focus more on perfecting your games. The price and gamble of developing risky titles can drop greatly, especially when combined with my alternative funding/payment ideas.
Just how free should your software be?
Eric S. Raymond recently went on record saying that we no longer need the GPL. He believes the restrictions it puts on developers are unnecessary as open source has already “proven itself” to be the superior method for software development. This goes back to the same kind of arguments the free/open source software community have been arguing about for years. What's better? The GPL style license or the BSD style license? There are hundreds of open source licenses out there, but they can all pretty much fall into one of these two categories.
So which one is better? It really comes down to what you want to happen to your software after it has been released. As Mr. Raymond's book “The Cathedral and the Bazaar” states, the power of the open source development model revolves around an involved community. If no one contributes back to your software, then it's no better off than a proprietary model. The main reason the GNU GPL was created was to force everyone to play fair with the community. While sometimes the GNU LGPL is better so that your software can be mixed with non-free software, they both share these same rules. All of Mr. Stallman's free software licenses require the developer to release back to the community any changes or improvements they have made. By putting this restriction on the code, it makes the software worth a great deal even though it is free of charge. Many companies won't use GPL'd code because they do not want to release their own code in exchange for the use of free software. To many people, GPL'd software costs much more than if they had payed for proprietary software, and this can be seen as good and bad depending on your position. Once again, the GPL and LGPL are the most commonly used licenses of this type, but are far from the only ones.
BSD style licenses take a very different approach. Most BSD style licenses have absolutely no restriction over it's use except that any derivative code have a notice of who wrote the original version. This is the kind of license E.S.R. is endorsing with his new outlook on licensing. Both he and the BSD community believe that the benefits of contributing code back to it's originators will be enough incentive to make developers want to contribute back. Unfortunately we're dealing with human nature here, so this ideology is a pipe dream at best. As companies and corporations get more and more involved with open source software this will become more apparent. In the business world, people are usually very short sighted and can't see past this fiscal year and the bottom line. These are the kind of people who won't contribute back to the community unless they are forced, and that is the exact reason for the restrictions in GPL style licensing. If the GPL can make your software worth more than pay/proprietary software, then the BSD license is like saying “oh I just made this for fun, contribute back to it if you feel like it.” The only restriction of namesake is very short sighted which fits perfectly with the corporate
mindset. Many people would argue that this is a much “free-er” situation than GPL like licenses, but at what cost? Just how free does your software need to be? What are your motives? The only place I could see using a BSD type licence would be worthwhile would be for
protocols and standards.
It's no question that Linux and other GPL'd software are exploding right now. Yet for some reason, BSD, which has been in existence decades longer than both GNU or Linux, is still fairly small and unknown to most. I'm not saying BSD and it's derivatives are bad software by any means. I know some people who find it far superior to Linux at times. But the BSD community would have you believe that its slow growth is only due to stringent testing and exclusivity amongst it's developers; however, I fully believe it's got a whole lot more to do with their licensing. To Mr. Raymond, all I have to say is maybe you've spent too much time dealing with just your computer and need to meet some people in the real world; they're not all as nice as we'd like them to be.
Dark Scribe
I made a modification of the "Scribe" theme on Blogger. I'm calling it "Dark Scribe"... I liked the textures of scribe, but I hate beige and browns :P
2005-07-22
First Post
Well...I'm gonna give blogger a shot and then choose whether or not to stay with my Live Journal account.
Subscribe to:
Posts (Atom)