TLDR; Some games are not meant to be played, they are meant to be played with.
I recently released “Protect The Square”, which according to my version control system I wrote on 2nd 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 for.
This is part of my “Buggy Games” series.
These are games which are ‘hacked together’ with little formal testing – just programming and play testing.
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.
- relatively easy to understand
- easy to override functions
- easy to amend variables
- easy to manipulate
This is a particularly hackable game.
Some games are not meant to be played, they are meant to be played with.
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, do you routinely:
- observe in the console
- look at the HTML
- use the development tools
- look at the network traffic
Messing with these games builds those skills.
And, if you:
- ‘trust’ a web front end
Messing with these games and apps will disavow you of all those ideas.
Anything that happens in your browser is yours to control, if you learn the skills to interrogate, observe, and manipulate the system you are working with.
From the dev tools we can pretty much change all of the HTML, forms, and information sent back to the server.
Where is it?
You can find the game here:
Or as part of the downloadable “Evil Tester’s Compendium of Testing Apps”
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
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?
Protect The Square and Buggy Games