Mindy Morton Dev

I mostly used the logic from this Godot tutorial by Nathan Lovato in GMS2 which helped me to really break down the character into good chunks. It was tricky to work out the kinks when I started but it worked just as well now and made the workflow with these other new features a lot easier. I also used a lot more functions() to be able to speed things up, since physics would need to be written in every state.

Essentially, these new states work like this:

Touch something bad? Damage State. Damage State? Check if they still have health. (tutorial on invincibility frames by HeartBeast) No health? Enter death state. Death state? Transition to title Game Over room.

And the winning state will simply transition you to the "winning room" as soon as you touch the winning item. And the looking-up and looking-down animations are used in the idle state if the camera detects that that is what the player is inputting.

Title Screen, Pause Menu, Game Over, and Winning Screen So to make these work, the first thing I had to do was actually decouple my camera from my player. Coupling is what happens when you write the code of two objects in such a way that they can't run without each other being present. Decoupling was difficult for me since I did not understand the key difference between calling an instance and calling an object. Basically, an object includes all instances of that object, but an instance is only one specific object that's already loaded.

However, once I did, it was fairly easy to move the camera around through code without a player present and create the Game Over, Title Screen, and Win Screen all on my own.

For the pause menu, I used this tutorial by Shaun Spalding and implemented some assets in the Draw event to make it feel like a proper pause menu.

I'm also just going to mention here that I used this other tutorial by Shaun Spalding to implement a transition so the game doesn't just freeze for 20 seconds while it loads the other room.

A few more assets I implemented a few more assets, mainly for UI. I actually was able to figure this out by reading documentation! It was pretty much all handled in the DrawGUI event. I also added some simple hearts and coins by using GameMaker Studio's health and score properties, which are universal throughout the project, like a global variable!

I'll continue to go hard on the assets for the last month of this semester. I want to implement more quality-of-life features like PAUSING and a TITLE SCREEN. You know, the basics.

It's crunch time, and who knows what I'll be able to truly get done. I'm already banking on not having the time for features like shooting mechanics and shooting enemies, but that will be okay as long as the visuals and platforming are fun.

With the time limit though, now I get to really buckle down on some of the small and quick features just to get them done. I've already followed this tutorial by Shaun Spalding to implement a quick pause menu!

What was I doing in Godot? Well just recreating the game from scratch, or trying to anyways. I might be insane. Part of me found this Godot engine very novel and exciting, plus it was the underdog so why not try it out?

It was a pretty overwhelming experience actually. Godot is a really awesome engine but I actually don't know if I believe it's necessarily as beginner-friendly as GameMaker Studio 2. This is just my personal experience, however, and I already have some experience with languages like javascript so GML just really clicked with me a little more right off the bat than GDscript did, although that's not to say the language itself was difficult for me to learn. On the contrary, GDscript's syntax was very beginner friendly.

Here's a snippet of some of my code that controls things like which way the sprite is facing, the gravity, friction, and acceleration. These things were very easy to implement in Godot, although it might be because I've already done it once in GameMaker.

I'd say the main thing that made Godot a little tricky for me was you have to use signals and hook up nodes to be able to have them communicate with each other. It took me a second to figure out how this works, which was a real headache while trying to recreate my camera system. Actually, the whole Godot version of my camera system really made me second-guess myself a lot and has kind of shot my confidence a little with Godot.

In general, I think there's a lot of really solid potential with Godot though. While there are far fewer resources, they are all consistently higher quality. And a lot of things are just naturally supported without coding compared to GMS 2. Here's a list of some of the more basic comparisons of how far my project has come:

Controller Support. Godot has built-in controller support and profile editing. This was basically a non-issue. GMS 2 doesn't do this natively but there is an AWESOME script called Input that did everything for me. It's basically even footing but props to Godot for supporting it natively.

Camera Limits. Godot's camera is just a lot more flexible out of the box, supporting things like lerping without needing to code anything nitty gritty and you don't have to code the camera to clamp to the room, because the camera has a limit property which you can just set in the inspector.

3D. Godot has proper 3D support. GMS 2 has 3D but frankly, it's just not made with 3D in mind.

So do I have a final opinion? Well, GameMaker Studio 2 just makes a little more sense to me so my project will likely continue prototyping in GMS 2. However, I really like Godot and want to learn it properly. It's very likely that once this academic year has ended, then I will take the time to do some smaller projects in Godot and really get used to it, and then continue developing Mindy Morton in it 😎

TRIGGER ZONES

First things first, I had to get the camera set up. There are a lot of tutorials on this, all of which are slightly different. My code ended up somewhere in the middle of all of them. Here was the first tutorial I followed:

How to make a Camera for any GameMaker game in 4 minutes by Shaun Spalding

