In “What I Learned Making Video Games,” Rachel Edelstein recounts her journey as a third-year engineering student recreating the classic arcade game Centipede. Despite limited programming experience, she navigates the complexities of coding and emphasizes the importance of breaking down tasks into smaller pieces, coding cleanly, and focusing on foundational concepts. Edelstein emphasizes the value of starting simple and exploring as needed through object-oriented programming and iterative learning. Her insights offer practical advice for tackling overwhelming projects and highlight the need for clear goals, methodical planning, and focus on fundamental principles for success. This article was originally published on Firstland Outlook.
What I learned from making video games
Rachel Edelstein
In 1981, the arcade game Centipede was released by Atari, a global leader in the video game market in the second half of the 20th century. Following the same formula as other famous arcade games of the time, such as Pac-Man and Galaxian, in this game, the player controls a moving object (also called a Bug Blaster) that tries to eliminate enemies (Centipedes) that appear on the screen. As usual, the game has several possible outcomes. One of them is that the player hits the enemy object and is destroyed, in which case the player loses instantly. Alternatively, the player succeeds in destroying the enemy object and instantly wins the game. In another outcome, the player can progress to the next level by reaching the end of the round unscathed.
Sounds pretty easy. Well, to a large extent it is. But as a third-year engineering student, when I was given the assignment to design, code, and replicate it in C++, it didn't seem that easy.
With little experience and basic knowledge of programming, the task seemed insurmountable, but by breaking the project down into small, manageable parts, the end goal gradually felt closer and more achievable.
Our version of Centipede needed four main components: the Centipede itself (the enemy object) that crawled down the screen and approached the player, the Bug Blaster (the player object) that moved left and right with the keyboard arrows, a field of stationary mushrooms that blocked the Centipede's path, and the player's ammunition (specifically lasers) that was fired using the space bar to kill the Centipede. The game needed to actually work and be playable by anyone.
While the coding itself wasn't scary, it was hard to understand the tools and new concepts in a relatively short amount of time, and looking back, what I learned there is valuable in other situations and can be applied to challenging projects.
Although most of my learning took place after the final deadline, prior knowledge of these tools would have made the entire process less stressful.
My number one learning goal is to write “clean” code.
One of the main goals of “clean” coding is to make your code easy to read, both for others and for yourself, and easy to understand and debug during review. More generally, comprehension is important in any project. What I learned here is to avoid sloppy work just to redo it later, otherwise it will only make the project more tedious and lengthy.
Elon Musk once famously shared two rules about learning, one of which is especially applicable here: build a tree of knowledge. Musk states that when it comes to learning, you have to view information as a semantic tree. The fundamentals and major theories form the trunk and branches of the tree, and similarly, the subtleties form the leaves. Of course, without the trunk and branches, there would be no leaves or flowers. So, to extend the metaphor, you need to ensure you have a solid foundation before you expend energy on the subtleties.
Keeping the end goal in mind will go a long way in helping you stay on track and make steady progress, so it's better to have a good plan in place than to make a half-baked plan now only to find out later that it will hinder your ultimate project's success.
Object-Oriented Programming (OOP) refers to the concept where code is written with the intention of layering reusable pieces of code throughout a program. For example, a centipede would be a suitable object in a game because it has a specific role that is used repeatedly. One such role is that it needs to interact with lasers that fire at it, as well as mushrooms that are in its path. Applying the rules of masking means using OOP from the beginning as directed, rather than just cobbling together code until a final deadline, as OOP concepts form the foundation of the project.
Another valuable lesson I wish I'd known back then may seem counterintuitive at first glance: while you may want to gather all the research you need at the start of a project, this process taught me that it's better to research as you go.
The Centipede project required all students to submit a game consisting entirely of a moveable object controlled by keyboard arrows by the first submission deadline. In this case, a little research was all that was needed. Soon we had a purple rectangle that moved around the game screen. Later in the project, we learned that bonus points were awarded for “better” graphics, meaning that having a creative-looking Bug-Blaster on screen would get more points than a simple purple rectangle.
The correlation between good graphics and high project ratings is more obvious, which probably worked to my advantage. If I had been obsessed with advanced graphics at the beginning of the project, I may not have had the focus necessary to realize moving objects. There is a lot of information on the Internet, so it's easy to get scattered if you try to grasp too many concepts at once. Instead, it's better to start somewhere and fill in the gaps as needed.
Believe it or not, I ended up with a working game, complete with moving centipedes, bug blasters, and lasers. Along the way, I also gained some valuable knowledge. In short, the lessons I found most useful were to have in mind a rough direction of where I want to go with my project, to code “cleanly” (metaphorically if the project doesn't involve coding, literally if it does), to focus on the basics, and to just get started rather than trying to gather all the knowledge you think you'll need from the get-go.
These tools may seem obvious enough that they don't need to be explained, but it's useful to know about them up front.
Everyone has their own approach to big projects. That said, there are some great tools out there that can help you get it done efficiently and seamlessly. Here are my current favorites:
Read also:
