Designing a story plot system with Groovy

Hi guys!

I am interested to hear your ideas on this topic.

The idea is to design a flexible story plotting system using Groovy scripting language.

Each game level has a piece of story that can be in continuation of a previous level story. I was thinking to create a “PlotScript” interface so that each game level has a PlotScript implemented in groovy.

A PlotScript consists of multiple PlotPoints. A plot point is a physical place on the map, that when players go there the plot point gets activated. As a result, it can trigger a cutscene on players, enable dialogues on NPCs, give tasks to NPCs or activate a quest. (also I may use it as a save point, so when players failed the mission they will get started again from there :thinking:)

Inputs of plot script are the events that are published from the game, for example, dialogue events, quest events, …

I can listen to those events in plot script and do something on the NPCs, for example, give them some tasks,…

I am interested to hear your ideas and your suggestions about this. :slightly_smiling_face:



Does it mean using scripts to make games?

I mean using plot scripts to drive the game story not game itself. :slightly_smiling_face:


Simply put, plot scripts should listen to player inputs and different game events, and based on game story tell what should happen in game and tell NPCs “what” they should do, but deciding “how” to do it will be handled by AI and not in the plot script.

I hope to have script driven game programming, just like the mainstream engine. :laughing:

Hmm… what about constructing a behavior tree for the entire level plot inside the plot script? :thinking:

1 Like

What you states seems reasonable.
I think ideally I would implement the features one needs right now… ← Prototype approach.
Then, as your requirements expand, add new features. ← iterating the Prototype
I think one will get it done and over with faster this way and then one can focus on the content of the game!


In fact, I always use the custom controller as a script, just like u3d, hanging on a Node.

what’s the point to use Groovy, when Kotlin is available? Kotlin inherits all Groovy’s good stuff, but at the same time has strong type system.

Java in jME takes the same place as C# in Unity (they call it scripting and engine is pretty mainstream). So we can say Java is scripting language for jME.

I miss kotlin and the days when Android was developed.

In the scene editor of sdk, you can add a custom controller for the node. I mount the custom controller for the node like u3d mount script. However, there is no initialization method for the custom controller. I hope the team can add an initialization method.

It’s a design choice. He could also have chosen JavaScript or Scala, for example.


Birds fly because birds fly, very informative.

I have a silly idea, why not reuse the style system of lemur, with a control that triggers styles when you want.

When a state is change, or is too near to something, or level is changed, it triggers a style.

The style could be your PlotScript and the control can be named PlotScriptControl, or instead of a control, an AppState that handles the triggering

Well, that’s something i would try

1 Like

Thanks, @pankey that seems to be an interesting idea, I am not much familiar with how Lemur style works, I need to take a look at it again.

Yeah, I was thinking to do kind of similar approach. To have a PlotSystem at server side (that implements SiO2 GameSystem which is similar to JME AppState) and inside that PlotSystem, when a game level starts I load the relevant PlotScript for that level, then inside the PlotScript upon initialize I can register triggers for different game events I need (mostly dialogue events and quest events).

(I am using from SiO2 for sending game events).

I am also interested to hear @pspeed ideas :slightly_smiling_face:

1 Like

1 Like

Heheh… me, too.

I’m in the midst of a handful of other thorny problems at the moment and may not have time to drill into other folks designs right now. From what I’ve read so far, it sounds cool enough.

Between my day-job’s big deliverable coming up soon and trying to make BIG progress on MOSS… and still participating in music weeklies challenges, I have a too full plate these days. :slight_smile:



Also, I am following your music weeklies challenges on your twitter page, great stuff, you are a man with multiple talents :slightly_smiling_face:

1 Like

Aw, thanks. I appreciate it.

Music is still one of those areas where my confidence comes and goes from day to day. But speaking of… I’m reading JME forums to drag my feet on getting the “ancient civilizations” song written this week. So I should probably get to that! lol

1 Like


Thoughts about how to do it

  1. to be universal, story plot system need to be abstract enough from scene graph. we need a trigger API here, that allows users to implement theirs own triggers to link PlotPoints to.
  2. it’s very tempting to use closures here for event listeners chain, but closures will catch state from local context and be very tricky in diagnostic and will make troubles with serialization.
  3. In general it’s better to stick to some DSL approach, which is Groovy is good for (actually was before Kotlin :slight_smile:).

Thoughts about why do not do it

  1. I prefer data-centric approach in game development, where we have solid and clear game state model and all other components are pure logic. so the state of game story plot should be part of this state. I can’t imagine simple enough way for dedicated library/framework to help organize of story plot with such architecture - it’s just easier to do it in custom way.
  2. dedicated story plot system is reasonable when game have really long or complex story. but… games with long or complex story usually has good budgets, because cutscenes and such things cost much. I think programmers of games with good budgets usually would prefer to implement their own small story toolkit than depend on 3rd party solution.

From my POV such dedicated story plot system is not viable product even in open source. Anyway, its proof-of-concept development would be good source of fun :slight_smile:


Hm, curious. Just browsed your twitter and haven’t found anything relevant. Could you share (maybe in private) some links?

1 Like