Every game section will be built upon a base class that has filtering (automatic filtering for $_POST and $_GET), and for outputting data. Some security experts have stated that you can’t prevent hacking just by filtering input, but also checking and filtering output for XSS attacks. The Filtering will be part of the base class functionality, so that it will be available to all child classes, because I’m tired of having to copy crap over and over again. I just may be able to get rid of the damn get_magic_quotes_gpc() checks (which would get the classes ready for PHP 6).

Every game part will be built off the game module, so everything I put in the base game class will be available to all of the child classes, which should increase the functionality and expandablity of the game. The filtering class will also allow the person to create their own classes to extend the functionality further. As well, as the same will be true to the base game class.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

Page Object Class

The Page Object class opens the link to the file and parses the XML tags.

Template Class

Controls the replace of the XML tags and runs the preset tags along with the users own class tags.

Tag Classes

Replaces the tags with what is in the classes. spits it back out in both raw and formatted versions.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

User Logging has always been a thorn on my side, because I can’t find a good way to do it and have it automatic. I’m going to try to some tests with properties and try to do it that way. Logging should be automatic and should also be disabled if it isn’t needed. I was thinking of just logging it in the Database Class, as it would be better served there as every class will have to be inherited from it anyway.

While having a lot of properties would solve the problem, it would also add a little bit of overhead and more work for the developer. Logging will also add another query to the list and for now I’m not doing any queue, so each transaction will go through automatically. I will try to do some work on using the prepared statement, but that will also take some work with the testing and research. For now, I think the logging is best served if it is automatic. The basic logging system could be better served by logging the insert, delete, and updating. Along with who is doing it and what is being updated, it could amount to a better tracking system for cheaters. The child classes could also give a better description on whether the action is staff based or player game based.

I’m going to give this method a go and see how well it works within the system and how easy it is to track events. If it does it job and makes it easy to do the logging, then I’ll keep it until a better system can be created and tested. At the very least, I have another test version before everything is finalized.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

DatabaseConfiguration Class

This will be a file that is created by the installer and will have all of the properties filled in. As such, it will double as the configuration file.


// PHP 5
class DatabaseConfiguration { }


Properties:

• protected host
• protected username
• protected password
• protected database

Database Functions Class

The abstract class forms the basics of all database connections, other then SQLite. It will be inherited by each of the different implementations and supply the functions for which each of the child classes are to implement. The base function list will most likely be increased as the game engine development progresses.


class DatabaseFunctions { }


Properties:

• protected version
• protected handle

Functions:

• __construct() : Connects to the database.
• __destruct() : Disconnects from the database.
• delete
• insert
• update
• select

Database Exception Class

I had proposed a exception class for handling errors thrown. The exception class is to handle all types of databases. There will also be different exceptions for each of the possible errors, it will start the throwing instead of exiting out of the code.


class DatabaseException extends Exception { }
class DatabaseConnectionException extends DatabaseException { }
class DatabaseSyntaxException extends DatabaseException { }


Database Result Object Class

This class handles the select (mysql) resource and it is its own class for handling the closing. It will load the database class type and load the elements in the properties and use the same functions for interfacing with the base class functions.


class DatabaseResult { }


Database

This is the class that will be used by other developers and extended.


class Database extends DatabaseFunctions { }


__construct($type = ‘mysql’)


parent::__construct($type);


Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

Start pages are the pages that the player doesn’t need to be signed in to view. I want to supply a sort of CMS style pages for allowing the developer or designer to supply what each page does. For version 1.0, they will have to supply that based off the template pages and will be hard coded.

Includes

I’m debating whether to have these files only in the base folder, or to have them along with the other game files. It is a little difficult, because I would have to fix the problem with the includes not working with relative links with CGI. I could work on fixing that and adding all of the other to their own folder. It would help development.

Version 0.7

• index.php – portal or base story page.
• register.php – for registering.
• staff.php – for viewing the developers and staff members.
• forgotpassword.php – for sending a new password and recovering an account.
• activate.php – If activated, then activates a users account.
• rules.php – terms of agreement and game rules.
• Signing In

Version 0.8 Additions

• resendactivation.php – Resends Activation email, if lost.
• donate.php – IPN paypal script.
• Signin Error.php
• gameengine.php

Changes to Version 0.8

Template

• Give the site a more of a “portal” look.
• Create better gradient headers.
• Use new template system for using in 0.8.
• Create XForms and normal Form support.
• Have predefined XML tags and allowing for those to be extended and inherited.

Index

• List the top five players.
• Display announcements.
• Display game story.

Registering

• Use a mix of JavaScript and AJAX to help with error checking and displaying help.
• With AJAX, do automatic checking for length of username and passwords.
• Check whether username and email address exist in the user table.
• Add support for customizing the registering in the admin panel.
• Should ask for two secret questions for recovering passwords.
• Should use an image for input to prevent bots.

