What is the goal of Parasite Transmission?
Parasite Transmission is a my attempt to make a turn based multi-player dungeon crawler in VR that can either be played to completion in a single session with friends or a play by notification style akin to "Draw Something". I really enjoy playing dungeon crawler games with friends, but as we've gotten older it's become more difficult to dedicate hours at a time to a single board game. I've wanted to be able to start a campaign with friend, and then "save it to the cloud". Then you could either continue the campaign a move at a time when you have a few moments. If multiple people are signed on at the same time then the game should open up chat and become more real time.
What's the gameplay/theme of "Parasite Transmission"?
The basic idea is that the game is played in a series of tiled rooms inside a dying starship. Each player controls a robot of a specific character class with a finite amount of energy with which to move and take actions. You need to make your way to the room with the escape pod and have enough energy left over to power it.
Game Mechanics
Fortunately, rooms frequently contain energy pods that you can drain on your way to the escape pod. Unfortunately, those rooms also contain enemy AI robots that are trying to compete for the same remaining energy supply. Before energy can be drained from an energy pods, it must be hacked so that the player's team can drain them. AI can also hack the energy the energy pods, taking possession away from your team. Since the star ship is dark and the enemy AI are trying to conserve power they can only see in a limited vision cone when they are stationary (when they move, they turn their vision cone off). They can spot players, other AI, and energy tanks if they pass through their vision cone while stationary. Different enemy AI have different abilities. Some can see better, some can move farther each turn, some can attack harder, and some can drain energy more efficiently, and some can heal other friendly AI. Since the player is controlling a hacked robot, they are subject to the same vision cone and abilities. However, players can also see through security cameras to plan their moves and avoid detection.
Turn Structure
The most important design element to note is that each time a player moves all the enemy AI in the room get a move. Since there is no turn order between the players (i.e. anyone can submit a move whenever they want) you have to be careful about wandering off on your own and getting overwhelmed. However, this also means that you don't have to wait for your friend if they are taking too long to commit a move i.e. the game won't grind to halt if someone disappears on vacation.
Player Interactions
A player in the client can currently:
- Sign in to the server
- Create a game and a character (using terrible temp UI)
- Move a robot through a tile based dungeon
- Hack and drain energy tanks
- Attack other robots
- Chat with other players in an chat window (via an IRC channel connection)
Enemy AI Interactions
An enemy AI can currently:
- Maintain a basic perception model
- Wander aimlessly in a room
- Spot other AI, energy tanks, and players
- Send chat notifications about their perception
- Navigate to, hack, and drain energy tanks
- Attack the player
Server
The server is actually just a set of REST calls over HTTP handled by a web server. The server logic is contained inside a single library. The web service can be hosted in a few ways:
Host the web service inside of an IIS server as a set of ASPX pages
- Good if you want a permanent, robust, authoritative game server.
- Kind of a pain to setup though
Run the web service from a light weight standalone web server executable
- The standalone AsyncRPGWebServer is part of the server project
Host the server inside the client
- When signing in you can chose to launch a server in-process
- You can either play single player this way, or other players can connect to your in-process server
Database
The game state is persisted inside a database. The server currently either supports SQLServer or SQLite databases. If you're running either the standalone web server or the in-process server the database will get setup automatically on start-up if it doesn't exist. If you want to run the server with IIS you have to run a script to set it up. Each call to the web service is wrapped inside a transaction, so you can't mess up the game state if something bad happens. The actual queries to the database are abstracted using LinqToSql as to minimize the amount of database specific code. DBLinq is used to auto-generate the binding classes using a dbml file to define the schema structure.
Log in or sign up for Devpost to join the conversation.