Summary

Imported character and monster files often contain only partial information about powers. Details regarding attack bonus, defense and base damage can usually be extracted, but additional effects are generally restricted to URL links in the file. A means of injecting missing rules for powers is required.

Implementation

The file character-details-page.js is responsible for laying out all of the powers for a character in tabular form, and serves as a convenient location for refining rules. For each power, there is a core set of attributes that must be set. A check can be performed to add an appropriate icon to any power that is incompletely specified. In addition, an edit button can be inserted to modify/clarify a power.

From a cursory look over the player handbooks, it appears that most of the missing information can be filled in quickly by making a few selections from combo-boxes. and filling in a few input fields. A description field would also be nice for the user.

A small percentage of powers contain rather unusual effects. In such cases, it might be necessary to mark the power as requiring DM intervention.

/home/rob/Documents/dungeon/server/client/js/dungeon-common.js:140
this.characterPlacement[eventData.character].condition.stats[
^
TypeError: Cannot read property 'condition' of undefined
at Object.processEvent (/home/rob/Documents/dungeon/server/client/js/dungeon-common.js:140:53)
at Object.eventReceived (/home/rob/Documents/dungeon/server/server.js:102:14)
at Socket.$emit (events.js:70:17)
at SocketNamespace.handlePacket (/home/rob/node_modules/socket.io/lib/namespace.js:335:22)
at Manager.onClientMessage (/home/rob/node_modules/socket.io/lib/manager.js:468:38)
at WebSocket.onMessage (/home/rob/node_modules/socket.io/lib/transport.js:387:20)
at Parser. (/home/rob/node_modules/socket.io/lib/transports/websocket/hybi-16.js:40:10)
at Parser.emit (events.js:67:17)
at /home/rob/node_modules/socket.io/lib/transports/websocket/hybi-16.js:289:16
at Parser.expectHandler (/home/rob/node_modules/socket.io/lib/transports/websocket/hybi-16.js:300:15)

Summary

When controlling a lot of characters combat is very tedious. We should speed this up by remembering the last used / selected powers for each character. Then when you (or the game when we have initiative order) reselects the character it will select the last used (still available) power.

This will effectively eliminate one click for each combat in most cases and if we auto-select characters then on average only one click will be required per combat.

Summary

Imported character and monster files often contain only partial information about powers. A mechanism for injecting new rules has been filed as a separate issue. Once rules are entered, there is still the problem of making them persist across sessions and to make them shareable between characters.

Implementation

Develop an export mechanism similar to the one used on the map editor storing rules. In addition to the explicit export, rules should also be auto-saved to local storage to prevent potential loss of data. When characters are loaded, the powers can be cross checked against the rule repository to fill in missing information.

Summary.

We need a better implementation for showing the results of combat. In particular it would be nice to animate the number of hit points taken from each of the monsters targetted in an attack (and eventually include effects like poisoned).

Implementation.

This is a UI change, but could involve changing the format of the message sent to indicate the combat result. Right now there are no usable messages sent on misses if we want to show those and attack-result gives the new hit point value (which could be used to calculate the hit points).

To implement this dungeon-common.js should dispatch a message with the necessary information after an attack. dungeon-client.js would listen for this message and show the relevant UI.

Damage adjustment did not work on a missed.

Summary

To speed up handling tricky combat advantage scenarios, we need a checkbox or some simple interface to say whether a character gives combat advantage. This can then be manually added and removed as needed without switching to the combat overview screen.

Summary.

We should be able to paint "features" onto the map. These can be subtle things which don't affect gameplay such as piles of bodies in dungeons or they could be obstacles such as tables or trees. In the case of features we may want them to be positioned and sized arbitrarily as they are meant to provide flare and their position doesn't matter, however if they also serve as obstacles we probably want them to be aligned to game tiles and have a well defined boundary.

Implementation.

Similar to the way tiles work, we should have a list of feature types, and a list of features.

Each feature type could have:

• A data URI image.
• A number of tiles in width and height (if used as a blocking object).

The map would then have a list of features and the update function in dungeon-client.js would intelligently determine which features to draw and where based on the visible tiles in the viewport.

Summary

Now that we can edit temp hitpoints we should always deduct from these first during combat.

Summary

Terrain should have a type with it. For the present terrain should be one of:

• A wall: Impossible to move or see through.
• An obstacle: Like a wall but only prevents movement through it (i.e. a pillar or a tree). We may need two types to determine which result in cover and which don't.
• Difficult terrain: Movement cost onto this tile is doubled.
• Open: Tile is open for movement and sight.
• Concealment: Tiles provide cover / concealment.
• Water: Have to regularly make athletic checks in water to stay afloat.

This is definitely a larger piece of work and will eventually require a new UI section to edit details.

Implementation

We could have each square of the map have both a tile and a terrain type or we could define terrain types for tiles. Either approach should work fine although we may want to support loading large background images and just defining terrain types for each square later. Whichever approach we use we will still want tile types to have an automatic terrain type to avoid having to effectively draw a map twice.

This will require changing the format of the map generated initially in dungeon-common.js and saved out to files. The map save file should include all of the tile definitions as it does with textures currently.

Use an event based communication model between components

Summary.

The game should work on an event based system to facilitate communications. On construction an object can add listeners for all events from dungeon.Game it is interested in, and dungeon.Game can add listeners for events from that object it is interested in. Then we can handle updating various components by dispatching established events which may cause several views to update.

Implementation.

Currently only combat-tracker.js needs to change. This should probably be created by dungeon-client.js and given a reference to dungeon.Client to listen for events on. In turn dungeon.Client can listen for events from combat-tracker which it's interested in.

Summary

The attack messages in the game log should include the character names. I.e.

Luna hit Orc for 8 hit points!

Implementation

The attackResult function in dungeon-client.js constructs attack related log messages when computing the attack result. The message names should be available in the character's name attribute.

The person who was tagged to go next died on their turn.

/home/rob/Documents/dungeon/server/client/js/dungeon-common.js:86
this.characterPlacement[eventData.index].x = eventData.x;
^
TypeError: Cannot set property 'x' of undefined
at Object.processEvent (/home/rob/Documents/dungeon/server/client/js/dungeon-common.js:86:50)
at Object.eventReceived (/home/rob/Documents/dungeon/server/server.js:102:14)
at Socket.$emit (events.js:70:17)
at SocketNamespace.handlePacket (/home/rob/node_modules/socket.io/lib/namespace.js:335:22)
at Manager.onClientMessage (/home/rob/node_modules/socket.io/lib/manager.js:468:38)
at WebSocket.onMessage (/home/rob/node_modules/socket.io/lib/transport.js:387:20)
at Parser. (/home/rob/node_modules/socket.io/lib/transports/websocket/hybi-16.js:40:10)
at Parser.emit (events.js:67:17)
at /home/rob/node_modules/socket.io/lib/transports/websocket/hybi-16.js:289:16
at Parser.expectHandler (/home/rob/node_modules/socket.io/lib/transports/websocket/hybi-16.js:300:15)

Summary

The game currently supports drawing at an arbitrary size. We just need to hook up a way for the user to actually adjust that size, probably by using the scroll wheel or worst case pressing +/- buttons.

Implementation

The size of a tile is called tileSize in dungeon-client.js. The UI just needs to change that value and call update to redraw. Don't use fractional tile sizes (i.e. 30.5) as these will not draw well on the canvas and are far less efficient. Scaling images to an arbitrary integer tile size is always okay though.

Summary

When monsters are killed they still seem to maintain their position on the map and get in the way of UI interactions involving those squares.

Summary

Allow attaching some conditional effects to characters. Name the effects as what they are so that we know not to apply (i.e. combat advantage) twice. We should also try to add some concept of when the effect ends (i.e save ends, end of next turn).

My orcs don't have their "Warriors Surge" ability when in Dungeon.
The files that I tried are:
-OrcBerserker
-OrcBoltThrower
-OrcFreak
-OrcRaider

Summary

It's fairly nice when doing an attack to see a dialog showing your rolls. We should show rolls in some sort of a dialog so that the user can see that this is still a dice based game.

Implementation

Currently the entire attack is implemented in dungeon-client.js, the attack rolls are made in the attack function and used in attackResult. Given that this is all done client side the implementation doesn't need to involve any server messages and can just compute the attack result and send it through an event.

Summary

For enabling an early playtest, allow adding and removing effects on the combat tracker just to remember which players have which effects.

Summary

Currently, there is no tracking of whose turn it is. Though computerizing the combat alleviates much of the mayhem of players simultaneously announcing their plans, ordering still plays an important role in the game mechanics. In particular, turn order plays an important role in determining when ongoing damage is applied and when effects end, not to mention who draws first blood.

Implementation

Combatants should appear on the combat overview page. The DM can trigger the start of combat, which automatically computes initiative and resorts the combatants into the correct order. New characters dragged onto the map during combat can have their initiative automatically assigned so that they fall into the right order. Groups of monsters of the same type will have the same initiative. In the event of a tie, initiative order can be resolved with a roll off.

When implementing order tracking, it may be best to err on the side of leniency, rather than strictly enforcing game mechanics. A player's start of turn can be denoted by issuing their first order. At this point, any ongoing effects are applied, and if they prevent the order from being completed (e.g. character drops below 0 HP), then the order is cancelled. Given that a player may choose not to move, or to move less then their full allowance, an end of turn button is likely required. Pressing "end of turn" would test for conditions that end, triggering saving throws as needed. For groups of monsters, the "end of turn" could apply to the group, thereby reducing the number of mouse clicks required.

Once a player denotes the end of their turn, powers and moves for their character can be disabled until the start of the next turn. The strictness for enabling and disabling of controls can be made adjustable. The strictest setting would require each player to act in turn. A more lenient approach would allow players to swap positions in the initiative order without involving the game engine. A possible restriction is to divide into hero and monster groups and restrict free initiative swapping to players that are not separated in initiative order by monsters. The leniency allows decisive player B to move while player A is thinking provided player B's action does not impact player A. A wait button may be useful for shifting down in the initiative order.

In any event, the next player in the initiative order can be shown in the combat log even if not strictly adhered to in practice. Additional feedback could be provided on the combat map, possibly with a pointer next to the character whose turn it is. For the DM, the appropriate monster could be auto-selected.

Summary

To enable the next playtest, supporting things like combat advantage each character on the combat should have an attack to hit modifier, and a defense to hit modifier. An attack will do an attack roll plus attacker to-hit modifier + defender to-hit modifier.

Summary

Would be nice to be able to drag dialogs around so that you can see things ocluded by the dialog.

Summary

The 1, 3, and 5 buttons on the map editing interface were meant to serve as a brush size to facilitate covering large sections. We should be able to use these to draw larger map regions.

Implementation

Implementing this would be a matter of allowing for a selected "brush size" probably following the pattern set for selected tiles. When generating 'change' events from the paint function in dungeon-client.js, the current brush size should be attached to the change message. In dungeon-common.js this brush size should be respected and the appropriately sized grid around the cursor drawn in.

Health bars for characters.

We should draw health bars for characters so you can see at a glance who's injured and how badly. Short term everyone can have health bars and in the long term only DMs can see everyone's health bar you can only see health bars for your allies and enemies will only show a bloodied indication.

Implementation.

Health bars are completely visual and as such only need to be implemented in dungeon-client.js. In the (poorly named) update function, health bars can be drawn when drawing the character.

Summary

Some powers let you select up to X critters. We should be able to select / deselect on the map and have a button at the bottom-right which will confirm your selection. If the power only lets you select 1 critter then we shouldn't show this button at all and the attack will automagically happen after selecting the only critter.

There should also be shortcut keys for this button, probably enter or space to accept or escape to deselect all critters.

Summary

The banner message should only be displayed once, not every time you flip back to the map.

The monster Aarakocra did not get his Dart and his Hurl Barbed Net attacks.
File: Aarakocra.monster

Summary

Add an initiative list to the combat tracker.

Summary

Allow clicking on a character in the list to select that character. Change the styles so that the selected character has a background colour and the character who's turn it is has an arrow icon or something similar.

Summary

When designing a map there will often be things which need to be replicated and/or moved. We should have some rectangular selection based map tools such as cut / copy / paste and consider having a store of "pre-fab" objects to be able to build a house once and place down several copies of it.

Implementation

We need to support dragging a selection rectangle, and add buttons to the UI. We should probably add event types for region paste type functions to avoid having to send hundreds of updates from a single UI interaction where the clients probably already have the necessary information.

Summary

When groups of characters are next to each other avoid overlapping the names by showing short names.

Summary

Escape should cancel a dialog and enter should be the equivalent of pressing OK.

Summary.

The character which is shown in the sidebar is not necessarily selected. We should have a stronger guarantee that when the selection changes the sidebar will also update.

Implementation.

I recommend implementing this by dispatching selectionChange events in dungeon-client.js and listening for those from combat-tracker.js. It should be fairly straight-forward.

Summary.

There is a race in the game in that images are loaded asynchronously. The result is that before the images have been loaded they draw black and you have to scroll the map to see them. We should be updating after the images have loaded.

Implementation

In dungeon-client.js whenever we construct a new Image we should have an onload handler. We can either detect when all loading images have loaded, or we can redraw after each image has loaded. This will eliminate the occasional black screens that you can see.

Summary

Add a simple UI for modifying attacks immediately before you do them.

Summary

Click or over to see details for a log message.

Summary

The single index.html file is going to get fairly large if everything must be contained within it. We need a library which will pull in other HTML files with the assumption that these loads are asynchronous and you can't access the elements within until it has completed.

Implementation

We should define a property on elements (i.e. <div src="filename.html">) which we will scan for. When this is found we can initiate an asynchronous request for the HTML and insert it. On completion we should fire an event and set an attribute to indicate that the div is "ready". Then we can provide an interface which will fire some callback on loading the div, which will be immediate if the div is already loaded.