My First Coding Adventure

So, I said I was going to make a game…

Up to this point, Ive been working on trying to figure out what that game is. Im pretty confident that Ive figured that out now, and so I needed to actually start making it.

To recap, in the game (lets stick with the working title: BOXBOT) you play as a robot, made out of a cardboard box by an obsessive box-collector, who ventures out into the world to collect boxes for their creator. Each level is a puzzle where, when you collect each goal box, it is stacked onto your head, changing your size, shape and weight depending on the order that you pick up the boxes. This will mean you need to collect the boxes in the right order in order to exit the level with the boxes.

With that slightly convoluted elevator pitch put together, I decided it was time to start programming a prototype of the game. This is the beginning of my first coding adventure.

Theres a really great YouTuber called Sebastian Lague, who has a series of videos he calls Coding Adventures. In each video, rather than creating a tutorial explaining how he programs something, he takes you on a journey through his process of figuring out how to program something or sometimes even just exploring an idea through coding. Theyve been a really great resource for me not because Im about to start writing my own procedural erosion program for simulating water eroding mountains as a way of generating an environment but because he really demonstrates what is, in my eyes, a more realistic approach to a coding workflow.

This is a really incredible coding adventure where Sabastian Lague creates a program that can generate planets and moons procedurally. Really mind blowing and just fun to watch come to life!

As someone who has literally never programmed something on their own before, most tutorials dont really explain how to figure things out. All the introductions to C# (Unity’s programming language) that Ive worked through pretty much tell you exactly what to write. Its a useful way to be introduced to the tools of the programming language, and to start to wrap your head around its syntax, but when you sit down with a unique goal you came up with yourself, you can find yourself a little bit lost for how to begin.

Thats where the coding adventure approach comes into play. Rather than trying to simply write the code I needed to make my game, I instead decided to approach this problem as trying to figure out what code I could use to try to make a prototype of my idea work. It might sound like the same thing, but by framing the goal differently in my mind, I was able to get over feeling stumped about how to start and just dive in. My goal wasnt to make it work, my goal was to start figuring out how to make it work.

And so let me take you through my process of trying to set up the most basic functionality I needed for my game: moving the character and picking up boxes.

Coding Adventure: Picking up a cube

For now, Im using some extremely placeholder elements. Everything is just plain boxes which will later be replaced with actual characters and props (more on that later).
Character movement is something I had enough experience with from tutorials that I knew how to get started with it. I wrote a little script that uses Unitys physics engine to apply a force to the player when you press the left or right arrows on the keyboard. This results in the player (box) moving left and right based on your input! Im not super happy with the feel of the movement at this point, but it works and I can figure out how to fine tune that later on.

Heres a snippet of what that movement code looks like:

public class PlayerController : MonoBehaviour


private Rigidbody playerRb;

public float movementSpeed = 5.0f;

void Start()


        playerRb = GetComponent<Rigidbody>(); 


 void Update()


 // MOVEMENT: I need to create a force in the horizontal axis when the player hits the corresponding buttons (left/right)

// this is a variable that accesses the horizontal axis

float horizontalInput = Input.GetAxis(“Horizontal”);

// this is how I add the force, multiplied by the speed and direction, to the character. Not sure if I want Vector3.forward or something else. I also have no idea if Acceleration is actually the right ForceMode, but I can experiment with that later

playerRb.AddForce(Vector3.right * movementSpeed * horizontalInput, ForceMode.Acceleration);



This is the resulting back and forth movement achieved using the simple code above.

Now that my player could move around, I needed to add boxes that they could collect. The key thing here was that I wanted the box to be picked up based on a button input (so it isnt picked up automatically), and rather than being put into an inventory and disappearing, the box would be moved to a position above the player and stacked on their head. Sounds simple, right? Im sure to someone with any experience it is, but this was the days long process for how I figured out something that works. For now. Kind of.

To start with, I knew I needed to have some kind of way of knowing what box I was close to and could pick up. Ive seen people use a technique for different things, so I tried creating something called a “trigger”. Basically, I attached a spherical collider in a radius around the box and made it a trigger, which means I can use my players collider to detect when Ive entered this spherical boundary. When the player enters a pickups pickup radius, the game sets that box as an object that the player can pick up. This kind of weird circular logic is something that Im starting to get used to the more that I work on coding, but it isnt super intuitive to me still. Its weird to think about needing to tell the computer that an object is in range of my player when you kind of take that stuff for granted in a finished game. Of course its in range, I can see it right there!

