Month: July 2018

Preparing for Display

Posted on by kipbrennan

This week we’ve had to take some time off from development in order to get ready for a public showing of Level Squared.

There’s going to be a number of occasions over the coming months where we’ll be carrying out public showings of Level Squared, and one thing that we learned last year is that it is important to get these right.

The absolute worst thing that can happen is having your play test or showing ruined by a faulty HTML cable, or a busted controller or some other peripheral that is entirely within your control (and yes, both of these things happened to us at public tests last year).

These early lessons have possibly left me a little on the paranoid side when it comes to preparing for shows. But after sitting in front of a television for an hour with a flickering, constantly resetting image of our game on it, I’m going to err on the side of caution.

So – here are my guidelines for preparing for a public showing (built up from experience as well as copying from more experienced game developers):

  • Be ready early.
  • Know where you are setting up. Scout out the location well in advance.
  • Know the equipment that you will be playing on. Ideally, all of the equipment will be your own. All the equipment will never be your own.
  • Test everything before any players arrive.
  • Have spares! Spare cables, spare controllers, spare builds on spare USBs. As far as is practicable have a replacement for every single piece.
  • If the area is not locked down (eg, IGDAM) try to get a position that ensures that your screen is facing out into the room/towards the entrance. This will ensure that people will see your game as they arrive.
  • Have something that will draw players towards your station. Posters, lights, sounds etc.

Feel free to steal and adapt as needed!

The event that we are preparing for at the moment is Swinburne Open Day. We’ve been invited along as one of their past success stories to try to get students to pick Swinburne when they graduate from High School. And that suits me, we got great support from Swinburne last year, and it gives us another opportunity for a public showing, for little expense.

Plus they called us gaming celebs:

However, it has meant that we have had to develop a new demo build.

Up to now, this year has been all about developing new content for the game with a view to a full length game. And that doesn’t lend itself too well to a demo. We don’t really want to put a player down in front of two+ hours of content. We’d rather cycle through a large number of players, while still giving them a taste of the full game.

So we’ve made a build out of a selection of levels from the full game which show off all of our new systems and mechanics, while still presenting around 10 minutes of play time. This has also required the development of a narrative specific to this build which is thematically similar to the full game narrative and tone, but delivers a much smaller story within the demo build.

And now that we’ve selected a suite of levels to show off, this week has been all about making sure that build will be stable and solid to ensure that we have a good showing, and that all of the feedback that we get is useful and actionable.

So if you’re free on Sunday 29 July and in the Hawthorn area, and interested in studying Game Development at Swinburne – come and check us out!

QA Passes and Fails

Posted on by kipbrennan

Level building has been a big part of the work that I have been doing lately. But that’s starting to wind down a little now and it’s time to go over everything that has been created and make sure that it actually works!

So this week I’m going to talk a little bit about Quality Assurance (QA), what it is, why it’s important, and how I go about doing it.

QA is the process of internally testing your game to make sure it’s ready for play testing. It is the process of playing through your own work to make sure it is doing what it should be doing. Basically, it’s the same as reading over a piece of writing before releasing it to make sure it’s saying what you mean, and that you haven’t left out any words.

Importantly, QA isn’t the same as play testing. They are two different processes, and they can’t be used in place of each other!

Play testing is putting your game in front of players and seeing how they interact with your game, and whether the systems that you have created result in your intended play. And whether that play is enjoyable.

QA is making sure that the systems that you have made work and have been implemented properly.

One thing I learned last year – if you don’t do QA properly, then you can’t do play testing properly. Because all the feedback that you will get is that the game is broken and that things don’t work. If you’d gone through you would have noticed this very easily on your own. And as a result, you don’t get any useful feedback on how the game makes players feel or if they find your systems enjoyable.

So, to summarise: QA is very important. QA is not the same as play testing.

What I’ve been doing this week, is playing through the levels that we have built and trying to catch and identify as many broken game elements as I can.

That second part is important too. Good QA doesn’t just identify that something is broken. It should really examine the problem, work out exactly how to replicate the problem and make sure that it is clearly documented so that whoever’s job it is to fix the issue can easily re-create the problem and work out what is causing it.

A well-documented QA report can save hours in bug-squishing time by narrowing down exactly where and when a problem occurs.

Here’s one of the issues I found last week. I noticed that in some circumstances, the player wasn’t able to complete projections properly. Instead of a proper projection completing like this:

It was failing to complete the projection, leaving a transparent copy where the projection should had been placed, like this:

Eventually I was able to narrow down the circumstances that would cause this to happen:

  1. The player had progressed to the point that they had learned to undo projections
  2. The player had died at least once within this level.

And from these notes the programmers were able to narrow down the cause of the issue and fix it.

This was something that wasn’t apparent while building levels, and yet would have resulted in a play test being totally wasted as players would have been unable to complete many levels. So it was very good that we found and fixed this!

So that’s a quick rundown on QA. It’s not as glamorous or as flashy as some design work, but it is 100% vital to making a good game.

And I can tell you that it can feel super satisfying to finally work out exactly what is causing your game to bug out at some point and pass on a really good bug report to your development team. And they will appreciate being able to quickly identify and fix a problem too! So everyone’s a winner!