Ben's Bug Log

Our Senior Project is quickly approaching its completion, with the majority of important features having been properly implemented and tested, leaving only minor improvements and flourishes to be added. There are still a fair amount of bugs, the type that can only be found through extended gameplay with a curious and watchful eye. Now is a time for reflection and contemplation, looking back on the challenges we both created and overcame.

One of the most difficult parts of the creation process was properly modularizing and dividing the project into reasonable portions. Initially it seemed humongous and daunting, but as a group we were able to cut it into smaller chunks that individuals of the group could take on depending on their interests and strengths. This was particularly challenging for me as I tend to have an all-or-nothing mentality when it comes to development, meaning I often skip over the careful planning that our group has done to make finishing this project seem possible. Thanks to my groupmates I was able to maintain a similar workflow as I normally would without sacrificing quality or acquiring technical debt.

One thing that surprised me with its difficulty was the sound design for the game. I spent almost as many hours searching for the perfect sound clips as I did actually coding them into the game. While there are countless free sources online, it was more challenging that I had anticipated to find audio that matched our desired outcome for the project. For each individual sound effect in ML-Breakout I had selected anywhere from 2-10 separate options that I carefully weighed against each other, eventually settling on the best ones based on numerous criteria, i.e. if it would get annoying hearing it repeatedly, or if it would loop continuously without being disjointed, or even if it disrupted the old school feel that we were aiming for with this revamped retro arcade game.

My favorite technology that my group has been working with so far is easily Unity Hub, which is a desktop app that runs Unity Games that allows for easily editing and testing of code. Changes made locally in the Unity Window can also be included in Pull Requests to make setup and presets much simpler. Once the code has began running, you can pause and inspect different variables and even change them if some minor tweaking is required. It is a very handy tool that helps abstract away some of the challenges that come along with video game development.

The technology that has had the highest learning curve so far has been the ML-Agents training software. It is extremely complicated, the recommended tutorial is around 10+ hours in length for the beginner project. Luckily one of our group members who is more experienced with Machine Learning created a very helpful instructional guide on how to create and train new Machine Learning Models, as well as how to manipulate the reward based on conditionals inside the game’s code. This however, requires a lot of fine tuning and training, the latter of which can take upwards of 30 minutes -> 2 hours to converge (which means the model’s mean reward stops improving and the error rate approaches a constant).

The current best performing models on for the ML-Breakout game are still only as effective as a human player would be on their first few attempts at the game. On an average attempt it will probably clear around a quarter of the available bricks before losing all 3 lives. The models I trained have a tendency to stick to the right wall, often causing them to miss balls that are skewed to the left side and I don’t yet understand why. The machine learning agents are difficult to evaluate, as the resulting “code” from training is not understandable in text form, and each model must be observed manually to accurately assess its competency. We are in the process of making a script to help us evaluate the agents by recording an average score over 10 runs after the training is complete. With the addition of this script and our improving knowledge of machine learning, we should be able to improve the efficacy of the ML-Agents to at least that of the average player by the end of this term.

Clean code means more than just having pretty formatting, it means that the code is structured and designed in such a way that any competent developer can easily understand, utilize, and even expand off of it. While reading an article on Clean Code [1], I read a quote from Martin Fowler that sums it up nicely: “Anybody can write code that a computer can understand. Good programmers write code that humans can understand”. One practice that I want to use to improve my own programming skills is to never include hard-coded values when a descriptive constant variable could be used instead. Numerous times when collaborating on an project I have had to guess and suppose what certain numbers or terms were supposed to represent, even sometimes in my own code from long ago. This leads to wasted time and the occasional erroneous assumption. I also commonly over-comment in an attempt to improve clarity, however sometimes this can have the opposite effect as it clutters the file and can make it more difficult to parse.

Code smells are defined as subtle issues with the code that may not disrupt its function at the current time, but could later lead to issues or confusion that could have been easily avoided. A study mentioned in another article I read from medium.com [2], stated that most code smells are generally present early on in development, often originating from a developer trying to cut corners that inevitably lead to high technical debt in the future. I am personally susceptive to “spaghetti code”, or long sections of code with minimal structure that can be difficult to follow, modify, and/or maintain. Just as my writing is prone to run-on sentences and occasionally poor punctuation, I often forgot to properly modularize my code and neglect to create helper functions that reduce the average line length of my functions. This issue is also present in my code comments as mentioned in the previous section, as I tend to ramble on in my comments and fail to limit them to only include helpful information.

Proper utilization of these tips and tricks from programming professionals will greatly improve the quality of my code, as well as help me grow as a developer. The moral of the story is that sometimes putting in more work in the early stages of development can greatly reduce the overall time taken by the project by increasing readability and reducing technical debt.

Citations:

1. Codacy. “What Is Clean Code? A Guide to Principles and Best Practices.” Codacy, Qamine Portugal S.A., 29 Oct. 2024, blog.codacy.com/what-is-clean-code.
2. Verwijs, Christiaan. “In-Depth: What Scientific Research Has to Say about Technical Debt and Code Smells.” Medium, The Liberators, 29 Aug. 2022, medium.com/the-liberators/on-technical-debt-and-code-smells-ae8de66f0f8b.

My major goal since my last blog post was to add sound effects for the project, ML-Breakout, and I ran into some unexpected issues. I started out by obtaining 3 separate Audio Clips from freesound.org, a great website to find and download audio clips for personal and commercial projects. After I had selected my new sound effects (and given proper credit to the creators via Attribution Text + More in the newly added credits folder), I added them into the game by connecting them to Audio Sources that are attached to GameObjects.

