Category Archives: Unity

Posts relating to Unity projects

Making a game in Unity 3D

Published / by robsws / Leave a Comment

Contrary to what I planned before, I decided to go back to Unity and take on a 3D project this time.

The main reason I hadn’t decided to do this earlier was feeling like I would need to create 3D assets. Having dabbled with importing 3D assets before via the asset store, I was a little daunted by how I would even begin to integrate these into my own game. Therefore, I decided to make acquiring and using an asset package from the asset store a key goal for my next project so that 3D projects no longer felt as daunting to take on in the future. I decided to limit myself to the downloaded assets and try not to get tempted to start making any art of my own.

I eventually settled on downloading the 3D Platformer Game Kit as it seemed to have all the basic assets I would need for a classic 3D platforming game. On downloading, I was surprised at how much functionality was already included on top of the models and animations. In fact, I was a little disappointed as I was hoping to have to code some of the movement and physics myself as a learning exercise. As a direct consequence of this, I decided that a project goal should be to make significant changes to the movement logic already present within the package, if not replacing it all completely by the end.

Whilst thinking about how I could modify the movement logic, I had the idea of moving the character automatically around waypoints in the level, similar to something like Myst but from a third person perspective. Moving around the level could then be some kind of turn-based puzzle, where the player must avoid predictable enemy AI and collect items before making it to the exit. Since this would make most of the existing movement code obsolete (as it is designed for a freely moving platformer), I decided it would be an ideal mechanic to try and implement.

Although this idea meets all my personal goals, I am concerned about whether the final game will be fun to play. First of all, if the game is a puzzle game at heart, it may frustrate the players not to have a full view of the level at any one time so that they can formulate a plan for making it through. However, this obfuscation might also add to the fun, as some players may enjoy exploring the level and noting down routes. Secondly, I will need to be careful to make movement times between the waypoints fairly quick as it may be frustrating not to be able to execute puzzle solutions quickly as soon as the player knows exactly what they need to do.

My rough project plan is as follows:

  • Implement basic mechanics – adjust the existing asset code to implement movement between waypoints rather than free movement.
  • Refactor existing code – remove any code that has become unnecessary to the new movement system.
  • Implement enemies – add enemies and different kinds of enemy AI. The AI should never be random as the player should be able to puzzle their way through. Basic AI should include patrolling enemies and enemies who react to seeing you.
  • Implement items – add collectible items in levels. My current idea is to have the level complete-able having picked up only one collectible, but in order to unlock more levels the player will need more further down the line.
  • Implement game mechanics – add support for multiple levels and have a way to end levels. I want all levels to exist in the same world and be visible from other levels, but performance may be a limitation as the game grows larger.
  • Add some levels – design a small number of basic levels. Hopefully at this point this should just be a case of dragging and dropping prefabs into Unity, so the challenge here will be more of a puzzle design challenge, especially with so few core game mechanics.
  • Add UI and menus – add the finishing touches such as UI elements, music and a menu screen.

At this point I could probably end the project, but if I want to continue, I have some other ideas:

  • Implement advanced mechanics – keys and doors within levels, switches, moving platforms etc.
  • Add more levels – add more levels introducing the new mechanics gradually.
  • Re-skin the game – at this point I may have had a better idea for the general story/aesthetic of the game, so I may want to switch out the models/animations/textures I have for some that better fit in with this theme.
  • Play test – ask some friends to play the game and give feedback on all aspects. I will most likely do this at earlier points as well.

Of course my main goals here are still learning goals, but I’m excited to see whether a fun game can emerge out of that!

Making a simple platformer

Published / by robsws / Leave a Comment


A little while ago, I decided to have a go at making this Amiga game from my childhood:

This project actually ended up being much more difficult than I anticipated, which I guess is why it makes a lot of sense to start out with these smaller scope projects. Whilst the majority of it didn’t cause too many issues, there were one or two key problems which I spent a lot of time on.

Sprites and animation

