Sauerbraten is modder-unfriendly

by CC_machine#10932712341 on 12/11/2007 00:07, 22 messages, last message: 12/14/2007 04:17, 4979 views, last view: 05/02/2024 07:41

OK, so we\'ve been told to package mods as an addon for Sauer, to avoid technically becoming pirates.

There are a couple of problems with this:
1. The directory structure changes over time. The engine also crashes if it can\'t find a model file.
2. As the theme of the game changes (like the recent soundpack change), repackaged mods will change these aspects also, which is problematic.
3. As the engine(release) is updated, newer formats and features are being added to the content. This is a problem because older versions of the engine (and forks/mods) may have problems with these files.

Instructing users to \"go to this page, make sure to select not the latest release, but release xyz...\" is in theory possible, but users are idiots by on large, and most of us don\'t want to bother with silly things like this =|

I know changes aren\'t too often, but it just becomes a pain having to change file references and implementing workarounds, as well as catastrophic problems if the mod isn\'t developed anymore ...

Suggested solution: make a \"stable\" package of sauer just once (now) or every so often for modders to use for content. What I mean is, this package will stay the same for a long time, so modders will be able to package their content to fit in around these releases and work no matter what. Like the current cube release, which is very mod-friendly. Have a different package link on sourceforge or wherever from the official Sauerbraten, so that modders can link there without worrying that users will download the wrong file.

   Board Index   

#3: alternatively...

by Aardappel_ on 12/11/2007 02:28

I would like to ask you, if sauer is so mod unfriendly, which games are friendlier? Note, for comparison sake, to only mention games on an engine in continuous development (i.e. no commercial games, or games based on relatively stable once-commercial engines, like nexuiz), and with a comparable feature set to sauer.

reply to this message

#4: ..

by Julius on 12/11/2007 02:34

Mind explaining what your plans on better mod support are for the future?

Forking is generally an ugly solution, and I guess there are a few people out there thinking about using Sauerbraten as a base for a game/mod.

Thx.

reply to this message

#5: ..

by Julius on 12/11/2007 02:37

P.S.: Yes Sauer is already the most mod friendly open-source engine IMHO.

reply to this message

#6: Re: ..

by SheeEttin on 12/11/2007 02:43, refers to #5

Indeed. Just look at all these Sauer-derived things: http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&words=sauerbraten
And that's just projects on Sourceforge.

reply to this message

#7: ..

by Captain_Ahab on 12/11/2007 03:34

I think its mod friendly...I used to think otherwise, but the way the RPG is set up, it couldn\'t be easier ( except for gameplay things, and that\'s only because I don\'t have the right skills for that. )

If I could change one thing, it\'d be to allow cubescript to directly change the monsters/npc\'s AI state from a list of generic actions ( attack, follow <hmm follow might end up looking similar to flocking in some ways?>, flee, move to a range suitable for weapon type, wander around, etc. ) and allow cubescript to pick animations beyond the standard \'shoot,die, etc.\' to allow for near machinima scripting.

hmmmmmmm I might as well say my entire AI idea.
AI types are 0,1,2
0 is inanimate objects..no AI checks, gui pops up only if player wants to use/interact with it.
1 is non-sentient animals..check AI but no gui ...pure fight or flight responses.
2 is sentient and is pretty much as in game now.

Actions are chosen by comparing \'fear\' and \'hostility\' . Fear governs how badly the AI wants to get close to player. ( flight response ) low fear means monster tries to get nearer to play...hi fear means it runs away.
Hostility governs fight and aggression...hi hostility = attack...lo hostility = cooperation.

just ideas.

reply to this message

#8: Re: ..

by JadeMatrix on 12/11/2007 13:58, refers to #7

That was going to be my next suggestion after I finished the mod-hud. :) Defining AI features in scripts would be very useful; might cause a flux in sp maps.

reply to this message

#9: ..

by Acord on 12/11/2007 21:52

Sauerbraten is not mod-unfriendly, just keep in mind that ideas which you cannot implement under your own steam are mod-unfriendly. Write up what you WANT to do, and then make another chopped down document that includes what you CAN do. Work from the second one, and when your skills get up to speed(or someone graciously agrees to lend you a hand), implement things from the first one.

reply to this message

#10: Re: ..

by Aardappel_ on 12/12/2007 00:02, refers to #4

maybe I'll make the fps more moddable in the future, but that is not as easy, especially with multiplayer.

If you want ultimate mod friendlyness, the focus for that right now is eisenstern.

For eisenstern, *every level will be its own mod*. All gameplay will be in script, and each level completely initializes all of it. So the level designer becomes the game designer, which is exactly what most people want: create their own world with their own gameplay.

It will also be highly convenient for players, rather than having to deal with multiple sets of mods and maps, they can just download maps and mods will come with them. They can play them side by side in eisenstern with no extra intallation work.

I intend to make it so flexible that it can cover a wide array of gameplay styles, so maybe one day it have more fps style maps right next to heavy rpg maps.

I am intending to push the implementation forward for this release, so more people can get involved making maps/gameplay/content just by using scripts.

reply to this message

#11: Re: ..

by MovingTarget on 12/12/2007 00:03, refers to #10

Cool! That would be really fun to be able to script every aspect of gameplay. I agree that that would not be good at all for the FPS though...

reply to this message

#12: Re: ..

by Captain_Ahab on 12/12/2007 02:18, refers to #10

