0.4 Design Pad

Changes and Updates

• 8/1/06 (Aquitaine): Detailed current proposal for Pace & Timing.
• Sept. 1, 2006 (Geoff): Clarified wording.

Outline

This page is a notepad/preliminary design document for the designers to prepare for 0.4, which deals primarily with space combat and ship design.

Current Decisions

• Slow Paced - The combat should be slow faced, to avoid a clickfest. This may mean long tactical combat, but is preferable to clickfests.
• Maneuvering - Somehow, facing of ships and their location on the "battlefield" must matter
• Order granularity - orders must not be too detailed, but also not too generic. Need to strike a balance that hits the sweet spot
• Ordering - Orders may be given at any time (paused or not), and are queued to be processed in subsequent turns
• Simulation - turns play out in real time, executing orders that have been given
• 3D Rendering - Combat will be rendered in 3D. Ships will be represented with 3D models. This does not imply movement in 3D or 2D space; it only refers to representation on screen.

Detailed Discussion

Battle Setting

Summary: Combat occurs only inside star systems, but is a system-wide affair; all assets in a star system should be represented on the tactical map. The defender is able to see the attacker deploy his forces, and the attacker must complete deployment before the defender (to simulate the defender having 'seen the attacker coming'). The extent to which information on the attacker is available to the defender will later be influenced by technology. Although the attacker may designate the deployment of his forces, the extent to which they actually arrive both a) all together and b) in the right place will also be determined by the attacker's technology.

Objectives

Summary: All tactical objectives must be achieved on the battle map if more than one fleet is present. In other words, invading a planet or flying from one stargate to another require resolution on the battle map if there is an opposing fleet (possible exceptions would be allowing the defender to retreat through any stargate other than the one from which the attackers are arriving, and allowing the attackers to retreat through the stargate from which they just arrived). Possible scenarios:

- Invading a planet (attackers provide cover for transport/assault ships or else perform orbital bombardment; defenders either engage attackers or provide cover for evacuation ships) - Transit (attackers attempt to get from point A to point B; defenders interdict attackers or else cause attrition) - Reconaissance (maneuvering a stealth ship past sector defenses/scanners to drop or retrieve an agent) - Surgical Strike (targeting a specific installation either in the system or planetside)

Combat on the battle map ends when one side's forces are all removed from the field. If the attacker does not engage the defender within some (yet-to-be-determined) maximum number of turns, then combat results in a draw. (Yet to be determined: does a draw force the attacker to retreat? Might there be technology to allow a vessel to remain in enemy space without engaging for a few turns?)

Pace & Timing

Summary: Are we looking at a real-time system (RTS) or a turn-based system (TBS)? Answer: A Hybrid. The primary concern with an RTS system is that it turns into a clickfest, a contest of who can more quickly and effectively manipulate one stack of numbers against the opponent's stack of numbers (Example: Empires at War). The concern with a TBS system is that it's too slow and too difficult to capture any real sense of strategy (Example: Master of Orion 2).

The current proposal commits us to hybrid real-time and turn-based engine. Individual turns will play out in real time, but player input, through orders, will only take effect once per turn. During turns, between the times when orders take effect, the player(s) have no ability to alter the outcome of game events (other than orders given before the start of the present turn). Player(s) may request a pause at any time, but pauses only occur and the ends of turns. Current thinking is that a turn should be somewhere between 3 and 5 seconds. (Example: Knights of the Old Republic)

Maneuvers

Summary: Facing of ships and their location on the "battlefield" must matter

Order Granularity / User INterface

Summary: For now, the smallest unit controllable by the player is a single ship. We will revisit for 0.5 the issue of whether or not ships should be able to (or always be) grouped with like vessels (and we will define what a 'like vessel' is).

Orders must not be too detailed, but also not too generic. Need to strike a balance that hits the sweet spot.

Giving Orders

Summary: Orders may be given at any time (paused or not), and are queued to be processed in subsequent turns

Simulation

Summary: Turns play out in real time, executing orders that have been given