Here you can see (highlighted in sick yellow boxes) the game log and player variables updating when my player gets near an object they will be able to pick up. This is the very beginning of being able to pick something up realizing theres even anything there to pick up.

Once my player is in range of the pickup, I created a condition where, if they press the pickup button, the box that has been marked as can be picked up will get picked up. The only thing is, there isnt a built-in method in C# for just picking something up, so I had to figure out how to do that, too.

A really useful basic coding technique I learned from multiple different tutorials is to use your log as a way of testing a piece of code. In this case, I havent written the code to actually pick up the box yet, but by having the log print picked up when I press the button in range of the box, I know my is in range of pickup condition is working as expected, and so now I can work on actually picking up the box.

This is where googling comes into play. Actually, googling has always been in play. Im not sure if any of this would be possible without googling, and it is the most valuable skill Ive learned from my years of professional design and animation work never be too proud to google how to do something. Accessing the infinite resource of the internet to figure things out is like a super power that we all have, and it isnt even a default skill that were all good at. Learning how to google for helpful information is actually a really valuable skill, too.

Here is a snippet of all the googling I had to do within a two day period to try to get a box to go on top of my players head.

All this work and we still havent even tried to pick up the box yet! From this point, I experimented with a few different methods for picking up this stupid box and had a variety of fun broken results.

A short reel of bizarre bugs and unexpected behavior that cropped up while I tried to figure out how to pick up this box. The one where the box is slowly launched to heaven is particularly strange and enjoyable!

Eventually, I actually managed to arrive at something that sort of works. It at least delivers the expected result (with one known bug where, if you are too close to the pick up it will attach to the player before it gets moved to their head) and I was even able to get this to work for multiple boxes!

This might not look like much, but it is endlessly satisfying for me to watch this knowing that, largely because of some words I wrote in a weird order, these cubes are moving around when I press keys on the keyboard.

And thats my first major coding adventure! At this point, Im feeling really pleased and also very sure that there are better ways to make this happen. One thing Im not sure about is whether or not I want these boxes to remain as physics objects or not. I think the only way to figure that out is to push forward and rework things if I start to run into issues with the way Ive put this together.

I’m already thinking of multiple different ways I could achieve the same result here and maybe avoid some of the issues I’ve been running into, and part of the fun of this entire process is how open-ended everything is! I don’t think you could really say there is a right way to do anything though I’m sure everyone believes they know the right way…

At this point I decided to take a pause from the programming to start working on some art. More on that next time!

Picking an idea, self-plagiarism and figuring out how to start

After my last post about remembering how to come up with ideas, I was left with another conundrum to navigate: actually choosing an idea to start developing into a game.

Choosing my idea ended up being about finding something that felt like it had legs. Something that I thought had a lot of different possibilities, even if I couldnt quite see all the possibilities yet. It felt a bit like staring at a bunch of puddles, and trying to figure out which one was the deepest by only looking at them.

My original sketch for the first idea of what the BOXBOT game might end up being.

I shared the above sketch previously of an idea I was playing around with about a year ago when I started thinking of making a game. I was calling this game BOXBOT, and my idea for it was to make a very simple game where you move a character back and forth and catch boxes on your head as they fall from the sky. The main mechanic would be around trying to maintain your balance as the tower became taller and taller. It was a direct rip off of a mini-game from the Nintendo Wii game, WarioWare: Smooth Moves. I literally thought to myself, I should make a game like that game. I kind of thought it would be easy.

This is the minigame from WarioWare that I originally based my idea for BOXBOT on.

BOXBOT never felt like an idea with depth. I felt like I could see all that the idea had to offer before I even started. In a way, that might have been good like having an idea for a painting that you can see vividly in your mind before you start painting I sometimes think having a vision and inspiration for something can be a good place to start. In this case, though, I could see that game clearly in my mind and it just didnt excite me, which is part of why I think I never pursued it further.

In another way, I think having an idea that isnt so clear in your mind can actually be a more exciting artistic endeavour. The feeling of experimentation, exploration and discovery you can have from figuring out what that work is, is in a lot of ways the very ethos of what I want this project to be about. Its about learning and uncovering things I didnt think I could do. For that reason, I feel like my idea should be something I discover as I work on it.

After exploring a few different ideas, I eventually came back to BOXBOT, because something about the character and the wrapping of that idea felt like it had potential it was just the game part that I didnt love. Thats where Andy J. Pizzas idea about plagiarizing yourself came into play for me, and everything seemed to come together. Essentially, his idea is to look to your own past work and to pull from those ideas in the future when youre trying to find something to work on now refining your own ideas from the past by plagiarizing yourself in the present.