Its a dream come true; the ideal game. My daughter and I both love it and give our thanks to the generous developers.

< its the first game/program that she specifically *asked* me to print ALL the documentation for.>

reply to this message

#13: ..

by thedarkhuman on 12/12/2007 19:21

exactly !!!!!!! modding is made impossible
exactly !!!!!!! modding is made impossible

the map editor and texture is pain to make sthg nice

reply to this message

#14: Re: ..

by Acord on 12/12/2007 22:51, refers to #13

Have you... Have you actually ever worked on a mod?

reply to this message

#15: docs

by Hirato Kirata on 12/12/2007 22:58

The only point, I would agree to on this, you didn't mention. Sauer is extremely modder friendly already with their use of cfgs to set mapmodel and texture lists.

Anyways, the only thing I would state makes sauer mod unfriendly, is that some of the functions are documented too poorly. Like the other day, I was looking for some documentation on the complete command, and I was unable to find any, and I still don't know what vacubemin does.

There are plenty of modifications to the game's content already.
http://www.quadropolis.us/node/975
http://www.quadropolis.us/node/172
http://www.quadropolis.us/node/124
http://www.quadropolis.us/node/418

just to name a bunch, though the last one used to be sauermod, and is now blood frontier

~Hirato Kirata

reply to this message

#16: Re: docs

by _+Gilt on 12/13/2007 07:29, refers to #15

You most likely shouldn't be changing vacubemin.

The commands that aren't documented are not documented for a reason; if you play with them you will screw up the game in weird ways, and then post strange comments in the forum about how messed up your game is.

reply to this message

#17: ..

by Acord on 12/13/2007 09:12

I'll agree that the documentation sucks pretty hard - some features aren't even documented. In addition to that the useful (mostly advanced)materials are spread all over hell and creation and very difficult to keep track of.

One thing that this community would benefit hugely from is a step by step guide to building a mod.

The first step of the process should be building a mod from existing materials - same maps, monsters, behaviors, weapons etc.

The second step would involve replacing resources, and slightly tweaking game behaviors - physics, weapon values, adding new particles etc.

The third step would be the hardest - replacing serious code, adding features which don't exist, seriously modifying existing ones and changing other large parts of the base functionality. Things that are out of my league which make me thankful every day that Quin's around.

To be honest, the first step could be completed by anyone, and most of the instructions exist, but not in a format that's readily usable as such. The second and third parts could be equally difficult, depending on whether or not you are skilled at art or coding or - as is the case with many people, neither.

Teaching in both cases would begin from the ground up - principles of modeling, animation, sound design, and coding.

Of course, none of these are useful without the ability on the part of the modder to realize what their own capabilities are and to improve them or to let their mod be guided by their limitations.

reply to this message

#18: Re: ..

by MovingTarget on 12/13/2007 17:30, refers to #17

I personally think that if someone really wants to do a mod, but has absolutely no experience, that that person should start with Cube 1, seeing as it has such a small codebase, and it is quite easy to understand.

I tried my hand at modding both Sauerbraten and Cube, and they had their advantages and disadvantages, but Cube was by far the easiest, and the most fun. But I would encourage all the budding modders out there to read up on C++ BEFORE starting to mod; read at least two books, and also an online tutorial. I can say that they will benefit hugely.

reply to this message

#19: Re: ..

by JadeMatrix on 12/13/2007 20:40, refers to #18

Can anyone do much in the way of modding SB without C++? I'm going to start learning it — so I don't have to ask "what's the .cpp file that does such-and-such?" etc. ;)

reply to this message

#20: Re: ..

by MovingTarget on 12/13/2007 21:02, refers to #19

I always like to hear that someones learning C++. It's a great language, with lots of cool features. Just beware of pointers ;-) I still occasionally struggle a bit with them.

reply to this message

#21: Documentation

by steve_e on 12/14/2007 01:42

Yes, this is perhaps the only negative I found with Sauer - the fact that the commands are spread over 3 or 4 pages, aren't always alphabetically listed, and that descriptions are not always clear.

However, when telling people about Sauer and what a great tool it is and they ask about documentation I do say that even though the docs are a bit weak it really does not take long to figure out what is going on and it is a very quick program to get into.

This can be contrasted with, say, the Unreal Ed runtime that has massive amounts of documentation and tutorials but working in the environment totally sucks imho and despite the tutorials things just do not work consistently. Blender has loads of documentation but little for its game engine and the fact the game engine UV mapping is different to the modelling approach does not help at all... Both these tools on documentation face value would appear to be superior tools than Sauer but the proof is in the use of the tool, not the docs.

So, despite the apparent lack and messy docs, Sauer is still way quicker to get into creating levels and maps than other tools I have explored, which is why I am recommending it for our courses here.

At some stage I will probably take the various commands and organise them - lay them out alphabetically and by category for my students. Should I be able to do this in a web friendly format I will post a link up.

reply to this message

#22: Re: ..

by SheeEttin on 12/14/2007 04:17, refers to #20

I'm learning some C++ as I play around with the code, and pointers are the only part that makes me want to bash my head into something. Everything else I can handle pretty well.

Re #19, absolutely. I knew next to nothing about C or C++ before playing with Sauer, and now I know next to next to nothing.
It's mostly pretty easy to find things, they're usually where you expect them. Those that aren't, though, can easily be found by searching.

reply to this message

   Board Index