I used these three sound files (.wav files) to give a unique sound effect to each of the three possible collisions, ball and paddle, ball and wall, and ball and brick. I wanted to have a distinct sound for each type of collision so that it provided a more diverse audio experience for the user while also helping identify which surfaces the ball collided with. Next I decided to add sound effects for losing a life, losing the game, and victory (clearing the first level). I quickly realized however, that our game wasn’t even designed to be winnable, as we hadn’t gotten around to programming in a win condition.

Is NewFile new or old?

One of my groupmates had created an alternate version of one of the most important files (GameManager) in an attempt to handle a certain issue differently, and named the file appropriately (newGameManager). However, unfortunately they decided against going with the new version but neglected to remove the new file or clarify which version was current for the project. Since both files were structured differently, I had to add my victory condition and sound effects in separately using different methods, taking double the time that it should have. My group got it straightened out at our next team meeting, but clearer naming conventions or more detailed commit messages could have saved us all a lot of time.

Game Breaking Bug

Unfortunately this was not the end of my problems, as now that I had written a victory condition I actually had to beat the game to verify and record that it worked properly. The game is more challenging than it appears, and a few attempts in I was only a few bricks away from the max score when (like a DVD logo) the ball perfectly hit the top left corner and began to bounce back and forth, perfectly horizontal, until I gave up and restarted the game a few minutes later.

I continued playing only slightly deterred, and began to lose motivation as this bug manifested itself in other ways too, getting stuck horizontal after colliding with the corner of bricks or even getting stuck underneath the paddle. Foolishly I wanted to test and commit this feature before embarking on a journey of bug fixing, but I probably could have saved more time if I started on that immediately.

After many attempts, I finally beat the game and heard the glorious victory music, only for it to be cut short as the Game was set to restart 2 seconds after the last brick was broken, ruining the video demonstration. I shamefully fixed my mistake and eventually I was able to beat the game again and call it a day. While being unable to beat a game that I was actively designing was a little demoralizing, it was an awesome feeling to have the audio effects functioning as intended and see the project begin to come together.

Machine Learning – Breakout

The project that I am working on for my Senior Project is ML-Breakout, where our group is recreating the game Atari Breakout using the Unity Game Engine, this time with a Versus Mode. Additionally we will be utilizing a Machine Learning Tool (most likely with TensorFlow) to allow for an Artificial Intelligence to play as well, both solo and versus another AI or human player. We have completed the requirements phase and have moved into the design phase of the project.

My Responsibilities

Our group divided up and assigned sections of this project based on our areas of expertise and interest. I will be working on the Physics interactions (2D kinematics) as well as the controller input scheme.

The Unity Game Engine has tools to help create a wide range of games, anything from a simple arcade game to a large scale-MMO. For this project I will be taking advantage of Unity’s built-in 2D Physics Engine, which essentially consists of Rigidbody 2D (physical game entities), with their interactions governed by Collider 2Ds (hitboxes/collision radii) and Effector 2Ds (determines the magnitude and angle of forces applied between colliders).

First Roadblock

The first issue that I have run into during the design phase of this project is how faithful to be to the original implementation. The original game ran on simple hardware compared to todays modern computers, so many optimizations were made to reduce physics computations.

For example, you may assume that if the ball approaches the center of the paddle at a 45° angle it will launch at a 45° angle, and you might be right. But what about a 44° input angle? or 43.7°? The original game had a limited number of acceptable angles and would simplify the input angles in order to reduce the computational strain on the machine. The paddle itself was also divided in half, with launch zones favoring angles respective to their sides (i.e contact with the left side of the paddle will give the ball a more left-leaning launch angle). However this was likely done to give the player more control when returning the ball rather than reducing computations. Since the source code of Atari Breakout is not available, the exact specifications of the physics are a mystery.

Figure 1: The above figure depicts the expected launch angle (dashed line) compared to the actual travel path of the ball in Atari Breakout.

Welcome to Ben’s Bug Blog!

Introduction

This b”Blog” will serve as a part of my debugging process as well as being a record of the problems I solve (and the ones that I cause :/ ).  Isolating and correcting bugs is as much of an art as it is a science, but like with most things in life, the easiest way to fix any problem is to avoid having it in the first place.  This is why proper coding practices and maintaining documentation is paramount to writing clean, efficient, and effective code.

Personal Information

I attend Oregon State University in-person at the Corvallis Campus, where I am pursuing a Computer Science Degree.  As of writing this I am 22 years old and have lived in Oregon for the majority of my life, having been born in Arizona before moving after around three years.  Even though my memories from early childhood are pretty vague, I remember being fascinated with Video Games and Computers.  My older sister had poor eye-hand coordination, so the doctor prescribed video games to help her practice and develop those skills.  She didn’t care for them much, but I quickly became obsessed.  My parents attempted to wean me off but it was already too late, and ever since then video games and technology have become crucial components of my life.  

Both of my parents are engineers, so when I applied to Oregon State University I did as a Electrical and Computer Engineering student.  While I enjoyed some of the complex mathematics and logic from that coursework, I had no passion for circuitry, but I immensely enjoyed the programming heavy courses.  Recently I switched my major to Computer Science with an option in Simulation and Game Programming and began my pursuit of a career that I could actually enjoy.

Family and Pets

I have one sibling (aforementioned older sister who lives in another state) who has a cat named Baby Daisy, and my parents who have an amazing Yellow Labrador Retriever named Jasper.

Skills and Interests

• C/C++
• Python
• HTML/JavaScript
• Assembly Language
• OpenGL

I also have experience with Digital Logic Design and microcontrollers due to my history with ECE.  My favorite examples of past projects are creating a visual HDMI connector, building simple ASCII and Simulation Games, and creating Interactive and Traversable One-Page Websites with JavaScript, DOM API, and MongoDB.