Make the necessary updates so the map can have a single editor assigned with multiple viewers. Linking users to it can be done via a campaign_id (see [
TTORP (cs-battletrack) / Campaign Linkage
]), which should be available in the database very soon.
Imported Tasks
AJAX -- Javascript
Build the javascript functions for sending changes (from GM) and receiving updates (to
viewers).
AJAX -- PHP
Create PHP scripts that the javascript GET/POST requests will be sent to. For examples, check out the code in "cs-battletrack/sample_scripts/" (either in trunk/0.5/ of
cs-battletrack or in the lib directory of the trunk version of CrazedSanity.com).
Database Schema
Figure out & write the database schema needed for the map, store in the "/docs/sql/"
folder in cs-battletrack. Some thoughts, discussed previously:
-- link icons to character sheets
-- unlinked icons (i.e. WHERE character_id IS NULL) are monsters or another type of NPC (that is for the GM to figure out).
-- try to avoid creating a record in the database for every single coordinate... from
conversation:
+--> set a default state (i.e. FogOfWar=true)
+--> store only coordinates that don't match the default state
+--> delete records when they match default state
-- considerations for overlays (i.e. 2-3 character identifier, if two players have
same/similar icons)
-- considerations for "status" (i.e. alive, prone, dying, dead)
Libraries
Write libraries for performing insert/update/delete operations on the database. Considerations need to be made for returning data in a way that is usable for AJAX calls.
To facilitate, consider checking out "cs-webapplibs/abstract/cs_singleTableHandler.abstract.class.php", which is very helpful for writing libs where each library handles a single table (can then write a class that utilizes those single-table-based sub-classes).
Templates
Build templates that separate-out functionality. Some suggestions that were discussed
previously:
-- menu template (tools for GM, or nothing(?) for viewers)
-- main map (editable for GM, read-only for viewers)
Consider having the javascript code separated into one that has generic functionality and
one that has extended functionality for the GM.
Make the necessary updates so the map can have a single editor assigned with multiple viewers. Linking users to it can be done via a campaign_id (see [ TTORP (cs-battletrack) / Campaign Linkage ]), which should be available in the database very soon.
Imported Tasks
AJAX -- Javascript
Build the javascript functions for sending changes (from GM) and receiving updates (to viewers).
AJAX -- PHP
Create PHP scripts that the javascript GET/POST requests will be sent to. For examples, check out the code in "cs-battletrack/sample_scripts/" (either in trunk/0.5/ of cs-battletrack or in the lib directory of the trunk version of CrazedSanity.com).
Database Schema
Figure out & write the database schema needed for the map, store in the "/docs/sql/" folder in cs-battletrack. Some thoughts, discussed previously: -- link icons to character sheets -- unlinked icons (i.e. WHERE character_id IS NULL) are monsters or another type of NPC (that is for the GM to figure out). -- try to avoid creating a record in the database for every single coordinate... from conversation: +--> set a default state (i.e. FogOfWar=true) +--> store only coordinates that don't match the default state +--> delete records when they match default state -- considerations for overlays (i.e. 2-3 character identifier, if two players have same/similar icons) -- considerations for "status" (i.e. alive, prone, dying, dead)
Libraries
Write libraries for performing insert/update/delete operations on the database. Considerations need to be made for returning data in a way that is usable for AJAX calls. To facilitate, consider checking out "cs-webapplibs/abstract/cs_singleTableHandler.abstract.class.php", which is very helpful for writing libs where each library handles a single table (can then write a class that utilizes those single-table-based sub-classes).
Templates
Build templates that separate-out functionality. Some suggestions that were discussed previously: -- menu template (tools for GM, or nothing(?) for viewers) -- main map (editable for GM, read-only for viewers) Consider having the javascript code separated into one that has generic functionality and one that has extended functionality for the GM.