dungeonsoffear - 2015-11-13

Today I worked on the room test tool. A lot of ground work had to be done in order for this to work, and the main problem being how to store the test users in the database. My goal was to use as much as the game code as possible in the room testing tool; I don't want to re-write any functionality and have to worry about differences. The test players had to behave exactly like real players would, so test dungeons, players, game players, and game traits all live in the same tables alongside of production ones. In order to differentiate the two, on player creation an additional player is added to the database, but has no user_id. Each player record has a test_id field that points to that additional player. Test game players are all created off of the test player.

I had to make changes to getPlayerById since test players have a user_id of null. Because the player constructor takes a user_id, it assumes that there is a 1 to 1 relationship of players to users. I got around PHP's lack of multiple constructors by using optional parameters and checking which params are NULL.

The progress on the testing tool is that it is creating dungeons and game players correctly, and I am on the step where the user will edit the traits for each test player. The following step will be the user choosing what each test game player chooses, and finally, displaying the resolution and cleanup. If I really buckle down tomorrow I should be able to get it done.

The goal is a playable version by Thanksgiving (2 weeks).

  • Decision parsing based on traits
  • Decision submission, resolution parsing from XML, modifying traits
  • Authoring tools for rooms
  • XML validator and a test feature <--- IN PROGRESS
  • Enter game and exit game (merge traits back to player)
  • Game invites, declines.
  • General game rules, like death and pants shitter.
  • Email functionality, day timer
  • Unit testing, code cleanup, documentation, minor aesthetic fixes

4 Hours