PlaneShift
Fan Area => The Hydlaa Plaza => Topic started by: Raleigh on April 25, 2007, 10:43:54 am
-
I readed this excellent article about how to suceed with a "bazaar" style of development(like the one used for Linux) and about how it can be much better if properly employed than a centralized, "cathedral" style commonly used for commercial projects. It is more of a reading for the open-minded people(but not so open to the point of letting the brain fall from it of course >o)) who may one day think about develeping a project(Like me, if one day I get the know-how, will and resources for it , for now all that happens is lots of ideas being stored on the obscure places of the mind... doubt I'm the only one). In this post are some general hints about it, in the next I'll try to brief on what is, according to the article, needed to make a successful start and avoid turning a "bazaar" development into a jumbled mess. So perhaps you may prefer to read it first and this one after(I cutted off the specific things and tried to adapt it to the situation of games, also the parts of the article defending the Bazaar style won't be throroughly mentioned)
http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html (http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html)
I will try to brief the main points of this document on the following text, but a full reading is still recommended.
First thing, bazaar doesn't work for starting something from scratch, and thus you(or a closed team of developers) will need to develop the basic design of the project before releasing it to public, and it must be a plausible promise and the first "basic" version release should at least run and convince potential co-developers that it can be evolved into something really neat in the foreseeable future, so sometimes it is better to start with something simple but interesting than to go with a hugely ambitious idea and a 50MB bugged tech-demo, for example. Simple does not mean not original though. You should keep it initially simple and robust, and focus the originality not on the software, but in the game design, as in this case it is where you can make something unique. And for suceeding you do not need necessarily to be a design/programming genious, but you need to recognize good ideas from the rest of the open-source community and work over them, as it can be usually better than making an original idea from scratch(in fact, it's probably impossible to see a game without any references to movies, literature, etc. So nothing actually comes from scratch). One important thing to do, is to create the "framework"(basic ideas) of the game first, the general ideas and guidelines about how it will be developed to avoid having cyclical development routes and excessive waste of code and design effort in the future. This "framework" must be very well defined, and work as the backbone where the "body" will be built creatively, but with consistence. I will try to exemplify it simply by putting some of the "framework elements" of PS Settings(They are not all):
-Underground stalactite
-Socially Stable
-Racial Tolerance and Interbreeding
-Medieval, but with the touch of science and magic
-Created by two known and opposing gods, Talad and Laanx
You can either create a complex and detailed "framework" design or a simpler one. Remember: the simpler it is, more open things will be but also more robust it will need to be to avoid consistency loss. And you shouldn't make it too simple, there is a limit and people won't be willing to aways give their ideas about how to build something over it. If you don't want to fill every single element that will be required to maintain consistency,then making a whole game design by your own and leaving the bazaar to the coding and art is a better idea(It's up to you after all). Giving users the choice of suggesting ways to fill whatever "gaps" you have on your game design is something not very different from "brainstorming" and might be a good idea as well. Receptivity to users is always something overall good.
As previously said, coding is the less difficult to deal when using this way and design the hardest. So if somebody wishes to replace the "Cathedral" for the "Bazaar", programming should be the first step, art second and if boldly enough, design as last.
Another important thing, as you need to give the headstart for the project, you should have the skills for it(Programming, etc.). And social skills are definitively important, as the way you treat others will define how others are willing to volunteer to help improving your idea. Finally, such projects work much better through leadership without any form of coercion, as these practices tend to desestimulate people.
Note: this is the basic content, beyond this is something that is just for those more interested, but still not interested enough to read the whole article.
1. Every good work of software starts by scratching a developer's personal itch.
This is a bit obvious, if you don't need something, don't make it. It can be applied for any kind of software, including games.
An Example: "I want to do a GPL Singleplayer FPS with a strong plot and history line because most of the well-developed ones I found are Multiplayer Quake clones and I like much more immersive games than simple mindless shooting, with or without real people to kill" .. this need can be expanded much more in the case of games, as the "ideal" game for somebody's preferences never exists and never will exist.
But remember to check before if the currently available things can solve your necessities before going for a dev-rush while something very similar is already being developed, if none of them have the features you desire.
Other thing that bothers me(although others may not agree), is about the creation of clones of famous games like "freeciv" and "freecraft". I will make a somewhat distant analogy about this practice, but sometimes a home-made soda is more expensive than a bought one, and usually it does not end as good, and this increases when we talk about software. What is the point of having a free clone that is like *Game* 2 while the develepers of it are about to release *Game* 5? If you wanted to offer a free alternative to a 4X game for example, it should be an alternative, not an imitation. It's possible to design a game based on RW and empire-building without being the same of commercial projects. Originality is something that lacks when we talk about open-source games. A sad factor, specially knowing that the need of following the "market trends"(read clichés) do not exist in these cases.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
*
*Change programmers for artists as well.
Why should I "reinvent the wheel"? If there's already a almost ready GPL engine that fits for a project's need for example, making another one is not a nice idea. If there is a large amount of 3D human basic models for download under Creative Commons, I wouldn't make one from scratch, but modify the ready ones according to the needs. Does this mean that the derivative art from the previously created work will be similar to it? Not necessarily. Just as an example, sound effects of guns in certain games are very similar, still this does not mean they are clones from each other. Take D&D as another example: the concept ideas on elves and dwarves of them are shared among most fantasy RPGs, and still they are not the same. Now, the same thing is appliable to storywriting and gameplay as well(but with more care than others), but books, rules for gameplay and existing materials should at most serve as a slight inspiration, as this is the field where originality really makes a difference as gameplay and storyline is what makes a game truly unique(This was much more obvious in the age of ASCII based games)
P.S.: One day I will launch something on SourceForge or somewhere else, and this day will come SOONTM :whistling:
-
The Cathedral and the Bazaar is nice, but behind it and its beautiful lies is a very... ugly truth. Hard work. Having an open development model (and all the implications derived from it) is often much more difficult than the closed counterparts.
-
The Cathedral and the Bazaar is nice, but behind it and its beautiful lies is a very... ugly truth. Hard work. Having an open development model (and all the implications derived from it) is often much more difficult than the closed counterparts.
Closed model is very good when speaking about coding and art, if you can actually hire developers to do it ;)
All depends... How would be Linux without the community of "hackers" that supported its development?
Of course, the game design(Its basic ideas on how it should look, gameplay, history, etc) usually is better when done by a small group of people, or even by a single person, but the same cannot be said about coding and art, if certain measures are taken of course to offset the negative points of it(guidelines, and the game desing itself describing clearly how things should look like is an example).
The only "ugly truth" that remains is that no volunteer-based model of development can compete with a well-funded and organized closed development of a commercial software
-
The point I was trying to make is that an open style of development requires much more work put into a project because of the necessity to make it "hold together" and people work on some things in an orderly fashion, following common goals. Sure, they all share the goal of completing a project but that's where they want to "land", getting there is tough.
You're perfectly right on most accounts but take note that any good and consistent project seen so far did not just spring up from various code put together with glue. For the most successful projects in the linux (and generally speaking open-source world), there was a team from the start working on it in a very professional manner. And they got support and pay for it from organisations, government grants etc.
All I'm doing right now is play the devil's advocate ;) because I love open source. The only thing I want to stress is that it's not easy and certainly not all roses as Eris S. Raymond says.