Today I bring you our group project for my Gameplay Programming university module,
To The Core!
To The Core is a 3rd person platformer where you've got to go deep into the earth to solve the case of the mysterious earthquakes that have begun to plague the land!
This group project involved 5 members, myself included, where I provided and created a range of mechanics and gameplay systems. I'd like to go through a few of them here and follow it up with a short review of how the team aspect of this proejct went.
As I was not only in charge of developing the player and how it felt withing my level, ensuring ground checks worked on the levels created by my fellow group members, but also in-charge of the player's combat system, it was only natural that I created the framework for enemies to be built upon. Zoe had mainly focused on the second scene and wanted to add spider enemies, and so after giving her the framework, she generalised the method of receiving incoming damage through a general 'Enemy' class. She went on to create the enemy AI and attack patterns themselves, but the stats fed straight but into the player stats script that I had setup. Later on, enemies were needed in level 3 and it seemed appropriate to also add my slime enemies, altering them to become 'magma slimes' given the lava setting. This was a simple copy paste job from my pre-made combat demo system, but I had to alter some things to work with the new lightweight renderer pipeline & the new generalised enemy framework, which wasn't too bad. Finally, I went on to balance the attack damage & health stats of all the enemies and the player to feel nice and balanced throughout the gameplay.
Other than all that, I mainly acted as a somewhat manager for the group, ensuring everyone was on track, had tasks to do. Zoe did a fantastic job creating all the lovely functionality of the second level's minecart system, as well as everything else within that scene. Cameron used his third-year knowledge to get in the know about advanced camera systems using Cinemachine, and provided all the cutscene for each level and did most of the work on the thrid level, albeit Dan's attempt to create it. Gabriel did a great job providing an NPC system, as well as the raw power-ups for each level. He also create most of the UI.
A full video of the game's playthrough can be found below!
The game features power-ups, coins, enemies, minecarts, moving platforms, cutscenes, combat, mazes, harmless sheep, and talkative farmers!
This blog post, I'll be covering my combat system I developed from scratch for my 3rd person platformer unity demo
The brief set in place by our university asked us to create Slimes, similar to those found in Minecraft. In Minecraft, slimes roam the land and spawn smaller slimes when they are killed, if they start as a medium or large slime that is. They are very basic enemies, with a simply jumping attack and large hit box when encountering large slimes. The difficulty within gameplay with that they spawn more and more smaller and harder to hit slime every time you kill the larger versions, even if they get weaker. This creates a nice balance for players to fight with.
When creating my own slimes, I started by getting the aesthetics down, making mine very close to the original just to give myself a feeling of threat when fighting them in testing, instead of simple cubes bouncing at me. I implemented a simple jump mechanic alongside an instant snap rotation to face the enemy they are chasing. I think a smoother rotation toward the player would have been better ideally, but this is what I would have added if I had more time.
Another property of slimes involved having an 'active area' or not. If they did, then the slimes would roam freely, but only within that area. If the predicted landing spot was outside of this, then the slime would not jump, but only spin to face the enemy, staring it down. I also created a spawner button that had the option to add an active area to the enemy if you wanted. I used a place for this, then ignored the y axis when checking if the landing position was within bounds. This worked nicely, but if I had a scene with a layered layout, then I'd have to rethink this and maybe only create a volume of area that the slimes can move within instead.
The Slimes themselves are all prefabs for each different size, with many options regarding jump force, if they spawn more on death, how many, what enemy to spawn on death, how much damage they do to players and how much health they have themselves. These can all be tweaked to however you would like, but following the guidlines presented to me, I left the defaults to always spawn 2 smaller enemies on death unless you were the smallest, all damaging 1 health point, and their own health going from 3 to 1 from largest to smallest.
For my own combat, I already had a simple punch animation set in place, I just had to tie a method of damaging enemies to that now. If an enemy stood a certain range in front of me when I punched (this can be changed, but by default it was set to 3.5 meters) the enemy would lose 1 health point. This mean large slimes took 3 hits to kill and medium slimes 2, and small slimes 1. Every time I punch the enemy, I wanted a sense of weight, so I added a little knockback. Similarly, every time a slime touched the player, they would knockback the player as well as damage them.
I could have added the sword to my character, but that would have involved major reworks of my character design, though I plan to implement this into my group project when I add my character to it.
Do look forward to my next blog post regarding my upcoming group project, but for now, thanks for reading!
Today I'd like to talk about my latest edition to my 3rd person platformer unity demo, moving platforms.
When I think of moving platforms in games, I think of 1 of 2 things: 'Platforming speed runs', with sequences of jumps where a range of platforms are moving in all kinds of directions, or 'transport platforms', where you stand on a platform to be elevated or moved to somewhere else whilst experiencing limited movement of sorts.
Whenever moving platforms are involved, you need to think about how many forces and axis the player has to deal with. In games such as Super Mario Galaxy, where not only is the game in 3 dimension, but your direction of gravity is also constantly changing. Looking at how most of their platforms work, any platforms that involve jumping onto/off and between platforms is usually done on moving platforms that only translate in movement following 1 gravity source point, and not rotating through multiple gravity zones. When moving platforms involve rotating in space from 1 gravity zone to another, the player more often than not simply walks onto the platform and then it will take the player where they need to go without the need to jump. Jumping off the platform at this stage will most likely throw you into the void of space if you even can control the player over that shifting period.
This is to accommodate player skill and how their platforms move the player. As soon as Mario's feet touch the platform, they are then stuck to and moved by the platform. The instant he jumps and leaves the ground, he is free. This is good for platforming sequences where you must jump from 1 platform to the next, but if rotation and gravity direction is changing, that will just make life extremely difficult.
Some games make it so that even when jumping, the player is still moved by the platforms, making it even harder for the player to accidentally fall off the platform right after they jump whilst still on it.
Switching to my implementation, I have options to handle these situations. I had setup a moving platform handler which contains a start, end, and pivot point for a line of moving platforms that are spawn at 1 end and disappear at the other. The rate of platform appearing and the speed at which they travel along the path can be changed with public variables.
Every time a platform is generated, it has it's own height check variable. This reflects how high up the player can be above the platform until it stops moving the player. By default I left this at a minimal 0.08 to that when only standing on the platform will it move it. If I bumped this up to 3, then even when jumping, the platform will still move the player is relation to its movement.
The 1 flaw with my system is that I don't rotate the player at the same rate of the moving platforms. I couldn't figure out how to get this number accurately in time. Not only this, but the player will move in correspondence with the centre of the moving platform, not where on the moving platform they are standing on. This means when standing at the edges, you will see you played drift across the surface of the moving platform ever so slightly
Other than that, with the starting, end, pivot point, spawn rate, and speed options I'm very happy with what I created.
Thanks for reading and I'll see you in my final blog post!
Back with another edition to my 3rd person platformer unity demo, this time I bring you 2.5D Splines!
My splines system has a whole lot of stuff it can do and is simply added by dragging in and unpacking a prefab. Once in the scene, the spline runs in the editor. Here you can play around with it's shape and length as you please using waypoints and waypoint toggles. You can even change settings such as how detailed the curve is.
When playing the game, players can walk up to the spline, then will enter a nice transition to go from free-walking to being locked on the spline in a 2D style. Once on the spline you can only move left and right. Once reaching either end of the spline again, you pop right off.
My spline uses a rather strange locking system, with a few bugs like being able to move out of bounds of the spline from the start position, as well as jumping not staying in-line with the spline when moving as well as jumping, but the base concept is there. If I had time, I'd like to make a more refined version in the future.
For now, checkout the video below for a much more detailed look into the system, showing what it can do, and the code behind it!