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, 20558 views, last view: 05/18/2024 16:48

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

   Board Index    Go to next 20 messagesGo to last 20 messages

#1: Python?

by RealNitro on 06/06/2005 08:27

How about using python as the scripting language? ( http://python.org/ ) It's amazingly simple to learn, but still very powerfull.

reply to this message

#2: Re: Python?

by Aardappel_ on 06/06/2005 08:48, refers to #1

Sauerbraten is about small/fast/simple. Python is big/slow/complicated. I hope that answers you question.

The only off the shelf scripting language I would consider is maybe something like Lua, but even there I can do a hell of a lot better.

Btw I really like Python as a language. But having a scripting language thats 10x bigger than the engine is a bit... pointless.

reply to this message

#3: Re: Python?

by RealNitro on 06/06/2005 09:01, refers to #2

Yeah, guess you're right. Too bad though. :-p

reply to this message

#4: Shaders, I have already done that!

by Rolf Stenholm on 06/06/2005 11:18

I saw you listed shaders on your list at step 3. It happens that my test build, that i showed off in the engine thread was actually a shader mod.
It fixed bugs in multitexturing and added Vertex, Fragment program support on a package and/or level to level basis.
The per-pixel Phong shading (not per pixel ligthning) lightning in my images are exactly that, a vertex program and fragment program defined specifically for my test map.

reply to this message

#5: Re: Shaders, I have already done that!

by Aardappel_ on 06/06/2005 19:14, refers to #4

well, adding support for shader extensions and some basic effects is rather trivial to add, that is not the issue. Please read my recent post about shaders in one of the other threads.

reply to this message

#6: Re: Python?

by Pxtl on 06/06/2005 20:51, refers to #2

I agree about Python. I've personally experienced trying to embed a Python interpreter - and while the language is very nice to embed, the problem is that it's very hard to cut out all the baggage of the standard libraries. Plus, Python has no sandbox, which is a definite no-no if you want to let users download untrusted scripts.

Lua all the way - it would avoid having to write documentation for a whole new language and trying to optimise etc. While I appreciate that you have extensive experience designing language, I think that avoiding Lua would be a bad case of Not Invented Here.

reply to this message

#7: Re: Python?

by jean pierre on 06/06/2005 20:53, refers to #6

Python you mean the landscape generater?

I like Terragen better for that case.

reply to this message

#8: Re: Python?

by Pxtl on 06/06/2005 21:00, refers to #7

No, JP, Python is a very slow but easy-to-use programming language. Like VB for opensource people. The point is that most modern engines have an embedded scripting language (like the Cube scripting console, but more powerful so that mappers/modders can make more complex logic, etc. without using C++)

Python is occaisionally used for this, but the original Python interpreter is very hard to strip-down enough to make it useful for an engine - it contains all sorts of esoteric stuff for XML, Regex, Tk GUIs, etc. Plus, the language itself is incredibly complicated because it tries to replicate pseudocode, which is just making things up as you go.

A more "K.I.S.S" language that would be more appropriate for Aard's minimalist philosophy would be one of his own languages, or possibly a LISP-oid. I prefer Lua because it's one of the few languages specifically designed to be put into a game engine as a scripting system, so there's tons of existing support on it's use in the subject.

reply to this message

#9: Re: Python?

by jean pierre on 06/07/2005 08:35, refers to #8

Oh i thaught you ment on the Terrain engine ok

But does that mean it changes alot to the engine(making the menu solid i mean not semi-transparent)if so then it's boring or atleast toggling from the .cfg

reply to this message

#10: Python ?

by Rolf Stenholm on 06/07/2005 12:41

I guess you people dont know Forth then ? Its smaller than lisp/Lua.
Here is a link
http://www.forth.org/

reply to this message

#11: Re: Sauerbraten future development timeline

by jean pierre on 06/07/2005 19:06, refers to #11

Hope it wont make BIG changes cause it wont be as fun as the normal Cube 2.

reply to this message

#12: Re: Sauerbraten future development timeline

by shadow516 on 06/07/2005 21:16, refers to #11

WTF are you talking about jean pierre? We need to use a simpler language so that we won't be limited to using developers who already know C++. It won't change the direction of the game, but it will speed up its progress.

reply to this message

#13: Re: Sauerbraten future development timeline

by Aardappel_ on 06/07/2005 21:24, refers to #11

Yup Lua would be my only pick. I will give it some thought, and maybe I will do the whole "gameplay" seperation and Lua integration at the same time.

I don't agree that is hard to outdo Lua though. My last scripting language was better in every way, about 5-10x faster (yes, really), optional static typing, more standard syntax but still scripter friendly, and more features in a smaller amount of source code and memory usage. Sadly its owned by a certain german games company. If I could get them to open source it, it would be perfect.

Even without it, it would take me about a month of full time work to write a language functionally equivalent to Lua that was faster & smaller.

reply to this message

#14: Re: Sauerbraten future development timeline

by pushplay on 06/08/2005 01:51, refers to #13

Would this gameplay and engine seperation involve moving a lot of game logic to a script? If so we probably do need every bit of speed we can get out of it.

reply to this message

#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

   Board Index    Go to next 20 messagesGo to last 20 messages


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


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
54037840 visitors requested 71818093 pages
page created in 0.044 seconds using 9 queries
hosted by Boost Digital