ASDAD: Under the Hood

I figured it would be great to give you all a peek “under the hood” of ASDAD!

I’m aware that a number of you probably don’t care about this stuff  and that’s fine! I won’t feel offended if you skip most of this post or the complete thing entirely. This is meant to appeal to those who crave technical details, love  knowing how things are done or simply enjoy a good ol’ “behind the scenes”!

It’s all Smoke and Mirrors…

All-Stars Dungeons and Diamonds has been completely developed in an in-house engine called SAME that I started developing circa January 2013. Both projects have been growing together for the past 18 months (ASDAD was conceived a few months later, around May) benefiting from each other greatly.

I didn’t use an already available engine not because they were bad (a lot of them are actually great and most-likely better than SAME) but because I love/need to have control over the way everything works internally. This gives me the freedom to tweak/grow this framework according to my own needs and priorities. It’s also a fun challenge and something I’ve done in the past many times for other platforms or for other people.

The name SAME is an acronym that stands for “Smoke And Mirrors Engine” and was suggested over the #ludumdare IRC channel while discussing the name for my project with fellow game developers. If I recall correctly I was thinking on naming my engine SMOKE, which was probably a silly acronym for something I can’t quite remember, and someone said that “Smoke & Mirrors” would be cool… and I liked it! It’s a well-known phrase used to describe/mock how big magic shows work (although it’s also a metaphor for deception and lies, which is kinda the opposite of cool :/). So I took the suggestion and made an acronym out of it. Because that’s what I do. I love acronyms. Even silly ones… Especially silly ones.

You can also call it SAM, S&M, The-SAME-engine-I-use-in-my-other-projects, etc.

Feature-wise there’s a handful of things I wished SAME had, and other things that can (and will) be improved in a near future, but it currently works great for my needs.

Bug-hunting Goggles

So here’s a typical AI debugging session of the single player mode in ASDAD (where you race against the computer). This is what it looks like when I activate “Debug” mode in the project.

The first thing you’ll probably notice are the “bounding circles” around each element (a concept we borrowed from the bounding spheres in 3D engines, which are similar in principle to bounding boxes but can contain the object rotated at any angle) which we use to test visibility, and some bounding boxes for labels and “collision-able” elements.

The thin vertical blue line shows a partition in the game space created by the collisions subsystem to cope with large maps and object-filled stages. The partition size can be tweaked depending on the map dimensions and average object size and helps reduce the amount of work done by the engine to detect and solve collisions.

Custom tailored

All of these “visual aids” are provided by the engine itself  for when we engage in bug hunting, but there are some additional debugging “markers” that you’ll notice in the screenshot that were developed particularly for ASDAD.

For instance barely visible in the image there’s two orange/yellow brackets around the item treasure box. This indicates that the AI is targeting the item (as it’s deemed as more valuable than the gems nearby) and it’s currently trying to reach it.

There’s also the arrows on the floor. They tell me the best direction of movement from any cell as computed by the AI, and create paths to the best locations in the maze. This is calculated based on the items and gems currently on the level as well as traps, walls, etc. There are several useful values computed by the AI that help with this process, like the “best reward” reachable from a given point and the distance to the nearest item. They also allows the AI opponent to evaluate the player’s position and compare its “strategic value” to their current location, helping them know when it’d be wise to swap places with you.

All of these aids have been terribly useful for debugging the game. Wrongly-placed collision boxes, layout problems and errors in the map navigation or item-targetting systems can all be detected with these tools.  In fact a lot of weird errors were caught this way in early stages of the development cycle.

I hope I can show you in future posts more of the internals of the game and the kind of things that are happening behind the scenes. There’s a lot of work involved in making things work properly that the player will probably never get to see!