dfb / gmtools Goto Github PK

When the user sees the welcome screen (#5), we should:

• use the persist API to present a list of existing boards
• probably have some way to delete and rename a board
• once the user chooses a board, we should:
  • read the board using the persist API
  • pass it to the main board module and have it populate the UI with the board data
  • we also need to modify the current board module to not have everything hardcoded

Instead of having the user click a tile, then select things like its type, then click another one, etc., it'd be better if we give the user a sort of paint brush so that as they drag around over a bunch of tiles, the current style or whatever gets applied to each tile they drag across.

Currently there are 3 main tile properties we need to be able to paint, and each tile can have a value for each of the different properties:

• type: forest, grassland, field, water, mountain, castle (or other inside-of-building)
• lighting: normal, dim, dark
• movement: normal, difficult, unpassable

We'll depict each property in the tile itself visually, but then also explicitly spell it out when you select the tile. So maybe for type we could have a little icon representing each type of ground, for lighting we apply some darkness filter, and for movement we overlay the tile with a hash or X or something. Hopefully at a glance you'll be able to see that e.g. this tile is a dimly lit castle with no movement restriction, that tile is a forest in the dark, etc. - without having to select it to read its properties.

As for how we present this to the user, one idea could be:

• up in the board tools section, have 3 rows of icons for the 3 different properties. Even though they are 3 different properties, only one of all of the icons is selectable at any given time, so if forest is currently selected and you click on the unpassable icon, unpassable becomes selected and forest is deselected
• bonus if we come up with a good hotkey system so the user doesn't have to constantly go back to the list of icons to change tools. One idea: have the '1' key be for type, '2' for lighting, and '3' for movement. Pressing the same key again cycles through the values for that property. For example, if unpassable is selected and you press 1, forest would become selected. Pressing 1 again would select grassland, pressing it again would select field, etc. Variation: when you jump between properties, instead of always selecting the first value for a property, we return to whatever the last selected value was for that property. [no idea if this is a good idea or not]
• once an icon is selected, as you leftMouse+drag in the grid, that property value is applied to all the grid tiles you hit, without affecting the other properties for each tile. For example, if you have a bunch of forest next to a river and you select the dim lighting icon, as you click+drag across those forest and river tiles, they'd remain forest and river like they already were, but for each we'd set lighting=dim.

The overall idea is that we make it as painless as possible to quickly create or edit a board, keeping in mind that a decent sized board may have many hundred tiles.

Also, painting tiles should use the persistence API (once we implement it #2) so that changes are saved. For performance reasons, it'd be good to batch the changes, i.e. instead of calling the save API for each tile we change, accumulate a list of changes to pass to the save API when the user releases the mouse button. As a bonus, this will work nicely with an undo/redo API if we ever get around to making one.

In the board tools/info section, have a button to open a resizing dialog:

• show the current width/height of the board in tiles
• lets the user choose new w/h values (with validation to prevent <= 0 or too big)
• shows a warning if the new size is smaller
• bonus if we can let the use choose where to add/remove space like in most image editing apps:
  

Once the user chooses a new size (vs cancelling), we should update the data structure, store it in the persistence layer, and then load it into the board viewer/edtior

Latest in git has a single grass tile type, so now we can go back and add in more. For each:

• make a cheesy 64x64 image to represent that tile type and save it in public/images
• have that image get loaded by LoadImages
• add a new entry to paintToolRows

For now I think we need:

• forest (a darker green maybe?)
• field
• water
• mountain
• maybe inside a castle?

We don't need anything too fancy, and we also don't want them super detailed because these tiles are drawn underneath units placed on the tile, movement indicators, and lighting indicators.

Adam said it'd be nice if each unit could have a little note attached for it to help the GM remember what it's for, etc. I don't think we need a big text area, so just a text input will do. And let's make it save automatically - i.e. no Save button but instead do an on:blur handler to trigger the save.

1. Place a unit on a tile
2. Use +/- buttons to change the number of hit points
3. Refresh the browser and see that the changes from the previous step are lost.

When the page first loads, we should show a dialog that lists the available boards (#7) and also has the option to create a new board (#6). Currently there is no login screen since we are using local storage.

When the user clicks on a tile in the grid, we should show it as selected (maybe an outline around it?) and then in the tile info pane on the right show info like:

• 0-based x,y coordinates of that tile
• the tile's type, lighting, and movement property values (both visually but also via text)
• what units are currently on that tile

Each unit should have a movement value representing how many squares it can move per turn. As with HP and AC, it should have an editable value at the time of spawn and then be editable after the fact too.

When the user sees the welcome screen (#5) and chooses to create a new board, we should:

• show a modal dialog prompting them for a board name
• prompt them for a board width and height in tiles
• have an ok/cancel button
• clicking cancel should return them to the welcome screen (#5)
• clicking ok should initialize a board, persist it, and then open it (#7)

After placing a unit on a tile, the user should be able to grab it and drag it to another tile, and then both the original and the new tile should re-render accordingly.

Also, on the start of drag, we should probably select the source tile, and when the unit is dropped, we should probably select the destination tile.

We need a way to show a popup modal dialog that blocks other input while the user interacts with it. We could either use an existing third party component library or whip up one of our own quick.

After we do #12 and #20, we should visualize unit movement:

• when a user starts dragging a unit, color differently all tiles the unit can move to
• Adam says diagonal and adjacent tiles are all 1 movement away
• omit any tiles that prevent movement
• for tiles that slow movement, count them as 2 movement points (so the cost to enter is still just one, but it takes an extra point to exit, i.e. an extra point to get to a tile beyond it)
• for now, don't try to enforce movement rules
• once the user stops dragging, remove any movement indicators

Currently you can pan the grid by dragging with the left mouse button, but that won't work once we get into things like painting tile types or moving units. Let's make it so that you instead press and hold the right mouse button to pan.

For the first version, we're just using the browser localStorage for storing the boards and other info. Long-term, however, I'd like to store everything in a remote database. It would be nice if we had a persistence layer/module that initially could be implemented on top of localStorage, and then later we could reimplement it for a remote DB without having to make too many changes to the code. I don't think we need to go crazy and try to make a perfect API that anticipates everything we could want; mostly I wanted it to be somewhat structured like what we'll eventually have so that it takes just some "light" refactoring to switch to it. So maybe something like:

• a db module through which all persistence calls are made
• most (all?) API calls should be async (return a Promise that gets resolved with the results)
• instead of having a generic, low-level DB-like interface, I'm leaning towards having something higher level for now, e.g. ListBoards, GetBoard, UpdateBoard, etc.

(another ticket broken out from #4)

It might be nice to be able to rapidly switch among tile painting tools via hotkeys. One possible way to do it:

• The number keys 1-3 select a tool in the type, lighting, and movement rows, respectively
• Pressing the same number again cycles to the next tool on that row, wrapping around to the front if needed
• Pressing shift + the same number again cycles in the opposite direction

Example: water is currently selected and the user taps '3', so it jumps to the first item in the movement row

Example: water is currently selected and the user taps '1', so it moves to forest (or whatever is next in the tile type row)

Possible variation that might be a terrible idea: when moving among rows, instead moving to the first one, move to whichever one was previously selected on that row.

As with hit points, when you have a unit selected, you should be able to edit its AC (and, of course, those edits should be persisted).

When a user selects a tile we should show which units are currently on that tile. If there are less than 4 units present, an 'add units' button should be enabled. Clicking it opens a modal for selecting the unit type, etc., after which we add it to the current tile, it gets displayed in the list in the tile info, and the tile itself re-renders to show the presence of the unit on that tile.

(this is a ticket broken out from #4)

As with tile types and tile lighting, we need a 3rd tile layer for movement restriction:

• it'll probably work a lot like tile type, where we have an image we display over each tile for no restriction, restricted movement, and unpassable
• remember that we need to display this in combination with tile type, tile lighting, tile selected vs not, and any units on that tile (although for unpassable I'm guessing we don't need to ever display any units, so the image could be a red X icon or something?)
• maybe for partial movement we could do an image that is mostly transparent but a few pixels around the edges show yellow slashes or something (no idea)