Over a million developers have joined DZone.

''Protect the Square'' and Buggy Games

DZone 's Guide to

''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.

· Performance Zone ·
Free Resource

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.



It offers longer-term enjoyment to me because I can revisit the games, and as my JavaScript skills and hacking skills improve, I can find new opportunities to manipulate the game from within the browser.

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

It can help support learning JavaScript in chunks. You don't have to learn how to write an entire app, but you can patch an existing app with a function when you learn how to write functions. And as your knowledge grows, your ability to manipulate the game grows.

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
  • Looking at the JavaScript and the JavaScript variables.

Messing with these games builds those skills. And, if you usually "trust" a web front end and assume that the JavaScript validation on your site is protection for the serve, messing with these games and apps will disavow you of all those ideas.

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.

From the console, we can pretty much rewrite the JavaScript for any client-side application. 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?

Typical Things

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.

performance ,debugging ,testing

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}