Learning Unity & C# Part 1: The Fortress and the Fog

I keep coming back to wanting to make games. I’ve learned a lot of skills, to the point where I feel like I’m nearly a jack of all digital trades, but a master of none.

The last digital skill that I want to acquire is game programming. I keep coming back to it. I’ve made a few experiments with Construct 2, but it doesn’t feel powerful enough. Once you try to make something intricate, you’re extremely limited or you have to spend hours creating workarounds. It’s not worth it.

I decided to learn Unity, at the time of writing this Unity 2017.3 is the newest version.

Background: I started with a bit of Python and got a job doing mainly back-end and front-end Javascript, complete with Node.js and almost a full stack of AWS services.
To my dismay, I’ve missed the boat on UnityScript. It was Unity’s version of Javascript. It’s no longer supported, so I’ll have to learn C#.

The Fortress and the Fog

Learning something new is full of challenges, but the biggest and most important challenge is getting past the initial barrier of learning. You’re outside of the fortress. The fortress looks big and intimidating, the walls of it disappearing into the low fog. The thing is, the fog is just your lack of knowledge of the fortress, and the fortress may not be as high as the fog makes it seem. This can scare away people from ever trying to get past the fog. I am not yet past this point, but from my past experiences in learning, the fog is always lower than the top of the fortress. It’s never as monolithic as you imagine.

One part of the fog is: where do you even start? Do I learn C# first? Unity first? Or try to learn both at the same time? For people who know a programming language already, learn both at the same time. If not, learn the basics of C# first, build something small, then move on to Unity.

I started with the Asteroid Shooter tutorial which was amazing. Seriously the best tutorial I’ve ever taken. Check it out. I felt confident I could recreate as many space shooter games as I want after learning that. You can find the Asteroid Shooter tutorial by starting up Unity, and press the “Learn” tab, and you can find it there.

Here’s stage one of my game.


It’s just a moving placeholder, but it already is a functional player character and has a bit of personality to it. It should feel like a single-wheeled robot, as it tilts when it moves.

I think making an Overcooked style game would fit my current skillset and also be a good practice. After all, Overcooked was made in Unity!

My first hurdle is creating 3D objects, terrains, and having the player interact with them. I want a counter (a cube object) and an item on it, and the ability for a nearby player to pick it up and put it down.

I’m currently unsure of how to approach it. I was thinking of storing variables to the item, but how do I detect if a player is close enough to grab an object?

I tried one idea, I made a Quad object inside of the Player, and made it a collision trigger. That was if a Player’s Quad is colliding with an item, that means they are in range, and I would enable them to pick up the item.

The problem is, I am so inexperienced, that I don’t even know if it’s wrong. Does this feel wrong? I have no idea. Collision checks are probably expensive. It’d probably be better to check for collisions only on item pickup attempts. Maybe I can still use the Quad then? Not sure yet.

Another path I keep reading about is Raycasting… But I get the feeling this is more for FPS’ since my character may not be facing directly toward an item on pickup. Players may not be clicking the items, but the tile they are sitting on. This will be more complicated than I anticipated. Now I am in a fog. I’ll have to learn more.