Brainstorming

altf4 edited this page Dec 27, 2011 · 7 revisions

Rough ideas:

The Gameboard

We are having a discrete gameboard comprised of hextiles. (Hexes not squares) The gameboard is laid out in 2 dimensions, but with a height attribute to each tile. Meaning that the gameboard can have contours (hills, walls, valleys, obstructions, etc...) but each tile can be uniquely identified by just an X and Y coordinate. (IE: No bridges that you can stand both on top of and underneath.)

The art for the finished product needn't look blocky, though. Remember that lots of games actually take place on a discrete gameboard but hide it in graphics well. (IE: Starcraft 2)

Client / Server Architecture

We will have a client / server architecture such that any game will take place with 2 or players as clients, connected to a single server. The server retains the authoritative copy of all units, actions, etc... It also serves as the coordinator of all actions. (Telling when turns are over, etc...)

Note: The server needn't be running on a separate hardware machine. If two people want to play, one of the players can run the server on their machine and also a client. (Though cheating will be possible by the server operator, then. See section: Cheating)

Code Organization

There will be four major components to the code:

  1. Client Core
  2. Client GUI
  3. Server
  4. Common Code

Basic classes and code that are used by both client and server will be placed into a statically linked library (Common Code) loaded into both. The Client Core is implemented as a statically linked library that implements all the functionality that the client needs to play a game and communicate with the server. The Client GUI is the graphical representation of the game which makes API calls to the Client Core. The server is where the game is actually "played", as well as all networking necessary to set up matches, find matches, etc...

Fog of War

We should include an RTS-esque Fog of War concept. This would distinguish the game from other TRPGs, and also introduce an element of strategy. Not knowing all of your opponents movements and positions adds to depth by:

  1. Making information gathering a risk/reward tradeoff. It will cost you resources (units, health, energy, time, etc...) to gather information which may or may not be valuable. Knowing when to gather intel is a big element to strategy.

Game Time

A very simple game engine to create would be one similar to that used in FFT. There is a single game timer that runs on the server, which ticks off game time. Every action is then scheduled on the server according to the game clock.

Every action (and unit) has a speed value, the higher the better. An action gets scheduled by initiating its charge. The server maintains a list of both every scheduled action, their speeds, and the total amount of "time" spent charging that action. An action becomes triggered when its "time" total breaks 100. (Or some other value)

The game server processes a round by:

  1. Adding the speed value of every action to their current totals.
  2. If any action's total is greater than or equal to 100, trigger that action. (Break ties as appropriate)

Then keep looping through rounds until some victory condition is met.

A realtime element can be added to this mix by having the game server not wait for user action to proceed. Thus, when it is a Unit's turn to move, the server makes note of it and allows movement of that Unit. But it will also continue to process clock ticks.

Cheating

One of the problems that many multiplayer games such as Starcraft have always had is cheating with things like map hacks. This is all due to their architecture design. Map hacks are possible in Starcraft because the game client receives all of your opponent's movements and positions, but doesn't display them on the map.

All you have to do to make a map hack is listen to the network packets as they come in to your computer. Or look for the data in the program's memory. It's a really easy hack.

We should not make the same mistake, and design the architecture such that clients are only sent information that the player should know. IE: Never send any data to a client that you don't want the player to see. Being turn based, this is a significantly easier thing to do than in a real-time game.

The game server is the software which runs the authoritative version of the game. Each client merely runs an incomplete version at any given time, using whatever information is available to that client. This means that whoever has access to the game server can cheat in essentially any way. For this reason, running the game on a neutral 3rd party machine is probably preferable.

Asymmetric Victory Conditions:

A match consists of two or more teams (which consist of one or more players). It may be interesting to enable asymmetric victory conditions. IE: Team A wins if they eliminate all opposing units, and Team B wins if they occupy a particular space for more than 5 turns.