Table of Contents
- Synthesis of Webber’s blog post
- Reason’s FOSS games aren’t completed
- How FOSS games should be created
Synthesis of Webber’s blog post
Last month, Christopher Webber wrote about why games matter for free and open source software (FOSS). In his ramblings, you might catch things like, games matter because we don’t want DRM-filled games, we want to control the direction of technology, and we want to make better hackers. Now how does that sound to a business man? Not very good. Apparently, Webber isn’t looking to win any allies in the proprietary software community, whom we should be trying to convince why free and open source software is a good thing.
Webber also tries to make a point on why we need games in society – an argument that he himself reduces down to because-we’re-bored. Sound any better than his other arguments? – Not from my perspective.
If games are really important to the free and open source software (FOSS) community, then what are the reasons we need them?
First, let’s synthesize what Webber said, and then maybe you’ll begin to agree with him or at least see his point of view. Webber states that games direct technology. While this is not necessarily true in every sense (after all, the computer was invented for business purposes, is used for such purposes, and always will be used for such purposes), he does make a point. For one thing, games can be heavily graphics-dependent. What can improve graphics and the speed of the game? – Build better hardware (graphics cards, mother boards, input devices)! Games can also be audio-dependent, hence this drives improvement in audio drivers and sound cards. And of course, all of this hardware has to be controlled by software, free or proprietary. Hence, for your computer’s operating system to be completely free (with respect to software rights even if not cost), we must ensure that the development of such supporting software is free. After all, even if your system’s software isn’t going to be running games, the future of the software you are using will probably be in some way developed to satisfy the needs of the gaming industry, and currently the software fulfilling that role is proprietary. Now, if there were FOSS games in development that were as demanding as proprietary games with respect to graphics and sound and such, it would creative an incentive for the FOSS community to develop such software long before it is needed for non-gamers.
That answers a development question, but now what about hacking? After all, most hacking is looked down on. Well actually, hacking can be a good thing (and not just because we need to hack virus software to see what’s in it so we can stop it, although that is a good reason). Free and open source software is open to be hacked, and this is necessary for improvement of the software when the original code of the program is not provided. By having the ability to see the code, you can also learn alot from that code. Hence, in the FOSS community, hacking is for improvement both of the software and one’s own knowledge of programming. Note, however, this is a different kind of hacking than hacking someone’s computer.
Finally, the weakest argument in Webber’s post was that games were to liven up life. While many people feel this way, I obviously don’t. There are plenty of other things to do in life to have a fulfilling life, and you just need to go find them. More important to this article, the fact that someone is bored is hardly a reason for games to be made by the FOSS community as opposed to being proprietary.
Now that you’ve heard Webber’s arguments, you might ask if anything else could be added to this tiny list. Sure! As an extension to the improvement of software, game development can result in the production of very useful tools, such as libraries and models. Models, for instance, are used in computer-aided modelling that assists engineering of all kinds of products. If the models and modelling software weren’t buried in copyright restrictions, they could be readily altered and improved to suit the needs of the designer without having to order a custom job to be done on the software. This saves time and money, which ultimately trickles down to you, the consumer. Now consider libraries. Nikolaus Gebhardt and his crew created the most powerful, lightweight, free and open source 3D C++ engine on the net: irrlicht. As an engine, it’s also a library full of neat tools for other jobs. While it’s not perfectly optimized, it is professionally written, and you can edit it any way you like. You can use it for both personal projects and professional ones.
Thus, all in all, the development of games in the open source community could drive the production of free and open source software prior to its need so that we don’t have to put up with proprietary stuff until someone develops the alternative.
Reasons FOSS games aren’t completed
Here’s the summary plus my own ideas:
- Lack of funds – As the old business adage goes, “Time is money.” People end up working on games in their spare time. When there is no spare time, the game gets put on hold.
- Loss of interest – Gamers tend to be the ones developing games because they have the passion to do it. Unfortunately, after months of not developing anything entertaining, gamers tend to shelf the project in favor of something new that catches their fancy. Those who do have a constant passion tend to finish their game. TORCs is an example.
- Lack of help – Sometimes only one person has the idea and no one cares enough about the project to help them out. Or, as is the case many times, only so many people are able to work on the game. Amongst other reasons for this is the fact that introducing a new man to the project requires investing time in someone who may or may not stick with the project to fruition.
- Lack of skill – Alot of programming entails pouring through books and/or scrounging the internet looking for the solution. While the solution may be out there, this not only takes time, but the first solution found isn’t always the best one.
- Disorganization – Task management delegation and job assignment can be tricky in projects not done by organizations. FOSS projects depend on everyone being assigned a job and then having to fulfill it. Questions that might come up in this category include: Is there a schedule? What happens if so-and-so quits? Can the newbie do anything?
How FOSS games should be created
Before you jump to conclusions, this section is NOT going to simply say “fix the above problems”. We already know those need to be fixed. What can we do about them? Here’s some ideas on how to fix the problems:
1) Develop the library.
This is the responsibility of the community and one that has never really been fulfilled. There needs to be a engine that makes it easy to write a game. This has been done for 2D games with respect to level building and somewhat for 3D games, but what I mean is code-wise. Sure, you can build a level, but what about controlling characters, doing in-game cinematic scenes, and handling combat? It’s possible programmers think these things ought to be left to customization, since we never really know what the game programmer wants, but that’s not true. How many games contain a menu screen or a health bar? Even if features aren’t used in the final game, maybe one day someone will want to mod a game and make it better using those previously unused features in the library. (Incidentally, I’ve already started a project for this without a game, using, of course, irrlicht engine.)
2) Find people with a constant passion.
It’s easy to find people with passion. It’s NOT easy to find people with a constant passion, one that has been with them for years and looks like it will stick with them. Even in business, the guy with the corner office should be the guy who has the passion to do the job and the willingness to learn how to do it even if he doesn’t have the skills. So how do you find people with a constant passion? Well, if you’re looking online for help (the usual way), try looking at forums and start talking with people about your idea. If they don’t seem interested, don’t waste your time talking them into doing it; they don’t have the passion you need to get the job done.
3) Keep everyone happy.
Whenever you start a project, it needs to be flexible enough to please all of the initial members in your group so that they keep their passion. Everyone should be able to do what they enjoy without too much burden of menial tasks (though there are always many of those).
4) Newbies are welcome but unnecessary.
This is important. A new man can really make the job easier, but the project needs to be under construction in such a way that if someone new wants to help, they can help without the job of anyone else being dependent on them. For games, this can means you can assign newbies to two things: modeling, game art, and story. Believe me, any newbie will love you for getting those jobs. Although these jobs need to be done eventually (whether the newbie completes them or not), they aren’t foundational.
And there you have it. My general summary on what to do about making FOSS games.