home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


Sauerbraten future development timeline

by Aardappel_ on 06/06/2005 06:29, 34 messages, last message: 06/22/2005 06:32, 20506 views, last view: 05/03/2024 08:05

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 :)

Go to first 20 messagesGo to previous 20 messages    Board Index   

#15: ..

by arghvark on 06/08/2005 03:19

I know it is slower and adds bloat, but what about a quakec~ish scripting language for game logic?

I imagine this is not a good, idea, but would like to hear your thoughts on it.

reply to this message

#16: Re: ..

by eihrul on 06/08/2005 03:26, refers to #15

Making a JIT compiler is actually dead simple. If performance is an issue, and you are using a custom language (as opposed to Lua), it can be easily bolted on.

reply to this message

#17: Re: Sauerbraten future development timeline

by Pxtl on 06/08/2005 03:56, refers to #13

I assume you mean CryScript? That would be nice. And Argh, don't talk about Quake-C. C is bad - it's old and unpleasant to work with, and any script language should avoid modelling after it.

reply to this message

#18: Re: Sauerbraten future development timeline

by jean pierre on 06/08/2005 07:40, refers to #17

So you Aard is going to stick with Lua right?

reply to this message

#19: Re: Sauerbraten future development timeline

by Aardappel_ on 06/08/2005 08:16, refers to #14

pp: Yeah, that is one of the reason behind wanting an as fast as possible scripting language: the faster it is, the more you can move to script. With a slow language, you will always have the uncomfortable seperation where every small thing you need to consider writing a C function for, splitting game code between C and script, and making things thus more complicated.

argh: any language we mentioned is 10x better than quake-c

eihrul: are you volunteering? :)

pxtl: yup that's what I am referring to.

jp: that remains to be seen.

reply to this message

#20: Re: Sauerbraten future development timeline

by eihrul on 06/08/2005 08:21, refers to #19

If you write the rest of the language, sure, I'd volunteer to write the few hundred lines of code for the JIT. :P

reply to this message

#21: Re: Sauerbraten future development timeline

by Aardappel_ on 06/08/2005 08:24, refers to #20

ooh, sounds like a potential eihrul-aard language project! exciting!

reply to this message

#22: Slightly offtopic...

by Pxtl on 06/08/2005 09:16

Anybody seen the newest toy - Kismet? Unreal Engine 3's scripting language is a graphical logic flow system similar to LabView and VirTools.

reply to this message

#23: Re: ..

by pushplay on 06/09/2005 01:39, refers to #23

Lisp is conspicuously absent from that list.

reply to this message

#24: Re: ..

by Aardappel_ on 06/09/2005 02:49, refers to #23

designing a syntax that only appeals to language designers/implementers is never a good idea ;)

reply to this message

#25: Nobody Gives It A Fair Chance!

by pushplay on 06/09/2005 03:23

*pout*

reply to this message

#26: Re: ..

by Pxtl on 06/09/2005 15:28, refers to #23

While I can see the incredible power of Lisp/Scheme type languages, the problem is that you want mappers to be able to understand your code. Lisp is a challenge to keep legible - even without the unorthodox syntax, there's the fact that all the language keywords make no sense (car, cdr and so on). I mean, what if it was decided to use OCaml or Haskell? That would completely confuse everyone.

reply to this message

#27: content

by jh on 06/12/2005 03:25

This timeline seems to be focused mostly on the engine without providing any guideline for future content, which I'm most interested in at the moment since I don't want to code c++. We know that the engine is going to add features that old Cube content does not adapt to(for ex. another thread showing a test of bumpmapped textures...Aard noted that the existing textures aren't really usable with bumpmaps).

The questions we need to answer, I guess, are:

-what new/replacement content is most important to support the test gameplay?
-what sorts of formats/features should artists expect?

I'm considering using some of my time this summer to work on textures; I don't consider myself a top-notch artist, but I've built a whole set for a map before, so I think I can make something usable again...

And I'm supporting Lua for scripting if no custom language gets built; even though I'm a Python fan I understand speed considerations and I like the idea of using a popular game-script language in Sauer.

reply to this message

#28: Re: content

by Aardappel_ on 06/12/2005 07:38, refers to #27

for the moment, the content required is primarily just very good maps. But yes, textures, models, and everything else can potentially also be improved, but that is less easy to indicate.

reply to this message

#29: Re: Sauerbraten future development timeline

by nieb on 06/14/2005 00:40, refers to #13

Couldn't you just make a new Script thats 10x's faster than CryScript and make "them" jealous. lol
It's been 3 years I'm sure you've thought of something better by now...

reply to this message

#30: Re: Sauerbraten future development timeline

by Aardappel_ on 06/14/2005 00:48, refers to #29

I can. It just takes time to implement.

reply to this message

#31: Re: Sauerbraten future development timeline

by Pxtl on 06/14/2005 02:21, refers to #30

Or there's the crazy solution:

Mono. Sandboxed, optimized - but the most obscene violation of the minimalist philosophy.

reply to this message

#32: Just thinking over....

by Pxtl on 06/14/2005 02:29

I've developed tons of little games in PyGame - mostly because it is simply way easier to make bitmaps than 3d models. There's something to be said for just having a simple scripting system where you can move sprites around, check input variables, and play sounds.

Phase 4 Sauer could be a perfect replacement for that kind of thing. After all, if Aard's "Octrees as models" idea flys, then devs could make a whole game using just script and models. Networking would still be out of the reach of most amateurs, but the rest would be making 3d games with highschool-level implementation difficulty. The only weakness would be a lack of animation - but moving Octree statics would still make good vehicles. Combine that with an easy system for adding HUD elements, guis, etc. and you'd have the ultimate game-RAD system for devs who don't want to learn MAX.

reply to this message

#33: Re: ..

by Aardappel_ on 06/14/2005 06:13, refers to #33

You clearly don't know me, or you wouldn't make such random assumptions based on how other people develop software.

I am unlikely to create a new language from scratch for sauerbraten. I just haven't decided yet.

reply to this message

#34: A question about separation of engine and game.

by enigma_0Z on 06/22/2005 06:32

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

Go to first 20 messagesGo to previous 20 messages    Board Index   


Unvalidated accounts can only reply to the 'Permanent Threads' section!


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
53862657 visitors requested 71637750 pages
page created in 0.040 seconds using 10 queries
hosted by Boost Digital