Introducing USE: the Universal Spot Environment for adventure games!


#1

It’s been a while since we discussed the development of our Dagon engine here. As you know, the C++ branch continues to evolve and is fully production ready thanks to the amazing contributions by @bd339. It’s the backbone of the upcoming Seclusion adventure game by @civanT, also featured in this forum.

The situation is a bit different with Asylum as we’ve moved on to Unreal Engine 4, though our framework (now in the form of a custom-made plugin) still builds upon the ideas and philosophies of Dagon++. It is, essentially, an UE4-minded implementation of Dagon.

So, other than the fancy name, something we’re doing right now is the proper implementation of a feature I always had in mind for Dagon++: a “smart spot” functionality that allows you to design hotspots with an object-oriented approach. A kind fire and forget affair in which you create the spot and let it intelligently handle interactions for you. I’ll let this graphic do the talking:

It’s the opposite of what you usually do when programming adventure games, where the spot is often merely a region that can be clicked on and you handle all the logic elsewhere – should the spot be disabled, should it load an image, change into something else entirely? Etc, etc.

With this approach, you can share some (and often quite a bit) of that responsibility to the spot itself. Let’s say you have a drawer that can be opened. You need to handle at least two states (closed, opened) and potentially several assets (image of closed/opened drawer, sound effect, maybe a video of drawer opening, etc). Here’s one way it could be done with USE:

That should be self-explanatory. Note how there’s not much you should do logic-wise to handle the “open drawer” event – it’s literally one click. Once the USE is properly tested and up and running, debugging an adventure using this system is potentially much easier!

It also extends easily to character interactions:

Also note how USE will ignore clicks during states which have no attachments of type Interaction. This is what I mean by easy debugging: one recurring problem in adventure games are “rogue” clicks that are badly handled, thus breaking stuff somewhere. Here they’re automatically ignored.

Anyway, this is something we’re still devising, so if you have any feedback and/or ideas, please feel free to share them. We’d like to turn in into a sort of standard that can be used in any adventure-oriented engine :slight_smile:


#2

This is fascinating. Even though I know zilch about actually implementing anything with regards to game development, I know just enough that I can follow along and understand why this is such a neat idea (even if I’ll never use it). :slight_smile:


#3

This is pretty cool. This actually reminds me of how things are implemented in Twine - probably the one game engine I actually know how to make anything for.