austin-scheiner-dfx

[austin-scheiner-dfx]

#3 Punching & Kicking

First of all, as you can see below, I've drawn new animations. This is because the previous ones were too short; punches and kicks would appear to hit at the same height, which isn't what I wanted. These new animations hit high and low spots much more clearly.

Now on to the code. Since the last post, I've looked at GameMaker Studio 2's built-in sequence editor. They look useful, but mostly just for animating specific sprites, which isn't quite what I was looking for. So instead, for these actions, I went for a more code-based solution.

Walking, standing idle, and being airborne are the three main states I had programmed before. These are states that the player can remain in continuously, and can switch fluidly from one to the other. So, it's easy to just have one FSM state for each action.

However, punching and kicking are a little more complex. When the player presses the "punch" button, the punch doesn't happen instantly. And, when the punch is over, I don't want the player to be able to move again instantly.

To facilitate this, I created a new type of state called an FSM state sequence. It's like one big state that gets cut into multiple smaller states that can have different traits or code depending on what part of the sequence the state is in. When the state begins, it automatically cycles through its sequence using the frame data provided by the code.

Let's take a look at the punching state in slow motion:

These colorful boxes are "hitboxes" that the game uses to tell if an attack is overlapping with an enemy's body. In slow motion, we can see that the punching animation has three parts: the windup, the punch itself, and the cooldown.

Even though these phases are all part of the punching state, the hitbox for the punch only comes out in the middle of the animation when the punch visually appears to be thrown. Then, the hitbox disappears before the animation is over. This is the advantage of splitting up the state into sub-states like this. I can program different blocks of code to happen at different parts of a longer animation.

There are still some bugs to work out, but once they're fixed, this is a major chunk of the core gameplay complete.

[austin-scheiner-dfx]

#2 The Finite State Machine

Here is some footage of the player in my project right now. They have three basic states: idle, walking, and jumping. Each of these "states" have their own unique behaviors and are handled by a system called a "Finite State Machine" (or FSM).

When it comes to the three states listed above, the rules are as follows:

If you are idle, you can jump or walk. If you are walking, you can jump. You will become idle if you stop walking. If you are jumping, you will remain jumping until you hit the ground, after which you will become idle. The FSM is a great way to give player characters lots of different abilities, but still be able to restrict what actions a player can perform based on context. For example, most games won't allow you to attack if you have been damaged and are still in the damage taking animation. With an FSM, you can make "taking damage" a state, and disable the player's controls while in that state.

FSMs are handy for games of all genres and levels of complexity. Since I'm making a beat-'em-up style of game where the player has access to lots of different actions, being able to mediate their abilities through states will be extremely important.

Next week I'll be learning about a built-in feature of Game Maker Studio 2 called "sequences". They're basically animations, from what I can tell. If I'm correct, they'll be very useful for programming player attacks, and should be able to mix right in with the FSM.

[austin-scheiner-dfx]

#1 Project Introduction and Planning

This semester, I will be designing and programming core mechanics for a combat game. I am a programmer and an aspiring game developer, so the code and designs I create this semester could be used in future projects that I want to do.

The genre of the game I'm looking to make is called a beat 'em up. It involves the player fighting waves of enemies in close-quarters combat. Games in this genre that I've enjoyed in the past include Castle Crashers, Scott Pilgrim vs. The World: The Game, and TMNT: Shredder's Revenge. I enjoy these games because you can enjoy their hectic battles while playing with friends, or you can enjoy their unique combat systems while playing on your own.

However, I don't expect to have very robust enemy AI behavior complete by the end of this semester. Mostly, I will be focusing on player controls.

Speaking of player controls, these are the controls I am going to implement:

Walking - The player will be able to move up, down, left, and right. This is the most common control scheme for beat 'em ups, since they use 3D (or faux-3D) perspectives.

Jumping - Jumping can be used to avoid low attacks, like kicks. It can also be used to close the gap with an enemy while attacking.

Crouching - Crouching can be used to avoid high attacks, like punches.

Attacking - Attacks can be "high" or "low" hitting. Players and enemies can dodge low attacks by jumping, or they can dodge high attacks by crouching. Players who can react quickly to how their enemy is moving can throw out the right attack to bypass the enemy's defenses.

The high/low attack system is a system that I adapted from what is used in many fighting games: attacks hit at different heights and must be blocked while standing or crouching correctly. I think it would be an interesting mechanic if adapted to the beat 'em up format.

Next week, I will start dedicating my time to programming. I will have to code for hitboxes, and object states that can be programmed with frame data. I will elaborate on what this means in later blog posts.