Hello, my name is Stephen and I think now is the time to reveal my project here;
After a year of research and development I feel confident enough to share my progress on my main project which currently is called 'Dinosaur Dungeon'. It is being developed in Game Maker Studio Professional and I started working full time on the project in May this year.
Where can I see gameplay?Follow this link to a post on my youtube channel
tinyurl.com/j2khsbz
What is Dinosaur Dungeon?
It is an action adventure game loosely inspired by Zelda, with a theme surrounding a yet unseen conflict between mammals and reptiles. It has been heavily inspired by the original (yet never released) pitch for Dinosaur Planet back in 1999.
Currently my goals are to achieve core functionality and create a complete dungeon instance (hence the current title) as part of my submission for my games art masters study; however my ambitions are set beyond my course.
If all goes well, I have intentions to complete this project as a passion project and will keep this post up to date with my exploits. The prototype will be released on itch.io around the time my course ends (the submission deadline), after which I will be free to take the game in a new direction, and hopefully get to collaborate with other creators.
What have you done so far?I will be detailing my progress every week in this thread and on my twitter feed at
@Straw_dev . Significant progress has already been made, however I will be revealing details gradually over time.
For now, here are some tidbits to tease you ;
- Graphics scaling and uncapped frame-rates
- Full KB/M and Controller support
- Lighting System
- All sprites and tiles produced by myself (So far)
- Enemy behavior system
TL;DR
I'm making an action adventure game in Game Maker Studio, the prototype will be released on itch.io this September. Hopefully you guys will enjoy it.
Replies
A stamina bar in particular would be a great way to prevent the player from spamming attacks so that's certainly a mechanic I seek to achieve.
In Unreal they have a simple tutorial for implementing a stamina meter on their youtube channel using blueprints, but I dont know how hard that is in Game Maker Studio. How do you feel about Game Maker in general? I've only dabbled in tutorials about game creation before never full on committed.
Unlike Unreal Engine, many mechanics still have to be done from scratch, but it means I have more control over the code.
A major challenge I've been struggling to tackle since I started game development was handling collisions in a 2D space and simulating depth simultaneously through the use of elevated stairways, ledges and bridges.
The Challenge
The technique used to calculate collisions in a 2D plane is simple enough; when a character attempts to move in a given direction, the game logic needs to check if the spot in which the character will move to is empty every step. This spot check is handled in terms of X and Y coordinates and if it fails (spot is occupied by a boundary), the character will not move any further.
However things get progressively more complicated if the game designer wants to implement bridges which can be walked under/over, stairs which can be escalated up and down and ledges with fiber thin 'walls'. This is because a game designer has to figure out a way of simulating depth (Z coordinate) and making sure both collisions and drawing order are handled correctly.
Below is an example I found online that illustrates all three of these challenges at once.
My First Approach
Initially, my solution was limited to the bridge and ledge problems by implementing an ad-hoc 2 tier depth system such that the player can intercept a special volume which changes their elevation between 2 levels (i.e 2 different types of collision objects representing two different elevations). This ‘solution’ however was far from ideal because for starters, it was limited to only 2 elevations (setting an arbitrary limit on game design) and more dubiously only the player could change levels due to the ad-hoc implementation. In short, it was not a good solution and I was never happy with it to begin with.
My New Approach
In my first two weeks of full time development I took on the task of giving this system a massive overhaul after I was inspired by my experience revisiting Ultimate Doom recently.
In the original Doom games, despite appearances the levels were predominately designed as spread out environments in a 2D plane with varying elevations in the form of doors, stairs and elevators. With this said, collisions were handled using a characters current X,Y coordinates and a Z coordinate to simulate the elevation from the floor (which in the case of characters that are effected by gravity is rapidly decremented when running off a ledge).
However I realized that with some applied logic, it was possible to isolate individual coordinates of characters and made a hypothesis; When a character goes up a flight of stairs, their X and Y movement remains constant with the only coordinate left in 3D space left to calculate being the character's elevation, which in theory can be determined by their escalation up the stairs.
After making this inquiry I decided to make the ambitious attempt to completely revise my approach to collisions by sticking to a single type of volume based collision to represent wall collisions and also design ALL in game objects with common qualities and variables, namely an elevation and height.
In principle, each in game object and wall has an elevation (distance from the floor) and a height (it’s physical vertical size). The idea to put it simply is; Given a combined elevation and height, a collision between two objects sharing the same X/Y coordinates can only be registered if there is a collision in terms of their elevations and heights as well.
So in practice if two objects pass each other in 2D space and one of those objects is elevated higher than the other, there wont be a collision.
To be completely fool proof however there has to be two conditions that BOTH have to be met to guarantee a collision has been made. The Combined height and elevation of the object A needs to be larger than the elevation of the other object B, and at the same time the elevation of object A must be smaller than the combined height and elevation of object B.
In short; Collision only when both ( Height A + Elevation A > Elevation B ) and ( Height B + Elevation B > Elevation A )
If one or both of these statements prove false in practice, no collision is registered. This is demonstrated in the more detailed graphic below;
In the first example, the collision is inevitable since both statements proved true considering that object B will collide with the broad side of object A; however in the second example, the second statement indicates that the object is elevated higher than its combined elevation and height, despite the first statement being true.
In terms of code process the only other challenge I had to overcome was circumventing Game Maker Studio’s approach to collision handling since unfortunately the proprietary collision script only checks for a single (and first) collision at a time and ignores all other collisions in a given frame, meaning that it’s possible for glitches in the circumstance that two objects overlap each other.
To solve this issue, my only course of action was to do a for-loop for all objects (that use this system) and checking collisions with all of them ever frame. Unfortunately this is expensive but such is the nature of collision checking. Thankfully my game project doesn’t have a complicated physics system like an open world Bethesda game which would impact performance.
Results
So in conclusion, my new approach to collisions has proven more maintainable and flexible than my previous approach. When designing levels all I need to do is to set the individual elevations of objects and volumes as necessary (almost like I’m placing them in a 3D space like in Unity).
In the screen-cap below, the stairs are represented by a green volume that is the length of the stairs in 2D space and the pots have an elevation which will draw them at the top of the stairs on the cracked tiles. When the player (or other NPC) goes through the green volume their elevation will be increased to simulate going up a flight of stairs.
The result during gameplay can be seen below. Note how the pots appear on the tiles despite their placement in the room editor.
With this system in place, it made it possible to add additional functionality such as being able to lob pots over walls and certain enemies to fly over obstacles given they are elevated well above them.
A major goal for my project was to create a scenario where the player is ambushed by several challenging enemies at once with unpredictable movement behavior to simulate a bonafide swash buckling experience. My primary source of inspiration has dominated my imagination ever since I first experienced it in my early teens, that being the lizaflos battle from Ocarina of Time.
While exploring the Dodongo cavern, the player enters what looks unmistakably like an arena in which they are ambushed by a group of knife wielding lizard men known as Lizaflos. These enemies are more sophisticated in their fighting style compared to those the player may have faced earlier, being able to encircle the player and even jump over them in a bid to stab them from behind.
Whats clever about this battle however is how it trains the player to fully appreciate the use of the games targeting system to focus on each of the lizards individually and fight them one on one.
The Challenge
This single battle originally had motivated me to develop the targeting system for one of my earlier Unity projects I already discussed on this blog (which I adapted mostly unchanged to this project). However it also motivated me to actually develop the actual battle in 2D. This meant developing several systems at once, namely a state system which would automatically determine the sprite to be drawn and the behavior to execute for a given NPC, and also figuring out how to make said NPCs move in unpredictable ways; namely kiting the player and moving to and fro.
To begin with I had to develop the sprite state system which would also be used for the player avatar as well. This lead me to learn how to produce state handling systems which I previously never tried before, but proved immensely useful for this project.
My Approach : Sprite State Manager
For my project, I decided that all characters would be able to move using two values, a movement speed and a direction, the idea being that the character will move at a constant speed in their current facing direction (which in the case of the player is determined by input).
Movement however is a separate process to the sprite drawing event, so I developed a sprite state system after I developed the movement system. Before this new system I had sprites changed directly since I was focusing on the player only at the time; however I had no intention of keeping it that way knowing fully well a state system was necessary for cleaner and more efficient code re-use. The initial evidence of my experiments is shown below.
In short, this snippet of code takes a given direction (usually the characters facing direction) and determines the cardinal direction the characters sprite should appear to be facing. This is done by finding the opposite and adjacent sides given a hypotenuse (direction with length 10, the value is not important as long as it’s not 0). The length of the opposite and adjacent sides represent the magnitude of the X and Y axis with a given direction.
The clever part is to use these two measurements to determine the cardinal direction the sprite should face. If the width (x measurement) is larger than the height (y measurement) then the character is facing either left of right. Since it’s easy to mirror a sprite, the cardinal direction is determined to be ‘Horizontal’
Otherwise, if the height is larger than the width, then the cardinal direction can either be ‘Up’ or ‘Down’.
These cardinal directions (Horizontal, Up and Down) represent the different sprite facing directions for all the characters in the game. This cardinal direction is referenced as the characters ‘Actor Sprite Face’ which is a state variable.
This piece of code however only determines the characters cardinal facing direction for the sprite, it doesn’t determine WHAT sprite to actually draw, or at least not on it’s own. The trick is to also use an additional state variable in conjunction with this cardinal direction state variable. This additional state variable represents what the character is currently doing, for example moving, attacking etc.
It’s finally very important to reveal at this point that despite being given names such as ‘Horizontal’, ‘Up’ and ‘Down’, they are merely macros referencing integers such that Horizontal = 0, Up = 1 and Down = 2.
In addition these values are used as part of a 2D Array vector with the first parenthesis representing the cardinal direction and the second being the current behavior state of the character. So for example, in the event a character is currently running upwards, the sprite which will be drawn will reference the sprite defined within the array such that ActorSprite[ Up , Moving ].
With this system in place, it made it potentially possible to define as many enemy types as I wanted without having to worry about having to create unique code for each.
My Approach : AI
I then went on to develop an AI system fit for an enemy combatant that would kite and attack the player much like the Lizard men from Ocarina of Time which especially with this system in place surprisingly was a lot easier than I had initially thought, namely because the solution meant exploiting the ways of calculating movement direction relative to another object.
To start with I made a character that was for all intents and purposes ‘dumb’, this was a slime creature.
All it does is find the nearest target (the player), calculate the direction said target is in relative to it and then finally moving in said direction. The result is that the slime makes a bee line towards it’s target, the player. Not very exciting.
However with some tinkering, this dumb behavior can be made more complex simply by mutating the calculated direction with offsets to change it’s course of movement.
By adding some additional calculated variables to this calculated direction, it’s possible to have the character move in directions other than straight towards the player. In the snippet of code below, it’s possible to break down the changes as follows;
A Boolean called ‘Engage Target’ which if true will reverse the direction of movement (IE Backpedaling), an angle called ‘Angle of Attack’ which is a value between 90 and 45 which will offset the direction in a way that will cause the character to orbit the target (IE Kiting) which is then multiplied by the last variable ‘Strafe Direction’ which is either -1 or 1 which simply changes the strafing direction.
Results
By changing this individual variables at random or when certain conditions are met, it’s possible to develop more complex behavior besides zombie like movement. The results of my efforts can be seen below; Notice how the enemies (which for testing reasons share the same sprites as the player) always appear to face the player (sprite state management using facing direction) and also engage the player in an intelligent manner.
Update Backlog 3 : Smooth Camera System (with delta-time)
Early in development, I had developed the basis for a smooth camera system. In games with environments which are larger than actually visible by the camera's FOV, the camera normally follows the player as they move around. A smooth camera system interpolates the movement of the camera as it travels to it's new position whilst following the player; this is usually done using a lerp function. In practice this will make the camera behave less jerky and also make it possible to perform transitions between different proximate perspectives dynamically without disorientating the player.
The Challenge
When I introduced the delta-time system, my initial approach to a smooth camera system didn’t work as intended because it originally updated every frame (originally capped at 60 fps). So when I removed the frame rate cap, the camera’s position updated as fast as the CPU could handle, which without being controlled with delta-time meant the transition would still happen, but it would be too fast to even see.
At first, I thought all I had to do was multiply the ‘lerped’ value by delta-time. However this resulted in inconsistent and jerky behavior, which proved far from ideal during gameplay.
The Solution
Unfortunately, unlike my other solutions, it was impossible for me to figure out how to address this issue without resorting to a google search, which led me to read an article about how to properly calculate a lerp using delta time.
https://www.scirra.com/blog/ashley/17/using-lerp-with-delta-time
The theory is so complicated that even the author of the article admits it’s not entirely obvious :
Instead of (a = lerp(a,b, deltaTime))
It should be (a = lerp(a,b, 1 - f ^ dt))
So armed with this knowledge all I had to do was do a lerp calculation using the old camera position and the new (previously calculated) position, with the last parameter being this formula.
Results
Later during development, I made the decision to add an offset to the new camera position such that it focuses on a point a short distance ahead of it’s target’s facing direction. In practice this makes it possible for the player to see more of their imminent surroundings. This was inspired by the poor implementation of camera systems in Sonic knock-off platformers which made the dubious decision to have the player focused in the center of the screen, meaning that the player can only see a potion of the screen’s equivalent of environment ahead of them, resulting in less time to react to imminent platforms and threats that enter their FOV. The results of my efforts can be seen below.
Is the demo still on target for next month? if so great going.
Combat AI looks cool!
Yes, the prototype is still scheduled for early September, if not sooner. I intend to release my remaining updates until then. ^^
Great project, is this your final video? I am trying to find the most up to date version, thanks.