The TACTICAL COMBAT
The TACTICAL COMBAT
Ronin battles are fought in castles to determine who will control the castle. The current owner of the castle defends against the attacking party that is trying to win the castle. During a battle, each player actively, but indirectly, controls all of his characters that are involved in the battle. The battle progresses in somewhat-slow-motion real-time, during which the player can at any time give orders to a character. Example orders are:
Some of the above orders are momentary (i.e. change weapons), others are short term (i.e. attack a particular opponent), and others are long term behaviors that last until a new order is given (i.e. hide and ambush). If an order becomes obsolete (like if the character being protected dies) then the current long term order is assumed (or the default).
The battle screen contains at least the following 5 areas:
The Map Window
The map window is the largest part of the battle screen. It shows the terrain around the currently selected character. All activity in that area is shown in real-time in the window. If a character other than the currently selected one appears in the window (due to proximity to the selected character) then that character can be selected by clicking on it.
The Character List
The character list gives the player a quick way to select any character to give orders or observe. When a character name in the list is clicked the map window is automatically updated to show the area around the character. The character window is also updated to show the character’s statistics. The characters are displayed according to which group they belong to (see below).
The Status Message Window
As the battle progresses the player is updated on the status of the battle. For example, if a character dies, surrenders, or is taking heavy damage, an appropriate message appears in the status message window.
The Character Window
The character window shows the statistics for the currently selected character. The statistics include things that are highly relevant to the battle (i.e. damage, inventory), less relevant (i.e. strength, loyalty ), and irrelevant (i.e. shoe size). The statistics can be used by the player to decide on orders for the character.
There are 3 elements that make a Ronin battle especially exciting. The player can issue pre-fab group orders to develop interesting strategies. The characters have unique skills which makes each one have different potential to affect the outcome of the battle. And terrain tiles having different properties create obstacles for the characters.
Group Orders
The characters can be divided into an arbitrary number of groups of arbitrary size. Groups can be issued special orders to support more interesting strategies. Here are some ideas for group orders:
In addition, there are special group-relative individual orders:
Skills
Characters have skills that come in uniquely handy in a battle. Example skills are:
Terrain Elements
The castle view is from the top and is made up of tiles representing terrain elements like:
Throughout a battle, either player can request to negotiate. If the other player agrees then the battle is suspended and the game enters a negotiation phase. Negotiation can involve characters, koku, allegiance, and the control of the castle.
The battle is over when the Daimyo of the castle is defeated or all of the attacking player's characters have been defeated, which means they either surrendered, committed suicide, or were killed or beaten unconscious. The winner can choose to either enlist, execute, or free each captive. Captives by surrender are likely to be obedient but fickle. Those who were beaten into submission could become loyal in time.
Client-Server
The fundamental networking model for Ronin tactical battles is Client-Server. The server part of the program will probably be running on the machine of the player who owns the castle. Both the clients and the server will maintain a complete game state. The server will be the sole creator of events (see below). The clients are the sole creators of orders (see below).
Events
The tactical battle will be based on an event-driven model of activity. An event will have an unambiguous interpretation with regard to the game state. Example events are:
Events are created by the server and sent to the clients. Events are guaranteed to be delivered to the clients, and in order. Both the server and clients update their game state according to the events. The client provides visualization of the events.
Orders
The player controls the progress of the game by issuing orders to characters. Orders are sent to the server; depending on the circumstances they may be ignored or result in the creation of events by the server.
Game State