Jacob Santos

I’m still in the planning stages of the beta 2 stage and will be a complete rewrite of the game. It will include RPG elements along with RTS ones. It will also be based off of either version 0.6 or 0.7 of the game engine depending on the how the work for Heat of the Race goes using the 0.6 version.

I’m going to take some more time developing it so that I can call it version 1.0 of the game. The main point is that it has to be FUN. Not just some automatic response for attacking and needs to have something to entice the players to keep playing.

The development of Heat of the Race and Mecha Asylum, will further the research for version 0.7, which the games will most likely be rewritten in parts to be compatiable with the changes and additions. After Mecha Asylum and Heat of the Race are stable, I’m going to turn my attention to another two games that will be based off version 0.7 of the game engine.

Projects to be Finished by December 31, 2006

1. Game Engine: Version 0.6
2. Heat of the Race
3. Mecha Asylum Beta 2 (which may become final)

Projects to be Completed December 2007

• Game Engine: versions 0.7 and 0.8
• Earth 3045
• Battle Machines (will most likely be work on converting the game over to the game engine and adding features and merging Battle Machines over to the game engine features)

Projects to be Completed December 2008

• Game Engine versions 0.9 and Final 1.0
• Two to be decided RPG projects.
• Maintaining the rest of the games and adding features to them.

While I do wish to have all of my projects finished before the year 2008, I at least want to have two finished games built by myself with a feature set that allows me to almost set back and enjoy the ride. Most likely the games that have the most active members will receive my most attention when adding features and fixing bugs.

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

Well, I couldn’t really work with it with PHP 5.0 because I would have had to download the PECL extension and I wasn’t going to go through all that trouble. With 5.1, it is part of the package as long as it is enabled and I believe it is. I can start testing now, but right now I going to leave PDO for when I add prepared statements to the database classes.

It should be that the developer can either use my database classes or use PDO, but right now PDO has some features that I don’t support and probably never will, but I allow direct API to the databases, so I can have better direct support for features that only SQLite or Mysql have. Which I also probably won’t do, but I’ll think about it.

This class framework stuff is still fairly new to me so I haven’t really explored the full extent of what I can do. It will take some time to get to know PDO and create newer frameworks for use in the game engine.

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 think I’m going to throw my hands up and just go with the simple method of doing everything instead of playing god and recreating the world. In the way, I plan on doing it, it will kind of work with PDO when I convert it over to it.


// Mysql
$database->mysql()->query($sql); // Regular Query
$database->mysql()->query($sql)->log(); // Run Regular Query, and then Log

// SQLite
$database->sqlite()->query($sql); // Regular SQLite Query
$database->sqlite()->createdatabase($name); // Create Database
$database->sqlite()->createtable($table); // Create Table

I believe that if I allow for a connection in the parameter:

$database->mysql('connection1')->query($sql);

Then I could have multiple connections connecting to different databases. This would allow for multiple database connections as well as multiple sqlite database file connections to be created. I’ll document this better and see how well it goes. If this doesn’t cut it with the speed and what not then I don’t know what I’ll do.

Exceptions

I need to create more exceptions for the Databases for the different errors that could occur. Right now the one exception isn’t even used at all.

Result

Result will still return an iterator for processing, but I want to continue working on cleaning up the code a little bit. Also making it more intelligent on how many rows and speed up the preformance of the 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

I was thinking about adding a few classes from the Zend Framework: Filter and InputFilter to the Security Section of the Game Engine. I’ll probably add them in to the Game Engine Filter class and allow access to them and use them for testing.

I looked over the other code and I’m unimpressed. It is good complex code but it isn’t simple enough for my needs. I still need to go over and fix the database class to optimize the time it takes to do queries. It shouldn’t take forever to load a page and it does when there are a lot of queries and results happening.

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 thinking and I totally have it. I also have some idea on how I will do it also. The idea is to create a factory class that allows access to filters for doing multiple stuff and editing content for security or reformatting or whatever.

The factory class called Filter will have no implementation on its own and will depend on other classes for functionality.

Add

The add method (or function) will take the add on class and put it in an array that will hold the class and the name of the class. Any number of classes could be added, but I will need to make sure that the names are unique so that two things don’t happen. For the basic implementation, I will only allow for the unique name value pair and later add in where two classes with the same name and functionality could run together on the same data with some type of priority in place to tell who goes first.

remove

