Cube Engine Games

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, 12414 views, last view: 05/05/2024 08:12

(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

#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.