general programming – Quadolor Games

Something’s askew here…

mstop_4 Cat Project, GameMaker: Studio, general programming December 16, 2014 0 Comment

A week ago, I had a bug-free, perfectly-good platforming engine. But then out of a whim, I decided to mess around with it and added support for sloped platforms.

Aside from a few bugs with the player or enemies occassionally getting caught in the slopes, it seems to be working just fine:

Implementing the code to make objects moving up slopes was the easy part. However, in the method I’m using, it initially caused objects to “float” above the slope, with only one corner touching it tangentially.

This looks particularly bad if the sprite is wide, (which kitty is in my case).

The first solution to this problem I considered was to make the object’s collision mask narrower than the actual sprite. However in my case, this would have caused another problem: kitty would have been able to walk partially through thin walls, which would have messed with the gameplay.

The solution I ended up using was to give the object two collision masks: a narrow one (coloured orange in the image below) for detecting the contour of the ground (and ceiling) and a wider one (blue) for detecting walls and everything else.

Now some of the “floatiness” has been transformed into “phase-through-the-ground-ness”, which I think is more tolerable. Both become less noticeable when the slope grade is reduced:

Foreground scenery (red) can be used to hide the remaining floatiness. In “Cat Project”, the fuzziness of the carpet platforms does this somewhat.

A challenge with implementing this within GameMaker:Studio is that it only checks for collisions automatically in each step once, with only one collision mask, and fires off Collision events accordingly. After doing a bit of searching on the Game Maker Community forums, I found that a way to get around this one-mask limit is to cycle through a list of masks, manually recheck for collisions between each mask change and execute the appropriate code for each. Essentially, you’re implement additional Collision events inside another event (usually a Step event).

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

mstop_4 general programming, Gonna Catcha, Wizard of Wor February 5, 2014 0 Comment

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.).

One day, out of boredom, I found my copy of Midway Arcade Treasures 2, an emulated collection of old Midway arcade games. I only played it a few times on my Gamecube a long time ago, so I decided to give it another chance and popped it in my Wii. After chopping down trees in Timber and crashing cars in Hard Drivin’, I played a game that caught my attention: Wizard of Wor, an action maze game from the magical year of 1981:

The basic premise of of the game is you and a partner must shoot and kill all the monsters in a maze-like dungeon to move on to the next one. The partner can be another human player or, if you’re playing alone, a computer player with limited intelligence. From what I’ve seen, the players’ movements aren’t confined to a grid like in Gonna Catcha. However (and this is the whole point of me mentioning this game in this post), the game had no problems with players getting caught in corners, as the player characters would “hug” the corners if they were close enough to one. In technical terms, the player would move in the direction perpendicular to the direction the joystick is being held, towards the nearest intersection if one was close enough. Confused? Don’t worry, there will be figures soon.

This got me thinking, if an actual early-1980s arcade maze game could handle intersections like this, then Gonna Catcha should be able to too. So I modified the movement code (something I haven’t touched in a long time) to make it handle corners and intersections like Wizard of Wor (and likely the multitude of maze games that came after it). The figure below shows the results of holding [Up] in each case with the new movement system:

Figure 3. Results of holding “Up” in the new movement system

Cases 1, 3 and 5 remain the same, however in cases 2 and 4, the player will now scoot around the corner of the nearest intersection if they are partially-aligned with it. Playtesting the game with the new movement system, I can say for certain that turning around corners is now much easier and smoother. One other thing I noticed when I was playtesting was that I had coded the movement direction and the way the sprite faces independent of each other. Before this change, the player’s movement and facing were always in sync, so I never noticed it, but now that there are cases where they’re not in sync, and in those cases it looks like the player is sidestepping or strafing around a corner. Technically, this is a graphical glitch, but I think I will allow it, because it looks cool.

The v.0.9.1 update will be coming soon. It’s not the finalized version of the game, the later levels are still unbalanced and possibly impossible to beat, but I am one step closer to it.

This game plays so good, it plays itself.

mstop_4 Game Maker 8.1, GameMaker: Studio, general programming, Gonna Catcha January 4, 2014 0 Comment

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.