View on GitHub

AsyncRPG

A multi-player turned based dungeon crawler written in Unity/C#

Download this project as a .zip file Download this project as a tar.gz file

What is the goal of AsyncRPG?

AsyncRPG is a my attempt to make a turn based multi-player dungeon crawler 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 on your smart phone when you have a few moments on the bus, or at home on your PC. 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 AsyncRPG?

It's honestly pretty thin right now. I don't even have a good name for the game (AsyncRPG is a terrible place-holder name at the moment). In any event, 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.

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. I'm honestly not sure if this is a good mechanic or not. One of the reasons I wanted to make this game was to see if this method would fix the M.I.A. team mate problem without making other team mates feeling left behind if they didn't commit moves as much. I'm open to suggestions.

What's implemented so far?

Quite a bit. There is a game client, a server, and some tools.

Player Interactions

A player in the client can currently:

Enemy AI Interactions

An enemy AI can currently:

Level Editing

Room layout is done in the Ogmo tile editor. There is markup for:

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:

  1. 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
  2. Run the web service from a light weight standalone web server executable
    • The standalone AsyncRPGWebServer is part of the server project
  3. 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.

What's can I help with?

A million things. Despite everything done so far there is a ton of work yet to do. Here are a few ideas: