Isometric Prototypes

     The senior programmer on my team had been developing a RPG inspired interface for teaching vocabulary and came to me about developing an isometric world map for it, based on a few isometric demos I had made in the tool in the past.
     While I was definitely onboard with the idea, I started by identifying three of the biggest problems I had with my demos. Performance, our runtime had a memory leak issue that could not be addressed by our team. Ease of programming, the existing paradigms didn't provide a practical way to program behavior for more than a few pawns. Ease of design, building objects like walls was extremely time consuming and too complicated for our designers.

     In this proof of concept game you steer your cart around the track and collect exclamation points while avoiding the blue orbs that chase you. With each point collected the orbs accelerate, eventually catching you.
     While this proved that isometric and more real-time games were possible in the company's tool it had a number of performance issues. It suffered from all three of the issues described. After a minute or so the garbage collector would start running every other second to address the memory leak. The orbs had to be hard coded into the game loop to be updated, and due to some issues with collisions all hitboxes for things that moved were exactly one pixel. At the design level, each object needed to be manually placed in the correct layer.

     In the first iteration of the engine I was able to eliminate most of the performance issues present in the demo. By divorcing the nodes that control the art in the scene from the data objects we gave ourselves more control, allowing us to avoid using the methods causing the memory leak as often, triggering the garbage collector so little as to be only noticeable to someone looking for it.
     As a side effect of these new objects, life was made easier for programmers as new children could be made giving pawns code specific to them that could be run as part of the update loop with out special changes at the scene level.

      Since it was originally designed to only have one floor layer and a few cosmetic ones the engine used a series of grids to store maps. This version would build the maps at execution time using a file of pre-fabbed components that were mapped to values in the grid. This allowed designers to switch out art assets in minutes and they were able to build maps using the Tiled level editor by exporting .CSV files and using a plug in I wrote to import them into our proprietary tool.
     Taking further advantage of the grid system I implemented a version of Dijkstra's for path finding, allowing navigation by single touch for iPad or the single click of a mouse.
      Unfortunately the art department was unhappy being confined to grid based assets. Also demand for multiple floor layers increased, and while I was able to get pathfinding working well between floors certain cases kept causing severe z-ordering issues. It was clear I needed to ditch the grid system to achieve the team's needs. I made it clear I could improve the rendering issues and accomodate more kinds of art but at the cost of some ease of use.

     Version 2 was substantially more sophisticated. We now used a 3d coordinate system. Objects were now defined using Axis Aligned Bounding Boxs instead of their grid position. This allowed me to sort for rendering using a topological sort which solved all the z-order issues.
     To help optimize path finding I first created a resolution parameter in the path finding class. This allowed the algorithm to treat the map as a grid and check each square objects it might collide with. Next I upgraded the algorithm to A*. Drastically improving the performance and giving more levels of control to other programmers.

      Since Tiled would no longer work as a map editor we started using the tool to place items as best we could in 2d. I created two utilities with JavaFX as a stop gap to aid designers. One is general purpose and converts the 2d coordinates to the 3d coordinates needed, adjusted for height. The other utility is for determining the origin and bounding box size for a given sprite. The designer drags the image in and sets the box size and centers it how they want before copying the figures into the scene.
     Designers were able to quickly master these tools and start producing maps, but had the project continued this workflow would have been a target for further improvements.

     Although the final prototype scene was ultimately rejected, I was able to reuse the bulk of the code for several other prototypes. Including some where I changed the projection to a fixed 3d camera instead of isometric.