Hello everyone! Recently, I have been developing a game in the Unity engine. I wanted to create a devlog so that I can quantify my work and share the development process with others.
Before I had begun developing this specific project, I was always nervous and not confident in coding complex features. Although I had learned a lot from University, I knew that I still had a huge gap in knowledge and knowhow. I wanted to create something that came from the heart. I had a vision to create a game but with my ideas and feel to it, but I was lost. I was aimless and didn’t know how to start, or where to go with development and how I would code these grandeur features such as advanced movement & combat systems with dynamic linking between them.
I came across a video on YouTube that outlined a basic process on how to implement almost any feature in a game. That video had inspired me and instilled a confidence that I could also do that. So, I undertook the Create With Code pathway from the Unity Learning resources to get a basic understanding of the Unity editor and its basic capabilities.
The learning pathway delves into the ‘primitive’ games where the objective and gameplay loop is simple. I’ll show the ones that I worked on:
The Unity Create With Code Learning Pathway takes us across multiple small games that give a nice introduction into game development. The pathway is split into prototypes and their associated challenge project. First I would learn what's in the lesson and continuously work on the prototype. When the prototypes are “done” there are challenges that use the knowledge learned prior and builds upon it.
The learning pathway starts off with a simple game that involves the player driving cars and gives a simple rundown of the editor and where the tools are.
This project introduces the need and processing of player input in the form of moving the player (A car). These cars are rigidbodies! Which is a term in the physics engine to denote that the object is “physical” and can interact with other rigidbodies (the obstacles: crates, barrels, vehicles).
This challenge featured ‘broken’ code that did not work as intended. At first, the no player input was being taken so using what I learned in the Prototype 1, the plane would correctly move throughout the barriers and tilt correctly based on player input.
This project introduces the need and processing of player input in the form of moving the player (A car). These cars are rigidbodies! Which is a term in the physics engine to denote that the object is “physical” and can interact with other rigidbodies (the obstacles: crates, barrels, vehicles).
The second prototype gets more serious, changing it up with a top down perspective and involves a bit more of a gameplay loop. The player, a farmer, is being overrun by animals! The player can fire a projectile (in this case, a slice of meat) to fill the hunger meter of the incoming enemy and score points when their hunger meter reaches 0. This prototype introduces enemy variety by tweaking variables such as speed, spawn rate, and hunger meter.
This game is also where I learnt of player bounding within the context of the game. The player must not move outside of the starting platform or the screen for that matter. Collision detections are also expounded on in this game, how to interface with the interactions between objects in the physics system: The food projectile hitting an animal, and then what to do afterwards.
The second challenge was a game about the player sending out a dog to retrieve a ball that falls from the sky. In this case, the dog is considered the projectile and moves away from the player, and also despawns when out of bounds.
The third lesson in the learning pathway introduced sounds and effects. In this case, music for the game, player jumping, obstacle hits, etc. This is also where I learned that in game development you’d have to be clever to implement some of the features. For this game, the player is actually just standing still! The only movement the player is responsible for is the vertical jumping to jump over obstacles that come in from the right side and move towards the player. For the infinite scrolling background, it was a still image that was moving and had to be “teleported” back into place where it would seamlessly continue forever.
The third challenge involves another infinite scroller where the player is a balloon and trying to obtain money whilst avoiding bombs that are also floating. Sound effects were added to the interactions to create meaningful and responsive gameplay: Hitting the top and bottom bounds, bouncing off those bounds, getting hit by the bombs, and collecting the coins.
This is where it started to get more interesting with the introduction of some camera movement based on input and a more interesting gameplay mechanic. A Sumo game, where everyone is a ball and the player’s goal is to not get pushed off the platform.
▸ I liked this project the most. There were a lot of avenues for improvement and variability. For instance, this project allowed for a straightforward way to implement new things/variations.
An image detailing all of the variations of items in the project (different enemies, different powerups, and even a boss type enemy).
I learned from this project that while in the prototyping stages, primitives (basic representations of to-be complex objects) serve an undeniably important purpose. It helped me focus on what was needed, which was the core gameplay since all we’re doing here is manipulating spheres.
A soccer game where the player is a ball and the objective is to deter soccer balls that spawn in and try to bump them into the other goal.
Although these lessons were great and I learned a lot, I felt a lot of knowledge was still missing. And that's fine! The course was advertised as beginner level, and I knew that going in. But, almost all of these projects were fill-in-the-blanks. I knew if I wanted to truly learn Unity and what it has to offer, I would have to make a game from scratch myself, all bumps included.
After a good understanding of the basic Unity building blocks, I dived head first in creating my game from a blank slate.
Diving headfirst into the project, I wanted too much done too quickly, without a good foundation. I didn’t know what I wanted to do:
▸ First person? Third Person? RPG? Fighter?
These questions I’ve found should be answered at least a little bit before delving into the development process.
Beginning with the development of a character controller, I decided to try to make a kinematic player controller, which tells Unity’s physics system that I will handle the physics interactions. I wanted to do this since I was envisioning a complex movement system and thought I needed to do this all on my own (Creating my own physics system). This was a mistake. It was frustrating and I felt like I was bashing my head against the wall as to why some things worked the way they did and most importantly at all, I was trying to do too much too fast. Here are some examples of what was plaguing the development process:
Unwanted wall collision behavior
Player speeds up when walking into the wall and collision is not checked when turning the corner for adjacent walls.
🍝 The Animator component for the player model
To get the transitions between the states of movement and it's associated animation, I found the Animator component worked well. BUT! It got very messy very quickly! And that's only the beginning for player animations. To expand on this would be a nightmare, so I decided to look for a better way to implement animations. -> Fast forward to now -> Animation trees and separation of animation routes and inverse kinematics which will be part of later devlogs.
Unwanted camera influence behavior
When the player is in the air, if the camera is rotated and holding the 'W' key, the player moves instantaneously with respect to the Camera's rotation.
Some good and some bad slope movement behavior
Works sometimes, which is never a good thing. We want it to work all the time. BUT‼ The slope detection worked by sending a raycast downward from the player with a set distance inside the player capsule. (We raycast inside since raycasting doesn't work if the ray is already intersecting/touching the surface we want to test if it is hitting. With the detection in change of surface angle, we take the user input direction and project it onto the slope of the surface the player intends to move on! But! we run into issues when moving onto different slopes from a sloped surface: we clip into the slope itself and actually go down! Something we did not want.
There were some triumphant moments during this early development, however!
A 3d model of a sword I made for the game
Learning and working on a 3D model was fun and gratifying to see work! I think this simple sword does the trick pretty well.
Good animation transitions
The transition between idling, walking, and sprinting was something that worked!
Good camera locking behavior
I did get a toggleable lock-on to work, which takes in to account things/objects that are targetable and changes the camera work!
Animations, rolling, and lock on
Here is a glimpse as to what Unity's animation blending can do. There are transitions between the different animation states such as idling -> walking -> sprinting -> rolling -> strafing -> rolling -> etc.
This brings us into the current day, where I am currently developing a movement system that will serve the purposes of my vision.
Starting off the development process, I needed to make a working prototype of how the player will move around and interact with world objects so that I could test other things.
I have learned to not bite off more than I can chew and practically scrapped the kinematic player controller and instead moved onto a dynamic player controller, which means the Unity physics engine will do the heavy lifting in dealing with collisions and movement.
To start off, I want to nail the movement and player feel first and foremost so that the basic movement is responsive and works the way it seems like it would work.
A quick GIF of the current progress
▸ There was more than I intended to be on this log, so I will seperate the current progress into another shorter devlog!
Although development has been going slow by my standards, I plan on turning it up a notch! Part of this devlog is to keep me accountable as well for weekly/bi-weekly updates of tangible results or a problem that I am facing. Perhaps if the project isn't worked on too much, I could share what I have worked on for the week (Other projects).
I hope to report in later with good news!
If you've made it this far down, thank you for reading it :3
Yoooooooo
