seagreen / depths Goto Github PK

https://github.com/seagreen/fpg-depths/blob/master/src/Id.elm#L6

Here, you only use the State constructor, but you are importing all of them. Being explicit in your exposing makes it more clear what is being used in the module.

CSS Bootstrap is so ugly it makes me cry.

Either

• https://bulma.io/
• https://foundation.zurb.com/

Or my preference

• Start from scratch

Happy to take ownership

Seems like the hex-grid fork is a bit behind the mainline. should we rebase?

• Building descriptions
• Describe what population does
• Scrollable map
• Switch to 'Left click selects' / 'Right click moves'
• Vary what enemies appear, increase them in strength over time.

• You should be able to reflect on your decisions without respect to your opponent. -- @mitchellwrosen

  (This is in the context of making it beginner friendly, so you don't lose if you don't tech up at the exact right time.)

• Beginners, if they don't know what the opponent's doing, will always turtle. -- @mitchellwrosen

https://github.com/seagreen/fpg-depths/blob/master/src/Building.elm#L10

Using Maybe can sometimes hide the domain meaning. Perhaps what you really have is something along the lines of

type BuildingCombatType
    = NotCombat
    | Combat { firepower : Int, sensors : Int }

(those names are bad, but perhaps better than using Maybe)

Or even move this up a ways, so you have a type alias for building stats, one for combat stats, then each building is something like

type Building
    = NonCombat BuildingData
    | Combat BuildingData CombatStats

Just a thought.

• Reduce the initial games choices to (1) attack, (2), defend, (3) expand. Currently we have "expand" broken up into two paths expand outward with colony subs and expand inward with a Factory. This is really hard to balance and shouldn't be an initial option.

• Cap the amount of buildings at each habitat, probably at 3 (not counting the PrefabHabitat which will probably be removed).

• Rework both units and buildings.

• Add hull to ships and give weapons two stats, one for chance of hitting and one for damage.

• Allow having multiple weapons and sensors on the same ship.

• Change stealth to evasion and have it rolled each time a ship is hit to try to dodge it (we might bring back stealth later).

• Show the location of all enemy habitats.

• If you have a ship at an enemy habitat, show all buildings there.

As suggested by jonf on elmlang.slack.com.

It's possible we want to use a type alias for State instead

Players who join after the first two should be treated as observers

This will wait until the mechanics of the game are perfected (#3).

The flow should now be:

• On startup, send a subscribe message.

  { "type": "subscribe", "topic": <room> }
  

• Continue as before with payload messages.

  { "type": "message", "topic": <room>, "payload": <payload> }
  

  The server will forward payload messages whose topic exactly matches any previously subscribed string, without the type tag. They look like:

  { "topic": <room>, "payload": <payload> }