From last year, this is a design I made for the BOXBOT character. I still really like that sketch of them running with the box in the background here.

Several years ago, I wrote and drew a four-page comic about a strange little creature that lives in a cardboard box, loves boxes, and collects them in their box house with a disturbing, fetishistic obsession. At the time, it felt a bit like a throw-away idea, but Ive always been really fond of the character and the box collector idea. I think the idea is partly drawn from my own instinct for hoarding boxes from every computer, iPod and game system Ive ever bought something Ive been working very hard to get over in recent years.

So thats where everything clicked, thematically, and I found the narrative for my game: you play as a box-collecting robot (made out of a cardboard box) designed by an obsessive box-collector to go out into the world and find more boxes for them to hoard.

Once Id convinced myself about the direction of my idea for the story and justification for this game, I started to rework my idea for the gameplay mechanics. The falling and balancing boxes idea from earlier was clearly not interesting enough, but I started to think of an idea where youd stack boxes on your head and try to balance them as you navigate through an obstacle course. Something like one of those egg-and-spoon races, except youre trying to balance three eggs on top of eachother at once.

In the end, I realized the idea of building a physics-based game wasnt the direction I actually wanted to go. Im not really interested in writing my own physics engine (and Im quite sure that that is outside of my ability, too), and so building a game around manipulating physics to keep something in balance wasnt the direction I wanted to take. But the idea of stacking these boxes on top of your head was still interesting to me.

In the end, the idea I came up with was solidified when I made this paper prototype of a super simple level to justify an idea to myself.

I made this prototype for a level idea with paper cutouts so I could manipulate them in real time. Ive heard of the idea of paper prototypes before, but Im not really sure if this is actually what that is. In any case, it really helped me picture the flow of this gameplay idea.

In the game, youll be presented with a level and a series of boxes you have to collect before you can exit. But, unlike other games where, when you pick up a collectible, it gets added to an inventory and effectively stops existing in the world, in this game, when you pick up a box it will get stacked on top of your head. This means that as you collect the objective boxes in each level, the size, shape and weight of the player character will start to change. What I came up with in my super simple paper prototype was a level where, if you pick up the boxes from left to right, you wont be able to fit in the last area to pick up the final box. So, instead, you have to pick up the boxes from right to left to be able to exit.

This idea is what Im talking about when I say I want an idea that I can feel has depth, even if I cant see everything yet. To me, the different ways that picking up the boxes will affect how you can navigate the level feels like something I can iterate on endlessly to create a lot of interesting little puzzle rooms for players to figure out.

And so, that new gameplay idea, paired with a solid feeling narrative concept, led me to feeling ready to start prototyping. And thats where I hit my next roadblock: how do you actually start making a game?

Now I’m trying to figure out how to actually start making a game. It’s going very well.

Blog appendix: taking time away from this project

When I announced that I wanted to make a game, I deliberately avoided committing to a cadence for these blog posts. Part of that was because I was already committing to one big project (making a game) and committing to another felt like I might be biting off more than I could chew. Another reason, though, is that I already have had plenty of professional experience that told me that sticking to that kind of schedule would only do one thing: create a lot of artificial stress for myself.

I love deadlines. They are, in a lot of ways, the only thing that truly motivates me to get anything done. But with longer term projects especially ones that are meant to be done in your spare time I find that setting arbitrary deadlines for yourself can create a lot of self-imposed stress, and they rarely account for the unpredictability of life.

And so, even though in my mind I had softly committed to weekly blog posts, I ended up skipping a couple weeks because other work, family emergencies, my own mental health and less dramatic things like relaxing and spending time with my partner all took precedence over this project.

And heres the thing: I dont think any of that is bad, and I dont believe that mentality will prevent me from finishing this game.

One of the many harmful rhetorics that is perpetuated by basically everyone, whether they realize it or not, is that you have to sacrifice everything if you want to be successful. Your friends, family, personal life and health all of those need to come second to your work if you want to make a splash in the world. To me, that feels wrong, and it certainly doesnt seem worth it. 

And so, if Im going to commit to anything with this project, it will be that it will not become a source of negativity in my life, and Ill continue to make space for everything else if this work starts to get in the way.

The Blank Page

So I said I was going to make a game. Now what?

For the last year or so, with this idea in my head that I wanted to try to make a game of some kind any kind Ive been tossing around vague ideas for what that game would be. Maybe Im coming at it from the wrong angle, but my goal was never to make a specific game, and it still isnt. My goal was to go through the process. To make a game, finish it and release it.

