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:
- 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
- Chat with other players in an chat window (via an IRC channel connection)
Enemy AI Interactions
An enemy AI can currently:
- 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
Level Editing
Room layout is done in the Ogmo tile editor. There is markup for:
- Tile foreground and background
- Navigable tiles
- Enemy Spawners
- Energy Tank Spawners
- Doors/Portals to other rooms
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
- Good if you want a permanent, robust, authoritative game server.
- Run the web service from a light weight standalone web server executable
- The standalone AsyncRPGWebServer is part of the server project
- 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
- When signing in you can chose to launch a server in-process
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:
- Design
- What are the player character classes? What abilities do they have?
- More fully define the enemy AI types? What abilities do they have?
- Power up / loot design?
- Bosses?
- Hacking puzzles?
- Dungeon Layout
- What are the player character classes? What abilities do they have?
- Art
- Need a real UI
- Using temp sprites, mostly purchased from RPGMaker.
- Particle effects
- Room Tiles
- Need a real UI
- Sound
- Need new sounds for everything
- Need new sounds for everything
- Code
- Get running on the iPhone and Android (sqlite will be the interesting part)
- DB should initialize from imported data, rather then from files.
- UI work
- Effects hookup
- Player interaction (attacks, abilities, etc)
- New behaviors in the behavior tree
- Security (encryption, account info)
- Thread safety
- Get running on the iPhone and Android (sqlite will be the interesting part)