Context. Different settings will have different requirements such as reset features, subtitles and play length. There’s a huge difference between a piece for an exhibition and a permanent installation at a venue.

Immersivity. Consider the immediate context of the piece. Custom controllers and screens can create amazing experiences but will require integration with the software, which isn’t too tricky if it’s thought out ahead of time.

Audience. There may be restrictions on the type of content related to the age or experience of the audience. Some organisers expect all games to be family friendly, but this is definitely not the case (see dildo controller), so double check any audience sensitivities.

Session length. The purpose of the event may help inform the play sessions. An installation in a thoroughfare may require minimal and quick interactions, while an exhibition piece may ask for extended attention.


Top

To explain this concept, I like to refer to this list of One Joke Games by the wonderful V21.

The key here is the moment that a player “gets” the joke. It doesn’t have to be specifically a “joke” either, this extends to all interactive media. When the audience understands their interaction, they “get” the point of the piece. This doesn’t mean the interactions then become less engaging, but it moves the player from feeling apprehensive and confused to feeling confident, and allows them to judge the piece from a place of understanding.

The more complex the work, the more difficult it will be to “get”, so work needs to be focused on simplifying and supporting the point of the piece through mechanics and interactions.

If in doubt, cut it out.


Top

Lessons from mobile games. The average length of time a player would spend on a mobile game before uninstalling it was seven seconds. If they weren’t impressed in that time they moved on. This is identical to games in physical spaces, and the same principles apply.

No options. A new player knows nothing about the piece, so there is no point asking them to choose a character or a difficulty level, they won’t have an answer. Make executive decisions, lead with the best content, and give the player the best experience possible.

Cut fat. Trimming extra features not only streamlines the experience, it reduces the likelihood of bugs in the software, reduces the file size, loading times and strain on the hardware.


Top

It's easy when you know how.If considered early in the process, exhibition builds can be very simple to create. They can serve as snapshots of bigger games or softwares, often showcasing a single feature for feedback and testing.

Timeout. Adding a timeout or idle feature, resetting after x seconds of no input, is vital, as people can stop interacting for a million unpredictable reasons, even if they’re really enjoying it! In fact sometimes you need an "okay stop playing now" feature, otherwise known as:

Kid mode. Kids have no social awareness and will play a game for as long as they’re allowed. If this isn’t desired, consider how to politely move a child on from the game, whether it’s a time limit on interactions or a secret ability for event operators to “finish” a game if they need a child to disengage.

Soft reset.Extra reset buttons and debug features can help the software avoid being closed and opened again. A good example of an important debug feature is a toggle for music and a separate toggle for sound effects, as audio suitability may change during the course of a single event.

Optionless.Ideally the software will launch directly into the piece without dialog boxes or external menus. If these are necessary to change display settings, create a version with the options and a version set to default. Better to have an extra build up your sleeve.


Top

It's important! Playtesting is incredibly vital, I’d say even more so for experienced designers. You simply don’t know how people will interact with your piece, so test often, and with different types of players.

Different contexts. Test different input devices, controllers, keyboards, mice, and note player feedback. Not just feedback verbalised, but the automatic feedback such as how excited they seem, and play session length.

Different people. Test with new audiences. Ask about their issues with other interactive works such as difficulty, colour blindness, dexterity, and note it in relation to your work.

I "get" it. Try give as little information as possible and watch for that “ah hah” moment.

Stay organised. Keep the test builds separate, along with the notes.


Top

Credits. Include a readme.txt in the zip file with the software. Include game credits and the contact details of major contributors. For every contributor that would expect their name displayed next to the work, include their social media or wherever they’d like people pointed to find out more about them.

Display. This doc can also include your desires for exhibition. Some works may be free to show anywhere, some may require permission, some may require fees. It’s best to be specific, but also include an appropriate way for a curator to get in touch about it.
Version. For archival purposes, a folder containing the project file and the version of the software used can be zipped and kept, although it’s not necessary for immediate display.

Loop.bat. Include a loop batch file (see appendix) to assist with crashes or alt+F4’s. This file will automatically re-launch the game if it closes on a windows computer.

Test early, test often. Send it through for testing on the target hardware as early as possible.


Top

This is a simple batch file that will re-open a file if it’s closed.
This method is for windows.

Create a new text document in the same folder as the file you wish to run (game.exe).
Write
:loop
start /wait game.exe
goto :loop

Save file. Edit file name from newtextdocument.txt to play.bat
Windows will ask if you’re sure. Tell them you are.
Run the bat.

To quit, use Alt + Tab to select the loop.bat window and close it.

By adding a shortcut to this file to the startup folder it can be opened automatically on boot.


Top