And so now Im left with a pretty hefty challenge at the beginning here. How do I start? What do I make?

This is a sketch from a year ago of one of my first ideas for a game. Looking at this now, I understand the prototype I was trying to make last year a bit more. I still don’t hate this idea, despite it being pretty simple.

This isnt a challenge unique to making games. Throughout your entire life as a creative person, youre often confronted with the fear of the blank page. There is this idea that the most difficult thing about any creative project is just starting. That the absolutely endless amount of possibilities becomes paralyzing like when my kitchen scale broke and I spent two hours watching YouTube videos and reading Amazon reviews to find a replacement theres simply too many options, and so you end up doing nothing. This fear of the blank page is a part of the issue, but I dont think its really the heart of the problem.

I recently had the privilege of getting to teach introductory drawing classes part-time at Mohawk College in the graphic design program. It was an amazing experience for numerous reasons, but one thing I didnt appreciate going into it was how much I would learn from it. Not because of some hokey thing like the students taught me more than I could ever teach them, but literally because I was having to teach them the fundamentals of a creative process, and so I was kind of auditing an introductory drawing class that I happened to be the instructor of. I couldnt help but overhear a lot of the advice that I was giving, which was a very bizarre and hugely helpful experience. We tend to take a lot of the things we learn for granted, and unless we make a point of repeating them to ourselves every day, its pretty easy to forget about some of the lessons youve learned that you might find useful later.

It took teaching again to really remember just how vital working with photo reference can be when you’re designing environments. This is some work from a concept art class I took in university. Our instructor did a great job making us use (and show) a lot of reference.

The reason Im bringing this up now is because one of the major things many of my students struggled with was coming up with ideas. Practicing drawing stick-figures wasnt a big deal, but as soon as I asked them to design a character to map onto those stick-people, a bunch of them hit a brick wall. And here I am now having a similar issue. So what was my advice to them? How can I learn something I might already know to help myself get past this blank page?

The process of coming up with ideas is something Ive always been fascinated by. Especially while I was in university, I thought that if I could figure out a reliable process for coming up with clever, intelligent, humorous, brilliant ideas, then I would finally have the key to all my creative potential. I would try to figure out the exact recipe for the perfect idea six dashes of mind-mapping, a cup of photo reference, fifteen grams of powdered inspiration, nine heaping tablespoons of eureka moments brought on by long walks and hot showers. It was perhaps the most Id ever forced myself to try to be clever and I think it showed. Thats because I was blind to the actual issue I was having every time I tried to come up with an idea.

It isnt that complicated. At the beginning of any creative process and I can feel that this remains true for this new process of game design your biggest enemy is yourself. While youre pushing yourself to try to come up with some real visionary, mind blowing material, theres this other part of you that is sabotaging the entire effort. That part is self-judgement. 

Ive found that I have this extremely harsh, judgmental filter on my brain that I am almost always completely unaware of. During the process of trying to come up with an idea, I feel like Im drawing a blank because in reality, Im filtering out ideas as bad or dumb or obvious before they even leave that boundary just beyond my subconscious. Ive barely even had an idea, and I dismiss it. No wonder it seems like I dont have any ideas! I threw them all away before I knew if they had any merit!

I dont think this problem is unique to myself, and when I taught my students I would try to help them realize that this might be going on by getting them to use that filter to their advantage! Dont try to fight your judgmental filter, but instead trick it into letting some ideas get out of your brain. I would do this by getting them to, rather than try to brainstorm a bunch of good ideas, brainstorm as many bad ideas as they could. Legitimately try to come up with horrible ideas that will not work for your project, and youll find you have an unending spring inside you absolutely overflowing with ideas. And heres the thing, the filter thats deciding that these ideas are bad sucks and it routinely lumps legitimately great ideas in with the bad ones. Ive found that that did a great job in breaking the dam and getting my students to actually start the process of ideating and coming up with something anything to draw. A lot of the time in that process, you look down at all the horrible ideas you thought up and realize some of them arent so dumb after all (though lots of them will also probably be dumb).

This is a screenshot of a bunch of reference images I downloaded for a creepy character design I wanted to do. I never did the drawing because I convinced myself it was a dumb idea and I lost interest.

The whole point of that process isnt to have a reliable way to come up with good ideas I already realized after university that that pursuit was flawed from the start. Instead, the idea is to continually remind yourself to recognize that you dont really fear the endless possibilities of the blank page. Instead, the issue is that youre prejudging your ideas before they even get a chance to make it on the page. At least give them a chance to get out of your brain before you decide they’re awful!

