Spending time "polishing".

It can be overwhelming to sit down and list out all the things that need to be implemented in a video game. I think that’s a wall everyone who pursues game development as a hobby encounters at some point during a project. I hit that wall this morning while working out a list of things to add. Should I start on a combat system for our intrepid player to fight back against the forces of evil? Should I work out a damage system? Add more monsters with unique abilities? Tweak the existing AI? Add fades and transitions between levels and scenes? You get the idea—overwhelming!

Faced with this seemingly unlimited list of tasks, I decided to eschew all of it in favor of doing some video game "polishing." Polishing is an aspect of game development that many hobbyist developers tend to neglect. It’s not as exciting as, say, writing a script that lets the player shoot fireballs or laying out the perfect dungeon level. It’s actually kind of mundane and, quite frankly, boring. Polishing involves playing through the game and identifying areas that lack refinement. These might not break the game or even impact gameplay but still look or feel unpolished.

Things like improper transitions, bad scene lighting, clipping issues, and more are all ripe for the polishing list. Addressing these systematically makes your game look better and, in turn, improves the player’s experience.

My polishing list for today included a couple of common issues faced by hobbyist developers: preventing the player camera from clipping through walls and improving the readability of pop-up windows.

The pop-up windows were an easy fix. It took just a few minutes tweaking the pop-up background in the Inspector to create a nice, black, opaque backdrop. Another minute or two centering the text properly, and the pop-ups looked 100% better. It was a minor adjustment, but it paid off in terms of how polished and professional the game felt.

The second issue, where the 3rd-person camera clipped through walls when the player stood too close, was another story. There wasn’t an easy fix in the Inspector for either the camera or the walls to prevent the camera from swooping outside the level. This was particularly problematic near the perimeter walls, where the camera would clip through and reveal the skybox and other unpleasant artifacts outside the playable area.

It became clear this required a script. I needed to create a camera collision system that could detect obstacles and adjust the camera’s position accordingly. This involved using raycasting to measure the distance from potential obstacles and repositioning the camera to prevent it from clipping through walls and other objects players tend to walk up against. After some testing and tweaking, I had a workable fix that solved the wild camera problem.

While testing the camera fix, I also noticed the scene lighting needed adjustment to create more ambiance. I added some point lighting to better highlight important objects, like those tied to the newly improved pop-ups.

Polishing isn’t an exercise in instant gratification, but it makes any game feel significantly more professional and enhances the player’s experience. After finishing these updates, my son test-played the levels and was amazed at how much better the game felt.

So, the lesson of the day is this: don’t forget to polish your game while you build!

Pop (Ups) Rock.

I decided to take the game in a slightly different direction when I realized I had overlooked a major aspect: the actual narrative. What’s happening to the player, and why would they want to run around in the game to begin with?

My son had an excellent idea: seed the game with loose journal pages that the player could collect throughout the game. These pages would gradually introduce the player to some of the less obvious aspects of the game, while also building the story of why the player’s character is there in the first place. The journal pages could also serve to incrementally piece together the game’s overarching narrative—introducing bad guys, bosses, and maybe even some twists and turns along the way.

Pop-ups are a pretty standard component of video games, but, to be honest, I had never implemented one in Unity before. After some Googling, I figured out how to create the necessary panel game object to make the pop-up work. I added text and a button, then found some loose paper prefabs in a texture pack I grabbed from the Unity Asset Store. After attaching a collider and a simple script, voilà! I was in business.

Well... sort of.

The problem I encountered was that while the pop-up worked when the player triggered the collider, those pesky AI monsters would continue attacking, racking up Madness Points while the player was trying to read. That wouldn’t do!

A little more research revealed that my pop-up script needed a method to pause the game. I adjusted the script to stop game time while keeping the UI functional, so the player could still use the mouse to click the “OK” button and close the pop-up after reading it.

It took some tinkering and a bit of help from ChatGPT, but we finally got everything working. Here’s a screenshot of the first pop-up in action:

