Main Goal

To make a modern open sourcestrategy/micro management game with slow, long processes like in Settlers AND fast, immidiate action like in Warcraft. The atmosphere of the game will be dark, serious, and the player will have a feeling of fighting against nature, using scarce resources and playing eventfull missions.The resulting product will have industry standard, or better, graphics, game play and AI.

What's this?

This is a description of the general direction the project is going and specific goals to accomplish this, also non-goals to make it clear where the project is not going

Goals

This is a brief list of the technical goals of the project. Or if you like, the quality and scope of the features in an abstract way (for specific information on a particular feature see the Feature list document.

Basically the goals define what will have to be finished for the 1.0 release of the game. The non-goals define things outside of the scope of the 1.0 release. Some of them we would like to work on and some will likely never happen.

    AI will not react linearly, that is it will not, necessarily ,react the same to the same input twice. Nor will it be random. So, some form of state based heuristic model is called for.

    Graphics will be comparable to or better than current games of the same type. We are specifically talking about Settlers II 10:th anniversary edition.

    Game state will be duplicated among all players and each player will only have access to the data he or she should according to the rules.

    In single player that means the AI will not be able to cheat with the old "I always know where you are" hack/bug.
In multi player it means that you can have consensus based game states. If any players view of the world is misaligned with the other players it will be mistrusted. This is good since it will help to avoid cheating.

    The game will be threaded. The AI, networking, rendering and game state will be in different threads. This is to remove the need for us to load balance the engine our selves. By using the scheduler to balance the load of these different functions we can reduce the likelihood of, for example, a difficult AI decision will result in a drop or freeze of frame rate from the renderer.
The game will be, at least mainly, written in C/C++. Modules for some things, like AI, might be written in a different language (LUA or ABL) but the main work will be done in C/C++.

    The code of the project will be open source. The games resources might or might not be. This means that while the engine and other code will be free to use by anyone the graphics and other content might not be. This is a measure to protect us from cloning of the project. That said we will in no way try to prevent the game from being open. All the formats used for the game will be documented and all the tools related to it will be listed and, if made in house, will be open source as well.

    The project will be cross platform for Linux (3.6+), Mac OS X (10.5+) and Windows (XP+). Lets put a few restrictions on that for the v1.0 release. The game will be fully playable on all three platforms. Not all features might work or might work differently. As for Windows, Vista would be nice but thats a "if there is time" kinda feature. We have not researched the difficulty to support other versions or platforms so any work in that area would be appreciated. Generally though, if we can cover these three platforms it shouldn't be impossible to port to a different platform or version.

    The uses of external libraries will be kept to a minimum and the libraries used must be cross platform for our target platforms.
Three (3) completely different races with different buildings, society, units, resource management, tech advances and magic systems. Unlike our example Settlers where the only thing that's really different are the graphics and names of stuff.
Maybe some more, we are still planning. This should be pretty much it though...

Non-goals

This is a list of things that the project is not about. Some of our visitors will inevitably want to do something different than what we intended. This section is to clarify some of the things we know could be done and that may be done with the project in the future but is not part of the v1.0 release.

If you think feature X would be great or prefer approach Y instead of our Z thats fine. It might even have merit. But if the project is ever going to get to a state where we can say "This is version 1. Let's release." it has to have bounds on the incoming features and approaches.

After version 1.0 we will, as a community, renegotiate the goals for version 2. But until then please consider this as the bounds of the project and do not waste the programmers time by asking for or suggesting things listed here. Thank you. (Want a longer explanation of this rudeness? Go and watch "What's In It for Me? Benefits from Open Sourcing Code" (http://www.youtube.com/watch?v=ZtYJoatnHb8) and "How Open Source Projects Survive Poisonous People"(http://video.google.com/videoplay?docid=-4216011961522818645). Two excellent Google tech talks about open source communities.)

    To create a general, customizable game platform for strategy, micro management or any other game type. This might be a positives side effect of our work, but in not a goal.

    To create general, library based, functions for use with anything here? to create other games. This to might happen, but is not considered a goal.

    Network play will be hacker proof. We would like to and if you can show us how to do it we will. But it's not a release stopper.