Gemini XIII

Magnificent Desolation

Gemini XIII is about cooperative survival in the depths of space. At the end of the 21st century Earth’s energy resources have been greatly depleted and nuclear fusion is one of the last viable options left to humanity. As a sign of good will between nations, the United States and China have launched a joint expedition to gather Helium-3 from the atmosphere of Saturn.

The game is based in science fact, with all technologies existing in the current day, or currently being prototyped for future use. There is a strong focus on communication between players with realistic movement in space, making Gemini XIII unlike any other game to date.

Production notes

My Role

During the course of development, I acted as Lead Design, Creative director and Technical Game Designer. This meant that I developed the primary mechanics, designed and implemented puzzles, implemented feedback as necessary, and managed the design team. As such I worked very closely with both the art and programming teams to keep the game within budget, and make the game feel as cohesive as possible.

NASA, but better

Early on it was decided that Gemini XIII was going to focus on science-fact instead of science-fiction. This meant that the team had to do a lot of research into NASA’s space program and the International Space Station (ISS). Fortunately, NASA provides a lot of information about their projects, and everything they put out is in the public domain. Because of this, we were able to look at NASA’s current accomplishments and research projects and figure out what technologies we could include as part of the game.

Video Reference

Having videos of astronauts on the ISS was invaluable for understanding the environment that the game would be taking place in. Guided tours allowed us to see the space in which the astronauts lived, as well as how they moved and what systems they relied on in their day to day routine.

Important Video References
Mike Fincke Video Tour: Part 1
Cady Coleman Video Tour


Communication and cooperation
Gemini XIII’s gameplay was built around the need for players to cooperate in order to solve puzzles and overcome obstacles. The player who hosts the game is put in the role of the “Commander”, and has the ability to use laptops and manipulate objects in the environment. The client player fulfills the “Mechanic” role, and uses their multi-tool to make repairs. Players must actively communicate with each other throughout the entirety of Gemini XIII and use their unique abilities to survive in the blackness of space.

Movement in Zero-G
Being a game set in space it was important to have a movement system that mimicked being in a zero-g environment. The regular camera used in shooters that limits how far a player can look in the vertical axis was rewritten to allow players the same degree of freedom that astronauts have.

Without gravity, objects that begin moving keep moving in that direction until they collide with something. In Gemini XIII, this principle applies to both dynamic objects and players alike. Players use a futuristic variant of the SAFER system NASA currently employs, allowing them to propel themselves through space. Momentum they build stays with them, and makes planning out your movement important when trying to maneuver to a specific location.


Because of the cooperative nature of the game, all puzzles that were developed had a lot of extra considerations that are not apparent in single player games. For example, puzzles had to be approximately equal amounts of work for both players. If one player did all the work while the other just sat waiting, the waiting player would quickly become uninterested in the game. Puzzles also had to make sure they used both players abilities, or at least had a few steps that required both players to act.

One early puzzle has players repairing a broken communications antenna (seen above). The antenna can be repaired in 5 steps:

  1. Commander goes into the storage module and grabs the replacement piece.
  2. Mechanic uses the multi-tool to remove the damaged piece from the antenna.
  3. Commander places the replacement piece in the proper slot on the antenna.
  4. Mechanic attaches the replacement piece with the multi-tool.
  5. Both players throw their respective switches simultaneously to reactivate the antenna.

This is a simple example of a puzzle that requires both players to complete, and where both players do about equal amounts of work toward completing the puzzle. A very different example comes later in the game when players are trapped in different locations and must work together in order to reach safety.

Cooperate or die

Players are trapped in separate locations by a dust storm the ship is passing through. The Commander is trapped in the Utility module due to an electrical failure from the storm, and the Mechanic is trapped outside on the solar panel during the storm.

From the inside of the ship, the Commander can rotate specific solar panels so that they shield the Mechanic from debris. Some panels have safety locks on them however and cannot rotate enough to be an effective shield for the Mechanic.

Notice that there is a color code that helps the Commander to move panels correctly, though it does not say which panels are locked. In this example the image on the left has all panels in the starting position, and the image on the right has the Orange marked panels rotated. Notice that one panel is fully rotated, and the others are only partially rotated and cannot be used as shields.

From outside the ship, the mechanic must use her multi-tool to manually override safety locks on the panels, so that they can more effectively be used as shields.

The image above shows panels that are rotated from the Mechanic’s perspective. The panels that cannot rotate fully are clocked by safety locks that can be removed by the Mechanic blasting them with her multi-tool as seen below.


When the Mechanic removes the safety locks the panel can be rotated fully by the Commander. This lets the mechanic slowly move forward one panel at a time.

By working together the Mechanic can gradually make her way to safety inside the ship and free the Commander from the Utility module.


By far the most successful aspect of production was team dedication during the second half of the project. Attendance to meetings was rarely a problem, and there was a skype group created early on that became invaluable for getting in touch with other team members. Whenever a problem arose, there was always at least a few people online that would take some time to look into finding a solution. This frequent communication sped the production process, and helped keep everyone on the same page as changes were made to the overall game. Simply put, this game would not have survived without the incredibly dedication of Team Monster.

Even with such a hard working team however, the game was ultimately limited by the technical restrictions of the free version of UDK. Documentation on the free side of Unreal is not usually available for anything past the basics, and so many technical limitations were not discovered until late in the project.  This meant that a lot of design revisions had to be made in order to keep the game both within the limits of what UDK can do and still true to the original concept as much as possible. That being said, the design team did an great job of keeping true to the original concept and gameplay despite being faced with such hardships.

Final Takeaway
The biggest lessons taken from this project, is that it is absolutely essential to know your teammates, and to know your technology as soon as possible. First semester had a slow start, as many of the team members were not familiar with one another and the team did not work as effectively as it could have. This is probably what led to us not knowing about the technical limitations until late into the project. These limitations took what was thought to be a simple task, and made it the most challenging part of the project.