The first thing I did was attempt to make some sprites. I’m actually pretty happy with the little guy in a suit, even if his Microsoft Paint heritage wasn’t particularly subtle.


I also made a bunch of animation frames for him to run around and set about making him animate in Unity. The animation tools allow you to set up a state machine that decides what animation should be playing at any one moment. The transitions can be triggered by setting the parameters from the C# scripts assigned to the player object.

2017-01-09 (3).png

This diagram used to be a lot more complicated, as I had separate sprites/animations for moving left and moving right. It turns out that you can flip the sprite easily by simply negating the scale of the object’s transform. This trick made the state machine much simpler and much less confusing. This lesson alone was probably worth the time I put in so far, since moving a 2D character left and right is probably something I’m going to want to do again at some point.


The next most interesting challenge came at the point when I realised that I wanted my character to have two different collision behaviours with the same object, namely a platform. He needed to be able to stand on top of the platforms, but if he hit a platform with anything other than his feet, he’d need to fall over and “sleep” for a few seconds before the player regained control. I chose to solve this problem by creating separate sub-objects for the player’s feet and for their body, each with their own colliders and own scripts for dictating what should happen in the event of a collision.

After having this working, it was clear there was something else that was wrong. My character, after jumping, could happy jump again and again in mid air without any ground beneath his feet. Similar to the sprite-flipping moment earlier, I felt the sense again that I was stumbling across a problem that had tripped up many a budding platformer developer in the past. The solution was to keep track of when my character was on the ground using a flag – set the flag to True when the character’s feet collide with a platform, and the flag to False if he is commanded to jump. That way, I could ignore jump commands if the flag was set to False.

At this point, I had my character running and jumping around, able to land on platforms and also knocked out by them. The next problem I encountered was easily the toughest to solve, and I again felt like I was treading in the footsteps of many developers before me. I needed holes in my platforms, and I needed the holes to move along the platforms.

2017-01-09 (4).png


It turns out it’s not particularly easy to make a hole in a rectangular collider. You have to use workarounds in one way or another to make it work. If it were the platforms that were moving, it would be easier because the holes would simply be gaps between the platforms themselves, which would have separate colliders. In this case though, the holes move along the platforms – you can see this in the video above.

The solution I used in the end I think really highlights how a lot of what you see in a game is smoke and mirrors. Whether the illusion is down to constraints of the engine or constraints on computing power, there is always a kind of magician’s act going on. When bizarre glitches occur, quite often I bet what is actually happening is that the illusion has broken down momentarily and we are seeing the game world for what it really is.

Anyway, in my case, the holes had to be separate objects that could move independently along platforms. Therefore, Unity objects were instantiated for each hole, and their colour was set to match the background colour so they would appear invisible.

2017-01-09 (7).png

Next, in order for the character to actually pass through them, I would need to detect when the player was in a hole, which meant assigning a trigger collider (a collider that detect collisions but does not apply any forces as a result). A script was set up on these hole objects so that, if the player jumped into one, the collider for the entire parent platform would be switched off. I actually made the colliders for the holes quite tall so that whenever the player was standing above or below a hole the collider for the respective platform would be switched off.


The issue with this approach was that it introduced a whole bunch of bugs into the game due to the number of edge cases, such as jumping through a hole and immediately falling back through it or falling through a hole without jumping first. Because I was switching the collider for the platform on and off manually, certain OnCollisionEnter2D function calls were not executing which I was relying on for checking if the player was on the ground or not. Without that function call, the game still thought the player was on the ground and so could jump in mid air again.

Eventually however I was able to overcome those bugs by essentially keeping an eye out for those edge cases and making sure that the correct code was executed at those times. Perhaps there is a more elegant solution for dealing with moving holes which reduces the number of edge cases, but in the end this solution worked well enough for me.


The final steps of the project were to add enemies and make the game work on my Android phone, neither of which kept me back too long.

Overall, I feel like the project was a good learning experience, especially in terms of learning a bit more about the common problems faced when building a simple platformer. Next time I think I’ll try something outside of Unity.