In “What I Learned Making a Video Game,” Rachel Edelstein recounts her journey of replicating the classic arcade game Centipede as a third-year engineering student. With limited programming experience, she navigates the complexities of coding, emphasising the importance of breaking down tasks, coding cleanly, and focusing on foundational concepts. Edelstein highlights the value of starting simple and researching as needed through object-oriented programming and iterative learning. Her insights offer practical advice for tackling overwhelming projects, emphasising the need for clear goals, methodical planning, and a focus on essential principles for success. The article was first published on FirstRand Perspectives.
What I learned making a video game
By Rachel Edelstein
In 1981, the arcade game Centipede was released by Atari, a world leader in the video game market in the late 20th century. Following the same formula as several other famous arcade games of the time, such as Pac-Man and Galaxian, the game involves a moving, player-controlled object (also known as the Bug Blaster) that tries to eliminate the enemy (Centipede) that appears on the screen. The game, as per usual, has several possible outcomes. One such outcome is that the player is destroyed upon being hit by the enemy object. In this case, the player loses instantly. Alternatively, the player succeeds in destroying the enemy object, instantly winning the game. Another outcome exists where the player can advance to the next level by making it to the end of the round unscathed.
It sounds pretty straightforward. Well, to a large extent, it is. But it didn’t seem so simple when, as a third-year engineering student, I was tasked with designing, coding, and replicating a version of it in C++.
With only a little programming experience and basic understanding, this task seemed overwhelming. Slowly, though, the end goal drew closer and felt more attainable by breaking the project down into manageable, bite-sized pieces.
In our version of Centipede, four major components were required: the Centipede itself (the enemy object), which crawled down the screen approaching the player; the Bug Blaster (player object), which moves left and right with the arrows on the keyboard; a field of stationary mushrooms obstructing the Centipede’s path; and the player’s ammunition, specifically lasers, shot using the space key to eliminate the Centipede. The game needed to work in practice and be playable by anyone.
Although the coding wasn’t scary, grasping the tools and new concepts in a relatively short time frame was. Retrospectively, the learnings that took place are valuable in other contexts and can be applied to overwhelming projects.
While most of my learning only happened after the final deadline, prior knowledge of these tools would have made the whole process less stressful.
My number one learning objective is to code ‘clean’.
One of the main goals in coding ‘clean’ is to make the code easily readable, both to others and to oneself, so that it is easy to understand and debug when reviewing it. More generally, good comprehension is important in a project of any kind. My learning here has been to avoid working sloppily to return to it later, as it will only make the project more tedious and long-winded.
Elon Musk once famously shared his two rules for learning, one of which is particularly relevant here. This rule is to build a tree of knowledge. Musk has said that when it comes to learning, one must view information as a semantic tree. The foundation and major theories form the tree’s trunk and branches; likewise, the subtleties form the leaves. Naturally, without the trunk and branches, no leaves or flowers exist. So, to extend the metaphor, ensure a solid foundation before expending energy on the nuances.
Keeping the end goal in mind is a considerable help in staying on track and making consistent progress. So, rather than putting a half-baked plan in place now only to find that it inhibits the final project’s success later, it is preferable to have planned the foundation well.
Object-oriented programming (OOP) refers to the concept where code is written with the intention of layering pieces of reusable code throughout the program. For example, the Centipede would be a suitable object in the game, as it has specific responsibilities that are used repeatedly. One such responsibility would be its need to interact with the lasers shot at it and the mushrooms in its path. Applying Musk’s rule would have meant using OOP from the start, as instructed, rather than trying to piece it together for the final deadline since the OOP concept forms the project’s foundation.
Another valuable lesson I wish I’d known then might initially seem counterintuitive. While one may be inclined to gather all the necessary research at the start of the project, this process has highlighted that it is better to research as you go.
For the Centipede project, the first hand-in deadline required all the students to deliver a game consisting of only a movable object controlled by the keyboard arrows. Doing light research was enough in this case, and soon, I had a purple square that moved across the game screen. Later in the project, I discovered that bonus marks would be awarded for ‘good’ graphics. In other words, having a creative-looking Bug-Blaster appearing on the screen would earn more marks than a plain old purple square.
The positive correlation between good graphics and a higher project mark is more obvious, but this probably worked in my favour. Had I been caught up in sophisticated graphics at the beginning of the project, I might not have had the focus necessary to achieve a moving object. With the mass of information on the internet, it is easy to diverge by grasping too many concepts at once. Instead, a better technique is to start somewhere and fill in the gaps as needed.
Believe it or not, I had a working game: a moving Centipede, Bug Blaster, and lasers. Some valuable knowledge was even accumulated along the way. In short, the lessons I found most helpful were to have a general direction in mind for where you want to go with the project, to code ‘clean’ (in a figurative sense when the project doesn’t involve coding and in a literal one when it does), to focus on the fundamentals, and simply to make a start, rather than trying to gather all the knowledge you think you need at the beginning.
Although these tools might seem too obvious to need explaining, I would have benefited from knowing them upfront.
Everyone has a unique approach to big projects. That said, there are some definite game-changing tools for ‘getting it done’ efficiently and seamlessly. These are my current favourites.
Read also:
- South African flora’s triumphant return to Chelsea flower show – Keith Kirsten
- On a mission to broaden perspectives, build relations, like Madiba did – Judy Sikuza, WEF 2024 Young Global leader
- Obesity is not your fault nor just for the affluent – Prof Carel le Roux, World-leading SA Diabetes expert
