Jump to content
  • Advertisement
Sign in to follow this  

Request for Feedback: FormulaEngine game scripting system

This topic is 1041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post

Link to post
Share on other sites
  • 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?

Only had time to skim over the readme for now, but I can answer the above two.
  • I would like an editor or compiler for the script. JSON is nice and easy to parse, but for me it's a nightmare to write. At least XML has schemas which an XML editor can use to provide auto-completion and basic syntax checking, but JSON doesn't have any validation system. Plus, JSON has no comment support (though depending on the reader you use you can enable it). I'm not saying throw away JSON, but I would want a tool or compiler from something easier to use that produced JSON before releasing it to users.
  • Sure, I'd experiment with it. Always looking for new ways to do things, and, having written a scripting language myself, I'm always interested in seeing how others approach the same/similar problems
Edit (after looking over the code and scripts):
  • Your bindings code seems to require a lot of "grunt work". This could easily be alleviated with template/macro work however.
  • Seems like you only allow very few parameter types (one double, two doubles, one unsigned) which seems like it would potentially be an even bigger restriction. Having some kind of variant array for parameter passing combined with vararg templates for unpacking and dispatching could remove this restriction.
  • Found the code a little hard to figure out - not because the logic was hard to follow, but I think because I had trouble figuring out the naming since I have pre-conceived notions of what properties and entities are, which doesn't seem to apply with this.
  • I would never want to script in this language as-is. The JSON is far too wordy and feels like someone basically mangled assembler in a hard-to-read and hard-to-write format. I basically have to write four or five "lines" of code for what would be a single line in assembler. Fine for the person making the language, but a user is going to want some kind of compiler with a more readable and easy to remember syntax.
  • I'm not sure what this gives you over a more imperative scripting language. It seems to do what other languages do - handle events to produce values and call functions in the native code. And if I wanted to do that I'd pick something I could easily read and write with a larger team behind it
TLDR: I wouldn't want to write scripting in JSON, the binding system is too limited for my usual use cases, and it doesn't seem to provide anything unique that other more-established languages can't already do.

So I would put some effort into making the binding code easier to work with, and add a compiler or editor for the language so I never have to see any JSON. Finding a unique niche for your language only matters if you're trying to "sell" it smile.png

Best of luck with it though, making new languages is always fun smile.png Edited by SmkViper

Share this post

Link to post
Share on other sites
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!

Share this post

Link to post
Share on other sites

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 smile.png


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


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.

Edited by Hodgman

Share this post

Link to post
Share on other sites
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 :-)

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!