So Shaun Spaulding's video helped me get the camera set up in the first place, although frankly, this method didn't last very long in my project. It was good and simple but for whatever reason, people really don't recommend you use GameMaker Studio's Room Builder's camera settings, but rather code them yourself. I'm not sure why else other than the fact you get a lot more control over your game's in-game camera, resolution, and window size, plus you can create cutscenes and stuff with it. Next was-

Smooth Camera Tutorial + Pan/Zoom [GameMaker Studio 2] by Matharoo

Matharoo's code was more complicated at first but it gives you that level of control that I was just talking about, and it sets it up in mostly the same way. Although, my code now is definitely a mash-up of the two tutorials.

With those two tutorials, now our camera looks like this:

This is great! Now we have an actual camera instead of looking at the whole room! But if we look at our camera's view, we can see that the camera is seeing out of bounds. Matharoo's video may have actually covered this (you can watch it yourself) but where I found my solution was-

Camera Modes | GameMaker Studio 2 by FriendlyCosmonaut (this one starts at 14:33)

I did not watch this entire video but it looks like it has a lot of useful information in it. Even though she isn't making the same type of game in the video, she does cover the topic I needed, which the provided link will actually jump straight to that section of the video

This is solid! Now that we have one problem solved, it's time for another-

Unless you're going for something more old-school like Super Metroid, we're likely going to have big open rooms that twist in multiple directions. I had a pretty clear vision of how I wanted the camera to operate. My trajectory is in the direction of Hollow Knight, which has a simple yet complex camera system that is very well explained in this YouTube video:

This video sort of became my "mission statement" with all this. Unfortunately, I don't have a tutorial I can point to for how I coded all the stuff in this video, but I did realize Shaun Spalding briefly touched on his own solution to this kind of problem with what he called "trigger zones". This is a good way to describe my own solution. Essentially we're going to create an array of overlay objects, or "trigger zones" that will restrict the camera's movement to only being able to move where they say. This is more or less the setup we're looking at:

This is how Hollow Knight's cameras appear to be working in the video, and how we'll set them up too. I won't dive too deep into the nitty-gritty coding on this one, but basically, each of these trigger zones is an object in GameMaker that will bind the camera by their respective dimensions.

This gets very inter-relational with all these objects since each object needs to be able to apply its own unique dimensions to the camera boundaries. It did become a little bit of a headache managing what turned into 5 or 6 different camera-related objects which were all modifying each other.

Here are some pictures of how this looks in practice. Keep in mind that these would all be turned on at once to function properly:

