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!
Continuing on with my 3rd person platformer unity demo game, this time I upgraded my camera system!
Previously, I had 'fixed' my last bug with friction of the player on objects in mid-air, but I actually missed out what would happen when jumping against a wall whilst grounded. This time, I fixed that.
The additions I made included a new camera mode, a method of swapping between to modes, and upgrading the default camera mode!
Normal mode now features collision detection! The camera zooms in with some padding when colliding with with a wall.
The new NSEW Soft-Lock mode locks the camera to either the north, south, east, or west angles. You can then rotate around the player only in 90 degrees whilst in this mode, snapping to the closest cardinal direction at the moment you enter the mode.
Checkout the video below for a much more detailed look into the system, what it can do, and the code behind it!
Again I'll be continuing from last time, with a new addition to my 3rd person platformer unity demo game. This time, I created an opening door sequencing!
Last time I still had the issue of friction against wall when in mid-air, as featured in the 1st player avatar demo post. This time around, I fixed it! It was a quick and simple fix that just used the ground check function to check if I was in mid-air or not. If I, as in the player, was in mid-air, then its rigidbody would have its material set to have no friction. This meant I'd just rub against surfaces like no issue. When the player is grounded, it adds friction again so that it can walk around normally.
Enough with bugs, on to the new stuff! I added a door, a door button, and a sweet cut-scene that plays out when you press the door button.
Checkout the video below for a much more detailed look into the system, what it can do, and the code behind it!
Today I made a double power-up systems based on top of my last post, the player avatar system in Unity.
First, I fixed a couple bugs from last time, one which limited your jump distance due to having only 1 max air-glide velocity. It limited the distance you could travel no matter if you were running and jumping or regular jumping. Now, there are 2 independent max air-glide velocities, allowing 2 different jump distances based on if you were performing a regular or a running jump. The second bug was not falling down on a wall you were colliding with whilst trying to move. I solved this by applying a physics material with 0 friction.
Now for the new stuff! I created 2 power-ups, a speed boost and a double jump. They both work as you'd expect, with public variables to control the outputs, and prefabs to place them down infinitely.
I also added a whole bunch of particles, for general running, jumping and landing, as well as for each power-up.
The speed boost looks like a ball with lighting sparking out in all directions, and the double jump looks like a ball of gust spinning upwards. When consumed, there is a unique splash effect for each power-up.
Each power-up also has particle indications around the player to indicate if they are active or not, and particle effects for when the added abilities are used, when you double jump, and when you run.
Checkout the video below for a detailed look into the system, what it can do, the code behind it, and the changes to the animation system too!
Today I made a 3rd person platformer player avatar system in Unity.
It can walk, run, jump, attack, and comes with a whole bunch of ease-of-life features including air control, dropping off edges, reacting to head bumping, short/long jumps, and more!
You can even interact with the player with both keybaord/mouse and a controller!
Checkout the video below for a detailed look into the system, what it can do, the code behind it, and the animation system used!
What is a Gameplay Programmer?
Today I'll be taking a look at the role of 'Gameplay Programmer' within industry, expanding my awareness, and seeing who is hiring today. To start with, I researched online looking at the most recent job posts for the role, expanding to encompass job roles of similar titles, given the flexibility of the job role. I kept my search results limited to the UK, given that is where I will most likely be proceeding in my career, at least initially.
Who is hiring?
It was interesting to find that most companies keep their name hidden, as they submit job advertisements through recruitment agencies most of the time. Most companies that shared their location, are commonly either based in London, or Manchester, with many other more built up areas around the UK having odd job opportunities here and there. Take note, that this is just a observation from job results of the current time, most definitely changing over the coming months.
The different levels of gameplay programmers
When looking at jobs, I identified there were different levels of Gameplay Programmers, with Junior, Mid-level, Senior, & Lead roles taking centre stage. Each different level expects similar requirements, but there are major differences the further along the ladder you go, like comparing the Junior role and the Lead developer roles.
Just looking a this structure in itself indicates the kind of career path that I have available to me, that being if I restrict myself to this particular job role.
How do hiring companies describe the role?
All gameplay development roles generally define the job as the following:
What experience is required to become a gameplay programmer?
There are many requirements to become a Gameplay Programmer, but the jobs usually more tightly define to range of work you'll be doing. Take for example a Unity Developer job, they'll focus more on having Unity game engine experience, and less so in Unreal Engine 4. Still, this all depends on the job that is being offered. Sometimes the role requires expansive knowledge on pre-existing APIs and frameworks, such as ASP.NET, jQuery, or Bootstrap, but these job comes with a high pay salary.
The general requirements I found to become a Gameplay Programmer consist of the follow list, including requirements that only appear sometimes depending on the how specialised the job is:
What is the difference between each level of the gameplay programmer role and how does it affect the job?
For junior developer positions, they are a little more slack with how much technical experience is required, like depth of knowledge of game engines, though you must still have solid fundamental knowledge, and commercial development experience is a major plus for this role.
Fro lead developer positions, major expert experience is all requirements is a given. They also need strong experience with mentoring/managing teams, with experience in previous lead roles providing a big plus. Experience is also expected to include previous work on AAA games due to the massive importance of this role. The pay rate certainly reflects the job, with annual salaries of £80-100k.
Specified years of experience isn't always included in job experiences, but from those including them, a general amount of 2-3+ years of experience is required for any senior and above positions. Even mid-level developers require 2-3 years at least.
What is the salary of Gameplay Programmers?
Each different level of the gameplay programmer role has a different average salary.
My future career path
- Talk about the career paths available, including adjacent/similar ones
Generally there is a simply level system to how experienced you are, and then you work your way up the ladder, though this isn't always the case.
Most games developers in industry will want to start with Junior development roles to further their knowledge and build up their experience, though others with major skills from personal projects will be able to leapfrog their way up the ladder slightly. Years of experience within the industry still matters and will limit those from applying for higher, lead positions, but yet again this can be bypassed by the start-up if your own games studio.
Not only this, but as you make your way up the chain, you can then begin to specialise more, steering yourself in a certain direction, for example VR development, which is what I want to achieve. From conducting this research I have a much better realistic understanding of how I can achieve my dream job (a fully-fledged AR/VR developer) and will use the ladder, to begin my venture into the games industry. Most likely I will branch out, happily starting my own small games company if need be, but I'm sure there are enough opportunities out there for me, as long as I work on building up my experience and tool-set, ready to tackle the next job's requirements list!