Staff

• Add full support for displaying staff in template code.
• Showing of staff stats, should include when registered, Contact (if the admin supplied and wants it to be displayed), and last active.

Signing In

• AJAX: check for errors and spit those out.
• Use new page for errors and allow for signing in, in that new page.
• Allow for setting what is checked when signing in, in the admin panel (email, username, screen name).

Forgot Password

• Should allow for secret questions to allow for better results and changing of email address.
• Shouldn’t depend on Secret questions for recovering password.

Activate

• CRON: Code should be started for detecting bounced replies and automatically deleting when the bounced replies are given.
• CRON: Admin Panel should be able to set the time for automatic deletion of accounts who haven’t been activated in a certain amount of days.

Rules

• Rules and Terms of Agreement should be split and dynamically created.
• Rules should be updated to include other cheating methods and bots. Terms of Agreement should also have any legal notices, such as if the user is under 18 but over 13.

Additions in Version 0.8

Resend Activation

• Should just resend the activation based on the username given.
• Should use an image to prevent bots.

Donation

• Move to start pages to help prevent session bugs.
• Allow configuration in Admin Panel.

Sign In Error

• Move displaying error code from signin script to new page.
• Show sign in form and error message.

Game Engine About

• Could be a link to an Absidon Games page.
• Legally has to be a part of all games made with the game engine code base.
• Gives Creative Commons some rights reserve legal message and link.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

I have been thinking of just releasing a pre version 1.0 and calling it version 0.8. As many problems Version 1.0 is going to have, it would be just be better to work on fixing the features now, instead of fixing them in version 1.1. I should be proud of the first release and release something that both shows what I can do and give inspiration for developing something better. Also once I release the final 1.0 version, it would be bad to not have backwards compatiablity and have to call the next version 2.0 to keep from any confusion.

Since I’ll planning on adding the version 1.1 features anyway, plus some extras, then it would be in my best interest to release a version that doesn’t make me embarassed to have someone else see and bitch about. Also, there are some problems with the internal configurations that need to be worked on. The changes will need to be plotted out, and listed, which I will do today. A full list will be decided and once it is completed, the list will become the working version for version 1.0. The current version will actually become version 0.7, but will not be packaged.

There are also two games going to be based on the pre version 1.0 game engine, which will be held as test cases. Version 1.0 will be done right and for that, some parts of the game will have to be rewritten and some new parts will need to be developed also.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

I’m going to use AJAX for a lot of the game core and not just for the cool looking stuff either. I want to use it for checking on the Register for the username to let the person know right away or while they are filling the form out, that the username has been taken or not.

For the Sign In, I want to check to see if the user is activated before they click send and after they click send if they are too quick for the checking. By allowing the checking to take place before they fill out forms and click send I take some of the hassle out. Everything won’t be AJAX as it won’t make sense and add bloat to the game(s). If it makes the game function quicker and return a faster response, then it should be used. Mostly for Error Checking and displaying. The tookkit should also allow additions and JavaScript calculations, so that they can be warned that they are spending too much than they have, then supply the correct amount.

I’m not that into the fading technique, but it could be useful for letting people know what is happening. Since the versions will be free, I could use an premade one that does just that. It would also allow me to get to know the technique, so I could create my own eventually.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

I wrote a while back that I wanted to allow the registering to be customized, which also includes whether or not the activate code will be sent. Most of the core parts will have the option of being OPTIONAL or REQUIRED and if CONFIRMED or not. The register parts in the game engine that is required by the rest of the game engine won’t be changable, but will be set in the register code.

There should also be an option to remove some parts, if they aren’t needed. There will also be a section for adding new options and the choices for the option. They will also have the same setup as the other criteria.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

I was discussing the game with someone outside the United States, and he wanted to translate the game. With version 1.0, you can do it, but there should be another way to do it. I will try to add in a locale template into the game engine for adding other languages, easily. It would be better it if was in XML format and in a file, instead of in the database. It is going to add some complexity, but it should be cool along with the other enhancements.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features

A review of the final code for version 1.0 hasn’t been done yet, so the items here aren’t finalized (well, the ones on here are), and more could be added. Version 1.1 will focus on improving features and the appearance of the underlying code. It will also look to improve the look (by allowing XForms) and feel (by adding JavaScript). The Core Game Engine code should be independent of the game pages to allow for easily upgrading the engine core and not break the game files. Even so, not of the items on the list will make it in the final release of version 1.1. There are only a few features that I’m requiring to be done before version 1.1 can be released, along with fixes from version 1.0.

The timeline for this version is two months, which should be a reasonable amount of time to finalize everything on this list plus do debugging. Unless I become lazy or have to work full time and don’t have any time to devote to the project, it should be done a pretty fast pace. This doesn’t mean that the code base will be worked on as soon as version 1.0 of the game engine is finished. I will still work on a few other games before I start the new version code base.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features