''Protect the Square'' and Buggy Games
''Protect the Square'' and Buggy Games
''Buggy games'' can be built on purpose to serve as testing and debugging exercises; see how an intentionally buggy game hones your everyday testing skills.
Join the DZone community and get the full member experience.Join For Free
I recently released "Protect The Square," which, according to my version control system, I wrote on the 2nd of May, 2016. I had forgotten about it.
I found it again a few days ago, and decided to release it as the technical exploration exercise it was intended to be.
This is part of my "Buggy Games" series. These are games which are "hacked together" with little formal testing—just programming and playtesting.
If I spot any defects which don't really impact the main gameplay, then I leave them in to support testing exercises.
I try to approach the games differently from the way I would properly write a game because I want it to be hackable, which means it should be
- Relatively easy to understand,
- Easy to override functions,
- Easy to amend variables, and
- Easy to manipulate.
This is a particularly hackable game. This game is the system under test for a 70 minute 'micro course' for my Patreon Community released in 5 weekly episodes starting on 10th May 2018.
Some Games Are Not Meant to Be Played; They Are Meant to Be Played With
For example, Core Wars. There are many "learn to code" systems where you write code to play the game. I like the notion that the game is complete and we are essentially manipulating it or modding it into something else.
Learn in Chunks
The Skills Translate Into Daily Testing Life
When testing a web app, testers perform many routine tasks, like:
- Observing in the console,
- Looking at the HTML,
- Use the development tools,
- Watching the network traffic, and
Anything that happens in your browser is yours to control, and you learn the skills to interrogate, observe, and manipulate the system you are working with.
Where Is It?
What Should You Use It to Do?
I'm really not going to tell you everything you can do with it or with any of the buggy games.
The process of investigating, exploring and manipulating is too much fun to spoil for you here. I'll happily spoil it on training courses, but not here, but...to guide you on your way, here are some suggestions.
Non-Technical Starting Activities
I try to build the games to support non-technical activities as well.
- Figure out how to play.
- Clue: use the mouse.
- Any obvious bugs?
- Clue: the known bugs do not require any technical knowledge.
- Build a list of improvements.
- Are there any feature requests that you would make for the developer? It is a useful exercise with any system to think through "missing" requirements. And can you make a case for their inclusion, i.e. "why" should someone care?
Are there any risks of this game that would require cross-platform testing?
What risks are there?
Can you reverse engineer a model of what the game is supposed to do?
After this, it tends to get a bit more technical.
You need to know what you are dealing with.
- Read the source.
- Look for anything that provides cause for concern.
- Does anything pique your interest?
- Are there any code comments that seem interesting?
- Using the source, what ideas do you have for manipulating the game?
- Do you understand the code?
- Do you understand its structure?
- Can you see what variables and objects it exposes?
Generally, you want to find out how to cheat: (infinite lives, high score, etc.). And there are usually many ways to achieve this.
Once you find one way to do something, don't stop. Find another way.
And at this point, I'll hand you over to a slide deck with more tips because I don't want to spoil it for those of you who want to play with the game.
Just how far can you push the system?
You can see the "Technical and Testing Challenges: Using the 'Protect the Square' Game" slide deck here.
Published at DZone with permission of Alan Richardson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.