|
A lot of people are interested in Sauerbraten for different reasons. And even though I still control it, the development of it is more open, and more people influence it than Cube.
For an open source project to be successful, there needs to be a balance between the community, and a person with a central vision. A lot of things that are cool about cube, and now sauerbraten again, is because I had a particular design vision. A community without leadership will not produce good designs. So for Sauerbraten I want to continue setting clear goals for whoever works with me on it, but at the same time I want to be more open to make sure it is ideal for a larger community, and I especially want to accommodate the larger contributors, meaning the programmers that may have their own plans, and the more active level designers.
So without further blah, here's how I see the development phases of Sauerbraten.
1) Get the core engine tech to a stage where the engine is fully usable.
STATUS: We just finished this stage! Congrats to all involved!
2) Get a basic FPS game along the lines of Cube, but slightly enhanced, up and running. For those of you who are wondering what the point of this step is: the biggest failure of most engines is that they are engines, not games. It is very hard to take an engine an build a game for it without an existing framework. Many people are interested in using sauerbraten as a base for a game. And what is the most basic gameplay you could give a 3D engine? that's right, an FPS. Especially since we already have the base cube gameplay to work from.
STATUS: we are 70%-80% done on this one, I estimate. Most of it appears to work, but a lot of refinements can be made. At some point this gameplay will be mostly frozen, much like Cube. Most importantly we need to figure out how we want to do multiplayer, given that currently it is wide open for cheating.
3) [this can actually be in parallel with 4 & 5]: improve engine tech. Geometry thruput optimisations, Level of Detail, Occlusion Culling, and a shader system are the most important items on the list here, but there are tons of other features that will keep on enhancing/refining the engine.
STATUS: planning/design. Currently we are not in a total hurry with these features as the engine is running rather nicely already. But we can do better and we will.
4) Gameplay & Engine seperation. Several people want to do widely different games with Sauerbraten. I don't want us to get in the same situation as most engine (Cube especially) where making a "mod" means forfeiting future engine development, or worse, mods add their own cool features that don't benefit the main branch. That's why I want to organize a system whereby we can have a main, shared engine, and multiple gameplay modules. For this it is also important to have the FPS gameplay polished, that way every gameplay module can be based off the FPS module and have something working to start with.
Even better, since this item will require a LOT of reorganisation in the engine, there will be quite a bit of time afterwards where things have to be restructured. To do this most smoothly, I will propose an organisation where all main gameplay projects (serious ones, approved by me) sit together in the same CVS, and initially even in the same program, toggleable by a commandline switch. This means that if you change the engine or the gameplay interface, you get to compile other people's gameplay modules as well, and verify wether you haven't broken their code, or even make simple fixes (such as when adding additional parameters etc.).
I am also open to thinking about a better scripting language, if time permits I will create one, such that we can move as much as possible out of the engine and allow non C++ programmers to make mods.
STATUS: I will do the initial engine restructuring to allow this to happen, but I'd like to postpone this as long as possible.
5) The sauerbraten RPG. This will be the main gameplay module seperate from the FPS module, designed by yours truely. I have particular ideas for this, but since our life will be simpler if we don't have 3 million different gameplay projects ongoing (we also have a limited pool of level designers), I will try to scope this project such with major programmer & level designer contributors such that we can all work on a single project, if possible. It may be that our wishes are non-unifyable, so be it, but I will give it a try. I think it can be done.
STATUS: Once we are past (4) and some of (3), I will lay out my plans... but if you dig through old threads on this forums you can find some of it :)
|
|
When you say that you want to separate engine code from game code, how far does that separation go? Does the engine basically entail maps, their rendering, drawing, and saving? Or are there other things that I'm missing...
I am thinking about (once sauer is finished) trying to make a platforming/adventure game out of the engine, but there are some things that I would need to change from the current FPS state of affairs (first person, for example, I'd have no weapons, just hand2hand combat. Something similar to Mario 64).
And of course, goals and stats for a platformer would be radically different than a FPS.
So my question is, how far do you plan on separating engine from game. It's a good idea, but there are inherent issues. I'd like to see complete and total separation so you basically have two "modules". The engine (renderer, mapper), and the game (physics, entities, characters, combat, netcode, etc.).
reply to this message
|
home 
files 
forum 
docs 
wiki 
faq 
