What are you looking for?

BPMN Quest – Camunda as a Game Engine!

  • Blog
  • >
  • BPMN Quest – Camunda as a Game Engine!

This year at the annual Camunda hackdays one team bravely took it upon themselves to balance out the innovative and useful projects with something fun and frivolous. For two days somewhere in Brandenburg we were “Awesome-Team-Awesome” and we turned the Camunda engine into a platform to create a D&D style quest game. We call it BPMN Quest.

Start page for bpmn quest.
Start page for bpmn quest.

The project was split into a few different features and handed out to the reverently skilled members of the (awesome) team (awesome).

  • Location Map – showing the current location of the character as they moved through the story was given over to Paddy with help from Neville.
  • Player’s Quest Page – the interface that the user playing the game would see, including story text, pictures and decision buttons was all in the safe hands of Sebastian.
  • Dungeon Builder- a restricted version of the bpmn.io modeler that would let users create stories to be played by the engine. Paddy accepted this challenge.
  • Game Mechanics – this included a monster fighting engine, riddles, character creation and many other behind the scenes features. Jakob and Myself worked on that.
  • A Quest – A nice little quest created in order to utilize (and test) all features we had implemented was also created by Jakob and Myself.
  • Integration – who doesn’t enjoy integrating independently developed features into one seamless application? We all took part in this particular challenge.
Player interface in bpmn quest
Player interface, the font end bpmn quest

We wanted to ensure that the game engine and front end UI was as decoupled as possible from the story being played. This would ensure that people could create their story and deploy it without needing to worry about integration with either the front end or the back end. To accomplish this we standardized how the communication between the engine and the front end was made.

The front end would ask the engine for the current user task and would receive a few objects it would use to display the story. Including a story object, a character object and a list containing possible choices to be made at that point in the story. Someone creating a new quest would just need to populate a few java objects in either a service task or as input variables to a predefined call activity called “Story Item”.

Dungeon builder interface
Dungeon builder, the place where quests are born.

We also utilized the BPMN standard in order to orchestrate the progression of the quest. Exclusive gateways are used for the choices the player would make. Call activities show up for reoccurring events like fighting monsters or answering riddles. We also used an event-sub process which is scoped to be evoked when ever the game ends (either through death or victory).

Final screen when you've died.
Final screen when you’ve died.

You can download the source from GitHub. It was a lot of fun to make – and we hope that it’s also a bit of fun to play.

Try All Features of Camunda

Related Content

Build software that meets needs while still protecting the environment for future generations.
Achieve our first certification as a Camunda Certified Professional—Developer.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.