Vertical Trigger Zones (the camera won't move above or below the zone the player is in)

Horizontal Trigger Zones (the camera won't move too far left or right in these zones)

Zoom-In (or Zoom-Out) Zone (the camera will zoom in/out as far/close as the width of this zone)

These are just a few examples but hopefully, the concept makes some sense to you! So finally, with these systems in place, our cameras will finally move like this:

And that is (mostly) the end of that. Scope creep has kept me coming back and adding incremental changes to all these features (specifically the zoom one). Fundamentally they will continue to work the same but it's easy to keep tuning things like camera speed and zoom speed.

Anyways, with this stuff done it's time to get to the next thing:

PARALLAX HELL

So the actual solution to this was straightforward--use a 3D camera and follow this tutorial:

From 2D to 2.5D: GameMaker Studio 2 TUTORIAL (Using 3D Camera) | Easy Parallax by Matharoo

It's what Hallow Knight does, it creates a natural parallax effect, and it makes a lot of the artistic work pretty easy. But, the reason it took me so long to get here is a story that brings me great pain...

To start, I wasn't originally going to use a 3D camera because they sounded somewhat complicated. Even Shaun Spaulding sounded like he didn't recommend them in his tutorial that I shared above (although maybe that's just for beginners). What I was going to do could be called "interpolated parallax," where we are basically moving a bunch of image layers around relative to the position of the camera.

You can learn more about this in this video by Pixelated Pope.

That doesn't really need to make sense to you, but that's what I was doing. Now, this method could have totally worked theoretically if it weren't for the fact that GameMaker Studio 2 has actually removed certain coding properties from GameMaker 1.4, which makes this method kinda unreasonably difficult? At least from what I tested. It works great if your only intention is to have an endless runner game or if you want to accommodate for open space by drawing individual sections of background together in a giant 4k+ canvas.

It sounded messy and I didn't really want to deal with it. Eventually, I learned more and more about GameMaker Studio's 3D camera, which was easy to set up for my specific needs.

It did take a while to fine-tune it all but I did get there in the end. It did, however, break my zooming trigger zone. This post is already long enough but basically, I thought the solution would be needing to change the camera's field of view with trigonometry when it was actually just changing the camera's distance with a basic ratio...

Not my brightest moment there and it took a painful couple of hours of staring at the same code and Desmos to figure that out.

ANYWAYS...

The camera system is finished! Or at least, finished enough that I can move on to designing backgrounds, and just fine-tune this bit by bit later down the line.

Honestly, this was all very time-consuming, and the struggles with the zooming trigger zone were a bit demoralizing, so I'm ready to get back into the art generation side of things!

I also plan to spend some time beating Hallow Knight and maybe a few other platformers I can take reference from for backgrounds 😎

The thing I've been noticing for a little while now is that Mindy should be bigger. You might remember from a previous post I made that the ideal character size is within 2-3% of the screen area, which for a 4k resolution was 436 pixels. However, there was an interesting thing I did when making those sprites-

She's way smaller than the box I drew her in!! For extra comparison-

As you can see, a majority of Mindy is actually taking up way less space, which means we have room to grow! This isn't a massive deal to me right now but since this project is for an illustration capstone project, making the sprite more legible is important to me.

Anyways I did some math and blah blah blah (it's 4 am right now), for the sprite to take up the same area as our original green square, we need to increase her size by 19.9%

Living large! Of course, we still have to take this 4k resolution and then DOWNSIZE it for the 1080p resolution I'm building the game at.

Maybe I'm working too hard...

Anyways, the new size for the 1080p canvas would have been 569 pixels. To be clear, I leave a lot of extra space for animations outside my green square, which is why this size is actually bigger than 436 px square.

The thing is, I accidentally set my sprites to 475 instead of 569, and they actually looked too big even though they weren't full-size. I ended up playing around with the size and also Gamemaker Studio's camera settings and found a nice balance at 400 pixels and a slightly bigger camera now.

It's like nothing ever changed! 🥲

It's worth playing around with more along with dynamic window sizing and resolution but frankly, every time I try to look into that stuff, I get a massive headache. It may be worth it to go back and strictly follow some of these tutorials for full games from start to finish later down the line if I want to understand some of this stuff better.

Anyways, I took the opportunity to build a new level with some actual gameplay lol. The next post is going to be about more camera stuff and hopefully some parallax scrolling too!

After I got this camera done, I ran into a weird headache with my sprites. I noticed that my animations were looping on the wrong frames, and I kept messing with the code to fix it. In the end, the code I already had worked perfectly, and I needed to add a filler frame to some of the sprites so that GMS 2 could actually do what I was telling it.

My code says "every time the animation plays frame 5, reset the animation to its second frame, and skip the first one." That's pretty simplified but that's the idea. But my problem was I didn't have a "frame 5" for the code to use, so it wouldn't run it and end up looping the wrong animation. Funny how simple the solution was! It was just a big headache that I felt like sharing.

Anyways, now the camera is working properly and we are officially done with sprites (for now), that means it's time to code in parallax scrolling and then draw in the backgrounds! Now for the video-

Aside from breaking down the animations, I also had to reduce the resolution of the drawings.  This was already the plan from the start but now that it’s finally happened, Mindy does look a little rough around her edges, but it doesn’t bother me too much.  Plus playing the game with the 4k drawing really hurt my computer’s performance.

Having to take the time to do this felt like a bastardisation of my animations, lol.  It really felt so unnatural to see them so dissected in this mechanical overview.  But hopefully it means I will be able to use the full range of my animations in the end!

I’m a little nervous about what this decision could mean in the future for my project.  The game is currently bound to be at a 1920x1080 resolution, which is standard HD, but definitely not as nice as 4k or even Full HD.  I would love to be able to scale the game’s resolution which is a pretty normal feature for computer-based games.  It might be less of a problem if this were for a console release?  Unsure.  However, the main thing I’m wondering is if these scalable options have whole different sets of game assets at different resolutions or if they just take the high-res ones and scale them down.  Apparently, the ladder option can actually impact performance though so I’m really not sure.  Either way, it sounds like it could be a daunting task to work with in the future.  Thankfully it’s not really a worry to me right now.

Also, I realized I never posted about this, but I decided to switch my animation process from Procreate to Rough Animator on my iPad.  I’ll likely still use Procreate for initial pencil roughs since it only requires a single layer and runs a little smoother for me, but for final linework and color, it will be Rough Animator.  Nothing really beats actual animation layer support.  It makes life WAY more flexible.

The next step is figuring out how to make these animations work with the code logic.  Essentially, I really want to avoid using If-Then-Else statements because those slow the computer down if you have too many, so a solution I found in this Reddit post is to use a system called a “Finite State Machine.”  Sounds pretty cool and this video by Shaun Spalding (it’s always him) gives a very brief explanation of the concepts of a state machine.  To make a very quick TL;DR version though, essentially you write code for every possible “state” the player could be in, and then you tell Game Maker Studio to load that state based on what the player does.  If that didn’t make sense, try watching the video instead.  

Anyways this is essentially the most likely way I can get my animations working properly.  Not only that, but it also seems like it could be extremely important in developing other things later on, like climbing ladders, walking on ice, or who knows what.  But basically, anything that could change the way the character moves that isn’t “left, right, and jump” will likely require its own “state” and subsequent code.  Frankly, it’s a headache for me right now, especially since I’m writing this at midnight!  I’ll have to spend a few days on all this, unfortunately.

To make my life easier with state machines and keep me on track with my art output, I’ve decided to invest about $5 in a premade state machine.  This is essentially the wireframe for the code, but I still have to put in the effort to learn and understand it as well as code all the specifics of each state.  Essentially, I bought a bike with no wheels, and I have to teach myself where to get the wheels and how to attach them to the bike.

Game Maker’s official article on Finite State Machines.

I’m a little nervous about what this decision could mean in the future for my project.  The game is currently bound to be at a 1920x1080 resolution, which is standard HD, but definitely not as nice as 4k or even Full HD.  I would love to be able to scale the game’s resolution which is a pretty normal feature for computer-based games.  It might be less of a problem if this were for a console release?  Unsure.  However, the main thing I’m wondering is if these scalable options have whole different sets of game assets at different resolutions or if they just take the high-res ones and scale them down.  Apparently, the ladder option can actually impact performance though so I’m really not sure.  Either way, it sounds like it could be a daunting task to work with in the future.  Thankfully it’s not really a worry to me right now.

Also, I realized I never posted about this, but I decided to switch my animation process from Procreate to Rough Animator on my iPad.  I’ll likely still use Procreate for initial pencil roughs since it only requires a single layer and runs a little smoother for me, but for final linework and color, it will be Rough Animator.  Nothing really beats actual animation layer support.  It makes life WAY more flexible.

But that’s pretty much it.  On a slightly different note, I am worried about other classes also impeding my progress on this project.  I feel like I stormed ahead the first two weeks and now I feel like a snail.  Multiple reading assignments and a couple of different personal projects are getting in my way.  I’m trying to balance my stuff out, but this is definitely why I shouldn’t be my own boss!

The next few steps are as follows:

Finish the clean sketches of the run and halt animations

See if I can get them working in the game in time for CRIT

If I can’t, get them working afterwards to see if they need any edits

Create alternate versions of each animation where Mindy is holding her weapon

Add some test backgrounds?  Or start on enemies?

It gets a little uncertain because while I would like to start on some background to bring it all to life, the tutorials I have been following mostly focus on enemy development next, both of which will be important.  

The next thing on my list of things to animate is jumping animation.  Above is an example of Hollow Knight’s jump animation, sprite-by-sprite.  This kind of stuff is particularly useful for seeing how many “in-betweens” another game may use so I can use it as a standard on my own.  This seems to range from game to game.  

Hollow Knight has virtually none while some have maybe 2-3 frames of in-betweens max, followed by the actual “jump” animation.  There’s also an animation for the peak of the jump where the legs and cape change direction, and a landing animation which is more or less its own set of 2-3 frames. 

 If I had to guess, Hollow Knight’s launching frames are reused in his landing frames as well, especially since he’s such a simple character.  I was already planning on reusing a frame or 2 from the idle animation for the jump animation, so perhaps I’ll end up using them for the landing as well.

For more examples of jump animations, I recorded some jumps from a few different games I own that have a similar feel to what I’m going for--

I was also able to get rid of all my WHILE and REPEAT functions.  There are more IF statements now, but I can’t really help it.  It works great now though, and without the risk of loops!

I’ve also been fiddling around with exact feel of the game.  I actually have a separate file in the game where I can fine tune settings like jump-strength, gravity, momentum, friction, etc etc.  I’ve been playing with the feel as I go along.  It’s a little hard to find the exact feel without more to look on the screen other than some squares but I think I’m in the ballpark.

Essentially, I ended up needing to make the speed flow from moving to stopping.  First, I made the code for when the player should STOP.  The first thing it does is check if the left or right key is pressed.  If both are pressed, then it skips the code for left and right movement.  This is because the code for “no keys pressed” and “both keys pressed” would have been the exact same, so it’s saves on space and computer power if I make it the same line of code.

I also recoded how the walk speed works.  Since now the player will have 2 different walk speeds depending on if they’re running or not, I created a new variable that by default will equal the walk speed, but when the “A Key” is pressed, it adds on an extra value that will increase the speed.  Technically that’s all I need for a run button, but I wanted there to be a transition from slow to fast and back to slow, because right now it’s essentially just flipping a switch.

Next, I added 2 new while functions.  Both of these check if the player is faster than or slower than the currently set movement speed respectively.  Then depending on if either is true, they will either reduce or increase the player’s movement speed to match what it should be.