CTYR Design Document Overview

Anymore, I simply cannot work without some sort of up-front design work, even for something as simplistic as CTYR.

Like most of my games, I need some common components:

• Configuration – Loads from xml, contains information mainly about the images, sounds, and other constants in the game.
• Image Manager – Images are referenced by alias, which are mapped into the image configuration xml file, which yield an actual resource name.  They are loaded when needed, not all at game start.
• Sound Manager – Sounds are referenced by alias, which are mapped into the image configuration xml file, which yield an actual resource name.  They are loaded when needed, not all at game start.
• Constants – Also loaded from xml in the form of strings and integers.
• Game State Machine – Taken care of by a Slick2D class.
• Game States – Derived from a Slick2D class made to work with the state machine.

Next, the state machine:

• Splash – Shows something like “another fine product of PlayDeez Games” for 5 seconds, keyboard or click will cancel it
• Main Menu – Has buttons for instructions, rankings, logging in/out, options, mute/unmute
• Instructions – Shows instructions for the game
• Rankings – Shows rankings for the player’s session(if not logged in) or for the player account (if logged in)
• Options – Controls for sound volume and muting
• Log In – User name and password, logs the player in. It will also support getting logged in from the web page and passed into the applet, and the ability to save the login information in some form.
• Pre-Game – Does a 1.2.3. count up at the commencement of each game
• Game – Does the main game handling
• Post-Game – Shows the final score, and links to new game, rankings.

And the appearance:

The main game field is square

The rhombus has an aspect of 2:1.

The area around the field is sufficient to show stats and buttons (stats on the top, buttons on the bottom), as well as a little border on the left and right.

In order to support communication between web page and application, I need to come up with a way to put the data into a payload.  I typically choose some form of JSON strings with base64 encoding and then an “encryption” method.

This will need to be supported on both the client and the server, so it needs to be written both in java and php.

I will naturally need some database tables.

Yes, this means I need a new user system.

Again.

Sigh.

I’d like to use some form of openid, ideally the google id at least.

That’s a research point.

Once I have some sort of user system in place, there is only one table that I actually need that stores the following information:

• User id (however that winds up working)
• Number of games played
• Total score
• Highest score

From this, the average score can be calculated (total score/games played).

This is, at least, for the “all time” rankings.

For the “last 30 days”, “last week” and “last day” part of the system, I need:

• User id
• When
• Score