As some of you may know, I have been spending the past half year or so learning the basics of game development. As a lifelong gamer, game design has always been something that interested me and I wanted to submerge myself in all aspects of game development just to get a better idea of how everything works. The ultimate goal is to create a full working game, no matter how small, by the end of 2022. It’s a lofty goal, but one I fully intend to hit.
I spent the final four months of 2021 doing tutorials daily and learning the ins and outs of Unity, a popular and powerful game engine that just happens to have a free version for those getting started. I quickly learned a lot of basics and started to get some fundamentals engrained on how to make a video game. I could almost call myself competent on a very beginner level.
As a 36 year old that has been long out of school, learning any skill is incredibly difficult. A lot of repetition and practice is required for me to maintain any knowledge, but I did my best to power through. By the time four months had passed, I was absolutely sick of tutorials and ready to move on to trying to create my own thing. I went in to my first project knowing that failure was not only possible but probable. I did the research to try to learn where people go wrong and better prepare myself to succeed. I went in with the knowledge, but still ended up making a ton of rookie mistakes. This article is here to document a bit about this first project attempt.
For years, I had kept a notebook of game ideas just in case some day I wanted to do something just like this. I chose a project I felt was pretty basic and not my best idea because I knew my first project would end up being pretty amateur and rough. What spawned out of that idea was an entirely different idea than I had set out to create.
The original idea was pretty simple. A clicker game. For those not in tune with the clicker game world, this is a concept that basically wraps around clicking on things, getting “currency” of some variety, and then buying upgrades that make the clicking happen faster and more automated. It’s a game that over time plays itself and is all about watching numbers increase. A ton of games use this formula on a fundamental level and it seemed like an easy thing to create. I’m not one to just copy ideas, so I felt like it needed my own spin on it.
This was the first mistake – trying to go for something a bit larger.
I wanted a game that revolved around a Windows 98-esque operating system from back in the days where downloading a file on Limewire was like a weird game of Russian Roulette where you might just end up with a nice little virus. What about a game that encouraged you to just infect your computer as much as possible – clicking on endless popup ads and installing viruses to beat a constantly evolving antivirus system. Not only is it a hard concept to follow, it was also a hard one to really pinpoint a structure for. While the original concept had a bit more to it, this was the heart of it. I’m only going to explain this much because it really isn’t important and the game I actually ended up making wasn’t even this. In order to get to that point, I needed to create a fake OS and that’s really what this story is about.
For the past month, I have been creating a shell of an operating system. Of course, this wasn’t a real operating system – it was just the smoke and mirrors version of one – the kind that makes video game development exciting. You don’t actually need to make the operating system, you just have to make enough that you can pretend to have made an operating system. I decided to make a new game concept around this, which I gave the name Microproccessing, that was narrative based. A kid freshly off to college gets their first computer, but everything ends up being a bit of a scam. Their brand new computer is loaded with a barebones trial version of an operating system that just constantly wants to be upgraded in order to see “full functionality”. A lot of the concept was based around my high school years – the idea of being new to the Internet and spending your time trading files with friends. I won’t go in to the whole narrative because I did actually storyboard a pretty large story and I may pull parts of it for other projects in the future, but the core of it was you would get emails from an old friend sending you little games he was making on his super powered top of the line computer. The gameplay would eventually build up to installing a virus which would then segue in to the actual game idea. It was a bit of a prequel demo.
This game idea was a way for me to make a bunch of small microgames while making the actual operating system core. This idea would accomplish three things – it would let me play around with a lot of small ideas, it was a narrative excuse for my absolutely terrible artwork that I was churning out, and it let me try to tell a story from start to finish – something I don’t know if I’ve ever actually attempted to do as an adult.
Initially, things went fairly well. It was easy to make a mockup of an operating system with primitive shapes and just kind of lay things out.
Nothing here was too fancy, just the basics being laid out – some nonfunctioning audio buttons for muting and volume control, a few white boxes to represent icons, a quickly drawn wallpaper, a launcher menu that opened on a click. The only new concept to me here was pulling in the time from my system clock which oddly enough serves as a good timestamp for all of the images you’ll see here. As a beginner, this project took me a long time to progress through (working on it for a few hours most days) because it took me many tries on a bunch of things to just get them functional.
While I have almost daily gifs showing the progress, I’ll just highlight a few here because some of the daily advancements are pretty boring.
Here is one from day 9 – it’s showing off a few different things. I had made working icons that linked to task bar icons. I had created an animal theme to the OS – something I thought would be easy to show the differences in different versions. SlothOS was this which was the basic entry level of operating systems from a company called Fauna Software and CheetahOS was their top of the line model. Yes, in retrospect I’m starting to realize this is all pretty cheesy. At this point, I also had opening and closing windows, a filler installer bar – actually a lot going on because of how early in the project this was.
By the end of the second week, I had gone as far as to have more task bar functionality, moving windows, and proper overlapping for active windows. Little did I know there were still major bugs that were found right after this. The UI elements, specifically the slider bars of the settings menu, were constantly proving to be the bane of my existence. They always wanted to be in the front no matter where certain windows were. I absolutely hate canvases and text functionality in Unity and while I have learned to deal with them, I still don’t have a full understanding of them.
This gif specifically shows the weird things that were happening frequently before I solved some major bugs. A lot of issues are solved by using the Z axis instead of relying on sorting groups and drawing layers. Even though it is a 2D game, this shows a little bit better how that works.
Seeing 3D representations of 2D games really can show you a lot about the tricks of game development. This stuff can be pretty annoying to someone trying to learn the craft, but it’s also extremely fascinating. It never gets old hearing the stories of how certain things in the video games you love actually work.
By the end of the third week, things were starting to feel a bit nicer. I made a whole drag and drop system with icons that locked them on to a grid and made sure they couldn’t overlap with each other. There’s a lot of hidden details at work here including different levels of highlighting, a physical grid that appears on dragging, and an overly complicated system of tags that makes sure things don’t mess up. Remember this concept of tags because we will be talking about it later on.
At this point, I had working installers that would add icons to a start menu. I even made a new wallpaper and had the settings menu let you select between them.
A trash system was one of my first hiccups and I actually ended up just making a weird thought bubble system because I was struggling so much to make a traditional feeling trash can. Dragging icons across the desktop was one thing, but dragging them to and from an active window was just not working whatsoever. The temporary error message was part of the narrative, but also a way to prevent icons from being deleted forever.
Oddly enough, I think the most fun I had with this project was making this tiny little install bar feel like an actual installer. I wanted to fully randomize it, but I couldn’t quite figure it out so instead I did a bit of trickery. I made five different install animations that would be chosen at random and then made a variable that determined the speed at which the bar would fill. Nothing too complicated, but really fun to create for some reason.
Once the OS was mostly complete, I started making some little games – this one was a Rock Paper Scissors game that would speed up with each round. I never got around to balancing it, but it was actually pretty fun to play and would get really challenging and become a bit of a reflex game. The best part of it all was, even though it was simplistic, I completed it in probably 48 hours.
There’s a ton of functionality that works in this project that I won’t cover here, but I’m for the most part happy with the work that I got done. Once I started working on the core app, the email client, the game really started falling apart. The biggest issues ended up being the actual code this was running on – it was getting messy and heavily relied on using Unity’s tag system which I’m quickly learning that string references are a good way to get in to trouble fast.
I ended up spending days just trying to figure out my code as the project got bigger – for every problem I fixed, two more would spring up in their place. The project was growing to a size that I was struggling to keep up with which is the core of why this project failed – scope.
I was actually worried about scope from day one, but I somehow convinced myself that this project would be pretty easy. I have now learned that trying to replicate something that people use on a daily basis is a good way to get in to trouble fast. Expectations of the way an operating system should feel are hard to hide when they just don’t feel right.
My system had no way to maximize windows because I just didn’t have the technical abilities to get it to work.
My system had a lot of bugs that had to do with double clicking because, well, teaching a computer what a double click is can be surprisingly difficult.
My system required tons of extra scripts and colliders to tell when a program was active and when a program was no longer active. Every click had to be processed by whatever was actually being clicked and because I did not (and honestly still don’t) understand how raycasting works, this was more trouble than it should have been.
There surely was a better way to handle a lot of these problems, but as a beginner programmer I got quickly lost in the weeds and couldn’t find my way out. What this really boiled down to was that I was constantly feeling frustrated when things didn’t work and for every solution I would look up they’d be full of high level technical speak that I was not following. The hardest thing about learning programming isn’t something that just comes with practice – you have to know WHAT you are practicing too. I could do things the wrong way for years and unless something tells me the better solution I will never figure it out on my own. This kind of learning comes from experimenting and trying new things.
I began this project trying to have fun and learn a new skill and once it became overbearing and frustrating, I decided to take a step back from it. This is not me giving up on programming, this is me taking what I’ve learned from this project and applying it to a new, smaller project. If that one fails, you’ll see a similar article – but this one is a much smaller scope that I already have storyboarded and mapped out in full. I begin development on it this weekend and I am very excited to see what becomes of it.
I’m going to release a game by the end of 2022 and hopefully it’s something you can all play and enjoy.
The key takeaways from this botched experiment that I will be using in my next game:
- A fully fledged and planned out concept from start to finish.
- Force myself to comment out more of my code so I don’t get as lost.
- Refactoring code along the way to make it easier to read and remove components that are no longer needed.
- A small project with a scope that doesn’t grow until the original concept is finished.
- Figuring out an art style that works for me and I am happy with.
- Not being afraid to experiment and then reverting if things don’t work out.
Hopefully next time you hear from me I’ll either be releasing this game or moving on to the next concept. Thanks for taking this journey with me.
If you’re interested in more regular updates, I post daily on http://www.twitter.com/brakthedev.
braktheman 
2 thoughts on “The Story of “Microprocessing””