So what game am I going to make? Honestly, this entire week was a process of getting to this point of reminding myself not to judge my early ideas. A lot of my time was spent avoiding this work. I did a lot of dishes, baked bread, researched the ideal kitchen scale, convinced myself I needed better office organization and spent $70 ordering cork boards, modular peg-board systems and boxes from IKEA basically anything I could come up with that could get in the way of putting in the work of coming up with an idea.

And so now that I’ve reminded myself of how to come up with ideas, Im going to go try to think of some really bad game ideas and see what makes it past that filter.

I’m making a game!

But I don’t know how to make games.

For a pretty long time I’ve been curious about making video games. I’ve loved games since I was a kid, and have admired the work of many game designers for years. There’s something special about interactive art that really excites me it’s similar to the feeling I get from animating and bringing pictures to life. It’s magical! 儭

But here’s the thing: I’m an artist/illustrator/animator/designer/creative person who, for a very long time, thought that making games was something I just couldn’t do. Largely because I got a 51 in grade 11 math and don’t know how to “code”.

Portrait of a robot trying to fit in. We all feel like impostors from time to time.

The thing is, I didn’t know how to do anything until I learned how to do it. Recently, I’ve really embraced the discomfort of learning new things. I’m learning Chinese (very slowly) and bought a skateboard and fell off of it a bunch of times. It’s a magical kind of thrill to do something with the certainty that it won’t go perfectly because you’ve never done it before. There are insurmountable feelings of impostor-syndrome associated with it, too (I’m still working up the nerve to hit the skate park), but maybe just admitting publicly that I have no idea what I’m doing is a good way of getting over that.

So I’m gonna figure out how to make a game. And this blog will be a record of that process.

I’ve decided to commit to making, finishing, and releasing a game. That’s just about all I know about how I’m going to do it, too. I’m hoping that part of the value of sharing this learning process in public will be to show that you really can just decide to do things. We manage to self-sabotage a lot we decide that our ideas are dumb before they’ve even fallen out of our heads so I’m just going to decide that this is a good idea and do it.

What I’m bringing to the table.

In case someone else finds this and wants to use it as a bit of a guide for making a game, I thought it would be useful to go over the things I already know.

Professionally, I’m an artist who primarily works in illustration, animation and graphic design. Games have a big artistic component to them that I know these skills will contribute to. From character design to animation, UI design to environment art the part of figuring out how things are going to look is something I know I have the skills (and the tools) to manage.

I also have a good amount of experience working with 3D software (3Ds Max, Blender and a bit of Maya) which will come in handy, too.

In university, I took a Game Design course where you were put into a small team and told to make a game over the duration of the semester. That course was kind of awful for the artists, though. It was meant to be an exciting collaboration between a group of art school kids and a group of computer science kids, but in the end it was very self-directed and I didn’t learn much about actually making games.

The main character of our game was a firefighter with a sort of lamp for a face. There was supposed to be some fire in his face but I don’t think that ever got figured out in-game since you always saw them from the back.

I used a peer’s character design to make a really basic character model, rigged it and made a few animations for that character. This was my first introduction to the Unity game engine, and I learned how to import animations into the editor (though I never got the chance to actually learn how to hook up and trigger those animations). The majority of that project was run by the programming students, which made sense since the artists had no idea what we were doing. It was kind of a discouraging experience.

Despite feeling kind of negative about that game design course overall, I was always really happy with this idle animation.

Since then, it took me a while to get the game-making itch again. University burnt me out on art making and learning in general, and only recently have I once again found myself interested in either.

About a year ago I experimented with making a prototype for a game, but my heart wasn’t really in it and I abandoned it after a couple days.

This is a screenshot from this abandoned prototype. I don’t really understand what I was trying to do, and some navigation plugin that I didn’t understand how to use at the time is broken now.

I’ve since spent some of my spare time working with tutorials from Unity’s learning platform (which is free right now, and a really wonderful resource), as well as getting a bit of an intro to Unity’s programming language, C#, from different channels on YouTube (like Sebastian Lague’s Intro to Game Development course, which is insanely good and free).

At this point, I feel like I could keep trying to learn from tutorials alone, but I’m feeling empowered enough to dive into the deep end and learn by trying to make my own thing (and messing up a lot).

So that’s my introduction post! Thanks so much for reading this, if you did. I’m going to go start now and I’ll be back when I’ve done something I can show! Let’s do it!

Learning can be painful but it can also be thrilling!

Follow Along

Apparently if you put your email in here you’ll get a notification when I post my next update. Give it a shot and let me know if it works!