I hope it’s is a good one for all of you. Here’s to another year of community, friendship, and gamedev. :)
So… it seems like a good way to start off the year is with a big ol’ update for ProtoDungeon: Episode I! Not only have I made a TON of changes thanks to developments from Episode II, but now available for the first time is…
(drumroll please)
PROTODUNGEON ON MAC!!!
But even if you’re not a macOS kind of human, don’t fear. As mentioned, this update contains quite a lot of updates for both PC and macOS versions thanks to Episode II. Here’s the full changelog:
From Episode II:
Lighting (reorganized the the torches in the level, as the new lighting draws emphasis to specific places; some places did not need to be emphasized, while I was able to take advantage of the lighting to draw attention to other locations).
Menu system (including a new Episode I title card).
Updated logo.
Saving/loading (all things considered, this dropped in surprisingly well; I did have to add a few extra cases to fix, such as falling through a pit to the level below).
Graphics settings.
Audio settings.
Updated to the Wandersong audio engine (also updated all audio container names to use constants instead of writing out the strings every time… there were way more of these than I expected).
Key remapping (new default keys as well to match the updated defaults from Episode II).
Ability to jump off all cliffs (had to rearrange some stuff to prevent softlocks and other issues).
Other improvements:
Repaired swap mechanic–this had broken after changing some of the underlying code for another mostly-unrelated system.
Updated the tiles for the pits that lead to floors below–these should be more distinguishable from the normal hazard death pits now.
Updated the swap spell item descriptions to be lore-based for consistency.
Simplified the lv1 swap spell puzzle, as it was trying to teach too much all at once and MANY players found this confusing (this was one area that the new lighting came in handy too).
Updated the lv2 swap spell puzzle, as it never actually taught the player how to USE the lv2 spell–this was the trickiest change, but adding a new room underneath both gives space for a lvl2 teaching puzzle and makes the punishment for falling a lot less brutal.
Fixed a collider in the outside room transition.
Updated the object activation/deactivation manager to account for falling to the floor below.
Updated the player “fall to target” state so modifying the target coordinates elsewhere won’t interfere with this state (“targetX” and “targetY” are variable names used for a handful of different states).
Tweaked the top of the teleporter collider so you can’t accidentally miss it.
Wow, what a crazy year in so many different ways! As promised in my last Year in Review post, we have a lot more to talk about for 2017. So let’s start with…. *drumroll*
A Look Back: The Waking Cloak in 2017
One of the most encouraging things I’ve done is look back at where the game was at twelve months ago. I’d just transferred from GameMaker: Studio to GameMaker Studio 2 and was still getting basic stuff like movement and the camera working again! And now you can walk around in game, explore a village, talk to people, fight very basic enemies… it’s so exciting. :)
So here’s a list with some fancy gifs of the major things completed!
Implemented basic Zelda-like enemy AI–gifs to come soon!
And now, 2018 is here!
So what’s up now? Well, I’m going to keep working on the game as usual. More and more foundational tasks are getting completed, and I expect as the year goes on, I’ll gradually transition to creating game content. I’ve got a task board over on Trello if you want to keep an eye on me! (I’ll keep it spoiler free)
Finally…
SOON AND VERY SOON we’re gonna have a Discord server up!! Keep an eye out for the launch announcement within the next few days!
New camera transitions! It’s doing an ease out (cubic) function here, which looks MUCH better than just moving it linearly.
In my newly minted, amateur opinion, all game developers should learn about easing functions. They’re so very useful for making movements more lifelike. Here’s a good visual with all the equations.
Oh, and here are some awesome free easing functions for GameMaker in case you don’t want to write them all out. :) Feel free to let me know if you have any questions on how to use them!
This is a small update because I’ve been doing some novel writing this week since we had writers group today. It went well! Good group of people and everyone had good critiques.
Note: Unless otherwise specified, when I mention “rooms” here, I’m talking about the old Zelda-like, static-camera rooms. Not GameMaker rooms. Sorry. It’s confusing, I know.
For some reason, camera stuff is one of the most difficult things I’ve tangled with in The Waking Cloak. I’ve reworked my camera and room system a half dozen times, pretty much since the very beginning of development. (It didn’t help that it broke horribly when moving to GameMaker Studio 2!)
Doing rooms like Zelda on the NES isn’t too hard (unless you’re a dummy like me… took me way too long to figure out). Every room is the same size. When the player touches the edge of the camera, move the camera a fixed distance north, east, south, or west. No big deal.
My problem is I wanted rooms of different size, more like the Zelda Oracle games (such as in the dungeons). I didn’t want to mess with a separate GameMaker room for each Zelda-like room (which would mean delving into surfaces and some pretty complicated stuff). The easiest way to do it would just to have one GameMaker room.
There were a lot of iterations to this, but it pretty much just ended up with me setting up an enum for the compass and hardcoding the dimensions in a two-dimensional array (called “region” so I don’t confuse myself with GameMaker’s rooms):
Long story short, this array helps the camera determine its limits for rooms of varying size, as well as the edges of the room for the player to run into. This is extremely unwieldy and prone to error. Every time I add a region, I had to redo math. When creating the most recent town GIF scene, I moved all the items in my GameMakertestroom down 400px, and I had to redo a bunch of math. I mean, sure, it works. But it’s not really very scalable or debuggable.
So, since I just revamped the camera (maybe a post on that soon), I figured it was time to get back to the region system and make it much easier to use. Mechanically, it’s a bit slower than the method above, but I’ve got thousands of FPS to spare, so no big deal. (This is not a demanding game, lol.)
First, I whipped up a new region sprite with a standard rectangular collision mask:
Next came an object. I won’t screenshot that because it’s literally just an empty object (with one line of code to prevent it from being deactivated by another process, but if you’re following along at home, you won’t need that).
Then I created a new instance layer in the GameMaker room specifically for these region objects and slapped one down for each
region. Tada:
So it looks a little silly
, but most of the time it’ll be invisible anyway. (I might at least edit the sprite later with different colors for each “wall” to make it more readable.)
Then, whenever the camera begins in a room, or when a camera “transition” is kicked off by the player touching a playerLimit variable (i.e., the edge of the room), this code is run to construct the camera limits and player limits. It’s pretty similar to the code that used the 2D region array:
Maybe there’s a better way to do this (please let me know if there is), but this works pretty great for now.
Just a note, global.viewX and global.viewY are the coordinates that the camera object uses to position the view. If you want to know more about this camera system, check out PixelatedPope’s awesome video on the subject. I’m doing some specific stuff in the camera’s transition state to throw the global.viewX and global.viewY north/east/south/west before the above method is called, and if it returns false, global.viewX and global.viewY are moved back to their previous location and the camera doesn’t transition. I’d paste a picture of the code in the camera transition state, but it’s kind of ridiculous.
Oh, what the heck:
Ok, so I know this was the world’s worst tutorial, so if you have any questions about this or implementing a similar camera/room system, please let me know either on Twitter (@MrDaneeyul) or on my Ask page. Suggestions work too. Otherwise… well, I hope you enjoyed these pictures of code. :)
Had a couple moments walking around town. It’s an oddly emotional thing to see a world that previously existed only in my head. I think I was expecting to be much more detached, since I know where everything goes, and I know there’s still a lot of work to be done even in this particular scene.
Here’s the video version, in case the GIF above isn’t working for anyone else! Be sure to watch in 60fps… :)
When developing Kerfuffle I needed an animation system that would allow me to hold any individual frame of animation for as long as I wanted in game, without having to manually add or remove frames to the sprite. I also needed to be able to trigger certain actions based on the current animation frame. Using this setup I was able to create hitboxes, play sounds, or change states, all while having full control over everything being drawn on the screen.
Variables
These are the important variables associated with the animation system. Refer back to this if you get confused.
frameSpeed The speed in FPS that the game counts through the frames to be displayed. Default is 1.
frameCounter Increases every frame by the frameSpeed.
currentFrame The frame of the sprite currently being drawn on the screen.
frameData Current list of frame data the game is reading from, based on the animation that needs to play. Idle, run, attack, etc.
frameDuration Total number of in game frames to display the current sprite frame.
maxFrames The total number of frames in any given sprite.
animSprite The actual name of the sprite resource in GameMaker. sprMomo_Idle, for example.
Helper Scripts
A couple of useful scripts that save us some typing later.
frame_reset(); Resets frameCounter and currentFrame to 0.
frameCounter = 0; currentFrame = 0;
animation_set(); This script accepts two arguments. First, the frameData (which is the relevant list of frame data) and second is the animSprite (the sprite resource you want to draw).
//animation_set ( argument0, argument1 );
frameData = argument0; animSprite = argument1;
Frame Data
Each animation requires a list of frame data. This is a list that contains the amount of in game frames that each frame of animation will be played. Each list of data uses the following naming convention. frameDataIdle, frameDataRun, frameDataDash, and so on. Also, if anyone knows how to use a table in tumblr… please tell me how.
Frame data for Momo’s idle animation
Be aware that all lists, and values, start with 0. So even though this animation has 12 frames, the highest number in the list is 11. This includes frames you want to display! If you want it to show up for 5 frames in game, the value in the list should be 4.
**GameMaker Specific Note** Make sure you manually delete a list when you are no longer using it! Otherwise you can run into memory leaks!
Frame Counter
Now that we have a list of frame data, we need to actually animate based on that data. The first thing we need to do is figure out what the maxFrames are.
maxFrames = sprite_get_number( animSprite ) - 1;
Then, if your currentFrame happens to be greater than or equal to max frames, AND frameCounter is greater than or equal to the maximum number of frames the sprite frame should appear on screen, reset to the first frame.
Now the frameCounter can do its job. It counts up to the number of frames the current frame of the sprite should be displayed, then once it reaches that maximum, ticks the currentFrame up to the next frame of of the sprite, and resets back to 0 to start counting again.
Side Note: Using maxFrames is also a good way to end animations, and change to a new animation or state! I use maxFrames to switch from an attack state back to the normal state after the entire attack animation has played all the way through.
**GameMaker Specific Note** Sprite_get_number is a built in GameMaker function that returns the number of frames in a sprite. This function returns the exact number of frames, and does not count up from 0! So if you have a sprite with 5 frames, this will return 5! This is why when checking against maxFrames, we do so while subtracting 1 from its value.
Switching Sprites
Everything in Kerfuffle runs on a fairly simple state machine. Depending on the state the character is in, the animation changes.
//store the current animation sprite so we can check it later currentAnim = animSprite;
switch ( state ) { case normal: //if the player is pushing left, or right, change to run sprite if ( left || right ) { animation_set ( frameDataRun, runSprite ); //if the player isn’t pushing any buttons, change to idle sprite } else { animation_set ( frameDataIdle, idleSprite ); } break;
case dash: //if the player is in the dash state, change to the dash sprite animation_set ( frameDataDash, dashSprite ); break; }
//check the current animation against the last animation. //If these animations are NOT the same, reset frameCounter and currentFrame to 0.
**GameMaker Specific Note** Use macros or enums instead of strings where possible. I used to use strings for player states (ie: “normal” instead of just normal) and it’s not the best idea. Strings are slower to process, and if you make a typo, GameMaker will not alert you! Your code will just fail and it is much easier to overlook!
Now that all of this has been setup, we just need to put it to use. Since we are bypassing GameMakers built in functions like image_speed and sprite_index, we need to draw the sprites ourselves. This is really easy though! We just need to use draw_sprite_ext!
So thats it! Pretty easy right? If you have any questions, or comments on how to improve this, please let me know. I will respond as soon as I am able. If there are any other write-ups like this that you’d like to see, let me know what they are!
“Let’s try a new animation system,” I declared. “It will be easy and work the first time!”
(I didn’t think it would work the first time. It never does.)
Anywho, this is a crucial piece in getting the new combat up and running. Currently, giving different frame lengths to each individual frame is possible (I think?), but I haven’t been able to figure it out. This new system, once it’s working, gives me a lot of control over each individual piece!
