This one is a little involved. To do this you need to:

• Add can-repair (set of armor types) for units types (loaded in unit-types-tx).
• Add repair-other action to :move-attack unit state map.
• Add a unit type that can repair other units (see Elite Command medic).
• Add a function to check if a unit can repair another unit (see check-can-repair).
• Add a function to execute a repair transaction (see repair-tx).
• Add a case to action-tx.
• Add a 'sub' to check whether the currently selected unit can repair the currently selected target (see can-repair? and selected-can-repair?).
• Add a UI event (see repair-selected even handler).
• Add a button for repairing a targeted unit (see faction-actions).

I suggest we call the action :action.type/repair-other-unit and the event :zetawar.ui.events/repair-targeted.

So people can post maps and scenarios in Gists, etc.

Instead of hard coding conditions in check-can-* use state transitions described in unit specs to define available actions.

https://github.com/tolitius/mount

https://github.com/weavejester/integrant

Currently the tests just create a DB connection and use that directly. They should probably create a system instance and pull the connection out of that instead.

Inspect should function like spy, but should take any number of arguments and inspect them all.

See: https://github.com/shaunlebron/How-To-Debug-CLJS/blob/master/src/example/macros.clj

It probably should not pretty print by default. Consider 'inspect-pprint' or 'inspect-pp' for a version that pretty prints expressions and output.

Also consider a shorter name for convenience. Maybe just 'i'???

https://github.com/ptaoussanis/timbre

For picking which unit to build.

Probably rename app component. Considering — ui, client, web, app-ctx, view-ctx

https://github.com/clojure/clojurescript/wiki/Compiler-Options#preloads

The idea here is to support multiple games with different rulesets in the same DB. This isn't all that useful currently, but it may be in the future if we want to support something like an optional Datomic based backend.

Got this suggestion from JP via the feedback form. Should help reduce confusion about when to use the copy link.

This will enable bases that only build particular unit types (e.g. airfields and shipyards).

The current version of posh/q doesn't totally match up against datascript/q. Particularly, it doesn't allow you to use pull inside a query.

I'm curious, could you use Deftrack to write a small wrapper around datascript's q, and get essentially the same functionality as posh -- or is posh's caching or updating much more sophisticated than what r/track would provide?

Could you wrap d/entity with r/track and use entities in the UI, or would that be inefficient.

As the reference AI gets more sophisticated I want to have a "dumb" AI that I can use for testing.

Initially inspired by capturing, which is currently a special case, but could be useful for other states too.

• https://github.com/danielsz/boot-autoprefixer
• https://github.com/postcss/autoprefixer#cli

Currently thinking coordinates (and other details) should be displayed in a status area under the map.

When choosing which new unit to build, it would be helpful to see things like their movement, their range, and any other metrics that affect their performance

I'm curious whether this

(defn e-by-av [db a v]
  (-> (d/datoms db :avet a v) first :e))

Might in many cases be more efficient than this, (even if adjusted to make use of ssolo etc, and why you wouldn't want to do a straight datom search in these cases

(defn find-by
  "Returns the unique entity identified by either attr (for singleton
  entities) or attr and val."
  ([db attr]
   (qe '[:find ?e
         :in $ ?attr
         :where [?e ?attr]]
       db attr))
  ([db attr val]
   (qe '[:find ?e
         :in $ ?attr ?val
         :where [?e ?attr ?val]]
       db attr val)))

• Move DB schema into 'db' namespace
• Move DB utility functions into 'db' namespace

• https://github.com/Izzimach/react-pixi
• https://github.com/lavrton/react-konva

Simplest way I can think of to do this is to have technologies that you buy and units that require those technologies in order to build them.

Setup Tongue to centralize strings and provide support for translation in the future.