home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


Plugin-based development of Sauerbraten or sauerbraten mods?

by IllvilJa on 04/29/2008 01:49, 37 messages, last message: 07/05/2008 05:23, 12432 views, last view: 05/23/2024 01:10

(This has been brewing in my mind and gnarling my skull for over a week or so, being impossible to get out of my mind... so I had to get this off my chest...)

When visiting the home page for the excellent editor jEdit (http://www.jedit.org), the very first sentence on that page is as follows:

"jEdit is a mature programmer's text editor with hundreds (counting the time developing plugins) of person-years of development behind it."

Now that at least SOUNDS impressive, marketing is a great thing! But now consider this rewrite of the sentence above:

"Sauerbraten is a mature FPS with hundreds (counting the time developming plugins) of person-years of development behind it's game engine."

That sentence depicts a hypothetical scenario, where we have some sort of architecture in the game engine allowing authors to create plugins that alters and extends the game in various aspects, potentially even inventing new aspects of the game. Note that I'm not talking about maps, textures, sounds, cubescripts or models here (even if they today provide some features of modular development which is good) but pieces of binary code which provides customized functions like custom lighters, custom 3d sound, custom modeling of shockwaves from explosions, custom particle systems, custom material cube shapers or why not custom cubescript commands. This without the requirement to recompile Sauerbraten but instead, just install the plugins at a place where Sauerbraten can reach them and load them whenever a map/mod/etc requires them. Of course, the plugins are opensource, so reviewers can read the source to verify that the plugins are not malicious.

Each sort of customizable plugin handles one well defined aspect of the game engine, preferably in some new special way, be it that it adds some sophisticated features for the game itself, or it is simply good at doing the normal job for such a plugin but only using 1/10th of the Memory and CPU usage normally used, or that it is intentionally simplified to bring down resource usages at the expense of ingame functionality and sophistication. The nice thing is that the plugin author do NOT have to grok the source of the entire game engine, it's just enough to understand the task of the specific kind of plugin being written. He/she writes the plugin, tests it and then uploads it to Quadropolis when ready, so others can use it.

Many good frameworks are built using this kind of approach. Many small modules and plugins, each of them doing just one or perhaps a handful of tasks but not more, but they do their job very, very well. Maybe Sauerbraten would benefit as well? Developers of the plugins and the maintainers of Sauerbraten can work independently of each other, which gives the plugin devs more freedom (at the end of the day, it is the acceptance of the end users that determines if the plugin is useful or not) and also, it frees up the Sauerbraten maintainers from having to manage the devs contributing with plugins and the developed plugin software. Then finally, the plugins can be distributed precompiled so the end users don't have to compile them or recompile Sauerbraten to use the plugins. Useful for modders too, as those now can create mods by creating some plugins as well as reusing already existing plugins that are useful. The Sauerbraten devs can also pick plugins they find really useful for the "vanilla" Sauerbraten and include them in the official Sauerbraten release.

jEdit is not an FPS. Sauerbraten is not a text editor. Both are however relatively complex pieces of software, both carrying out tasks which can be analyzed in such ways that separate functions inside can be analyzed. I think this kind of plugin architecture and associated development model can benefit Sauerbraten as well as the game's mods.

Curious about your thoughts on this. These plugins can be implemented one kind of plugin at a time. The plugin architecture can even be implemented in a mod of Sauerbraten (some more generic mod or a mod created ONLY for implementing this plugin concept) and then, if working well, it can be incorporated into the official Sauerbraten. Software development should be a little like Lego, after all ;-).

