Skip to content

May 11th, 2014

May 11th, 2014 published on

At long last, planning on the new sprite/ui system has come to a close. This week has nothing really special to talk about. The majority of the remaining problems were all about filling in the last few things that hadn’t been fully documented for the latest changes (dual graph system, collision handling, scrolling, etc). Implementation is going smoothly so far, but since I made the unenviable choice of doing it on the C++ engine side I know full well that there is going to be some heavy debugging costs later on.

Not just that, but large swathes of the existing game are going to have to be updated for the new system (how maps are managed, battle backgrounds will accessed very differently, map objects are going to be handled as sprites instead of tiles, how every sprite in the game needs to be handled is changing, etc). So there’s still a lot of work ahead. On the plus side I feel like the last parts of the core engine that I was displeased with are finally getting into order. Once this work is done I feel like I could use the engine to make future games easily, instead of the weirdly cobbled together game-specific mess it started out as.

Unforeseen Consequences: Collisions Collide!

Only one design entry to talk about this week since there weren’t that many. Last week I decided to split the graph into two: one to inherit display/position properties, and one to indicate draw order. There was one thing I hadn’t considered when I did that, which is that linking those two things is extremely useful when it comes to collisions. By having every child be within every parent with the transform graph, it allows the property of only checking children for a collision when it collides with their parent. By having the layer graph order indicate draw order, it allows collisions to be intercepted by sprites towards the top of the draw order- ie if the user clicks on a window that’s on top of another window, only the top window actually receives the collision. These two properties are crazy useful, but by splitting the graph I had to choose one or the other.

At the end of the day the layer graph won out, since it’s a useful property rather than just an efficient property. But I didn’t just discard the transform graph’s filtering, I just made it an option for parents to pass collisions to children even if they themselves don’t collide (alternately, they can just encompass the entire world). Since the majority of the two graphs are identical only the few exceptions need concern themselves about this. It’s not ideal (more because these details are easily forgotten and create problems later, than from inefficiency), but it’s good enough.