A class should be able to be removed at any time depending on the needs of the user. It won’t be dereferenced, just put aside in a place where the class says, “Hey you, you go play, we’ll call you when you are needed again.” Then once that part is done, it can come back and play with the others.

parse

Will take the unique name return the class and take the parameter for the value.

$cleanFormData = $filter->parse(’security’)->cleanse($rawformdata);

Keep It Simple

By keeping the Filter class simple, I can add complexity to what could be done with the multiple filters for different tasks. Also allowing any number of developers to create their own filter classes to add on to the ones. It would be cool because it would done so that only the classes that are needed are used when they are needed and then taken care of afterwards. It shouldn’t add that much overhead and to the developer using the filter, it would seem that all of the functionality is taking place in that one class and would only need to download the other filters as they come.

By keeping all of the filter functions out of one class and keeping the one major filter class stable, I can keep it clean with a small footprint. As the game engine development continues more filters and better functionality can be added to the filter class, but by keeping to the simple functions I could perhaps keep some backwards compatiblity. Only the classes themselves would have to be upgraded and the filters to them changed, if at all. There shouldn’t be a need to worry about whether something would break because of a filter was changed or an upgrade version added something new or removed something. “It will just work ™,” and that is how it should be and how I hope I will be able to create it.

Actual Implementation

It won’t be as simple or easy as that as I still have to code the damn thing and test it. Then I have to create the actual filter classes to go with it. I hope to have a good library of filters for when the final version comes out but for now the 0.6 version will be pretty minimal with myself adding them as I need them or as I think of them. Here is for wishful thinking.

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 decided that it isn’t a good idea in a development cycle of two months to work on a template system for the whole two months. Trying to reinvent the wheel is fun at times, but is isn’t getting me any where, any time soon. I’m going to take the “simple” approach and use includes and classes. It will be a lot easier to mangage and I don’t have to worry about having to spend a week implementing a tag system.

The Template system is going to be moved up to either version 0.9 or 1.5 or 2.0 depending on how much time I can spend on it between versions and games. Leaving the complex template system out of it until I can find a way to easily and quickly do it again, is a better approach.

The only problem is that all the time I spend working on it for version 0.8 is pretty much been wasted. I’m going to move it away and work on the new system. It was pretty cool on what I could do with it, but right now it isn’t worth the time. When I can implement something faster and just worry about the game features. I do hope to make the game features template independent so that I don’t have to redo them at a later date.

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 could do this tag this version, but time constraits have me thinking that I should take the easy route and just separate what would be inbetween the foreach tag into its own page and just clone what is in the page. It would be far easier until I can either come back in version 0.8 or add it in version 0.9. What the tag would allow is for looping the contents and replacing the other XML tags inside of it with something else.

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 separate the configuration and use SQLite instead. It would allow me to create a number of tables and not clutter up the MySQL database. The configuration doesn’t really need to have any special features that MySQL offers and SQLite could offer a speed boost. As of right now, I’m not really using the configuration, so it won’t be all that hard to change over to SQLite. I will test and see how well it goes.

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

The Template should have the ability to load the template skin, load the XML Tags, load modules, and output the result.

The Template Factory

I believe that the Template Factory should take the name and then load the skin class, since the template folder is set anyway.

Functions:

• Constructor: Name of Template
• Load Module
• Output

The Load Module function will load in an object that holds the module class code for transforming the skin.

The output function will display the finished contents… as will the destructor if it hasn’t already. It should allow for controlling when the contents are outputted.

XML Tags Classes

There will be one main class, with a few other classes for iterate through the XML tags and replacement. It should simplify things and allow easier creation of other tag classes, while speeding up tag development.

Module Factory

Module factories are loaded and take the contents and replace the xml tag with the results. The Module works by itself and returns the result is a simple way of writing it. It may also implement an Iterator, for buffering. Separating the Modules out for different components allows for easier modification, implementing new features, and use in other development projects.

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

Version 0.9 will be another direct rewrite of all classes and will implement a lot of SPL interfaces and use Factory Class Design in the development. This will be done once version 0.8 is finish and version 0.9 will use the 0.8 code, much like the 0.8 is based off of the 0.7 code.

By the time I do use the SPL, I should have a better understanding of it and the core systems should be pretty stable. I don’t have the time to rewrite a lot of the other systems to work with SPL as I don’t want to spend the next month debugging the code. I may try to implement some of the basic interfaces and see how well it goes in preparation of version 0.9.

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