A Cube mod-system?

by e:n:i:g:m:a on 02/23/2004 16:35, 10 messages, last message: 03/14/2004 22:57, 1472 views, last view: 04/25/2024 00:53

Hey, does anyone plan on coding a cube modding system into cube, so that you can add extensions that don't necessarily have to meess up cube itself? (eg. extra guns, diff. models, etc.) you could then release another server that requires certain mods to be enalbed/disabled/downloaded, etc.

   Board Index   

#1: ooops...

by e:n:i:g:m:a on 02/23/2004 16:36

Oops, perhaps this belongs in the "Most Wanted Feature" thead...

reply to this message

#2: hmmm

by Lethedethius on 03/08/2004 02:46

Aard, this would be something to think about when your making the new engine. Sauerbraten is gonna be more advanced in mapping, why not in modding? :)

reply to this message

#3: Re: hmmm

by pushplay on 03/08/2004 06:54, refers to #2

One of the things I would like to influence in Sauer is keeping the gameplay code more at arm's length from the rest of the code. You can see in Quad that I started to pull all that stuff out into a seperate file. If there's a better way to organize gameplay code I'd like to hear about it.

reply to this message

#4: ..

by staffy02 on 03/08/2004 07:06

so your saying there should be like a .dll file with all the information for your mod.
so that you can keep the engine totally sepereate from the actual game code for easier updating?

reply to this message

#5: sorry

by Aardappel on 03/09/2004 03:29

but personally not interested in this. As I have already said, it is very hard to predict all the stuff a mod will want to modify. Planning for such a structure is just a wild guess and needlessly bloats the engine. Personally I'd prefer (if I was a modder) some neat little engine with sample gameplay already there and ready to be modified, then some huge modding API that I have to learn and doesn't do half the stuff I want to do.

Yes, there's lots of advantages for ways the other engines do it, mainly that mods can keep working with newer engine versions, but those engines have vastly different goals.

Also, no offense, 99% of mods suck ass. I prefer to have a game with really good standard gameplay and lots of cool maps etc available for it, than 101 mods from people who are better off not touching game design. But that's just me :)

reply to this message

#6: Re: ..

by pushplay on 03/09/2004 05:49, refers to #4

Whoah whoah whoah. I'm not talking about some dll or plugin arcitecture. Guessing the needs of all the mods people would want to do would make any application interface cumbersome and it still wouldn't do everything you wanted.

I'm just talking about cleaner code so that tweaking the gameplay doesn't resemble an easter egg hunt.

reply to this message

#7: ..

by staffy02 on 03/09/2004 07:55

ok cool. i just saw the .dll thing in a few other engines.

reply to this message

#8: Re: sorry

by fsmunoz on 03/09/2004 11:55, refers to #5

To support Aard view on this let me just share my very small experience. Yesterday I devoted 15 minutes to change something in Cube. Basically I was aiming at making the chaingun recoil (press the fire button without taking the finger off and the shots start going up the actuall aim). As I repeatedly said I'm not a gread coder, but here's the thing: Cube's source is so brilliantly clean and logical that making that change actually work was possible in the said 15 minutes, and easy as hell (even if the recoil is simplistic). Most - if not all - things want to do with Cube already have most infrastructure in the code itself: it simply isn't used as the gameplay isn't intended to go that way.

I would argue that to make a "mod" with Cube as it is is way simpler that to program a mod for other games with a modding API. Generally this are limited and one has to go round the limitations of the modding API (or so I hear). In Cube the source itself is *smaller* than most modding API related files in other games!

As it is now a "mod" can only be made as another executable that livs in the bin* directory and that can use specific data inserted into the packages/ et al folders. This is actually not bad at all, if you consider that the size of the generated binary is gain *smaller* than most .so's and .dll's that constitute mods in other games.

The only request regarding this that I would wish would make it ti Cube itself is the whole VWEP-like weapon handling (seeing what other players are carrying, etc.) since this would IMHO enhance Cube's own gameplay *and* be a major bonus for people making mods. All the other stuff people suggest can be made by changing the source.

Now, this doesn't mean that is someone desings (or has designed) a mod-system that it is useless; it can be of great use if well made. But in the end, even without it, changin Cube is not only relatively easy but actually quite enjoyable. Being able to see how e.g. player shooting is handled by reading *1* file is a blessing comparing to have to dissect 10+ files of physic models and 20+ include files with structs that do god knows what just to be able to find how a bullet is created.

reply to this message

#9: Mod system

by Pxtl on 03/09/2004 23:10

Actually, I would like a limited mod-system available in the game. Honestly, I have always had a weakness for engines where any 2-year old could mod. Basically, my thought is this - super-simple mod system for designing weapons, pickups, player mods, etc. Very limited and frustrating for anyone who wants to do serious stuff with it. The advantage is you get something an 8-year old could play with, and let the non-coders have some fun. Power and usability are almost always mutually exclusive in design tools, but I sometimes like to make things that go at the other end of the scale for fun.

I've got some things in mind, and might make a mod of it if it doesn't grow too bloated in my head. It would probably be twofold, a Tkinter-based editor (I like Python and Cube lacks sufficient GUI tools for me) in which you design gametypes, and the actual in-Cube code to run them. Basically, instead of the current system, a server could design additional weapons, pickups, etc. and build them together into gametypes. The clients can then vote for them from the list. This would encourage people to run servers, since then they'd have the power to define new gametypes.

reply to this message

#10: Yeah...

by e:n:i:g:m:a on 03/14/2004 22:57

*bump*

Yeah, that's my idea, just enough to change some models or guns, add more guns, enemies, diff. gametypes, stuff that you can change w/o messing up the cube engine and having to run a separate server.

reply to this message

   Board Index