It’s been almost a month since our last update. Things aren’t going fast since we’re not many people. You may have noticed it if you read the credits in Kill Yourself.
Anyway, let’s talk about the current challenge in the development: extending the engine.
Kill Yourself was conceived as a toy project for a small, minimalist adventure game engine. We wanted just to create the smallest subset of classes and instructions to define a game, and we needed a couple of puzzles to test it. We didn’t want to lose time with cool but unnecessary features, and if you think about it, the game shows all its limitations when compared to the old adventure game classics: no dialogs, no secondary characters, only one room developed in one dimension. We’re completely satisfied with our decision, since it gave us the possibility to create the engine and the game in a relatively small time. But now it’s time for us to grow.
The actual goal of a 1D room was to force the character to move horizontally in order to avoid to animate a front/back walkcycle, which is something we hated doing. But then we got to the window puzzles, and since the window was too far away from the walking line, we needed a front/back walkcycle anyway. So we felt like the next improvement for the new game should be 2D rooms.
When adding a dimension, some problems arise: what happens if my room is concave? What if I have an object in the middle of the room? 1D is easy: just define where the room starts and ends, and then let the player move in a straight line. With 2D rooms, path finding becomes crucial. Fortunately, path finding is a well known problem in computer science, even if its main applications are usually too complex with respect to what we need to do. In a game like ours, the search graph is usually extremely small and there’s no need for the actual shortest path, but an approximation would suffice.
Our solution, which
we blatantly copied from was inspired by this post from Ron Gilbert, makes use of walkboxes. If you subdivide your walkable zone into convex boxes with no holes then you could just walk on a straight line whenever the starting point and the goal lie within the same box, and if you have a strategy of finding a path between different boxes everything’s solved.
What we do is visually define the set of boxes and the adjacencies between them with help of a small Java application, which then saves the corresponding graph in a code readable by our engine. The path from A to B is then defined as follows: if A and B lie in the same walkbox, it’s just a straight line. Otherwise the best path between the start and end walkboxes is computed with the A* algorithm using the centroid of each walkbox as a node and the adjacencies as edges. The obtained path is then furtherly refined using the gateways, which are the edges with red squares as endpoints in the image: for each gateway we must traverse, we take as our next waypoint the coordinate that minimizes the overall walking distance. So it’s just another A* search on a graph that uses points in the gateways as nodes.
In layman terms… we do some magic stuff to obtain a straight as possible path. It works, believe us.
The next planned features are enabling/disabling boxes on the fly and triggering onEnter/onExit events. If you played KY long enough you might have noticed a small cutscene the first time you enter the bedroom and the bowling ball is not on the wardrobe anymore. That was an onEnter event on a walkzone, which is the 1D equivalent of a walkbox in the previous version of the engine. Since some puzzles and some scenes in the next game rely on understanding when the player enters or exit a particular zone, we need to port the same mechanism to 2D.
Stay tuned for new updates soon!*
*the meaning of soon may change without notice