Other Projects
(and things I've learnt)
(and things I've learnt)
Flippin' Hexes is my first commercial game. But I made other smaller things along the way, all using Unity (a game engine). I've outlined a few of these projects below. Many were made as birthday gifts and I inserted the people receiving the gift as the main character. I used most of the projects to learn a new skill, which I've highlighted below too. I also used them as distractions to avoid burn-out whilst working on one larger/more polished project (Flippin' Hexes).
A note on the artwork: I can't take credit for most of the art used in these projects (in particular the 2D sprites in Quiet Quest and Supreme 21st Shindig)! These were small personal projects that I needed to complete quickly and never intend to share, so I used free assets I found online.
One of my first small projects. I wanted to make a tiny game to give one of my roommates (Jon), as a birthday present. It was super simple and stupid. There was a bar on the right that represented Jon's level which continuously decreased. There was also a picture of him taking up most of the rest of the screen. As you pressed X on the keyboard, Jon's level increased a tiny bit and a sound played of either my wife or I yelling "Jon!". Because his level continuously decreased, you had to mash X rapidly to increase it with any progress (all the time getting bombarded with my wife and I yelling "Jon!"). At certain levels, Jon's picture changed into a "cooler" picture of him, until finally it reached the top and Jon evolved into his ultimate cool form (which was just a picture of him with his arms crossed wearing sunglasses).
Key takeaway:
Can I make a game in 1 day like they do for game development competitions (like Ludam Dare)? Yes (so what if the scope's very small?!).
My wife had a dream about a two player game where each player controlled a vertical coloured line. White balls dropped from the top of the screen and filled a giant bucket over a 15 second period. During those 15 seconds, each player changed the colour of the balls into their own colour by moving their line over the balls they wanted to change. You could make the opponents balls disappear in the same way. The winner was whichever player had the most balls at the end. It took just under a day to make and was silly, frantic, simple and ridiculous.
Key takeaway:
Can I turn someone else's idea (i.e. a "client request") into a fully realized prototype? Yes (at least, yes for sure if the game's about colouring balls).
I stole the idea from the fencing/insult section in the first Monkey Island, but in my version, my wife had a number of job interviewers that she had to impress. It started with your mum, who helped you practice interview responses. From there, each interview was for a more important job and required you to answer more questions than the last. You picked from 4 responses for each question. If you came across a question you hadn't encountered before, you wouldn't get the correct response in those 4 options, so you had no option but to get it wrong and you often had to choose a completely nonsensical reply. The interviewer would say something scathing in response. Only after you'd answered a question poorly would you learn what you should have said. When you encountered the question again on another play through, the correct response would be included in one of the four options. So you had to play each interview a number of times to learn all the responses. It was part memory, part silliness.
Key takeaway:
I could already read/write to JSON (a "human readable" text format), but I wanted to expand this. I'm an accountant. I love excel. So I used this project to learn how to read and write to/from CSV files (a simple file format that excel can open and represent in columns/rows). By doing this, I was able to easily add new questions and responses without even opening Unity.
This one was for my cousin's birthday and was an abstract representation of his work in IT. You had to connect client problems with their solutions while dealing with other annoying requests. Your promotion round was coming and you wanted to impress the bosses and increase your annual income as much as possible by dealing with as many problems/requests as you could. The problems and solutions were represented as circles and squares of the same colour, and the annoying requests were red triangles with exclamation marks in the middle. These elements would all appear randomly as time passed and you'd have limited time to deal with each. If you took too long, you'd annoy whoever had made the problem/request and it would disappear. You could only annoy a certain number of people before you capped out your annual income increase (i.e. got game over). You dealt with the circle problems by dragging a line to a corresponding coloured square, but the annoying triangle requests would block your path if they got in the way. These annoying red triangle requests would slowly grow over time, so they become more likely to block your path if you didn't deal with them by clicking them a bunch to shrink them into nothing. To add character, each of the clients (circles), problems (squares), and annoying requests (triangles) received random silly names (... like "Bigwillys.com", which I'm sure is a website for large men called "Willy").
Key takeaway:
I learnt how to use "line renderers", which simply draw lines between two points. Doesn't sound too interesting, but it was handy for this project and something I hadn't used before.
This was for my brother-in-laws birthday. I initially had a grand idea about a game where he would run a Dungeons and Dragons campaign and would have to balance a bunch of unruly players, but the scope was a little bit too big for the time I had. My wife suggested a red panda theme (he likes red panda's), and I ended up incorporating this into stealth game play ripped straight from Metal Gear Solid for the first PlayStation. The story was that he'd been to the zoo and met a new friend there, but he'd accidentally left the friend, so he had to break back in to help them escape. I used old school Super Nintendo looking JRPG sprites that I found online (thank you to the unnamed contributor!). You had to sneak around the zoo's secret underground lab avoiding penguin guards. Each guard had a vision cone and if one touched you, you had to restart the level. You could hold F to "listen" which would turn the music volume down and slowly pan the camera out so you could see more of the map and watch for guards. You had to avoid the penguins by learning their patrol routes, hide in the shadows, and make your way through the maze-like levels to the exit zone. After 4 levels, you reached the end, which turned out to be the red panda enclosure and it's revealed that your friend was a red panda. You free your friend and live happily ever after.
Key takeaway:
This was the first time I'd used Unity's 2D lighting (which as at October 2019 is still rather new) and sprite tile-maps. It was actually the first time I'd created a game with levels, so experimenting with different level designs was fun (all of which I plotted out on graph paper before creating in Unity). I already knew how to use raycasting (a way to detect objects by shooting out imaginary lines and finding out what those lines hit), but I was still proud to get the penguin vision cones working properly. If you were behind a wall and a penguin was looking in your direction, they couldn't see you. Unfortunately, Unity's 2D lighting didn't support shadows out of the box, so the vision cones would pass through walls and make it look like you'd get caught (even though you wouldn't).
This was a gift for my sister-in-laws 21st birthday. The idea was that she wanted to throw the best 21st birthday party ever. She had to balance the needs of her guests with her own needs. It was kind of like the offspring of The Sims, and a survival game like Don't Starve (I actually used a font style from Don't Starve). My mother and father in-law have a huge outdoor area with a pizza oven that my father-in-law made, a "man cave" area with a few computers, a couple of old fridges, a number of benches and a huge bushy area behind it all. This is where the actual party was held, and where the game takes place too. You had to keep the music playing to maintain everyone's fun meter, and also run around collecting peoples favorite drink and pizza orders, find the relevant ingredients, and deliver them to the punch bowl (for drink orders), or your father at the pizza oven (for food orders). This would replenish the guests hunger and thirst meters. The ingredients were always found in the same areas (so you could learn quick routes between specific ingredients), but your guests favorite orders would change each game (to improve replay). While you're running around delivering food and drinks, your energy and fun decrease too and you have to top these up by stopping to eat or dance on the dance floor (all the while your guests are getting more hungry and thirsty). If any 3 meters reach a "critical" state (below 10%), then the party ends and everyone goes home. Again, I used sprites I found online (and again, thank you to the unnamed contributor!).
Key takeaway:
Actually, there weren't too many new learnings. Instead I got to reiterate on a lot of the things I'd already learnt in Quiet Quest (2D lighting and tilemaps). Supreme 21st Shindig didn't have multiple levels, but it did have one giant map of the outside area of my mother and father in-laws house. It was cool to see that I could invoke the look and feel of a real-life location, but modify it in ways that made playing fun.
Overall things I've learnt:
I've learnt a ton over the last few months (to October 2019). Here are some of the things I've learnt in general across all projects I've worked on.
1. I really like making games.
2. UI is hard. There are small details across all aspects of a user interface that you don't know exist until you have to make one yourself.
3. I don't really enjoy polishing games a great deal. If you've ever heard of the 80/20 rule, I can confirm that it applies to game development (or at least, the way I do game development). For those who don't know the 80/20 rule - 80% of the work takes 20% of your time, the remaining 20% work takes 80% of your time. You can get core game play working pretty quickly if you have a specific idea, especially if you're using an engine like Unity, Unreal, Game Maker, or Godot. But I found that making something feel like a "finished product" / "polished" is incredibly time consuming. A days progress can become the answer to the question "What specific shade of grey should this button have when it's disabled?". I got all my projects working with core mechanics in 1-4 days, but it's taken months to get Flippin' Hexes into the exact state it's in now. Admittedly there was a lot of learning involved, but the slow progress has certainly been frustrating at times. Even after the 80% of time polishing, I still can't officially confirm if I've actually learnt how to polish a game. But hopefully I've become slightly better at it.
Things I want to learn next:
There's an infinite number of subjects to learn in game development across a variety of areas, but I can't learn everything at once. So after I've learnt enough of one thing, I have to assess what I need to learn next (hopefully identifying something that's about to become relevant for my current project). So right now (as at October 2019), I'm looking forward to working on developing a few of these skills:
System Architecture
I like coding, and in general I want to improve my coding skills and my ability to architecture systems to make my future projects more maintainable/extensible. Right now, my code is pretty brittle by default and any small change can cause a ripple effect of unintended consequences that breaks everything. I actually spent a LOT of time trying to understand what best practices were to tackle certain problems I encountered. But I think I tried to tackle many of these best practices way too early. I'd get lost in the weeds because there are so many competing opinions out there about the best way to approach a problem (an easy example is the debate around the "Singleton" pattern). It turned out that the best way I'd learn, is to make the mistake (often multiple times) before I could even begin to understand a solution or specific design pattern. Now that I've made those mistakes, I look forward to revisiting some of those ideas I tried to learn before. I'm moving into my next project ready to make a slew of new mistakes that I'll have to improve in the project after that (and so on etc. into infinity).
Shaders
Very broadly, a shader is code that tell the computer how something should look. I haven't played with shader coding at all, but I know it'll make my life much easier if I could write my own.