montyr75 / dungeon Goto Github PK

If a monster is fought but not defeated, it needs to be placed in the next available numbered slot, and the corresponding token should be placed on the Dungeon! board. When slotted, the monster should probably be couched in a Slot object that includes a reference to the deck the monster came from. Need to find out the rules regarding what happens if all 12 slots are full....

In the upper right, we need a button that, when tapped, will reveal the slots area if it's currently collapsed. If the button's ID is "slots-btn", it should have some CSS like this to make it visible only when the drawer panel is collapsed:

core-drawer-panel:not([narrow]) #slots-btn { display: none; }

Separate dungeon.json into encounters.json and treasures.json. Each of these should just be a List of List, with the first being level 1, next 2, and so on.

Slots are just <td> elements right now, but they should become more robust, able to display more information (monster stats, treasures in the slot, etc.). It's likely that it will need to be compact by default (monster name, number of treasures...), but expandable to show details.

If a hero encounters and fails to destroy a monster, the monster can return fire. We need an attack button that automates a 2d6 roll behind the scenes and displays the result from the game's monster attack table.

Talking about Card models, of course.

If a card is accidentally discarded, there needs to be a way to "undo" the mistake.

In the function that handles the JSON data intake, a switch statement might be cleaner than the "if" for determining what type of class to instantiate.

This class should be able to handle encounter cards like monsters and traps, and also treasure cards and special items. It should closely emulate the behavior of an actual deck in the board game.

Trap card descriptions should have a special data insertion point that will be automatically filled in the constructor. Cage traps will cause a player to lose 1 or 2 turns (50/50 odds) and slide traps will always deposit a player one level deeper than the trap's level. Any approach will probably be made easier by including a "subtype" property that identifies the specific kind of trap.

The Trap class could handle all trap types (since there are only two), or there could be subclasses for each subtype that contain the appropriate special data handling.

Remove the HttpRequest and just load with the element. Example can be found in the card_shuffler program.

This element's layout will be modeled loosely on the board game's cards. Traps will display a description section instead of the attack numbers, and they will not display "Attack" or "Slot" UI. The user will need to be able to perform these actions with the view:

• Return card to deck (use Deck.add())
• Discard (use Deck.discard())
• Attack (use CardView.attack())
• Slot

The view will need to have an attack() method that rolls on the monster attack table and displays the result. Would be great if the result popped out of the attack button itself (<core-dropdown>).

Trap card descriptions should have a special data insertion point that will be automatically filled when the card comes into view (in the Trap class's description getter). Cage traps will cause a player to lose 1 or 2 turns (50/50 odds) and slide traps will always deposit a player one level deeper than the trap's level.

We can avoid some code redundancy in Monster and Trap by calling super.fromData from the child classes' initializer lists (after the colon).

Random r = new Random (new DateTime.now ().millisecondsSinceEpoch);
r.nextInt ()