TWiki
> Main
>
DesignAGame
General Guidelines for making a mediascape game
Introduction.
Mediascape games can be conceptually simple like “tag” or “hide and seek” or they can be complex quests such as the kind illustrated in the video Roku’s reward. Whatever the game, the process of mediascape game design is to translate the game idea into a form which the current medium supports and one that will work within the current constraints of the toolkit.
All games have a hierarchy of rule systems: there are the rules of the game itself, the local rules and the wider rules of the culture and society in which the game will be played.
If we take the game of soccer as an example
- The rules of the game are specified in the “rule book” and taught to each player. Game props such as goal posts, corner flags and chalk lines are used to help enforce the rules.
- The local rules take into account the local circumstances such as the size of the area you have to play in whether there enough players for a full team of 11, how long should the game last etc. These local rules are usually enforced by a referee.
- The wider rules take into account local laws and social rules. For example in a non professional game are ball games allowed in this area? In the professional game of soccer there is a governing body FIFA who enforce the integrity of the game across the world.
The point of highlighting this rule hierarchy is to show that much of game play depends on human and social mechanics not just the in-built game mechanics. And so whilst the current mscape platform does not currently support capabilities for devices to talk to one another or for devices to talk to a game server, it is still possible to design compelling and social games that rely on human and social protocols rather than system protocols.
To take a very simple example you could easily turn the stamp the mole mediascape game into a childrens party game just by telling the children where they need to place the mole holes and see who can do it quickest. You could also add obstacles or make them further apart to make it more challenging.
To design and create a mediascape game follow these seven steps.
1. Identify the core game mechanic that you want to use and implement and test that before you design the detail of the game.
Whenever you design a game there will be at least one main game mechanism that underpins it. For example hitting a ball with a racquet, moving a piece on a board or shooting at targets with a weapon. Mediascape games will typically involve movement around an outdoor space and maybe some interaction with the screen.
Mechanics based on GPS and movement.
You should think of your GPS as being like a balloon attached to a long piece of elastic which you hold. As you walk the balloon will more or less track where you are, though it will very rarely be directly overhead and it will also be prone to gusts of wind blowing it about. If you want a game to be based on your physical movement you should let it account for the fact that the GPS will not move as quickly as you can – just like the balloon it will jump and then follow depending if you turn or go in a straight line. If you are basing the game on movement and relying on GPS there are many things to bear in mind.
- GPS needs open spaces to work reliably – and built up areas will interfere with the readings
- Even in an open space GPS can drift. It is dangerous to rely on region sizes of less than ten meters if you need to associate regions with specific landmarks.
- GPS catches up quite slowly. If you run fast it can take a while for GPS to catch up with you.
So if you want to use the simple mechanic of moving between regions to trigger events build and test a prototype first. (Stamp the mole and Doubloons are good mediascapes to try out as they use this mechanic).
Mechanics based on screen interaction.
There are several different ways to create screen interaction.
How to let the user press buttons
You can create simple buttons by adding hotspots to images. They are reliable and effective.
However if you want to display dynamic information like your score, number of things collected etc then you will need to use HTML. Be warned that if you use HTML buttons the action the user needs to make is a quick tap rather than a press. This is because HTML is designed to ignore presses of the screen when the point at which you press on the screen is more than a few pixels away from the point at which you release the press. (Danger UXB uses HTML for screen interaction in the mini games – you should try it out to get an idea of this issue).
Flash interaction.
If you are going to use flash as the front end interface to your game you should try out some simple tests to decide how much of the game logic you want to implement in flash and how much should be done in the maker.
How to use Flash
2. Sketch out the game as a storyboard
Once you are happy with your core mechanic and you have tested that it works you should sketch out the rest of the game design. On paper sketch the series of stages that the game will go through and thus the number of different images that you need to create.
You should also think about the overall structure – if the game is complex make sure that the design can break down into discrete chunks or game segments. Map out the overall design interaction – how people will move from one game segment to the next.
Rich narrative games.
If it is a plot and narrative based game you should write the key elements down. You should also try to break up the narrative into plots and sub plots. These may be levels of the game or different missions. For example in the Tower of London game there were a series of missions and each mission could be designed separately. You should then write the scripts for the main dialogue. It is helpful to write the scripts in a similar style to that of a stage play. Try to keep each piece of dialogue to 30 seconds or less in duration. If you have to stay in the same place for too long people get self conscious.
For each piece of dialogue identify the character who is speaking and how their piece of dialogue gets triggered. It may get triggered automatically after the end of the previous piece of dialogue or it may get triggered by walking into a new or pressing a button. Specify any conditional logic that might be associated with the piece. For an example of a script that we used for the design of the Tower of London game please see this file. *
Polar_bear_script_v3.pdf: Polar Bear Script
3. Record temporary audio and image files
It is a good idea to record all of your scripts in “scratch” form so that you can see how well they play out in the mediascape. You should also create rough images for any of the dialog screens. You should test out this scratch content in both the tester and by walking outside. If you are creating an anchored game then ideally you would want to test it in the real setting. However if you are creating the game a long way away from its real setting you should still test the game in an outside area. To move regions from one area to another follow this link.
How to Move an Anchored Mediascape
4. Develop, test and iterate.
If it is a large game you should develop it in stages and test it as you go. Continue to implement the mediascape in the maker, test it in the tester and copy it to your PDA to test it outside.
5. Create final audio, image and video assets.
Once you are happy with the overall flow of the dialog you should create your polished audio, images and video. This can simple mean re-recording your scripts with your friends and editing them to cut out any background noise, mistakes, umms and ahhs. In mediascapes such as Hidden Danger UXB this involved bringing actors into a recording studio to record the dialog and introduction. A graphics artist created the images.
6. Add final content to the mediascape
The process for swapping out the scratch content for the final content is very easy. Simply right click on the mediascape object and replace the file, this will delete the old file from your current directory and replace it with your new file. It is best if the old and new files have slightly different names for example your old file might be called introductionScratch.mp3 and your new file would be called introduction.mp3.
7. Upload the finished game to the website
Once all the final content is in place you should be finished. Upload your new game to the website.
--
JoReid? - 04 Jun 2007
