Description

SoBS has two primary views - planetside and spaceside. Where planetside is a dense packing of tiles, spaceside is more apparently an undirected graph. Here are the components of the graph:

• Planet: A node on the graph, representing an available Planetside. The scenario will technically have moons, but conceptually they are the same in the implementation.
• Lane: An edge on the graph, representing a spacelane by which space units can move from one planet to another.

Roadmap & Implementation Thoughts

The least ambitious goal would be to implement the Spaceside view as simply a sparse Planetside with special rigging for interacting with Planet tiles, just like Fading Suns. That is what this roadmap initially reflects. However, there is a lot of room here to do something new, and some of these options are presented as well. I would say that it'd be better to get the basic stuff done, and then revisit/change/rewrite as desired.

Create a separate issue for each of these as they are begun

• Initialize Spaceview
• Camera Controls
  • Panning
  • Focus On Planet
  • Zoom?
• Display Planets
• Display Space lanes
• Implement Planet interaction
  • Switch to Planetside view on-click
• Implement Space Unit interaction
  • Should units be shown like in EFS?
  • Should units be shown in a UI view, instead of on-map?
  • Make it so players can click their unit, then send them to another planet
• BONUS
  • Have planets orbit sun a bit each turn
  • Have moons orbit their planets a bit each turn
  • ........

Units need to be able to move around on the planet surface. This movement should be able to be queued across multiple turns, take into account movement cost, and whether a unit becomes in the way.

Selection

