Today: Improving movement around corners in Gonna Catcha. Tomorrow: Humour check-up

In my various playtests of Gonna Catcha, I have noticed that many players were having difficulty trying to turn at intersections, going from one corridor to another perpendicular corridor. The solution I came up with was simple, yet I still managed to write this whole blog entry about it, so here goes.

Gonna Catcha uses a smooth, grid-based movement system, as in, even though the players move smoothly, they will always be aligned with the grid that divides the play area when stopped. This is to facilitate players in lining up properly intersections and going around wall corners, instead of having the player painstakingly line themselves up with pixel-perfect precision. Even with this alignment aid, I've noticed in my playtests that players were still having problems negotiating those corners.

To explain this better, below is a figure showing five different cases where a player is approaching an intersection (click on it and any other figure to expand):

Figure 1. Five cases of a player approaching an intersection

The figure shows two horizontal corridors linked by an opening between them. In cases 1 and 5, the player is not aligned with the opening; in cases 2 and 4, the player is partially-aligned, and in case 3 the player is fully-aligned.

The next figure shows what happens when the player holds [Up] to try to move upwards in each case:

Figure 2. Results of holding [Up]

As expected, in cases 1 and 5 the player cannot move upwards since they are completely blocked by the wall; and in case 3, the player is free to move upwards since there are no obstructions in the way. The problematic cases are 2 and 4; where the player is partially obstructed by a wall, which for all intents and purposes counts as being fully-obstructed by the game. In most of my playtests, players end up in cases 2 or 4 when they try to turn too early, and they end up getting snagged in corners, which was a bit frustrating to them.

For a long time, I've thought about whether to fix this problem, or just leave it in as a "quirk" of the game's movement system that players need to get used to in order to get good at the game. Many games in the 1980s did have control schemes that had quirks or little annoyances that players needed to learn to in order to master them (I'm looking at you, Bubble Bobble, Ice Climber and Super Mario Bros.).

This game plays so good, it plays itself.

Welcome to the first post of 2014! I'll been working on the autoplay system (for the "How To Play" segments and the attract mode) for Gonna Catcha since the last time I posted. And since it's also been a while since I uploaded something on my Youtube channel, let's make it a twofer; here's a short video of it being tested:

As I was coding this, I realized that creating the autoplay system would have been a lot easier if I was using Game Maker 8.1 instead of GameMaker:Studio to make this game. That's because games made with Game Maker 8.1 could be coded to be dynamic at runtime. That is, you could add, remove or change graphics, sounds, rooms and even code while the game is running.
So what does dynamically-generated game assets have to do with the game playing itself? Well, the assets of interest in all of this are timelines, a series of code snippets that are run at assigned steps in time. Once a timeline is assigned to an instance and is set to run, it will automatically fire off the code snippets at their predetermined times. If I was using Game Maker 8.1, I could record player input to a file and then save it to the disk. Later, when I want to play the input back for demo purposes, I could read the data from the file, translate it into a dynamically-generated timeline and let Game Maker (and my player input code) handle the rest.
Unfortunately, due to cross-platform incompatibilities, the ability to dynamically add and change game assets at runtime had been restricted in GameMaker:Studio. In particular, most of the dynamic coding functions are gone. Fortunately, the all of the dynamic timeline functions survived the cut; well, all of them EXCEPT the function that allows you to ADD new code to a timeline. Without this function, this function, it is impossible to created new timelines with new code from scratch on-the-fly, pretty much destroying the above method of creating an autoplay system with a surgical strike.
In light of that, I tried to think of other ways to do this. First, I tried to record the player input into a human-readable format then manually translate and hardcode it into a timeline. However, this method was too tedious and took way too long to do, and if I wanted to re-record a play session, I would have to retranslate everything from scratch. Next I tried to build the timeline from scratch, but it was also too tedious since it was too hard to predict NPC movements, even though the random seed was fixed.
In the end, I decided to create my own timeline system. It's not as through or functional as GameMaker:Studio's native timeline system, as it can only take control of the player characters, but it'll do.