Sauerbraten modding - engine design

by Urre on 03/13/2007 14:45, 12 messages, last message: 03/16/2007 06:40, 1989 views, last view: 05/04/2024 03:04

As far as I understood it, mods are made by compiling a completely new engine with the gamecode in it. Has there been any discussion on separating the gamecode into a dynamic lib, for easier compatibility with engine updates?

I\'m used to modding with Quakes ever so handy QuakeC language, which works (mostly) the same in any of the Quake1 engines out there, so one doesn\'t have to bother with the engine if one doesn\'t want to, and also gets updates for free :P

I saw a bot made for Cube, but haven\'t spotted any Sauer bots, so I figured I\'d give a go at it, to brush up my C skills, and to have another platform to make bots for. More on that subject, does anyone have ideas for generating volumes for navigation from Sauer\'s geometry (which I understand is Octtrees capable of crushing vertexes inwards) similar to the Q3 bot navigation?

   Board Index   

#1: ..

by absinth on 03/13/2007 23:28

>mods are made by compiling a completely new engine with the gamecode in it

source modifications are only neccesary if you want to change gameplay. you can make a total conversion just by adding media (maps textures models etc).

if you make a mod you should of course have a look at the legal implications as explained in the documentation and on the wiki.


>I saw a bot made for Cube, but haven\'t spotted any Sauer bot, so I figured I\'d give a go at it, to brush up my C skills

you could have a look here and contribute before rolling your own:
http://www.quadropolis.us/node/418

reply to this message

#2: SauerMod

by Quin on 03/14/2007 04:39

I more than welcome input from any competant and interested parties so long as they are able to conform to the main project guidelines:

... 'specific focus on modification portability and limited core/engine changes' ... 'create an effective AI for offline multiplayer games and extend/improve singleplayer
and multiplayer gamemodes' ...

Feel free to email me, or message me on IRC (#sauerbraten @ QuakeNet), or respond in the official thread on these forums (which would've turned up had you searched for 'sauerbraten bots') at http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=1164 -- if you'd like to talk further on the subject.

Realise the release on quadropolis is several months old and I have since been working on SauerMod using the current CVS version of Sauerbraten.

reply to this message

#3: Re: ..

by Urre on 03/14/2007 08:50, refers to #1

absinth: I wouldn't consider it a TC if it only changed the content, barely a mod :P. Weren't mods originally code only, and as other tools were released you could add new content as well? ;)

Quin: I'll have a look-see.

reply to this message

#4: ..

by Urre on 03/14/2007 09:05

Still wondering about separating gamecode from engine... Maybe it's too big a step with the current design, haven't had a look at the code yet. It'd certainly be a feature to be had in the official release.

reply to this message

#5: Re: ..

by shadow,516 on 03/14/2007 14:23, refers to #4

game code and engine are separate... and have been for over a year.

reply to this message

#6: Oh?

by Urre2 on 03/14/2007 20:29

So why are mods released with their own executables? Or are they? Or did I just look at an old mod?

(btw how come I can\'t use my nickname, just cause I\'m at another computer?)

reply to this message

#7: Re: Oh?

by Aardappel_ on 03/14/2007 20:41, refers to #6

they are seperate to facilitate us working on the FPS and the RPG without duplicating code.

Sauer was first and foremost made as a game, not for modding. That's because we have an interest to make the game real good, rather than to spend lots of time just so someone with no skill can say, ooh, look, here's my mod where I changed the firerate by 200%, its so cool!

Serious people that want to create a game based on the sauer engine will have no problem anyway using the entire source. And if you do not want to fork entirely, the game and engine code are sufficiently seperate that you can easily rejoin a future engine update with your gamecode.

The RPG will support custom gameplay mods on a per-map basis, which is a much more sane approach for satisfying the urges of the "ooh look at my firerate" crowd.

reply to this message

#8: Re: Oh?

by KoiKitsune2006 on 03/14/2007 20:45, refers to #7

Reminds me of the dumb gun mods in Unreal Gold, Unreal Tournament Classic, Ut2k3, and ut2k4 always having the gun glow blue and shooting at a higher rate. Eck.

reply to this message

#9: ..

by Quin on 03/15/2007 04:21, refers to #7

"And if you do not want to fork entirely, the game and engine code are sufficiently seperate that you can easily rejoin a future engine update with your gamecode."

What'd be really useful is if editing and physics was more accesible by the game code (eg. changing movement, adding materials, etc).

This is actually my biggest barrier to game module development at the moment, as I have to duplicate alot of engine code, and even then I sometimes can't do that from the game module itself as some things (structs/functions) are only defined for the engine code, then I need to add too many hooks into the engine itself.

If you're willing to address this issue I'm more than happy to share my views on which parts of the code could be more 'gameplay module friendly'.

reply to this message

#10: Re: Oh?

by sinsky on 03/15/2007 12:04, refers to #8

I haven't played Unreal etc. but it sounds cool, thanks :)

reply to this message

#11: Re: ..

by Aardappel_ on 03/15/2007 18:44, refers to #9

sounds like you're doing things which go beyond a gameplay mod... like I said, sauer was never architected for modding, and we certainly have no plan to ensure everything is moddable.

reply to this message

#12: Re: ..

by Quin on 03/16/2007 06:40, refers to #11

Yeah, eihrul and I talked a bit about this last night, and I tend to agree for the most part with the decision of minimalism. I just think seeing as extra entities can be done in the game module, materials and physics (like quake had it's physics in the quakec code) could benefit from the same thing, allowing the game module to influence it better.

For instance, in my SSP module I'd like to be able to mark cubes as 'destructibe' with a material (so the player can break blocks like in Mario), which really only applies to that game module.

Not that it really matters, I've already hooked some physics into my game module, and can apply much of what I've learnt about the entity system to the material system. It just means I need to manually patch each time I renew the engine code.

Take what I say with a grain of salt, I know there's a big difference between what I want/need and what's practical.

reply to this message

   Board Index