It’s not perfect yet, and I’ll probably tweak the settings in the inspector to clean it up a bit more, but it works! This will go a long way toward fleshing out the game and building a solid narrative.

Eventually, I plan to upload all the scripts for this game to GitHub and share the link here—just in case anyone out there might want to peek under the hood of this project. But that’s a task for another day!

It's alive! Well, sort of...

After a couple of days reacquainting myself with Unity, I decided it was time to start creating. I laid out my notes and began by setting up a basic sandbox environment where I could create prefabs and hook up scripts to implement some of the game’s core mechanics.

I started with a simple scene featuring basic obstacles—nothing too fancy. Then, I decided to import Unity's standard third-person controller. I know there are plenty of controllers out there, and I could have opted to create one from scratch, but I actually like Unity's default controller. Plus, it works seamlessly with my USB PlayStation 4 controller, which I planned to use for this game. So, the standard option it is!

After writing some janky scripts (did I mention that C# isn’t my preferred language? I mean, “methods” instead of “functions”? What’s up with that?), I had a character who could walk, run, jump, and was fully animated.

A couple more scripts and a quick trip to the Unity Asset Store later, I had a generic monster chasing my player around. I have to say, the AI script for my monster is probably my proudest Unity moment so far. I managed to make the monster patrol randomly within a set perimeter and then chase the player as soon as it acquired line of sight. I even got the monster animated—huge for me, considering Unity's Animator has always been one of the most perplexing parts of the engine.

My son suggested that the game should feel like a nightmare, where the monsters gradually drive the player mad just by being near them. Think of a nightmare where you feel an evil presence close by—maybe right behind you—and you know that turning to look at it would be your doom. That’s the vibe we were going for.

To keep it simple (at least for now), I decided that if a monster got close enough to touch (collide with) the player, the player would accumulate “Madness Points.” Get enough Madness Points, and strange things would start to happen in the game. Too many, and the player would die. It seemed like a cool and doable mechanic. After a couple of attempts, I had a script that registered Madness Points and displayed them on screen using TextMeshPro.

While working with colliders and triggers, I decided to implement a system where the player has to find and activate a series of floating orbs. Activating these orbs would eventually open a portal to the next level.

Pretty soon, we had a playable prototype where you could run past monsters, activate hidden portals, and progress to the next level. The two levels we have so far are pretty basic but completely scalable. We even added music to each scene for that extra post-apocalyptic meets Stranger Things vibe.

Next on our to-do list:

• A custom model for the player.
• A few different types of monsters.
• A combat system, so the game isn’t just “catch me if you can” parkour.
• Sweet fade transitions between scenes.

Brainstorming 101

 

The most important lesson I’ve learned since getting serious about coding is this: you need a plan. The biggest trap I’ve fallen into when starting a new coding project is not having a clear roadmap for where I want to go and how to get there. I’ve spent countless hours writing what I thought was meticulous code, only to realize I had no idea how to tie everything together or how to implement the components I needed to fulfill my vision.

With that in mind, my son and I sat down over a delicious meal at a local Mexican restaurant to hash out the basics of our game. We brainstormed plenty of ideas, but these are the ones that rose to the top:

• A 3D game.
• A setting in a post-apocalyptic, broken world.
• The player is on a quest to discover who they are and their ultimate purpose.
• Minimal combat, with a focus on puzzle-solving.
• Dark, nightmarish entities that stalk the player.
• A “Madness” mechanic, where the player accumulates madness, which alters aspects of the game.
• A storyline revealed gradually, potentially through finding diary pages.
• The title: "Descent Into Madness."

Based on these factors, I decided to stick with Unity. I had dabbled with 3D projects in a few game jams before, so I felt more comfortable with its workflow. I did briefly consider using this project as an opportunity to learn Godot, but Unity’s sweet siren call was too strong to resist!

After reviewing my notes, I decided the best first step was to create a basic "sandbox" level (or “scene,” in Unity terms). This would be my testing ground to get the core mechanics in place: basic player movement, collisions to trigger events, and a simple AI for some monsters. My goal was to build prefabs and reusable scripts that could be implemented throughout the larger game as we expanded the world.

Time to fire up Unity Hub!

Let's make a video game!

 

Full disclosure: I’ve never worked in any sort of technology field—aside from a couple of awkward years in my early 20s when I worked as a maintenance technician for Digital Equipment Systems, troubleshooting and repairing surface mount technology equipment on their night shift. However, ever since I saved up my money at the tender age of 12 to buy an Atari 2600 video game console I’ve always considered myself a fairly avid fan of all things computers and anything remotely “techy.”

It’s no great stretch of the imagination that during COVID, while everyone else was picking up hobbies like baking sourdough bread and knitting, I took on the seemingly impossible task of teaching myself how to stop passively enjoying computers for entertainment and actually learn to manipulate these electronic magic boxes by teaching myself to code.

I did have some experience with coding in my past. It started with my trusty Commodore VIC-20 and its built-in BASIC interpreter and then progressed to my school’s Commodore 64 during junior high. I enjoyed peeking and poking my way through the numerous magazines dedicated to the burgeoning microcomputer scene of the mid-1980s and even had modest success creating text-based dungeon crawls for my friends to play.

I didn’t do much else with coding until I worked part-time at a community college library during the evenings while pursuing my bachelor’s degree at a local public university. One of the librarians decided the library needed a website (this was the early 2000s, and many organizations were still ramping up their online presence). I had mentioned in passing that I had some experience with HTML. It wasn’t entirely a lie—I had dabbled with HTML and JavaScript a bit during the ’90s—but it was mostly the ubiquitous “Hello World” stuff that many people never seemed to advance beyond.

Long story short, I found myself charged with creating a basic website for the library. After spending numerous shifts Googling and scanning the library’s limited selection of web development books, I managed to pull it off. Afterward, I felt content to leave my coding journey on the sidelines, enjoying games, social media, and general web surfing. Regular “normie” stuff.

That is, until COVID hit.

During the pandemic, I had the wild idea that I could actually learn to code—actively create software and unravel the mysteries of all those binary files people depend on for everything that makes our digital lives so cool. To my surprise, it was easier than I’d imagined.

I started with C++, which probably wasn’t the best choice in terms of ease of entry. Still, I eventually got the basics down well enough to create a terminal-based version of a solo board game I’d designed a few years earlier. Needless to say, I was stoked, though it was far from impressive.

Soon after, I made the rookie mistake of jumping into another language: the much more user-friendly Python. Python was great, and with its plethora of libraries, I quickly figured out how to create simple games with basic graphics. I had finally escaped the terminal!

At some point, I discovered “game engines,” which facilitate game development—a natural focus for me since I love video games. After experimenting, I landed on Unity, which uses C# as its scripting language. C# clicked for me because it’s a powerful language in the tradition of C++, yet it has the high-level syntax I’d grown accustomed to with Python.

Before I knew it, I was writing lots of spaghetti code to cobble together broken games for game jams, swearing under my breath because none of my TextMesh Pro features worked the way I wanted.

Now, here we are.

A few weeks ago, my 13-year-old son—who has diligently absorbed all my knowledge of Star Wars, LOTR, and all things nerdy and cool—approached me with the idea of collaborating on a video game. He had a head full of ideas for a story about a person lost in a nightmarish, post-apocalyptic dreamscape, on the run from dark forces while piecing together the clues of their own identity and purpose in a cold and cruel universe. He would handle the ideas, and I would provide whatever meager technical skills I’d cobbled together to make it happen on screen.

I’m not going to lie—it was one of my proudest moments as a parent. (Well, maybe not the proudest, but it’s definitely up there.)

This “blog,” or whatever it is, will serve as a sort of development log and a place to vent when things don’t go well (looking at you, TextMesh Pro).

So, as they say, the journey of a thousand miles begins with a single keystroke...

---