So for a variety of reasons I've found myself looking into unusual or even novel models of scripting for implementing gameplay logic. Most models seem to draw heavily on imperative programming with a little bit of extra sauce of various flavors, depending on the framework.

FormulaEngine is a homegrown approach to creating gameplay logic. The elements are simple and yet highly composable, meaning it is easy to build complex logic systems that do pretty much anything. My goal is to minimize the amount of bindings needed between the scripting core itself and the C++ side of the game engine, something that I think I've accomplished at this point.

You can see the complete project on GitHub along with a simple "MUD engine" that supports rooms and items. I'm continually working on this so expect more features to pop up in the coming weeks.

I'm interested in feedback on this system on a number of facets:

• Does the approach seem sensible? Do you foresee awkward limitations or bottlenecks in the architecture?[/*]

How intuitive is it to extend the logic of FormulaMUD?[/*]

What sorts of improvements would you make to the system to make it appealing for actual use?[/*]

Is the approach overall something you think you might experiment with?[/*]

Thanks in advance.

Keep in mind that this is largely proof-of-concept and not really a heavy lift for making it embeddable; I assume that most people will want to heavily customize the bindings as well as the front-end for writing the actual scripts. JSON is a throwaway choice meant to expedite the POC, not a permanently coupled data format. In fact it would be trivial to rewrite the DeserializerFactory module to use anything else you like.

I also started adding a GUI tool for editing the data files which hides the JSON and a lot of the ugliness involved there. It's worth playing with for a moment if for nothing else than to see where things can go with a little bit of elbow grease.

As for unique selling points - the richness is actually in the formula system itself, not the scaffolding for events/actions/etc. As more game systems come online in the MUD framework it should become increasingly clear how useful the formulas are. A glance at the Flocking demo is also instructive IMO.


Thanks for the feedback!

Lots of engines supplement/augment their imperative gameplay language with a declarative one which is written using a GUI front-end -- e.g. Kismet, Blueprint, Flow, uScript. This is pretty much a standard must-have feature now.

However, there's no good open-source implementations of this idea AFAIK

Having good interop with C++ is of course necessary for such a project, but it would be great to have good interop with other common gameplay languages like Lua, C#, etc...

e.g.

Unreal 4 uses runtime-compiled C++ as it's scripting language, and seamless integration between C++ and blueprint scripts.

Stingray uses Lua as it's scripting language, and has seamless integration between Lua and Flow scripts.

You could even have your JSON/etc files get compiled into Lua code, perhaps with a small Lua runtime library. That would then make your declarative scripts integrate with Lua gameplay code completely seamlessly, and engines could use their existing Lua binding system. I would definitely make use of that project!

Of course, everyone has different language preferences, so going to these lengths for Lua, C++, Mono, Java, etc will be a massive effort multiplier... There's definitely potential for something like this to be a really important project though!

p.s. I haven't actually checked out your GUI yet, and only had a very quick glance over the examples.

The GUI is now pretty powerful and even with the odd missing script element I find it pretty easy to whip up interesting MUD content. I'd be really keen to know what people think of the experience of building a tiny mini-game out of the parts supplied in the GitHub repo.

Obviously the big missing piece is the documentation explaining the thought processes and how to get from A to B with the tools available... I'll be yammering about this at GDC but hope to also provide some wiki pages in the next several weeks which detail the ins and outs of using the whole thing as a concept.


A quick note on bindings: the whole point of this is that you shouldn't need to be doing much working with bindings on a daily basis anyways. It's more like you set them up once, to suit your engine's tastes, and then just use the infrastructure to build more complex layers. If you find yourself adding things like manual bindings to engine routines a lot, you're probably doing it wrong. Again this really deserves a lot better documentation and I totally sympathize if it doesn't make sense yet :-)