(and yes, I know that developing this kind of architecture requires both development effort as well as some (reasonable) amount of thought. I'm not naively assuming this is trivial.)

(BTW. I think the above statement from the jEdit homepage regrading jEdit actually IS accurate. The editor IS mature and very useful (I use it for software development) and there ARE a large number of plugins available, so I suspect even the "hundreds of person years of development" is accurate too)

   Board Index    Go to next 20 messagesGo to last 20 messages

#1: I like it!

by tman_elite on 04/29/2008 03:57

I think this is a great idea if developers have the time or resources to implement it.

reply to this message

#2: ..

by MovingTarget on 04/29/2008 15:37

/goes and researches dynamic loading of DLL's...

reply to this message

#3: Re: ..

by Quin on 04/30/2008 03:57, refers to #2

/me watches MovingTarget's head explode.

reply to this message

#4: Re: ..

by SheeEttin on 04/30/2008 04:47, refers to #2

Or we could just see about backporting the Lua VM from that ET:CE project (which I haven't heard any news about recently...).

reply to this message

#5: Re: ..

by MovingTarget on 04/30/2008 06:12, refers to #3

Yeah, it just about did! Interestingly enough, the Linux way seemed *slightly* easier, but still... my brain doesn't look good all over the floor.

reply to this message

#6: Re: ..

by Quin on 04/30/2008 20:07, refers to #5

Yeah, Linux shared objects are a tad bit nicer, Windows DLL's are hell.

reply to this message

#7: ..

by IllvilJa on 05/01/2008 01:26

Um... wasn't supposed to blow up anyones brain.

If swept together into a nice pile of brain, can you pour it back then? Would that help?

(This is soooo embarrasing!)

reply to this message

#8: Re: ..

by MovingTarget on 05/01/2008 01:53, refers to #7

Hmm, since I don't have my brains right now, I can't tell you! Try it. :D

Anyway, I have an idea that might work that involves DLL's, but not the crap I was looking at earlier. I'll post something on Quad when I'm done (if it works).

reply to this message

#9: Plugins

by tentus_ on 05/01/2008 02:10

Isn't the plugin concept really just a natural extension of the current game/engine separation concept?

I would personally love to see this become a reality, it would make Sauer a much more flexible tool. If you guys ever need some beta-ing, give me a call and I'll find some time.

reply to this message

#10: Re: Plugins

by MovingTarget on 05/01/2008 03:36, refers to #9

Yes, it is. My first step in the plugin direction will be to break down the code even further, and have such libraries as weapons.dll (containing the weapon code) and particles.dll (yup, you guessed it, particles!). Then, for a mod, instead of distributing a new executable, they just distribute the necessary dll's. Not quite plugin-like (you have to replace stuff), but until I gather up my brains from the floor and master this dynamic loading stuff, it's gonna stay similar.

reply to this message

#11: Re: Plugins

by SheeEttin on 05/01/2008 04:12, refers to #10

Hey, if you can do it, it'd be awesome. Then I could just distribute DLLs (or something) with maps so people can use the wacky changes I made. :P

Seriously, I do have some maps that are only useful to me because they require source modifications. I'd love to see them usable by others.

reply to this message

#12: Re: Plugins

by tman_elite on 05/01/2008 04:14, refers to #11

This makes me curious to know what these maps involve. The rest of us might be able to benefit from these source modifications too.

reply to this message

#13: ..

by MovingTarget on 05/01/2008 04:59

OK guys, what should the libraries consist of? fpsgame.dll, rpggame.dll, engine.dll? Should I split it up a bit more?

particle.dll, fx.dll, etc.?

Give me what you'd like.

reply to this message

#14: Re: ..

by tentus_ on 05/01/2008 05:27, refers to #13

Particles and models should probably be their own DLLs. It could be quite useful for future modders to be able to write their own model format dll. Demo related stuff should probably also be independant: that would hopefully lead to someone making a more powerful and easy to use demo creator.

reply to this message

#15: ..

by Quin on 05/01/2008 07:57

My opinion is that people use the cube engine to make use of it for that very reason, as an engine. I doubt many people would be writing code to handle new model formats etc. I'd suggest just splitting it into the engine executable, and the game module. In addition to that, you may want to move some things (like player movement) into the game code (which I did in BF).

I used to work quite alot with shared objects in Linux, but found the "DLL barrier" when trying to port the stuff to Windows, so let me know what you're up to and how you're going - I'm fairly interested in seeing where this goes, as I've always put this in the "why bother" department because there just aren't that many programmers in this community.

reply to this message

#16: Re: ..

by MovingTarget on 05/01/2008 14:43, refers to #15

Hmmmm, so what your suggesting is that I should somehow make the engine load the game module, instead of what I earlier did, making the game load the engine module. ezombie did say he'd appreciate that.

I'll try that, and the path I was going with earlier. Could be quite educating.

reply to this message

#17: ..

by MovingTarget on 05/01/2008 22:27

OK, so far, I have moved physics, networking, sound, and the shared stuff into their respective modules. I started out with my first separation, and am breaking down the engine DLL.

What is really ticking me off (I don't know why) is the interdependencies of the stuff: it's understandable that everything needs to link to shared, but engine has to link to physics, physics has to link to engine, and the executable has to link to physics and engine. Somehow that seems wrong.

7*6=I wonder why I got the exact same problem I did last time?

reply to this message

#18: Re: ..

by 2345234523452345 on 05/01/2008 23:19, refers to #17

this seems not well thought out...

all you'd really want to do with a plug-in thing is add new COMMANDs, VARs and game mods.

basically you'd have the lib supply one function along the lines of:

struct plugdefs *__init_my_plug(void)

where struct plugdefs just contains a dictionary of the various COMMANDs, VARs and mods that the plug-in supplies. then the lib loader registers those things, and yer done.

reply to this message

#19: Re: ..

by MovingTarget on 05/01/2008 23:29, refers to #18

That's not so bad of an idea! However, how would Sauerbraten know to load your library instead of its own (say engine.dll)? Would there be a txt file containing the lib to load? Would Sauer index all directories containing a lib of the preset name, and give you an option to load that mod (like with id games)? Would you simply replace the default one (not a good idea)? Would Sauer index all non-necessary libraries and load the one that is first in alphabetical order?

reply to this message

#20: Re: ..

by Quin on 05/02/2008 00:45, refers to #17

No, that is absolutely correct, and part of why I never bothered. In Linux, shared objects do exactly that, share. You can have them reference code from each other or the loading executable, in Windows.. this is another story. Sucky huh?

You'll need to come up with a good method of interprocess communication (IPC).

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
54106624 visitors requested 71891166 pages
page created in 0.028 seconds using 9 queries
hosted by Boost Digital