I’ve always dreamed of creating a fantastic space ship simulation along the lines of what I’ve described in my xVRM Manifesto, something I wrote years ago. In the past month, working alongside Kenneth Bowen and Andrew Armenia for my Experimental Game Design class (taught by RPI’s Professor Ruiz), that dream took shape in a project called Atropos.
Inside of a structure best described by Vicarious Visions’ Karthik Bala as a “space shanty”, three players work together to pilot a virtual spaceship through a virtual world. The tactical officer, working at the left console, can fire missiles and lasers, scan of targets, start electromagnetic, biological, and radiological sweeps, and both hail and accept hails from other ships in the game world. The navigation officer, working at the right console, is responsible for flying the craft and has the ability to engage a FTL (faster than light) jump, allowing the players to jump across large areas of space. The command officer, sitting in the center, can monitor the status of the ship and other scan targets via the center, dual screen display, and is responsible for communication with NPCs over the radio (the device with the phone handset).
Overall, Atropos was a major success. We managed to have it fully set up for the exhibition component of the RPI Game Symposium and took home 5th place, as well as drawing a fairly large crowd and running about ten teams of three through our 15-minute mission. Players were instructed to destroy a ‘radioactive asteroid’ in a nearby asteroid field, and were then ambushed by Captain Nagel, a pirate with somewhat aggressive intentions.
We were able to incorporate a few interesting concepts into Atropos that I’ve wanted to try out for a while. We were able to use a number of interesting interface peripherals, such as a flight yoke and two foot throttle lever for flying, a giant potentiometer and lever for firing the laser, a dual-screen CRT for providing ship status and scan information, a radio that players could talk to NPCs through, and a dot-matrix printer (which everyone absolutely loved) for providing a physical copy of mission briefing and de-briefing for players to take with them after the game was finished. By fully enclosing the ship, we had complete control over lighting and sound, which consisted of an incandescent bulb for main lighting, a red CCFL for emergency lighting, and a fairly loud speaker set. When the players’ ship was damaged, the lights would ficker as explosions sounded; when the players were ambushed, they were plunged into darkness as the lights turned off, their screens turned black, and alarms sounded. When players used their FTL drives, the lights would flicker while the screens “glitched”, and our obnoxiously loud and over-phasered warp sound effect played.
In addition to an over-the-top interface and ridiculous special effects, Atropos features absolutely no artificial intelligence or pre-scripted events aside from special effects timelines. As the fourth player, the game master is responsible for controlling all other ships and events that happen in the game, along with improv-acting out the dialogue that all NPCs have with the players. Using video-portraits and creative voice acting, we brought the NPCs to life and held interactive dialogues with the players, allowing us to both immerse the players and give them in-game assistance on some of the more confusing technical aspects of the ship.
Although working with such a large project on a short timeline was somewhat exhausting, I am extremely pleased with how everything turned out, and will most definitely be exploring the simulation-LARP genre much more in the near future.
Download the Atropos GDD
Download Atropos Video Footage
The concept is highly interesting, and it looks like your group executed it very well.
I actually think i have to go and try to build something similar myself, just to try it out.
I like the idea, I think that it had been very hard to make (or am I wrong?). But, if I could, I would build a version where you can fly alone (or with two or three persons), so you don’t always have to be with more people than 1 player and a game master to play it. Maybe a good idea for you?
WOW. I think I could make something like this but would need a bit of help,
Zach could you send me some plans or even just how you used the PCs i.e. code.
Thanks
I will post pictures when im done btw what is pygame
The photo with "ARS-24 Instructions" inspired an idea. Part of the game and challenge could be for the team members to interact with each other, communicating their individual needs and balancing competing desires between players in order to succeed. Before the game each player gets a few minutes to examine their instruction packet for the role they are going to play. For example the Navigator packet lays out the fact that three different navigation terminals exist: ARS-24, automated ARS-25, and enhanced ARS-26. The ARS-24 instructions are even uglier than your original ARS-24 Instructions, requiring the navigator to preform obviously unmanageable calculations in their head in order to set course. Running the automated ARS-25 terminal requires a few very simple steps, taking maybe 10 seconds to set a course or activate an FTL jump. The enhanced ARS-26 is dead-lazy where just click what you want and instantly go. When the players get in game the first thing they can do is buy ship upgrades/weapons/cargo/whatever. When the team launches the space station will radio with an order "Set course and move out, you’re blocking traffic". If the team failed to upgrade from the basic ARS-25 navigation system they won’t be able to move and station command will tow them back in, billing them for the tow and an upgrade to their navigation system (maybe seizing cargo or whatever to cover the cost). If the Navigator failed to tell the commander he couldn’t run the basic ARS-24 navigation system, or if the commander fails to buy the upgrade to solve that problem, then the team gets penalized for it. The Navigator would prefer the enhanced ARS-26 system over the automated ARS-25, and the team would definitely benefit from the faster navigation response, but the commander must trade that off against getting more weapons or cargo or something when preparing the ship for launch.
Another example for team members to interact with each other, communicating their individual needs and balancing conflicting desires, could be done with ship energy. The various player all want to do stuff at the same time during a crisis – firing weapons, moving the ship to dodge asteroids, scanners to detect threats and see what the hell is going on out there, communications to calm a hostile ship or call for help, shields, life support, whatever. The point is that there isn’t enough power for everyone to do everything at once, and the players need to communicated with each other what they NEED to get and what they would strongly prefer to get, and someone has to decide who gets power and decides which player-desires get denied power. Are we going to deny power to the weapons and use engines to dodge asteroids and flee the attacking enemy? Are we going to kill the engines and use weapons to blast incoming asteroids and attack the enemy? Are we going to risk cutting life support for a minute (room goes dark and LOUD annoying sirens) to both dodge asteroids and fire on the enemy?
The general theme I’m thinking is finding multiple ways to give the players conflicting needs and desires, forcing them in their role to communicate with their teammates and to effectively resolve those competing needs and desires. "I’m Tactical officer and I really *really* want to fire my guns, but Navigation is telling me we’re going to hit a planet and die if i don’t give him total power for the engines."
I may be really late to this party, but that really looked like a lot of fun, like a Disney simulation but actually having to do something. With other people. I love the dot matrix printouts.
Maybe this would be a great thing to make for teambuilding courses.