WorldForge Community

tomva

Hello all-

I've been making decent progress on my WorldCompiler tool. I hope to publish some design and even working code in the next few days (in the Tools forum). My motivation and more use cases are mentioned here: http://wiki.worldforge.org/wiki/DecouplingUseCases.

As I've been working on it, other questions have come to mind. How does a world author specify a combat system? And a combat system may require a skill system, how is that chosen? And other things like whether there is a character creation/levelling process, or whether it is a lightweight character game, etc. I suspect all of these elements (skill systems, combat systems, etc.) will also be atomic, separable units (a package of python scripts or some such) that game authors can build and share. But how do they build them?

So my question would be: if we think of the WorldForge binaries (particularly cyphesis and ember right now) as a base kernel for building games, what is the supported API they expose? How do you recommend that coders and world creators layer skill systems and combat systems on top of the core components?

I suspect (hope) it would be a fairly primitive API, with a number of events that you can register for, and a few high-level commands. So for instance, someone building a combat system on top of the basic binaries would get collision events, and could use collision information to figure out how combat was going. A skill system would need some sort of eventing to set up UI when skills were being used, etc.

My assumption is that the core binaries do not have any hard-coded knowledge of skill systems or combat systems etc., but just provide the basic primitives that developers need to add these layers. Does that sound right?

I'd like to document whatever is there now, and whatever is being planned for the future. But I think if a few examples are outlined (recommended way to build pluggable skill systems, combat systems, etc.) it will really spur additional development.

Thoughts?

-Thomas

erik

I'll chime in on how this is supposed to work on the Ember side.
Ember is meant to be a reference client platform which should be adapted to specific games. This is one of the clear goals of it, so if there's any areas in it where this is lacking I will work on fixing it.
That said, there are currently some parts of the code where there's behaviour hard coded for Mason. Not many, and not something that can be fixed. I've strived to keep everything as data driven as possible, just because it's then easier to change the behaviour. The things that are game specific are mainly the different gui widgets and the media. However, this is how it currently works:
1. Ember is started
2. The file resources.cfg is parsed and all resources are loaded.
3. WFUT is contacted in accordance with what's set up in ember.conf and media is updated
4. Standard widgets as well as those widgets which haven't been ported from C++ to lua are loaded.
5. The gui is initialized and the file Bootstrap.lua is loaded. This loads all the lua widgets

However, I would like this to be a little more dynamic, so that
a) It should be possible to have multiple "themes" which can be specified at startup. This decides which widgets to load by default.
b) A more dynamic way of using WFUT. As it is now it's hardcoded to the same server for every world/server, but it would be better if every world could specify a different WFUT path. This also means that we would want to distribute different "media packs" for some standard worlds (we want to avoid using WFUT to download all media)
c) a better way of loading and unloading the widgets. I've been thinking of using a system similiar to the init.d system, where you put lua script files in "mason/connected/S10inventory.lua" and similiar.
d) More dynamic loading of the resources. This could either be driven by the theme selection mechanism in a), or by loading them first when the user has connected to a certain server (and then knows what ruleset to use)

Edward

"tomva" said:
I've been making decent progress on my WorldCompiler tool. I hope to publish some design and even working code in the next few days (in the Tools forum). My motivation and more use cases are mentioned here: http://wiki.worldforge.org/wiki/DecouplingUseCases.

Thanks for the link. I hadn't seen that.

As I've been working on it, other questions have come to mind. How does a world author specify a combat system? And a combat system may require a skill system, how is that chosen? And other things like whether there is a character creation/levelling process, or whether it is a lightweight character game, etc. I suspect all of these elements (skill systems, combat systems, etc.) will also be atomic, separable units (a package of python scripts or some such) that game authors can build and share. But how do they build them?

So my question would be: if we think of the WorldForge binaries (particularly cyphesis and ember right now) as a base kernel for building games, what is the supported API they expose? How do you recommend that coders and world creators layer skill systems and combat systems on top of the core components?

I suspect (hope) it would be a fairly primitive API, with a number of events that you can register for, and a few high-level commands. So for instance, someone building a combat system on top of the basic binaries would get collision events, and could use collision information to figure out how combat was going. A skill system would need some sort of eventing to set up UI when skills were being used, etc.

What you're describing sounds exactly like the Ruleset Modeling Language, which Project Angela is working on at http://rpg-gamerz.com/smf/index.php (though they'll be moving to http://www.projectangela.org in a few weeks). It's open source (MIT Expat License), so you're welcome to use the code.

The idea behind the RML is that a non-programmer should be able to design a ruleset without needing to dig into the engine itself. The main goals are to make it as easy as possible for a game designer to build a game, and to make it as easy as possible for an engine to integrate the RML. A secondary goal is to allow rulesets to be designed in a modular fashion, so that parts can be freely exchanged (although some may not mesh very well, of course).

WorldForge Community

Howdy, Stranger!

Categories