• Be able to select unit to move (issue #4)
• Enter an 'assign movement command' mode
• Click on destination tile and show the quickest path.
• 'Shift+click' by some mechanism to queue seperate movements explictly ('move here then there')
• Store connective matrix (with edge weights specific to the motion type) with the planet
• Confirm path selection. Store on the unit

Collision

• Only allow selection/ordering of units in stacks under the current player's control
• Route suggested path based on if stacks under other players' control in the way

Function

• Terrain Costs based on movement method
• Units run out of movement points
• Units can move 1 hex (guaranteed) each turn, even if lacking the MP to enter a tile, if at full MP
• Move unit along path as far as planned/able for this turn

There are a couple gamestate mutations that, although pretty innocuous right now living in the Populator and a couple other spots, stop me from claiming a complete seperation of MVC. So, go through each of the following and make a quick little Mutator for each and use those instead of the existing calls:

• Add Player Mutator (Populator)
• Remove Player Mutator (while we're at it)
• Set Player Order Mutator (Populator)
• Set Hex Terrain Mutator (Populator)
• Create Unit Mutator (Populator)
• Next Turn Mutator (GameState & Command Panel)
• Rotate Planet Mutator (Orrery)
• Assign Move Path Mutator (Planetside View)

It would be neat to keep a big list of units, constructions, and player/faction settings in a database (loaded from a serialized save file of course). This way I could load up a view and do SELECT * FROM Units WHERE Planet = 'Foo' to load up all the units on a planet. Would make summary statistics and potential AI calculations easier. I could even leverage a geospatial functionality or r-tree partitioning to implement 'get nearest' queries in the game logic.

Likely would use Sqlite3, since it has some good Lua interfaces available.

Certain space units should be able to land on the surface of a planet from orbit, carrying units

• Dialog confirming a landing
• Load/Unload Unit UI elements
• Conditional check: perhaps some landers can only land on airless worlds, or only on atmospheric worlds

Remote players need to be able to submit orders on their turn via websockets.

Description

SoBS has planets over which players battle for resources, and they do so by interacting with the Planetside map view. The map consists of tiles of various terrain types, linked East-to-West in a regular grid of flat-topped hexagons. Each tile is a stack of sprites, which show units, terrain features, and display elements.

Roadmap & Implementation Thoughts

The ambition with this is very straightforward at this point: remake the Fading Suns planet map view with a couple quick modern conveniences.

• Display Multi-layer Tiles
• Layout a Hexagonal Grid
• Camera Controls
  • Panning
  • Focus on Unit/Tile
• Implement Click-Selection on the Hexgrid
• Display Units
  • Show Unit Sprite
  • Unit sprite should indicate owner, ui selection, and a data field
• Implement Unit Interaction
  • Select Unit
  • Focus Unit
  • Issue Movement Command (Show Path)
• Seamless East-West scrolling

I will need UI elements eventually, and so the simplest one that will test out my view system and such would be a simple overlay view that presents a confirm/abort option with a prompt text that will call one of two callback procedures

• Do the fundamental 'show a box and have parts of it be clickable' stuff, or figure out a LUA lib to use
• Trigger the popup with a keyboard command for now (debug)
• Hookup callbacks to the Confirm and Abort buttons respectively
• Make sure ViewManager is pushing/popping it and disabling the underlay correctly while the dialog is up
• Initialize dialog with a proper instantiator (constructor stuff)

Stacks need to be able to attack each other.

• Allow controlling player to issue an attack command
• Attack resolution code
• Destroy Unit mutator
• Damage Unit mutator
• Attack Stack order
• Show health bar of stack
• Show health bar of units
• Animate the attack
• Validation code

Right now Units have a "foo_layer" member variable for each sprite they are displaying. My draw code then has to call each such variable directly.

Much better would be to maintain an instance table and loop through it. This was confounding me with the old class system I had written up, but the one I've just replaced it with should be more amenable/intuitive for this fix.

What kinds of things need to be processed at the beginning of a fresh turn?

When a stack attacks another stack, it should show a battle view. This battle view shows the result of each assault, units being destroyed, final result, location, and who are the combatants.

• Layout new view
• Show location on minimap
• Show names of combatants
• Show each unit
• Animate & play the result of each event (mutator animations)
• Push & Pop the view appropriately

The View Manager needs to loop through its views from top to bottom in its Mouse* events.

Update: Being addressed by #19

The game will eventually have several planetary maps, a starmap, dialog menus, option menus, construction windows, and so on: all of whose contents will depend upon which player is watching. The notion of a 'view' is needed: a UI element that takes as parameter a game class or two and displays it to the user to interact with.

As it stands, the de facto view is the combination of the TilemapCamera and the Tilemap it is loaded with. This notion needs to be generalized, and handle a typical lifecycle (open, interact, close) for the view, so that I can let the player move across the different views of the game.

The actual UI is left for another time, but the core concept of a view needs to be introduced quickly.

• Create View Class
  • Pause/Stop Updates to Inactive Views
  • Unpause/Activate View when activated
  • Set Model of View (gamestate, or dialog options, etc) to determine content
  • If Needed Rewrite TileMap Camera to Accomodate needed changes
  • Have input handler (potentially as another class? 'ViewController' class kind of thing perhaps)
• Create ViewComponent Class (Subview, basically)
  • Detect which ViewComponent is to receive input
  • Make some quality-of-life improvements to instantiating a view
  • Make View Components dynamically laid out (for window resizing)
• Create a View Manager
  • Introduce some dirty keyboard events for changing current view, for now, until UI worked on
  • Intercept then Propogate User Input (Views should have to subscribe to the Manager to get clicks)
  • Implement View Push & Pop
  • Do rectangular intercept (z-index sensitive) to determine what View receives mouse/key input
  • Implement event bubbling (allow a view to receive input, then pass it to the View rect beneath it)
  • Look at caching/loading views

I need hexagonal tile assets for terrain tilesets. Although eventually there will be several tilesets for planets, right now I just need one unanimated 'Terran' tileset:

• Ocean
• Grassland
• Steppe
• Desert
• Tundra
• Ice

Hexes should be 128px x 111px hexagons (flat-topped hexagons) in a 128px x 128px tilesheet section. Use transparency for space outside of hexagon. top of hexagon should be flush with top of image

How should I show events that happened on other players' turns?

I implemented an undo/redo queue as well as an Order and Mutator abstraction (consult the docs). This is great! However, it means I've undone some prior progress, so some tidying up is needed before proceeding further

• Reintroduce validation logic for moving units into a stack. Right now, movement into an uncontrolled hex is being allowed, and then an exception thrown when trying to move out due to the mixed stack
• Selection logic interacts with undo/redo oddly. Rigorously test: players don't have access to undo/redo, but it is important that the gamestate is not accruing oddness.

Right now all mutations on the MutatorBus get published to memory subscribers. For the ufBot competition (and future multiplayer in general), the game needs to publish events to websockets.

This is the tileset that will be applied to Earth & Moon in the standard scenario once the Sun expands to swallow up Mercury and Venus. It can be used in custom scenarios for very hot, solid-surface worlds.

• Base Tiles
  • Blasted scorching plain
  • Blasted cratered plain
  • Dried Shallow Seabed/ Scorched Mare
  • Blistering Sea
• Land Features
  • Dehydrated Ravine (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • Road (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • Scorched Hills
  • Scorched Mountain
  • Large scorched crater
  • Coastal fringes (N, S, NE, NW, SE, SW)

Some spaceships should be unit transports that are able to 'shoot' a unit onto the surface of a planet without landing, using drop pods.

• Dialog to confirm Drop Pod launch
• Make spaceship 'use up' its supply of drop pods whenever it launches
• Make Drop Pods recoverable from the surface (immobile unit that can be carried back up by a lander back to the fleet in orbit)
• Maybe ([ ]?) make Drop Pods able to reorbit on their own if on a low-gravity planet
• Maybe ([ ]?) give Drop Pods a great defensive bonus while coming down through the atmosphere against Anti-Space defense guns
• Maybe ([ ]?) make some classes of Drop Pods 'stealth'
• Load/Unload Unit UI elements

Blooming Suns is a turn-based game, where each agent (AI or human) takes their turn in a fixed order, finishes, and the next player begins.

The game needs to have the concept of who the active player/Actor is, a notion of beginning/ending turns, and a process to start/notify the next player/Actor.

• End Turn button needs to be visible
• End Turn button should present a confirmation dialog (issue #17 )
• Current Actor object needs to be available to the game loop
• Actor List object needs to be available to the game loop (as well as methods for Adding/Removing actors)
• Begin Turn logic needs to fire for next Actor when the Current Turn ends
• Decide if an Actor/Turn Manager class is needed at this point. If so, implement it or make an issue for it. (Not now: Gamestate will keep track of current player, but not much seems required just yet)

This issue does not cover more advanced considerations such as storing an event log/queue. Once simple turn-cycling is completed...

• Make issue for making Actor Action queues, so they can be potentially be replayed for various purposes (PBEM, reports, AI reactions, etc) (issue #35)
• Make issue for implementing Start Turn logic (issue #34)

At the moment, each Tile has a single Sprite that draws itself. However, we need support for potentially many layers of sprites to exist at a tile, such as terrain features, units, UI elements, buildings, roads, and effects.

The original EoFS game seems to have the following effective layers on world map tiles (bottom-to-top):

• Terrain : The basic, root tile sprite. Water, Grass, Steppe, Desert, Tundra, Ice sprites
• Fringe : Edge decoration. Animated coast lines, terrain transitions
• Feature : Terrain features. Mountains, hills, forests
• River : River sprites
• Road : Road sprites
• Resource : Strategic resource marker
• Building : Constructions. Cities, factories, ruins, mines
• Shield : Shield sprite overlay
• Unit : Unit sprites
• Do basic tile layer graphical support
• Make logic for adding entities at each layer (tile-specific things)
• Figure out best way to handle buildings and units
• Finish #14

When finished, make the following issues:

• Make 'edge' logic for Fringe. For example, a sea hex that has a land hex to the upper right should have that hex-edge show a 'coast'
• Make road & river routing logic. For example, a river hex with river hexes to the NE and SW should show a tile-traversing diagonal river, but a river hex with river hexes to the N and S shoudl show a tile-traversing vertical river.
• Make fog of war issue

Right now I 'require' everything in the main.lua into global scope. It might be nice to revisit this and make it a little nicer.

Right now all the tiles are square and arranged in a hexagonal arrangement. This is just temporary: the tiles themselves will be hexagonal at some point

• Make hexagonal terrain tile assets (just a few for testing). see #5
• Make Tile arrangement algorithm lay out hex sprites edge-to-edge
• Adjust 'tileAt' function to convert screen coordinate to selected hex

Tiles with rivers and roads should link up to adjacent tiles' rivers and rods. For example, a river hex with river hexes to the NE and SW should show a tile-traversing diagonal river, but a river hex with river hexes to the N and S shoudl show a tile-traversing vertical river. This ticket is in the same category as #20: I should expect some crossover.

Logic can live in Populator for now.

• Get some test assets (probably animated coasts would be best)
• Make some "if next to X tile in direction A, put edge sprite Q on edge W" logic based on adjacency matrix. Logic can live in the Populator for now.

The game needs to be able spit out a numerical summary of the current game's 'power' state: who's winning, who has most units, etc.

The game needs an 'Airless' tileset for the many smaller barren bodies in the solar system. These include the Moon, Pluto, and many moons of the gas giants

• Base Tiles
  • Mare
  • Highland
  • Ice flat
  • Salt flat
  • Craterland
• Land Features
  • Ravine (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • Road (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • Large Crater
  • Cryovolcano
  • Mountain
  • Mare fringes (N, S, NE, NW, SE, SW)

Background

At the beginning of the scenario in 5200 AD, Mercury, Venus, and Earth (the latter two in particular) are heavy populated and metropolitan, with lush jungle-y Venus being the Imperial Seat. The current Emperor is of a non-player House and all the player Houses have facilities (albeit few mobile troops) on these planets.

In the second turn, the sun expands and engulfs Mercury unexpectedly, and the stellar turbulence fries space infrastructure all the way past Venus. On the third turn Venus is engulfed and all on it destroyed, including the entire Imperial Seat and the reigning House. Earth starts to fry, and revolts break out as the world begins to wither.

In the third turn, Earth is in deep trouble. Arks and freighters are enlisted to evacuate as fast as possible in the second & third turn, but life can only hold out on the baked planet for two more turns. Player houses can scramble to get their assets off-planet to the outer system, can 'adopt' refugees into their house, and general compete for hearts & minds (for future plans)

In the fifth turn the Regency is put in place, and the game proceeds normally.

Right now the code depends on my diligence/honor to not change the Gamestate directly. Currently I return true references to units, tiles, and such when I look them up for querying purposes. I should investigate making these returned references read-only to and throw an exception if I inadvertently modify them inappropriately (that is, outside of a mutator).

When viewing a world map, scrolling to the left and right should never reveal the 'edge of the world'. Although right now scrolling left & right will loop correctly to the otherside, it is a 'jump' that is very evident by the black unfilled expanse where the world tilemap ends.

Ghost tiles or such would solve the issue

• Figure out approach
• Implement
• Make it specific to planetary maps: space view doesn't need this

The current object system works, but doesn't tend to play well with LUA libraries that I import, which all like to use the : syntax to invoke things. A refactor to match them might be prudent, early in the production cycle. Just because I'm used to javascript syntax doesn't mean I ought to cleave to it in LUA.

In many of my functions I deal directly with a reference into the gamestate. It might be perferable to work in terms of unique identifiers that are used to lookup the game objects rather than passing closured data.

Is this workable?

Tiles aren't much use unless units can walk around on them! The concept of entities that can exist at a tile (and have this membership change potentially, i.e.: when I implement movement) is needed.

• Create basic Unit class
• Implement Unit sprite
• Make Units graphically selectable (click on unit, have it be focused, blink it)
  • Click causes selection status
  • Have unit blink when clicked
  • Have unit be 'focused'
• Have a notion of 'currently selected unit' in game loop

Up to this point, all changes on the game state have been done directly by the UI. This is undesirable for many reasons and further, will hamper my efforts later. Critically, a player has to be shown what happened between their turn, and the best strategies available require that the gamestate preserve a deterministic and replayable history of changes. Thus, I will implement a mutation queue ('bus') and rewire everything to use it.

• Create a Mutator abstraction: an object which can execute and undo a particular gamestate alteraion
• Create a Mutation Bus: it stores a queue of mutators that comprise the History, and can be played through like a VCR tape.
  • Add Mutator
  • Rewind
  • Replay
• Make units have an Order queue, which serve as plannable mutators
• Create redo/undo keystrokes for dev purposes
• Run validation logic on Orders before they are allowed to enter the History
  • Figure out where validation logic truly lives: in UI or on the Order?
• Cleanup refactor ripples #37
• Implement PubSub ([ ]?)
  • Publisher implemented
  • Subscriber objects subscribe
• Mutation Bus Unit Tests
  • Rewind/Replay with 'no history change' condition ensured
  • Seek behaviour works correctly
  • Edge cases (don't rewind past beginniing/end, etc)

It would be neat to have the gravity and atmospheric characteristics of planets have a game play effect

Gravity

• Low gravity worlds could make it so that some units can 'orbit' that can't normally. Ideas might include space fighters, drop pods, jet pack units, certain planes...
• High gravity worlds could cause certain land troops to have reduced movement speeds

Atmosphere

• Airless worlds could make it so that some units can 'land' that can't normally. Ideas might include vacuum freighters, non-atmospheric space craft, space fighters...
• Airless worlds could forbid/require-an-upgrade-for units without spacesuits
• Hostile atmospheres could have damaging effects on certain ground units

The game needs a 'Terraformed' tileset for the terraformed planetsides. These include Venus, Earth, Mars, and some Saturnian & Jovian moons.

• Base Tiles
  • Desert
  • Steppe
  • Plain
  • Tundra
  • Ice
  • Shallow Sea
  • Deep Sea
• Land Features
  • Forest (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • River (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • Road (Alone, and with N, S, NE, NW, SE, SW connection/fringe logic)
  • Hills
  • Mountain
  • Coastal fringes (N, S, NE, NW, SE, SW)

There needs to be capturable cities

Assets

• Capitol
• Factory
• Fort
• Mine

Logic

• TODO

Units, when clicked on the tilemap, should show where they are going, when they will reach, and what they will do when they arrive.

• Implement an 'Order' abstraction
• Implement order queue on each unit

Units should have a 'Spot' attribute, 'Scan Distance' attribute, and a 'Stealth' attribute, and this should determine if you are able to see units at a location and how far Fog of War is turned back. Tiles that are not Visible will have fog of war enabled (a darkening visual effect).

Scan Distance - Determines how many hexes away from the unit is Scannable. Only units in Scannable hexes will have Spot vs. Stealth checks run against them.
Stealth - Determines how difficult a unit to see in a visible hex
Spot - Determines how keen your sight is. Is the attribute used against 'Stealth'

In space, there is no Fog of War, but Stealth & Spot still apply. Every unit in orbit is Scannable by other space units (although must be Spotted to appear). Units in space are not generally considered to be in Scan Distance of the planetside (they don't reveal fog of war from orbit, and planetside units don't see 'up'). However, special space units may be specially allowed to interact with the planetside in ways that ignores fog of war (bombarding obscured hexes, doing directed scans, etc).

The game needs coded the notion of units in a Stack: a general object that has set properties and can be commanded as a gestalt of its units

• Unit membership in a stack (all Units must be in a stack, even if it is a singleton stack)
• Stacks need operations (add, remove, lookup, peek)
• Stacks need Selections (I should be able to select members of the set to create a new stack)
• Selections should be able to be assigned orders (move/attack)
• Movement & Attack should be selection level
• Have Inspector element to select units within a stack
• Preserve selections as stacks/units move
• When selecting a stack, always at least have one Unit selected
• When selecting a stack, select all units that have the same move_queue as the autoselected unit

Right now, on the planetside view and inspector, unit tiles' sprites are offset by magic numbers to center the icons.

Make it not so!

Several planets are not wholly terraformed, or have a remarkable terrain type. This tileset kind of collects all these into one extra 'special' tileset.

• Martian Plain
• Venusian Jungle
• Titan Oil Marsh
• Ionian Sulfur Waste
• Tritonian Canteloupe Terrain
• Plutonian Tholin waste (reddish wasteland)

Tiles should have some edge decoration to soften/transition the adjacent biomes. For example, a sea hex that has a land hex to the upper right should have that hex-edge show a 'coast'. This needs some asset support, but also adjacency testing.

Tiles with rivers and roads should link up to adjacent tiles' rivers and rods. For example, a river hex with river hexes to the NE and SW should show a tile-traversing diagonal river, but a river hex with river hexes to the N and S shoudl show a tile-traversing vertical river.

• 'Coast' logic : decorating edges to transition to different-terrain in adjacent hex
• 'Forest' logic : decorating edges to merge with same-terrain in adjacent hex
• 'River' logic : decorating main bits to logically link to adjacent hex with same terrain aspect
• Test assets

The order queue needs to be robustly represented on the tilemap.

• Associate a sprite to display on a tile for an Order associated with it
  • 'Attack' chevron
  • 'Move' throughpoint (a dot)
  • 'Move' waypoint (an X)
• Display Order sprites on relevent tiles when unit focused
• Cleanup order sprites when/as needed
• Color path based on how many turns it'd take to reach
• Animate unit motion along path (translate sprite. animate sprite for bonus points)

Certain kinds of spaceship units should be able to perform planetary bombardments (attacking planetside tiles)

• Ignores fog of war
• Dialog to select tile to bombard
• Uses standard combat system to resolve