Game Plugins should be placed in separate directories, and main class should automatically load all available games.

game/<name>/main.py - extra web code, will be called on route /game/<name>
game/<name>/plugin.py - main plugin class
game/<name>/views - extra views used by the game and web pages
game/<name>/stylesheets - extra stylesheets used by the web pages
game/<name>/stylesheets/game.css - stylesheet automatically added to game
game/<name>/javascript - extra javascript for web pages
game/<name>/images - images used by game and web pages

Some ideas of things to do in the framework:

• Registration to allow site owners to create their own hero.
• Functionality to add monsters (login required)
• A bit more design
• Generic data file editor?
• API call for hero list.
• List heroes within widget.
• Show info about dead hero in charsheet if necessary.
• Keep list of latest actions to prefill in game.html
• När hjälten dör, maskera sidan och visa gravsten, och reroll-knapp.
• If no character, automatically reroll.
• Add game title and description in header.
• Login page/link
• Allow guests to enter name.
• Automatically add web routes for games if web.py exists in plugin dir.
• Move heroes.html into goldquest dir.
• Set basepath of GameWebHandler to game dir.
• Dynamically create charsheet.
• Metadata to force login or allow login.
• Template for death lightbox.
• Maybe add support for empire games in the future.
• Trigger events in javascript, to allow extra functionality to be added by games.
• Page to upload a new game (will require deployment, possibly by automatic git checkin)
• Continuous Integration
• Automatic deployment from master?
• Native Android app
• broadcast groups doesn't seem to work properly.
• Metadata for list of links to show for game.
• Index page should list game links for current game.
• Optionally return different responses for client and broadcast.
• Handle multiple instances somehow. Easy way is to always call setup() for each request.
• Clear old client_id's in memcache.

• Create info page.
• Create top list.
• Bombs give a chance of instant kill (one time use).
• Daggers increases damage (one time use).
• Rewrite game texts.
• Change Buy-action to Item action, with option to equip as well.
• Equipped item used for every fight until all are used.

Instances need to synchronize with each other.

Either just remove the caching of the Game object in the instance, or call seup() for each request.

API root should display all games, game root should display links to all commands.

Sent via Hubroid

It would be nice to add some social features to Dicey.

• All rolls broadcasted to all users (needs bugfix for broadcast groups)
• Save combined rolls to easily roll several dice at once.
• Challenge rolls - ask other players to roll a specific type of roll and see all results.

Add automatic unit tests for all game actions and necessary methods and metadata.

This can be completely generic, by reading action list from the game metadata and test that all actions return the proper response.

Create a game/app to allow choosing other games.

Will need game specific game.html/game.js working and API call to list all available games.

Templates should be easier to add, there are a lot of places that need to be changed when adding a new template.

Also, stop using game html div:s as transport method for templates, just load via json so that we can use standard django "{{ }}" notation and don't have to worry about escaping problem.s

Sometimes clients don't seem to receive broadcast messages as they should.

The code for the Android app is missing from the repository.

The communication between client and server is a fairly simple REST-like solution.

There needs to be a guide on how to use this to write your own client.

It should probably also describe the HATEOAS similarities.

A tree of texts, where the text in the root node can have placeholder strings. These placeholder strings will match sub-nodes in the tree, and the text from the nodes will be used as replacements.

Each node will also have requirement attributes, meaning that they will have to be met by the attributes in a given value object.

{
  text: "It was a dark and stormy night. {{ wet }}",
  nodes: [
    {
      key: 'wet',
      text: "{{ value.name }} is drenched.",
      reqs: [
        "!items HAS umbrella",
      ]
    },
    {
      key: 'wet',
      text: "{{ value.name }} is carrying an umbrella.",
      reqs: [
        "items HAS umbrella",
      ]
    }
  ]
}

value.key means to display the value in the attribute 'key' of the given value object.

Requirements:

• Start a requirement string with ! to negate it.
• First word is an attribute name of the value object to match agains.
• Second word is a comparison operator.
• Third and all following words will be the value to match against.

Comparison operators:

• HAS means the attribute is a list that must contain the value.
• IS (or =) means the attribute has to be the same as the value.
• LESS (or <) means the attribute has to be less than the number in value.
• MORE (or >) means the attribute has to be more than the number in value.

There might be a need to separate actions into actions and GUI elements.

To begin with, each action should have a new attribute: "button" with possible values "active", "disabled" and "hidden"
Active means that the button is visible and clickable to trigger the action. Disabled means visible, but won't trigger action, possible grayed out. Hidden means it won't show at all.

There should be a API request to get the metadata as a hash. Internal API requests such as this need to be prefixed with some sort of namespace to not risk clashing with actions. This resource should be used to setup the client with all the needed buttons, preferrably via javascript so that code won't be duplicated.

Responses should also be able to contain a metadata value which can contain updates to the metadata structure. This will allow letting the game tell the client which buttons are available at any given point. It will also allow games to update the list of available elements in an action argument list.

It hsould be possible to set data types on argument input text fields. I.e. integer, alpha, alphanumeric etc. Should be set as html5 attribute if available, with validity check.

Actions and GUI definitions should be split up.

GUI definition could be saved in a yaml file, and should allow for more elements. Image buttons, text links, input fields directly on the toolbar etc.

Example yaml:

toolbar:
 - key: buy
   name: Buy
   action: buy
   type: imgbutton
   arguments: ...
 - key: chatinput
   name: Post
   action: chat
   type: input
 - key: login
   name: Login
   action: login
   type: link

The arguments attribute is the same as arguments on actions today, to open up dialog menus/inputs.

Initially only toolbar needs to be supported, but this could possible also be used to setup menus etc.

When a game is selected on the index page, show game specific links instead of GQ links.

The channel broadcast grouping doesn't seem to work. Games get broadcast messages from other games.

Put all generic javascript code into a GOLDFRAME "namespace" to make it available to all games when adding game specific javascipt.

• Risk of getting caught in a trap.
• Stats increase 1/10th of level when going deeper
• Visa alltid (Killed by {{monster}}) vid raden där hjälten dog.
• Spara info om vilket monster som dödade hjälten, visa i topplistan.
• Add morale value (1-100) based on percentage of successful loots out of total possible, recalced every level.
• Morale is used as a multiplier on strength in fights.
• Items can drop when looting.
• Weapons can be equipped to get stats increase.
• Shields/armor decreases hits from monsters.
• Items degrade for each use, possibly just 1 point of stat decrease per use, and automatically disappears when reaching 0.
• Action to equip items.
• Different weapons could work better against specific types of monsters.
• Monster type selectable per level.

Write a scaffolding tool.

Features:

• Create new Android versions of apps.
• Create new game, setup all files that are needed.
• Create a Chrome web app for a game.
• Deploy to appengine
• Run tests
• Build and deploy Android app to Android Market (if API is available)
• Deploy Chrome Web App to Chrome Web Store (if API is available)

It should be possible to allow arguments to actions.

An argument can either be a string, a list, or a dictionary. If it is a string, the client should prompt for a user input. A list is a list of elements that the client should let the user select between. A dictionary will be sub-arguments, which will allow for nested selections.

Example:
'arguments': [
{
'type': 'string',
'name': 'Amount',
'description': 'Amount of items to buy',
},
{
'type': 'list',
'name': 'Item',
'description': 'Item to buy',
'values': ['Potion', 'Bomb', 'Dagger'],
}
]