How to Mix Open Source and Games 88
MikeDartt writes "Linux Today has an excellent article on how to best mix game creation with open source software and the Bazaar model of development. In short, the author looks at why games are different from other pieces of software, and suggests that the technical aspects of the game (engine, modeler, scripting language, etc.) be OSS, with the proprietary/differentiating focus on design and art. "
Art is not programming (Score:2)
As an artist (written, visual, music, etc.), I feel that art should only be open if the artist wants it open, and I don't want most of what I do open. Do you want to know why?
Because I hate my job, and I love my art.
I am an artist because it makes me happy, and I work to pay the bills. They are NOT the same thing. Sorry. When I have enough money to not have to work and get any more money, then I'll give my stuff away. No problem. Maybe I'm too concerned about the real world of my life and those that are dependant on me. (shrug) Who knows? All I know is that I have obligations, and if I can get money from doing something I love and live in a fashion I like, I am sure as hell gonna do it.
Another point: I don't want everyone to have the PSD's of my photoshop editing because I don't want them to butcher it. I don't want it changed, because everything is there for a reason.
Art is NOT programming. It doesn't break. But there is a line here with levels for games (like quake or half-life). This is the hard part:
Is a level programming or art, or both? Can source be art? Can a program be art? I can answer the two of them as a "Yes" and one as "both."
But should it matter? In the long run? Really? All I am concerned about is my own ass and those around me. Sorry if that sounds selfish, but I don't like being poor.
Thanks for your time:
bunk... (Score:1)
Sure you can release the code to game engines, but most game engines are usually obsolete within a year of release, and if the engine is good, other companies will pay for it. What may be nice is for the companies to release the source to the engine a few years after the product is no longer being sold or making money. Like what id does. But designing a game engine is always a race against time. you sometimes have to tos everything you did last month if you find a much more efficient way to do things, and sometimes you can't toss it out cause you are behind schedule, so you leave it for the next version of the game, but you may not be able to use it then either, cause hardware would have changed, and you would need to push it even more than you did this time. OSS just can't apply. Games are purly entertainment. if you want entertainment for free, then you are just being a cheap shit. Now don't get me wrong, i have nothing against people making a game engine or games and giving it away, hell, it will help alot of programmers understand how its done, and they can then play with the code and make cool stuff out of it. But when you look at the industry that these game companies operate in, its scary! they are always behind schedule to get the next "big thing" out there... why? well, cause everybody want the most textures, and frames per second that there brand new $(insert price) computer cost them.
Now some types of games like flightsims could be oss, but the problem with that is there arn't many folks who know about the physics of aerodynamics, and such things. and with alot of games, there is usually alot of stuff involved in the actuall engine that will make or break a good game.
So, don't start preaching from that tower as yet, seening source code does not mean better code. not always.
Quake lasted a while (Score:1)
Crystal-Space could be an engine like that. It needs lots of work, but it really seams to be as good as the quake3 engine. The level editor is very "new", thats why the screenshots don't look that hot. However, as far as visable features, it seems to match most of Q3's features.
planning to GPL our 3D game engine (Score:1)
It currently uses 3D studio max for level creation (geometry may be imported from several packages).
So once the engine is working, the big chalenge will be to pick a 3D editor for the level editing system.
Any programmers interested in assisting please contact me at kts@worldfoundry.org.
Kevin Seghetti
Startup Cost - Reinvention = Better Games (Score:1)
The movie "industry" was born in an industrial age, and the characteristics of "building" a movie seem similar to building anything else: Get a whole bunch of money, spend the money to build something, sell the something at a profit, return the capital + some profit to the investors, keep the remaining profit.
The problem with this model is that there is only so much capital to go around, which creates a barrier for would-be builders.
Add to that the current wisdom in building computer games which says: invest 10,000 man-hours to come up with the world's greatest graphics engine, and the remaining 20,000 man-hours to debug it. Then, spend an afternoon on the gameplay and copy it to a CD.
This is the movie industry equivalent of inventing the camera, film, sound equipment, editing facilities and building a soundstage before starting work on the actual film. I suggest movies would be far lower quality if this were necessary in each case.
If the computer game industry is to succeed, the reinvention must be reduced considerably. Using Open Source or Free Software to make good game engine technology available to the game industry at large would make it possible for games to be constructed where the majority of hours are spent on gameplay and quality. If Open Source or Free Software were unavailable, then perhaps the engines could be licensed.
In any case, spending construction time on gameplay and quality would have a positive effect on computer games.
Just a thought or two.
On a similar topic... (Score:1)
Re:On a similar topic... (Score:1)
Not for commercial... (Score:1)
Shareware/freeware projects, however, should flourish. Imagine a thousand linux hackers all working together on some funky new network hack n' slash.
Re:OSS is not the answer to everything -- depends (Score:2)
This is true for some games. Like stupid shooters and arcade ones that will be warezed anyway. But I'm more interested in simulations and rpg.
In the racing simulation domain, it's the support, the docs, and the engine who counts, but also what the users will do with it. For example, gp2, gplegends are 2 games that have been extensively upgraded by people who reversed engineered them to build new cars, new seasons, new tracks.
Had them been opensourced, this developpement would have been far more efficient, and it could have boosted the sales of a few games. (Especially since a few companies can't do everything an user can... like for example the company that brought us sports car gt and didn't implement extern car damages to not hurt manufacturers' image)
My point is that it is feasable for those kinds of games to exist, and be successful, even if they had been opensourced... as long as the support is sufficient and good.
Stereotyping game programmers and programming (Score:3)
1. Don't care about quality, only ego.
2. Produce poor, quick, hackey code.
3. Don't understand scripting languages.
4. Are less usefull than Artists/Designers
He also goes on to say that
5. 3d engines are trivial to program.
Although these stereotypes may exist in the game programmer community, I believe that this is a romantisized view and is not grounded in reality. Here are my rebuttles.
1 and 2. If game programmers didn't care about quality, then most of the titles that ship wouldn't have the level of polish that they do. When you buy a game off the shelf at best buy, take it home, and play it, you usually don't have to worry about whether you have the correct libraries or fear that it will crash. Also, if game programmers produce such low quality code, why is 3d engine licensing so prevalant? Not just Id, but also Unreal, Monolith and friends.
3. At GDC this year, there were several talks about scripting languages that I found quite interesting. Nihilistic is using an embedded java interpreter for their scripting language. Why would the open source community be better at this?
4. There are plenty of titles out there with bad art that are still a lot of fun to play. I wouldn't say that nettrek or xpilot have particularly good art, but a lot of people find these games more fun than the latest stylized buggy games. Programmers are just as important if not more because they implement, rather than simply adding spice.
5. If 3d engines were trivial to develop, why is the industry in a licensing frenzy? Please remember that 3d engine != 3d API. An engine has much more responsibility than simple triangle texture mapping.
Finally, I don't see how such a money driven industry can profit from open source. RAD and other companies like it make all of there money licensing game engine utilities, and would have no source of income if they opensourced their products.
--Tom
3d modeller for linux (Score:1)
just a word of caution, creating a 3d editor is different from most oss projects, even Gimp imo, in that the user interface can make or break the program. alias/wavefront i belive has a dedicated research division just for studying psychological and workflow effects of user interfaces. such an editor would require a serious amount of planning and design up front so its less likely that the project would mushroom out from one person's efforts.
what you see in top of the line programs like softimage|3d and Maya is nothing that can't be learned from back issues of siggraph proceedings and good design. anyone interested?
pagan
--------
http://q3arena.net/mentalvortex/md3view/
http://pagantech.hypermart.net/
Re:Roguelikes! (and types of games) (Score:1)
One of the reasons that roguelike started up was so the authors could play there own game, and that's probably an important point for OS developers. Almost all OS projects start off with a programmer creating something for his own needs, then he releases it.
I can't imagine creating Myst to play by myself. After all the hours spent developing it, I would know the answers to all the puzzles. If a game is going to develop OSS-style, it probably has to be one the authors will want to play a lot.
HA HA HA; Another dumb OSS idea (Score:1)
Re:Stereotyping game programmers and programming (Score:1)
Comments from a maintainer (Score:3)
A comabination of bad code, almost superb design, and bad licence had killed it. The design was so good that any programmer who started working with it was immediately tempted to upgrade all the code to fit it (an unrewarding task which caused every one of them to give up almost immediately), and the license not only stated that no money could be made on it, but also forbade the distribution of modifications without the author's permission.
The first thing I did was rewrite the UI for the inventory (it'd been a sore point for everyone; hard to learn and hard to use). I showed that to the author and the current maintainer; the maintainer gave me permission to take over, and the author gave me permission to change the license. Working with him, I chose the LGPL, modified to fit the needs of an expandible game (more on this later).
In just a couple of days, I started recieving offers of help from people who had been working on Omega for all those years. The sheer volume of fixed code was almost incredible. Even when I was drawn aside for several months by my work schedule, their work proceeded. If code had been money, my investment in the inventory code would have paid off hundredfold
I credit this partially to the resumption of development on a formerly-thought-dead project (which isn't something most people have an option for), but also to the change in license.
The license fits my idea of gaming. Specifically, I wanted the game to be free, but at the same time I also wanted it to have secrets -- as this article points out. So I started by defining the terms of the LGPL. In my game's context, I defined the "library" (the part protected by the viral clauses) to be the engine, the entire part written in C, plus all of the original game no matter what language. In other words, there's no way to keep a secret that's already out, and I wanted to make sure that a fully playable game was always freely available. I then defined the "application" -- the completely unprotected part -- as being add-on modules.
I haven't finished the licence, nor have I linked Python into Omega. Once I finish the second I'll be able to define the terms I need to make sure the original game remains free and my secrets remain protected.
One other interesting thing I'm doing is adding a cheat mode and relatively strong anti-crack to the savefiles. I want to discourage people from cracking any part of the game for the purpose of cheating, so I'm making cheating legit, and making the only penalty being that all cheaters get moved onto a "cheater's hiscores" list so that they don't get in the way of the legit players. I'm not sure how this will work, but we'll see.
-Billy
Re: (random) Myst (Score:1)
The thing about games is that they have to be god to be noticed. For my definition of 'good', see my post a couple of levels up (roguelikes (and game types)). Now if you're writing a small (~share)ware game, or a blockbuster you're working to different standards.
If I understand correctly, your suggestion for a random or AI based world (as well as NPCs) looks very intesting. A plot-based game where the plot isn't directly written. It would certainly be worth looking into. The problem is, if you've ever GMed a RL RPG (dig those nLAs *:) ), you'll know that players often need a little nudge in the right direction, or a little fudge in reality to keep the excitement there. Lots of people know the frustration of trying to find the button to open the gate to the next level. In a really random world this would be worse because you won't necessarily know that there is a button.
This could, of course, be gotten around by having lots of semi-interconnected plots (randomly generated), and letting the player go through them as they want. At this stage, tho', it starts to get BIG!
Of course, I may have missed your idea/point completely, but it's given me a few nasty ideas. Thanks. *:)
Cheers,
Noisdsn
What in the world is the author thinking? (Score:2)
[Games]
This two sentences have at least 3 inaccuracies as far as I am concerned...
1. Games do have support costs. Support costs include phone calls/email about how to play the game. They include revisions to the documentation. They include writing articles,
press releases, etc.
2. Interoperability is crucial! What good is a game designed to run on Linux if it doesn't work with the user's hard drive, or mouse, or joystick, or whatever? What good is it if the version of language runtime it uses interferes with the proper operation of the operating system? What good is it if it requires kernel changes that make the system unstable?
3. Reliablity is important. If the game crashes every time the user goes to save the game, or any time the user doesn't have a particular video card, then it doesn't get played.
A few years ago while visiting my in-laws I noticed my father-in-law had gotten a new program for kids to learn to read. The software company which created it is one which people have heard of - you might even have gone to see their new jungle based movie recently . Anyways, the packaging advertises that it ran on the machine my father-in-law had. It's memory and disk requirements were met by his machine. So we plugged it in and started thru the install steps. The software asked that a particular version of a graphics support library be installed. Neat, I thought, and clicked on the button to say "go ahead and install that version". The install script did. Then we start thru the install script again. Again we are prompted to install the particular version
Clearly, if we had access to the source, we could have fixed the problem and continued. Instead, he was out the cost of the software (because of course, once you've opened the software package, it can't be taken back...)
Re:quality of commercial games (Score:1)
Re:OSS Games not good for Multiplayer (Score:1)
For instance using sophisticated clients (with auto-triggers) in combat based Muds is almost the norm - it's considered part of the game - not really cheating. ie everyone's client is as sophisticated as the information it's sent allows - a level playing field.
Yes minimal information is a pain, because it doesn't allow you to do things like deadreckoning for smoothing out lag, or downloading the map in one go to reduce bandwidth usage. This is why games such as xpilot (on which you can cheat but cheating isn't a huge problem) tend to be high-bandwidth only games.
Remember - obscurity is not security - open source or not, as you said, people cheat, you need to deal with this in your design of the game - by which I mean design of the actual game play and game architecture, not design of obscure packet formats. Of course another aspect is being able to choose not to play with people you think are cheating - again games design in the way you set up, control and join games. Cheating has been a big problem with commercial games because people didn't really think when they added multiplayer options to essentially single player games.. if you look at opensource/public games you'll actually find it's been dealt with better in the design.
Gab
Re:Startup Cost - Reinvention = Better Games (Score:1)
creates a barrier for would-be builders.
The statement is nonsense. The "problem" with the model is that very few people have the credibility and the experience to attract investment - it's as simple as that.
And, of course, that's exactly how it should be. Investing capital in any venture regardless of merit led directly to the great depression in the '30s, and would quickly break any investor who tried it in the modern world.
Note that the gameplay in Quake, Quake II, Unreal, Half Life &c isn't particularly differentiated: it's the engines (graphics, physics, logic) that set these apart. This is the case to a lesser extent with movies.
It's being done (Score:1)
(BTW they could use more programmers)
This could be intresting as the accuall project managment style can be used to do any larg project.
I think we could use it to put together some useful projects for improving Linux in some of it's weak areas.
quality of commercial games (Score:1)
I don't think having a bazaar style development process for game development would improve anything.
Buying games is not like buying office 2000. If it doesn't work, or there is a bug that hinders gameplay, you go get your money back, and make sure you never buy software from that company again.
I am a major fan of computer games, and I find that if companies don't release perfect games, they have patches available to fix problems within two weeks or so.
Take Aliens vs. Predator for example. That game is about as good as it gets. I hadn't experienced any bugs in the game at all. But there was a major outcry from fans because you couldn't cheat and you couldn't save games in the middle of a level. Just a week ago they released a patch which enables all of these features and more, and that was only a few weeks after the game was released.
Of course there are exceptions. When Quake 2 was released, it was a useless piece of crap. It took several months of patches to fix it completely. And people will still buy software from Id anyway.
But how many years has it taken John Carmack and his team to develop their graphics engine? I doubt they would feel OK about not getting any royalties when someone uses their graphics engine.
Of course, PATCHES might come quicker for an open-source game, but I think the actual development would be seriously hindered.
No spectacular games? & Gameplay. (Score:2)
I guess that depends on your definition of spectacular. Spectacular to look at or spectacular successes. Games like nethack were a spectacular success when they came out, other games like nettrek/xpilot/freeciv and muds etc have been spectacular successes in that people still play them, even many years after they originally appeared (though they have gradually evolved over time).
Yes the engine isn't everything, but neither is the art - it's the 'gameplay'. This is hard to define but definately largely involves how the game engine responds to the player - from speed, to ironing out annoying bugs/network problems, to the interface design. At the end of the day it comes down to the skill of the programmer. Great looking games that are irritating to play are ... irritating - not fun.
I think the author makes some valid points but takes it a little too far. I'm not saying a 'precompetitive' engine wouldn't be a good thing.
It's very easy to think up the storyline to the greatest 3D first person RPG - to think of this feature and that, it's very hard to program the game so that the player interacts with the world in what feels a natural way for anything other than running around and shooting. This (IMO) is the next great challenge and it's essentially a programming one (as you have to implement all your ideas in the end) and cutting edge games will need to employ cutting edge programmers
I may be a cynic but I would suspect that the game industry prefers to produce 'consumable' games with low replay value rather than long lasting games because it can then sell more - built in obselence. I think the sort of games you find made on the internet (see above) are more of the 'slow burn' variety - but they are games nevertheless and successful at that.
Gab
Re:Art Is Worth Less, Open Source It Instead (Score:1)
The reason why you give away the code and sell the art is because people are willing to pay money for the art, but aren't for the code. Very few people look at a game and say "cool rendering engine." Many, many people look at a game and say "nice gameplay."
Remember: the value of something is what someone else is willing to give you to get it, not how much it cost you to produce. In fact, reducing or eliminating the cost burden of developing new software is at the heart of why the code should be open source.
Paying for games (Score:1)
However, I also have no objection to paying money for a game. As the author of the article quite rightly points out, games to not fit the evolving software model, and as such are not really suitable for Open Source development.
However, I think that we can learn a lot from the explosion of popularity in things like TCs and so forth - I am far, far happier to buy a game if it comes with an editor of some sort that will allow me to extend the game as I see fit, and exchange my extensions/modifications with other people. In this way, the game becomes an evolving entity (although slightly more restricted than a 'true' software entity) - and I think this is where we should be looking...
Thoughts?
Re:Art Is Worth Less, Open Source It Instead (Score:1)
-Mike
OSS is not the answer to everything (Score:3)
Allow me to elaborate. OSS model works very well for software that can be maintained and improved *over time* by different people. An operating system and lots of utilities fall under this category. However, games are generally played for a (relatively) short time and then abandoned in favour of newer games. For example, ID released Doom code, but how many people are gonna play it now that Q1 and Q2 are out and Q3 is on its way?
With OSS, you give away the software for free and make money on support. Works great for operating systems. Doesn't work at all for games.
As for the game engine being free and the art & design proprietary - that's a valid point. But consider this: ID has sold Q1 and Q2 game engines to several other companies which then developed their own 3d shooters based on ID's engine. Do you think they'd be able to make money by selling the game engine had it been OSS? How many companies need support to go with it?
Well I guess then artists can write AI code.. (Score:1)
easy as possible for the artists and level designers, rather than leading from the front with
state of the art technology.
While the article as a whole was pretty well written, I have to take an issue with this particular point. The author seems to imply that the programmers' skills, ingenuity, and inventivness have to take a back seat to what the artists do for the game. Programmers should just be trying to make life easy for the artists? Well, then, why don't we find a bunch of fresh high-school or college grads with some adequate programming knowledge and stick them in this support position and see what happens when the game designer comes in and says "We need to do much better path-finding!" or "The game will need to have a physics engine". What, the artists are going to put that in? No. Don't think that I'm dissing artists here, they do a great job on most of the games I buy, but saying that programmer's role is not important anymore is just plain wrong.
Art / Property / Effort (Score:2)
Article Misses the Boat (Score:1)
this article was just that: an effort. It was
an effort to try and apply the OSS model
to games, and I for one don't think it belongs
there. Games are simply for entertainment,
and just like movies, comic books, and premium
cable, they are made to make money.
Now, in the past, it has been shown that if
users can change a game around and play with it,
it stands a much better chance of being played
for a much longer time. Developers know this,
and as we can all see, most games ship with
editors, campaign makers, etc. And as we all
know, games like this do very well.
But to expect game developers to give away
their source code would definitely be too much.
Despite what the author thinks, the code is very
much a part of the game, and helps to establish
it as different from other games.
That is not to say that because games are
closed source, they can't be portable and
well written code (ala id). If developers
did this, we would have many more games
for linux. In the end, I feel that as
the linux user base gets even larger, and
graphics and sound subsystems for linux
improve, developers will simply stop ignoring
linux, and make money from us too.
A long way to go (Score:1)
Even for Windows, there's a severe lack of good, reasonably-priced game engines available. The next easiest thing to starting up a phony game company that never releases a product is to write a game programming library ("Those who can't, teach
I also think the author underestimates the amount of programming that goes into a game. If it were always as easy as Myst, there wouldn't be 5 to 12 programmers working on every commercial game.
Ironic (Score:1)
I think he's right, though. The code is just a tool used by the artists to create the game. Witness 'Team Fortress' and all the other popular games which are done without ever touching engine code.
--
"Games are drawn, not programmed' (Score:1)
I admit I find it difficult to understand how this guy can be in the same industry as me - perhaps they work differently at Probe?
Games are much, much more that just a 'graphics engine' with a some art tacked on, otherwise you've got little more than a VRML 1.0 viewer.
Sure, it's not that difficult to get a simple graphics engine up and running that will get some 3d objects on the screen, however you need much more than that for a modern game. You need to have an engine that is flexible and easy to use - it's important that all the coders working on the game don't have to waste any time bending over backwards to get something to work. It's not easy to make an engine flexible and easy to use - there are a lot of comprimises that you have to make, and considerable design effort goes into it.
Also, getting 3d graphics to go fast *isn't* something that anybody can easily do now - the difference between a naive and a streamlined graphics pipeline can be very big - you could easily see in the order of a 200% performance increase. That makes the difference between 'playable' and 'unplayable' on lower-end machines.
Other than that, there's all the game code itself - AI, menu code - game logic, simulation, effects etc... The code to handle the game itself will normally be considerably larger than the code to handle the graphics.
Also, another point about game art. It tends to take a lot longer to produce the original art and maps for a game than it does to produce add-on or replacement art later, simply because it was having to be developed at the same time as the game. Once the code is done, the process is much more streamlined, because everything needed to do it is in place.
cheers,
Tim
Roguelikes! (Score:1)
It's also interesting that code-forking seems to be quite a healthy thing for these games. There are scads of variants (esp. off of the Angband code-base) and each has interesting game quirks that authors have added.
They may not be commercial quality, but they're often more fun that commercial CRPGs.
-Dana
Re:Bzzzzt... (Score:1)
GPL should apply to levels too... (Score:1)
The GPL is about freedom - my freedom to make changes to software, and my freedom to make sure that my changes are availble to everyone else. A "free" (speech, not beer) game MUST have ALL of it's components availble for me to change and share my changes to be truely free.
This will lead to old engines (Score:1)
objections... (Score:3)
1. A lot of us don't look for flash and novelty in our games as the definition of fun. Some of us will go play Half-Life at a friend's house for half an hour because he just got a Voodoo3 and wanted to show off, and then go home and play Nethack. And enjoy the latter more. Look at today's slashdot article on the Pac Man high score for lots of discussions on "classic" video games. On the other hand, many people *do* look for flash, so I can't fault him on this one.
2. The author seemed to think that stability in games is nothing more than a nice perq, saying that an annoying bug in a game will simply cause you to return the game and never buy from that company again. IMHO, it must not be a very engaging game, if you give it up for a bug and don't lament it. The games that are worth playing, you'll play despite the bugs (and home the company releases a patch). I don't know how many times I screamed in irritation after hours of Alpha Centauri (yes, I admit it, I play games on Win98. I'll go cower in shame for daring to say that on slashdot, I promise) on Iron Man mode (no saving in exchange for 2x score) only to have an invalid page fault pop up during the computer's turn. Yet I go back and play it again because it's *fun*. It's engaging...Engrossing...It may not be the flashiest thing in the world (and, indeed, the graphics are often quoted as the worst aspect of SMAC) but the gameplay is enjoyable, and the replay value is very high.
I think I had a few more, but I can't remember...Overall, it was a well-written essay.
deja vu (Score:1)
Re:3d modeller for linux (Score:1)
that the user interface can make or break the program. alias/wavefront i belive has a dedicated
research division just for studying psychological and workflow effects of user interfaces. such an
editor would require a serious amount of planning and design up front so its less likely that the
project would mushroom out from one person's efforts.
This is very true. By nature of my work, I spend significant amount of time developing plugins for 3d studio max/maya/softimage3d, and I can attest that GUI makes or breaks the package. Even features come in the second place.
what you see in top of the line programs like softimage|3d and Maya is nothing that can't be
learned from back issues of siggraph proceedings and good design. anyone interested?
The idea of a top-quality 3d modeling/animation environment for Linux does intrigue me. I've looked at existing projects, and, somehow, they just didn't appeal to me. It would be a lot of work to write something like 3d studio max, but it's not impossible.
The Time City Project (Score:1)
Theoretical ideas about how an Open Source project will develop are inherently flawed. We are entering new territory and no one is really sure how the industry, developers, and users will react. Prior to Linux, who would have thought that an operating system would gain so much support?
The Time City Project received over 300 e-mails within 48 hours of being announced. If this isn't proof that people want to work on a serious gaming project, I don't know what is.
Anyway, come and visit us at http://www.timecity.org and send comments to mark@timecity.org if you have any questions or comments about how we're trying to shake up the industry =-)
on organizing an open game movement (Score:1)
open source flourished by providing open infrastructure for building complex projects, from networking tools and standards to good programming tools. it may sound obvious, but it seems the same should happen here. there's no need for open games with public domain artwork and such, even just the notion is absurd.
but there is a need for infrastructure. for example, an open source engine, with sophisticated networking (minimal packet size, massive multiplayer support, etc), a couple pluggable graphics engines (for 3d shooters, orthogonal rts, etc.), and hooks for plugins for ai and such.
people will come to this project if it frees them from rewriting the same engine over and over again, and lets concentrate on the aspects that need to be customized - such as graphics.
now how to make such an engine that's general across genres and still efficient is a whole different topic...
Myst (Score:1)
While true in a general sense, from my experience (which isn't great - a couple of cheesy text adventures), the fun came from creating the game - think of the creation of the plot-style game as a wierd godsim - I had fun designing the worlds, making the creatures/NPCs act correctly, placing clues, building rooms, etc - maybe I am strange, but this is what I found fun, even though I knew how to beat the game when it was all finished.
Others might not like this - so perhaps we would need to redefine what and how a plot oriented game is/works - maybe better AI, at both the NPC level, and the world level - so that we could define a world, but the game would automatically evolve based on NPC and user actions, as well as world based actions (say, it rains the next day in the world, erasing tracks left behind by the killer?).
This sounds damn complicated - perhaps such an engine would be so good you would feel it should be closed. But if something like this were started, then opened for others to expand on, the complications from creating such a system could be overcome perhaps...
Some negative posts, but listen anyway... (Score:3)
I think OSS for games would work something like the way Quake has developed, from Wolf 3-d to Doom to Qauke 1,2,3. Each step is really the same game just taken to a new level. I disagree that we need a constantly revolving buffet of games. I am most happy when I really get to sink my teeth into a game and get to knows its most intimate secrets. Having to shift from shallow game to shallow game (at $50 a pop) gets old rather quickly.
An Open(tm?) game would just continue to evolve over time. You only have to cover three or four genres and then work to make it customizable over those areas. I'm thinking...Real-Time-Strategy (Starcraft), First Person Shooter (Quake), Godsim (Civ,CTP/Alpha Centauri) and of course an RPG.
Just have one extremely customizable game for each genre (remember how the author mentioned that the themes were more important than the file selection system, we have experience with themes) and then improve on it. Networking would be a big issue (multi-player is how games "should" be played), but sprites, stats, and behavious could all be easily customizable. It would be a larger undertaking, but I think it could have the significance of a GNOME or KDE for the community (i.e. open it up to a larger audience).
I think there would be value in selling the "distro" (a la Redhat) as it were, if it included all the tools and various "live" games. From that mythical Open 3-d Studio (which I'd like to see) to the network code, to hackable examples for each genre. I would buy it.
I think it's silly to dismiss a possible future of free/open games. With all it's pitfalls, it does have that magic dust that works in the free software community, it's SEXY, baby!!
(Disclaimer: the above opinions are from a hard-core gamer,i.e. would rather game than code, or much else(99 out of a 100) so take it with a bit of salt)
Re:OSS is not the answer to everything (Score:1)
Re:GPL should apply to levels too... (Score:1)
by your logic documents for a GPL word processor would be GPL. The levels are loaded into the engine just as a document is loaded into the word processor. You don't hace to use the levels made by the people who released the engine, just as you don't have to open a document provided by the people who made the word processor.
I agree with you though, under certain conditions: that the engine is dependent upon the specific level set released by those that produced the game, and that set of levels can't be replaced.
Engines evolve too quickly (Score:1)
consider this scenario (Score:1)
I would like to see what happened i.e. bin Mortal Kombat style games!
Off course, the same could be true for the levels as well. Consider a very evil level building team, that invites your (self developed)"army" to come and invade.... (as in Red Alert).
The main tasks for the gaming company would be to release a 'closed' gaming engine (physics, basical character interactions, levels), some initial (open source) levels and characters.
And, in agreement with the Linux Today article, editors and programming tools, and artist tools are perfectly suited for bazaar style developement. So it would be kind and wise for the gaming company to turn these over to the community.
Also, I think it is necessary to stay clear of implying that the same licencing models apply to source code and art works. In the above scenario, an artist could well copyright his arts (skins or something).
Games are special. (Score:1)
Seriously, folks. Go look at the Linux kernel source in version 1.2, and you will see vm_area's, a swap cache, that bloody weird goodness-based scheduler, vnodes, bottom halves, etc. These kernel abstractions have been refined, tuned, occasionally reimplemented, etc., ad infinitum between 1.2 and 2.3, but they still serve the same purposes, and have similar semantics. It's a good thing, too; it's taken me all the time between 1.2 and 2.3 to gain enough confidence in the kernel to make substantial changes. If Linus violently reorganized the kernel every couple of weeks, those precious few people employed full-time to work on the kernel might be able to mentally track the changes, but he'd lose all the weekend warriors, many of whom have useful contributions to make.
Games present almost the opposite situation. Their quality is largely a subjective matter, and since tastes are always changing, so will the requirements for games. The hardware (and people's expectations) change so rapidly that retaining an engine for more than a year or two is unlikely in the extreme. If you're going to throw out the code base that often, only people who earn their living working on the code will be able to keep up, and that eliminates any supposed open source advantage.
Re:Stereotyping game programmers and programming (Score:2)
*Most* titles do NOT have a decent level of polish. Besides, what is usually referred to as 'polish' is nothing but good user interface and pretty graphics. The first comes from good design and the second comes from artists -- neither has much to do with programming.
When you buy a game off the shelf at best buy, take it home, and play it, you usually don't have to worry about whether you have the correct libraries or fear that it will crash.
I don't know why the correct libraries should be a problem anywhere -- if you are shipping a precompiled binary, either link statically or include the libraries on the CD. Nothing magical about it. Commercial games, though, play an entertaining game called "the latest driver". If you have problems, the first thing you'll be told to do is to get the latest drivers for your hardware (graphics card, sound, etc.). That may or may not help, which brings us to the point of crashing. Hate to disappoint you, but off-the-shelf, shrink-wrapped, commercial games do crash. A lot. Especially in the first couple of weeks after the release (before the patches). Some games crash rarely, and some are effectively unplayable until the patches come out, but they do crash.
Also, if game programmers produce such low quality code, why is 3d engine licensing so prevalant?
'Cause it works and 'cause it's cheaper/faster to license than to develop in-house.
There are plenty of titles out there with bad art that are still a lot of fun to play.
There are exceptions to the rule, sure, but a game with bad graphics will turn off a large part of its intended audience. It may be so much fun that the bad graphics will be forgiven, but that's a rarity. As to the programmers being more important, you seem to think that games are made by programmers and artists. That's not true. There is also the all-important game designer position. Generally a game is fun to play not because it has been programmed effectively, but because it has been designed very well. Often game designers do program, but that's just one person wearing two hats. Game design is a special skill, quite separate from programming (and from creating art, as well).
Finally, I don't see how such a money driven industry can profit from open source. RAD and other companies like it make all of there money licensing game engine utilities, and would have no source of income if they opensourced their products.
Replace 'game' with 'software' and your statement will not change in any significant way. Yet, open source exists and is quite successful.
Kaa
The MUGU Project (Score:1)
The author neglects to discuss the impact of adventure and roleplaying games. People may *buy* a game because of flashy graphics, but they will only continue to *play* if the game is fun. The OSS model may not be the best for cutting-edge tech, but it can certainly produce some addictive fun.
In the MUGU Project [mugu.org], we are keeping the game engine seperate from the game world and graphics. This allows world design, such as Alira [mugu.org] to be developed independently.
As with any Open Source project, we're looking for more tents in the bazaar. Check out The MUGU Project [mugu.org] if you're interested in working on an addictive massively-multiplayer game.
OSS Games not good for Multiplayer (Score:2)
Me: Open Source would be a very, very bad thing for multiplayer gaming.
Idealist: Whoah Dude.. How could that be?
Me: Simple. Too many people would cheat when they play.
Idealist: No Dude. Most people always play fair.
Me: Come closer.
Idealist: (Walks over closer to me)
Me: (smacks idealist across skull with a crowbar, breaking bones)
Idealist: (In pain) Dude... Why did you do that?
Me: Because I could... and I'll do anything to defeat you. You trusted me. You lose.
A dirty little truth about Multiplayer games is that if they are even remotely popular, an incredible amount of effort goes into hacking the games so a player can cheat or have some sort of advantage. The first day a game is available, there'll be some users putting it under the microscope, analyzing every byte of every network packet, testing dynamic modifications, and seeing what happens. Save game files will be dumped and examined. Process Memory Space will be scanned relentlessly and the object code reverse engineered.
And the result? Reduced playing experience and enjoyment for everyone.
If you give people access to the source code, It will only happen quicker, be more insidious, and more widespread. Most popular games get their executable code hacked sooner than later. With the source code, hackers won't be limited to patching existing code in place; they'll be able to add and expand the code!
Oh, and please don't start in "But there'll be other people who'll fix the source code so it'll be secure." Please spare me. It's perfectly possible for my client to convince your client that I am secure and compatible, while it runs my special build of the game. There are a lot of things I can do that'll never see. Play any RTS games? How about removing the fog-of-war? Adding an AI extension to make my units dodge whenever a missile is target at them? But I made it look like I just can click the mouse really, really fast! And how was I to know that's where your secret base was? Luck guess I guess...
And don't say that a Client-Server model where only the client code is released is the fix to it all. It ain't. People like to tell me that Quake II and Half-life are secure if the server is secure. Not true. Where there is a will, people find a way to cheat. Ever heard of zBot? It's a little proxy that sits between you and the Quake/HL server. The server tells you the location of everyone while your client handles changing directions and issuing commands. It can see that you just issued a weapon fire command, and that nothing is in your current line of fire, so hey, why not insert a command packet saying you are now pointing straight at this guy over here... That's why packet encryption is in there and has to get updated. (/Sarcasm on) Give me the source code and I don't need to break your stinking encryption - the client has to decrypt it before it can use it, and I got the source... hehehe.. Your ass is mine now! Boy, I'll bet you will really enjoy playing online with me and my hax0r buddies. It'll be a great and enjoyable experience for you. (/sarcasm mode off)
Commercial games have had to go to great lengths (and many patches) to combat cheating. With open source games, if you have to release the source to the anti-cheat efforts, then why bother?
And why would I know anything about this? It's what I do for a living...
it's the attitude (Score:1)
XRacer (Score:1)
Take a look: It's here. [annexia.org]
The really hard stuff (for me) like modelling, sounds, textures isn't coming along very fast because in spite of what other people have said, the coding is the easy bit.
Rich.
Re:OSS is not the answer to everything (Score:1)
What of the opposite: the game is free (at least like in beer) and the programmers make money on the engine?
Can this work? Maybe with a double license policy.
You release all your source code under the GPL or a NPL-like license and under a non-free license. if somebody want to do a free game with your engine he an but if he wnat to do a proprietary game then he must agree to the terms of the proprietary license?
Don't know if this work but this is worth thinking about I think.
Bzzzzt... (Score:1)
Source isn't "the" source (Score:1)
From a level creator that feels that it can be "art" and should be protected from being butchered:
No, you misunderstand (Score:1)
The documents for a GPL wordprocessor must be GPL'd ONLY if those documents are required for the wordprocessor to run, or are intended to be part of the package, like templates (Actually, I'd release the templates with some LGPL-like license, that ensures that you can use the templates and not have to share the letter you write with it, but if you derieve a new template from it then that template must be free (speech, not beer) as well.)
Any document you CREATE with the word processor (like your letter to Grandma) would not have to be availble under the GPL - software is a tool, and the freedom to change the tool and share that change is what's important.
When the levels, or models, or QuakeC scripts, or whatever are an integral part of the game, then they must be free for the game to be free.
You don't have to use the levels provided by the game writer, and by the same logic, you don't have to use the engine provided by the level designers. (There are tons of things that can read Quake levels)
As Bruce Perens says, "It's time to talk about Free Software again."
-Erik
Re:Roguelikes! (and types of games) (Score:1)
The problem with using this approach to develop most games software is that it's so hard to churn it out quickly. Any game that comes out has to do something better than any other. For fps's, for example, you can either make the game prettier (Q3), more intelligent (half-life), or different in some fundimental manner (Aliens Vs Predator / Thief). If you can't do this the game just won't sell. For example, Requiem seems a damn fine game, but since Half-Life game out first, I just never got into it.
To get this edge, the game has to come out as soon as is humanly possible. You also need a very high spec development platform to match the game's target machine. I don't think these really suit the OS method since so much time and money has to be put into it.
In short, if you write a game that's based on addictiveness, like nethack, and is expandable, OS works exceptionally well. If you're trying to make the next great fps, I'm not so convinced.
Noims
BTW, I know I'm mis-using the term Open Source, and using it to mean less and more than it does, but I hope I got my point accross anyway.