Hex grid board game based on SVG: planning project structure



I would like to build a turn-based board game on a hexagonal grid field.

At first i was going to use D3, but then i decided to try doing vanilla SVG manually. I intend to have grid elements as Ember Components as SVG elements, e. g.:

UnitComponent = Ember.Component.extend({ tagName: 'cicrle' });

I hope that this will allow me to leverage Ember superpowers on the game field pieces directly, without having to convert Ember flair into D3 calls, and have many small components like UnitComponent, BuildingComponent rather than one monstrous DeeThreeComponent component.

Question 1: is that reasonable? Am i right that D3 would introduce a layer of abstraction that would prevent me from manipulating the board with native Ember powers: components, data bindings, etc?

Even if my assumptions are correct, i still struggle to plan the app structure.

From the user’s perspective, i’m going to have:

  1. The hexagonal grid.
  2. Hexagons: slates representing different kinds of terrain, resources, etc… Hexagons form the game map over the grid.
  3. Game pieces: buildings, units, roads, just like you would do with a real-life board game.
  4. Visual aids. E. g. when you intend to move a unit, the hexes where it can go should be highlighted and the available area outlined.

The result should look something like this (except mine will be flat and simple):

example grid

Currently, i don’t plan any backend. Only the hot seat mode.

On the first stage of development i don’t plan to store turns info. You just modify the board like you do with a real-life board game.

Question 2: which models and components should i create?

I think i should have a model and a component for every game piece. Also, it is confusing for me which logic should go into UnitModel and which in UnitComponent.

Should i subclass different types of units? E. g. SiegeTankModel, SniperModel?

Should visual aids have their own components? Say, i want to display a dashed trajectory that a unit is going to follow. The tragectory will be represented by a bunch of SVG elements. Should they be summoned by the GridComponent or should there be a TrajectoryComponent or should HexagonComponents have the ability to display portions of the trajectory? The latter appeals to me most, but i’m not sure.

How should the methods be directed? For example, when i move a trooper, should he move himself or should he ask the GridComponent to move him? I would like to abstract SVG coordinates: a unit should know the hex he’s standing on, not the x y coordinates of the SVG sheet. I want the grid component to take care of SVG coordinates, not game pieces. Is that reasonable? How should i implement that?