Oh, sure, random number generation is a cinch with computers, but try to explain to an opponent that you aren't cheating when your "dice" keep coming up favorably.
I'm working on a director file that tries to simulate a couple other things inherent to dice...throwing them, for example. Again, a lot of this is trying to build an illusion of control, or dressing up a game of chance. Plus, the dynamic nature may make it a lot more fund than clicking a button and recieving a number.
I'll see if I can embed a .swf file of the program in a future post.
This project will take the form of a rather simple arcade game, reminiscent of Pac-Man or Dig-Dug. The player must navigate an area while being chased by antagonists (referred to hereafter as “zombies”). The twist is that the player does not use a keyboard or joystick to navigate, but their actual, physical location. After all, if joysticks connect to the serial port of a computer, than why not a GPS receiver? A player’s position, direction, and speed can be determined by such input, making the GPS functionally equivalent to a joystick or mouse in the context of a game.
The initial setup will involve a GPS receiver connected to a portable computer, probably a Tablet PC. The player will be able to look at the computer display to see their location in relationship to the “zombies”. The zombies, in turn, will have rudimentary follow behavior, and hunt down the player. The zombies will not be hampered by terrain (unlike the player). Since the only information necessary to play the game is the player’s position and possibly their orientation, the game could theoretically be played anywhere that can adequately receive GPS signals.
An alternative setup may forgo the visual display and instead have the player wear headphones, being only able to hear the zombies. Stereo panning and volume of sound could determine direction and distance. Another alternative to a tablet PC could be a PDA, although development on such specialized platforms could prove problematic.
Details of actual game play will change as the potential and limitations of the hardware, not to mention balancing factors of the actual game, are learned in field-testing. Obviously, many games could be made using this interface; a standard chase game could be expanded if time and hardware qualities allow.
Schedule:
Week 1: Develop method of parsing GPS/Serial data
Week 2: Integrate Parser with graphical interface. Field test.
Week 3: Fine tune physical setup of hardware devices, Start including game elements.
Week 4: Build in/test game play elements and game balance.
Week 5: Continue testing game elements.
Week 6: Polish interface, finalize.
To those of you who heard my idea for integrating interaction into a narrative, not a week goes by before I find they're stealing my thoughts!
It was bound to happen, of course. A lot of the ideas thrown around in class are actually present in the game, like dead players converting to zombies. Penny Arcade has a comic depicting a variant of the sort of infighting I would like to encouraged between players, keeping with the zombie genre. Of course, when you apply adventure game logic, this infighting ends up like this. THIS is why these guys are doomed, not the slow moving living dead. Nuh uh. Heh, they even mentioned a gemstone, the universal skeleton key of adventure games.
To those who I talked to last night about mobile input...the Director serial Xtra I just downloaded can read in serial data. This includes the Garmin GPS.