Agile software development relies on good test coverage, frequent small updates, and CI as core practices. These all break when it comes to web games. Let’s look at these points individually.
Test coverage
I love tests. I love TDD. But once the canvas gets involved things go pear shaped. An HTML canvas is essentially an animated bitmap. If you look at a canvas element in the DOM it’s going to look something like:
<canvas id="game" width="1440" height="764"></canvas>And that’s it. No individual elements are available; no buttons, no positions, no audio. So, how do you write a test for a game that runs on the canvas asserting that firing a canon at a tank hits the tank? The standard answer has always been “You don’t”. Coming from a Rails / Node background I found that shocking.
That;s not to say there is NO testing. But in my experience it has always been extremely limited. Game engines can have tests written for them, which is a great start. But the tests tend to revolve purely around the code, not caring about how a game implements the engine or what happens with the game on the canvas. Quick example:
describe('testing constructor', () => {
it('should set up constructor and emit Events related to Background', () => {
background = new Background(
EE,
store,
config,
displayView,
responsive,
);
expect(ee.includes(Events.SCREEN_RESIZE)).toBe(true);
});
});The usual process is to check public module interfaces and method input/output. No canvas required.
I once worked where we had hundreds (thousands?) of canvas mini games implemented and they went one step further. There was a batch job that loaded the games sequentially, waited for assets to preload, and the game to initialise. If that worked the test passed. Again, the canvas wasn’t used, it was just waiting for certain events to be emitted. It was the only thing remotely involving the canvas in the CI tests.
There are a number of work arounds here. The most basic is logging element positions and bounds and using the logged messages to determine if a test passes. But there are two problems here.
- We need a way to mock user interaction
- Asset bounds don’t reflect bounds or a sprite
I’ve seen a recent development that looks very interesting Caesr. I’ve asked our QA to take this for a spin and see if it looks promising as it may be the answer we’ve been looking for. I really hope it’s going to work with complex dynamic games, not just charts, and come out reasonably priced.
Frequent small updates
OK, this one is pretty self explanatory. It depends on what you’re building. If you’re making something long running, with frequent game updates like Candy Crush, then you’re fine here. But that’s not the world I’ve ever worked in. We create games which are tested then released. The only updates are bug fixes. It’s nothing like a continually updating web site or business app. It’s also pointless to release before we have a completed version.
CI
See the point above. I did work on one location with frequent deploys and CI, but they were almost always either releasing a business logic update to the site, or the occasional new game. Once a game had been released it was rarely touched again except for bug fixes.
Where to from here?
I’m currently putting together the bits of Agile that work in our game dev flow to form some kind of mini manifesto that makes sense in our little corner of the web. I’m looking at ways AI Assisted Engineering could make our game dev flow more fun for the devs and produce better product, quicker, and then posting my findings here. This is my journey log.