Game Production and management

HoverEX is an open source game. Although we are not the first (Open TTD) but we are definitely among the pioneer who venture into open source game. As no one could give us advice and guideline on how to run an open source game project (project here not only refer to the game but also building a fan base), we have to explore it by ourselves.

Being a pioneer is fun and challenging. However, it also tiring as we could easily made mistake. Thus, case study and more reading is necessary on how to manage this open source game project that have great vision: To create an Open Source game that is of commercial quality.

An open source game means, anyone can modify the game engine, the game machanism, the game design and the game outlook (graphic and music). For HoverEX, you can even modify the game official site. Unquestionable, HoverEX is very much difference than others commercial game out there. HoverEX as well do not share benefits that common open source software owned. Thus, Open Source Game is undefindable and we are the one that totally have the right to say on it.

Despite the impressive list of achievements of open source software, it can be argued that there have not been any world-class games created under the open source banner. Sure, several old games like Doom and Quake have been gifted to the open source community, but there are no comparable original creations in this area. One should not expect this situation to change anytime soon, because the open source development model does not make sense for game development.

http://www.osnews.com/story.php?news_id=8146

I alway fail to categorize game into art or science. If game is an art, an open source game would definitely ended up as a mass. While an art is about identity, and game required branding through its unique game play and style, I strongly believe HoverEX should mantaine its official game design and promote it well.

I quote from the article Playing the Open Source Game to show the author are agree with my points of view. — Tan Yee Siang 2005 09 07, 19:40

The problem with writing games on the net is that good ones need to be designed around a consistent style, artistic vision, or whatever you prefer to call it. They need to have a carefully graduated progression of difficulty from one level to the next, and there has to be a fixed point in the development cycle at which you can say “ok, this game is now complete”.

Most programs gain strength by integrating all these various ideas, but with games you are usually better off letting each new idea have separate life in a game of its own.

Although you may well get a lot of response to this type of request, you are unlikely to find more than one person who agrees on what type of game they want to make, so you will waste all your energy in pointless debates, ending up a year or so later with a great logo, a fancy website, and no game.

In order to attract other developers to an open source project, you need to have a plausible promise of what it might someday become. A post on usenet can never be plausible, though, because without code to back it up, this is just hot air.

I suspect that the most successful open source games will end up working very much like an Enlightenment theme.

If you are one of the people who think that Linux should have GNU written in front of it, you probably don’t want to get involved with writing open source games, because that sort of thing is likely to happen a lot. You will spend a couple of years writing a superb game framework, only to find that although the latest hit title does have your name buried away in a readme somewhere, all the kudos is going to the guy who modeled a new version of Lara Croft with bigger breasts.

Commercial game developers periodically figure out that high level scripting might make their life easier, but they keep doing it wrong. Either they invent their own specialized languages that are too limited to be really useful, or they use something based on C, in which case they might just as well have written the whole thing in C in the first place. Hacker culture, on the other hand, knows a lot about scripting systems and configurable programs, so we can do this the right way

Ultimately, I believe the future of games on Linux will depend on our egos, or rather upon our lack thereof. Game programmers are traditionally very bad at trusting anyone other than themselves to write useful code, but open source development will only work if we can grow up enough to leave this attitude behind us.

• The ability to build on existing code and art.
• Allows many users to benefit from the application and provides an opportunity for users to become volunteer developers, thus furthering the project.
• The continued interest of the public drives the developers long after personal interest or utility has faded.

• Will developing a game as open source make things easier?
• How to prevent HoverEX ended as a game that looks and sounds like a hundreds of sound clips and pictures put into a rojak 1)?
• “content-based” games are a one-time experience and not suitable to use as open source game.
• Games are drawn, not programmed. How we move open source software development on game development?

The road to release HoverEX is long enough.

1. Brainstorming
2. Prototyping
3. Planing
4. Lock Down
5. Implementation
6. Quality Assurance
   1. Alpha Testing
   2. Beta Testing
7. Release & Promotion
8. Fan Feedback
9. Next Version

Version controlling system/scheme for the game design and game data should be implemented. It will be something similarly to Mozilla FireFox extension. Please read the following text for the reason.

Currently, HoverEX game release as a whole that included:

• Map Editor
• Game Engine
• The Game
• Data Set for the game

This release model could caused problem and limit the flexibility. For example: Map editor is use to create map for HoverEX game. A user might used the map editor to create different map and expected it to run in the future release of HoverEX Game, or a variation of the current version. However, as the engine keep improving as well as the game design and these could caused conflits between difference version of game engine VS game map VS game data and design.

This problem become more complex when it involves different players that are using different version of game that might come from different variation (after all, this is open source project) playing on a multilayer game using the same map. — Tan Yee Siang 2005 09 07, 20:39