Category Archives: Projects

Writing WordPress New-BSD Library

I think after all of the complaining about how WordPress is GPL and all themes and plugins that use the WordPress library is GPL, I think a solution would be to write a library that everyone can use GPL free. The library will have a clause, which will say that all commercial entities using the library will be required to pay me a sum of money in order to use the library in their projects. So actually, it will be dual-licensed, or tri-licensed.

The first license will of course be the New BSD license, which basically gives everyone the right to use the Library with almost no exceptions for anything. That license will be for those using the project for free projects or for commercial projects that won’t be distributed. The second license will be for distributed commercial projects, like premium themes and plugins that wish to have an End User Agreement prohibiting the user from redistributing the theme or plugin. The third will be LGPLv2 and up, if WordPress ever wanted to use the library and distribute it, but I doubt that possibility. However, it could apply to any GPLv2 or GPLv3 project.

I think part of the issue is that library is under the same license as the application WordPress. Therefore all code that links to it, has to also be compatible to GPL. This means that it doesn’t restrict the user that isn’t in the GPL. The clause to restrict Commercial entities shouldn’t really apply since their license will not be GPL anyway. The licenses that work with GPL, namely the New-BSD and LGPL can be used without restriction. So if the project was GPL, then it would have to use one of the two, and it couldn’t be the one with the commercial clause. It also means that the user will be able to take full advantage of the GPL, which means redistribution and selling it. If a commercial project wants to protects their rights, they’ll use the library, or write their own.

Regardless, I think there are a lot of code in WordPress, which is done right and is almost impossible to reproduce without copying the code. Personally, I’m not going to rewrite the entire WordPress library. I’m just going to focus on the parts that Plugins and Themes use the most. I’m also going to focus on other components to experiment on how they could be improved for optimization.

Oh yeah, I’m also writing the library to where it will be fully unit tested, where applicable and with documentation. The progress is pretty slow with that, but it is worth it. It allows me to see in real time how far I need to go and how much I’ve accomplished.

The project is new, and right the repository is local to my machine. I’m going to put it up on the Google Code, when I get to the point where it can be reasonably be used in applications. Oh yeah, I’m writing the library for PHP 5.3, I’m going to backport it to PHP 5.2.x, but it won’t be available on PHP4. Right now, there aren’t any hosts that are using PHP5.3, because it hasn’t been released. I want to see what it would look like using the top of the line PHP code.

I’m going to be posting more about the library. Well, I suppose I should have a disclaimer, I might not complete the library depending on what happens. It is going to be a lot of work, so I might not have the motivation to complete it. However, I’m going to spend as much time as I can get to it where it needs to be. At that point either someone else can take it on or I can work with some one on it.

Possibly Related Posts:


Mecha Asylum Design Document

The current game is a little convoluted and broken, which means it is unplayable until I rewrite it. I’m going to focus on a minimal feature set for the next version to get the game playable and improve the quality of the features. By keeping a small feature set, I can know ahead what features I should complete and how long each feature will take. Also I’ll know when I’m finished with the project.

This time I’m not going to open the game until I’m completely finished and the game works after testing and acceptance test cases are completed. In order to improve the quality, a lot more testing is going to be done for this game and all of the games I make in the future. It will take longer, but focusing on improving the quality before players bring it up should improve the reputation of the games.

Story

The main setting and story line will change. The game will take place on an alien planet, the soldiers from different fractions crash landed and need to rebuild their fleet to get home. The other fractions aren’t going to make it easy for the others. The players will need to regroup, rebuild, and fight off the enemy to escape the planet and head back home.

Focus Points

The focus points will be territory, soldiers, research, and buildings. These will be tied together and balanced, so that the meek aren’t completely overrun by the strong. There will also be time limits and the success condition will happen over several months.

I want the game to last long enough to where new players that joined late can learn the game, group with people and appreciate the game long enough to where when the next game comes along they can just jump in and start as soon as possible. They might not win, but they’ll have the opportunity soon. I also don’t want the game to be over soon enough to where none of the players had enough time to accomplish the objectives and enjoy the game.

Territory

Research items used to escape the planet will appear at different locations. Only when the fraction has captured the research item can the item eventually be used to escape. This will mean that a grid based system will need to be used in order to coordinate where the research items and what land the fractions hold.

LandThe Grid structure of the game will limit the amount of land the players will be able to fight over and hopefully should limit the amount of players are in the game. I believe I’m going to have a main grid that covers the planet, sort of like latitude and longitude. Then sub grid coordinates with those and so on. The containers will be big enough to hold the player and a number of buildings.

This will mean that one piece of land is actually an square acre or larger depending on the amount of buildings I finally allow. Actually, I think I’m going to do it in sq. miles and sq. kilometers.

This should allow for quick access to where players are currently and I won’t actually have to populate the entire planet with coordinates. By calculating the distance, I can figure out how long it will take for one player to attack another. At the most, since the database table could grow to be very large, or at least the coordinate table with many rows. It won’t take that much space since the most the table will have is numeric values with one of those pointing to the player which holds that piece of territory.

There will also be mining to harvest precious materials in order to pay for mecha suits, buildings, and research. The amount of mines will only be preset for the initial land of each player. Captured land will be randomly generated and will remain until the game cycle is complete.

When the land is destroyed only the buildings on that land will be destroyed or captured.

Soldiers

The mecha suits from the previous game will be used in this game as well. The mecha suits will gain attributes that will be able to be extended, so that balancing can happen quickly. Since there are only going to be five mecha types, the base attributes might be hard coded with the modifiers held in the database.

The mecha suits will be built from buildings, and require men that will also grow depending on the amount of food, research, and housing. Housing is another type of building that can be constructed.

The different suits have different capabilities that allow for different maneuvering, strengths and weaknesses. Some of the land types will not be able to bring down the flying types, no land to air missiles. The strength and weakness ratio will be dealt with the Rock-Paper-Scissors usage. This will improve the balance and prevent one player from building one type to rule all. That said, there is still one type that is all powerful, but will be extremely expensive.

The attributes will be about four or five to start out, but I can envision that future versions having more. The difficulty is that the more attributes the harder it is to balance the game. I don’t think more than 10 will ever be used, but that will decide upon later and depending on the game play.

There will also be a mechanical device that will spy, thief, and capture land/buildings. This device, called a probe, will not have any attack capabilities, but will have other purpose during the game to help find the main research items.

Research

Research will be very important and I will build a tree much like the grid idea. The Research will have dependencies, amount of time to complete, and materials. I’ll create the tree after the component is completed and think of what will go into the tree after it is complete.

The feature seems to be easy to create, but it will be difficult and time consuming thinking of all of the research items.

Buildings

There will be different types of buildings for different purposes. The list below has them all:

  1. Housing

    Used for the amount of men will be available. Housing will be needed and when these are destroyed, then the available mecha suits can not be used beyond the amount of men available. Will also double as food suppliers, because there won’t be a food building type.

  2. Mecha Manufacturing

    Builds the mecha suits. I’m undecided, if one building will build one mecha suit, or if the building can be queued to build all suits for one type at at time. I’m going with the former, but the latter will allow for greater flexibility.

  3. Research

    These types of buildings will be required for research, there will be different research buildings. There will also be one main building for improving the research speed and level.

There will not be much macro-managing with the buildings, so besides the research buildings, there won’t be many buildings to develop items.

New Player Protection

The game will employ “New Player Protection” to keep stronger players from attacking new players. This will be based on the strength of the player and as long as the player doesn’t attack anyone else. This should allow for new players to grow and learn the game without being harassed by other stronger players.

When the player has graduated from this status, there will be ranges for attacking. This is only in the event that the game reaches enough players that each range has enough players within it. I’m going to try to develop the ranges to where it is dynamic and allows for recalculating the ranges based on growth and the amount of players.

Game Cycles

The game cycles will continue until all of the research items are collected and a single fraction has collected all of the pieces needed. The research items will not exist all at the start of the game. I want to allow the game to continue for at least two or three months before all of the needed items are available.

There will be more than one research item available of the most basic items, which will be available at the start of the game. Other ones will become increasingly rare as the game goes on. The first couple of cycles will probably require that the research items be “dropped” near the territories of the players, so that they can be found within the five or six month hard limit, where the game will automatically recycle whether or not anyone “won.”

Collecting all of the research items is the win condition and required of the players to track the components down. This will force players to try to collect as much territory as possible.

Possible Modules

Modules are game components, which can hopefully be used on other games. If developed correctly, these modules below can be used in future and past projects. They will be developed separated and updated on all of the games, since they aren’t tied to any single game code.

The games will be developed around modular components to reuse as much code as possible. Each game will have separate components that won’t or can’t be used elsewhere, but as much code as possible will be transferred to the Quantum Game Library as possible.

There will be the code that will exist in QGL and the plugin code for the game engine that will use the QGL code. The code that isn’t dependent on a database will be committed to QGL and the code that does rely on the database will not be part of the QGL.

  1. Territory Grid
  2. New Player Protection
  3. Research Tree

Possibly Related Posts:


September WordPress Development Plans

Inline Documentation

I have switched my focus to the wp-includes directory files, because there is a lot more support for documenting those files. Peter Westwood helped document general-template.php and Scott H helped with formatting.php. There are only 13 remaining files that need to be documented and I plan on finishing the remaining ones before next week is over.

I hope that those who have contributed will contribute some more. It is a great feeling to be down to such a small number, as opposed to the 26 files from several months ago. It is nice and I hope to have a few more files done today.

It is beginning to get to the point where the functions I’m trying to document aren’t within my ability to correctly do so. I’ll try my best, but I’ll hate to leave the functions without any type of documentation. If it comes to it, I might have to use the functions to understand what they are supposed to be used for. Doing so would take a lot more time, so I hope there aren’t a lot of functions that need this method.

Plugins

I still want to develop several plugins from my previous list. It would be nice to grow my list of plugins. There are some enhancements I’ve been waiting to do for a couple of my plugins. Alternative Mailer needs to support attachments, but I’m actually unsure how to go about doing that. It needs other enhancements.

WordPress Acceptance Tests

Finally, if I can get to it this month, I want to start writing some acceptance test cases using Selenium. WordPress 2.7 is a little too buggy for my tastes and I want to offer better QA, so that users won’t take up arms for the lack of proper testing.

It should go fairly quickly. I’m going to focus on the Administration Panels first and go through each page. There should be upwards to about a 1000 total tests. I think I’m also going to plan it out a bit more, so that it can be known when all of the tests are complete.

Given how much time I’ll need to devote to my plugins, I’m not sure I’ll be able to finish this month. However, starting it and then finishing it in October might give better reason to releasing WordPress 2.7 in November instead of a month early. Well, depends on I think it will take a full week to do everything I need to finish up the plugins and create the new ones. That will give me a week to finish this project.

Given my future plans I’m not sure I’ll be available to create any patches for the administration. It isn’t my area that I usually write patches for. Also, I’ll be moving on to other projects that use the WordPress library, but I don’t really want to support the Administration, unless I have to. Regardless, the tests and bug reports should help the community and core team fix the bugs on their own.

I’m not going to use the Automattic WordPress Tests repository. I’m going to create my own for this project. It is going to require more work than the WordPress Tests, so I’m unsure how many will actually participate with using it.

Possibly Related Posts:


Heat of the Race Design Document

Heat of the Race is a racing simulation, that is text based. The player customizes their cars and bikes and competes against other players. The setting will take place in the future, so that the car and bike components and racing locations will be futuristic.

The player will win money from races and will be able to buy better parts to go faster, and complete races better. There will be racing teams that will help each other and will be able to compete against other teams to win greater amounts of money.

Cars / Bikes

The cars and bikes will have attributes that each part will increase or decrease depending on the quality. The speed of the car won’t matter much, if the vehicle can’t turn at the top speeds. The amount of upgradable parts will be small with the first version, but the amount will increase as development continues.

There are two types of bikes and cars, one will be with wheels and one will be hover crafts. The player can have both types, and unless they have both they will be restricted on which race track they can go on.

Some attributes don’t really make sense, since the player will not be able to control the car and will get the results quickly. It is text based, so there isn’t much that can be done to allow the player to control the vehicle. Future versions might have something from old Nintendo and arcade games to improve the racing experience. The first version will just give the results immediately.

Race Tracks

There will be several race tracks with different qualities of turns, wetness, temperature, etc that will affect the cars. The race tracks will also be one different planets and in outer space. There will be attributes for the race tracks and will also have grid layouts. This will allow for calculating the car attributes based on each race track, like it would if they were playing an actual PC racing game.

Parts

The cars and bikes will have upgradable parts, which will allow for improving the vehicle against other players. The full list has not been decided and will be developed after the game code is completed. The parts will be entered dynamically, so that new parts can be added quickly and current parts can be modified easily.

Teams

There will be the team leader that will control how much the fee to join and stay in the group is. The fee is optional, depending on the team leader and the team leader can use it for gifting players parts and setting as a betting pool for racing against other teams.

I want to develop the team mode to have many enhanced features for controlling the team almost to the macro-management level. I want to allow the team leader to do many tasks for the group, but have most of them to be optional.

This will most likely be a module, so that it can be applied to other games easily and quickly.

Conclusion

This game will be developed next year, during the first or second half, depending on the number of projects that have been completed at that time. Battle Machines will be developed before this, and this game will also be developed after Earth 3045.

I think I might create a simple version, much like the Farmer Sim pbbg, and then continue to add features after the games are finished. I think the goal will be to release very simple game which have all of the features. This will allow the games to be playable, but not take more than a month or two to complete and build off of the other games that came before it. Therefore teams might not be part of the first version.

Possibly Related Posts:


Farmer Sim Design Document

Farmer Sim PBBG

The concept of the persistent browser-based game is simple, you grow crops and raise animals to sell to the different markets. It is a basic simulation of farming, partially because I haven’t farmed a day in my life and I want to finish the project quickly.

There are a few features of play that need details.

  1. The first is land, which will limit how much you can grow and, or raise. This also includes the amount of help is available to tend the land.
  2. The seeds you can plant,
  3. the animals you can raise,
  4. and the amount the market pays for the animal and harvest crops.

Land

Every player will start out with set number of acres. The player can buy more land later in the game, when the player has the money for it. The player’s avatar can only maintain a limited amount of land, before the player will need to hire help. There will be several kinds of help ranging in how well the “help” works.

Cheap help will probably not do much for the player, but expensive help might not be what the player needs either. There will be a balance between the cheap help and the expensive help in the abilities. This is so that each kind should be used. The player should be able to get away with using all of one kind, won’t be as efficient, but will work.

The player will be able to buy land outside of where the player starts. The player will also be able to hire soil experts to test the land to see how well the land will grow crops. To make it simple, the land will either be suited for crops, animals, or both. The land each player starts with is suited for both.

The price for land will be set by how far or close it is to the cities. Having land close to cities has the advantage of being able to deliver supplies faster and receiving money sooner. To simplify the game, deliveries time will be set and can not be upgraded to shorten the time. This will allow for players to buy up land away from the cities for cheap and still grow or raise animals and not be limited for long to their set acres.

Land Attributes:

  • Growth Type: crops, livestock, or both
  • Distance From City
  • Closest City
  • Acres
  • Player

In future versions, I want to have a grid for the acres for the number of cities and create new cities when new players exceed the range of the city. This simple attribute set will allow for unlimited amount of players to be the equal distance from the city, while also allowing for unlimited amount of land to be bought at different ranges from the city.

Worker Attributes

  • Acre Limit: How many acres of land the worker can tend with the base efficiency.
  • Crop Efficiency: How well the worker can tend crops within the acre limit.
  • Livestock Efficiency: How well the worker can tend livestock within the acre limit.
  • Hours of Work: How long the worker will perform their duties before ending their “shift”.
  • Price: How much it costs to hire the worker.

Even the player’s avatar has the same attributes, so this will allow for easier balancing of the game. It will also allow for adding new workers in the future. I only plan for three other types other than the player’s avatar worker. I’m not sure if I’m going to tell the player all of the attributes, but they will be pretty simple to figure out in the first version.

The cities will have their own attributes, but those will be kept secret from the players. The land will also have a concept of taxes and overhead. This will prevent the player from gaining to much land and money too quickly. The player will need to make at least so much to prevent bankruptcy. Going over the overhead amount will give the player profit to enjoy spending on more land.

I’m wondering if the taxes and overhead can be built in to the market of buying seeds / animals and selling crops / processed foods. If the supply is too much then the player will make less than what was spent to buy the seeds. This can sort of work like gambling in that the player might lose money on the market or gain money on the markets.

Seeds

I’m going to limit the amount of seeds, but I’m going to develop the game to where I can easily add more later. The seeds will have attributes that will allow the player to predict and know when to plant the seeds and how long it will take.

Seed Attributes:

  • Plant Season: When the seed should be planted, so that it can grow
  • Growth Length: How long it takes before the seed is fully grown and can be harvested
  • Base Price: How much the seed costs
  • Sell Base Price: How much the crop goes for in the market. This fluctuates based on supply and demand.

The seasons will go by and the player will grow the seeds. The player will be able to grow crops many times during the different seasons, so that the player will be able to make enough money by growing enough crops during that season.

Seeds

  1. Strawberries
  2. Corn
  3. Rice
  4. Green beans
  5. Cotton
  6. etc

The problem is that each seed has to be researched, I want to have at least 10 or at least three that can be grown per season and several that can be grown all year around. It might come to it being that all seeds can be grown all year around and just have it to where next version the season are restricted to certain seasons.

Livestock

There will be only a few livestock that can be grown. The basic one of course will be cows to get milk and cheese. Chickens are another. You’ll be able to breed the animals to get more and there will be a lifetime for the animals.

The processing, for the meats, milk, cheese, etc will be automatic. In future versions, it will require processing buildings to process the animals. In the first version, it will be done automatically.

Markets

There will be a market for buying seeds and animals, and a market to sell crops and processed meats, cheese, etc to the cities. The buying will be a set price, but selling will be based on supply and demand. Also, the demand will be based on an algorithm that will change based on the “needs” of the population at the city. So each city will have different demands and once that demand has been reached the sell price goes down.

Possibly Related Posts:


WordPress Controller Design Overview

I’ve been thinking about this and I really do think that the code could be improved for the Model-View-Controller implementation. My focus is more on the model and view and not the model however. There is code which exists in different files, which I would like to combine in some areas and split up in others. Some areas do things that it probably shouldn’t be required to do.

Rewrite Component

The rewrite component tries to find, or query what controller is needed to be run. The difficult parts are figuring out what method is being used. Is the page being accessed using URL query vars, or for example index.php?p=## is it the path info method (index.php?/2007/10/5/1) or finally is it the mod rewrite method or permalinks.

It is highly possible that the code might be an combination of the query vars and permalinks. The rewrite module must enable the plugin or code to transform their code to use one or the other. It still must support query vars along with path info or permalinks.

There will be several support classes along with the Rewrite Component. The first will determine whether or not mod_rewrite is even enabled (probably use an option like now). Another component to test each of the methods described above and return the one that makes the most sense. Finally, the last support class will extract the URL useful information based on the query vars and, or URL path.

The main component class will be the WordPress_Rewrite class, which will be used to push to the controller to handle the code.

Mod_Rewrite Component

This component, I want to seriously overhaul to simplify the code base and try out some fluid interface design. It will most likely use most of the same code, but split up into multiple classes.

Controller Component

Ah, the catch with this is that the Controller just needs to be an object or function, which loads the correct template or plugin file. So I mean, you could very well say that the Rewrite class is the controller, but the hook or object will be expected and run.

Possibly Related Posts:


Thirteen days of Writing WordPress Inline Documentation

My original intention was that after school I would write inline documentation for WordPress, while going back over old patches I made and update them for 2.6. The problem I see with that is I might be spending more time trying to get the patches in to the core then I would be writing inline documentation.

I believe that if I succeed with my intention that all of the wp-includes will be documented for WordPress 2.6. Which will be great, but I also plan on having repositories for creating patches for the 2.5 branch and for the 2.3 branch for the inline documentation. At some point I’ll create a patch which documents all of the files for the 2.0 branch, but I’m still undecided.

  1. Tuesday, the 13th of May
    1. Update current trunk repository and fix any conflicts.
    2. Create two new repositories for the 2.5 and 2.3 branches.
    3. If time, start fixing known documentation issues and go over current documentation in all files.
  2. Wednesday, the 14th of May

    Fix known documentation issues and go over current documentation in all files.

  3. Thursday, the 15th of May

    Document user.php, and start query.php documentation in the wp-includes folder.

  4. Friday, the 16th of May

    I have surgery this day, so I might be a little out of it, but if I’m semi aware of my surroundings and feel up for it, I will try to document cron.php and finish documentation for wpdb.php. Also, if during the check over the old files, if any previously completed files have undocumented functions, then to document them also.

  5. Saturday, the 17th of May

    Depending on the pain, I’ll document category.php and start comment.php.

  6. Sunday, the 18th of May

    Finish both query.php and comment.php documentation.

  7. Monday, the 19th of May

    Start functions.php documentation.

  8. Tuesday, the 20th of May

    Continue working on functions.php documentation.

  9. Wednesday, the 21th of May

    Finish functions.php documentation.

  10. Thursday, the 22th of May

    Finish post.php documentation.

  11. Friday, the 23th of May

    Start formatting.php documentation.

  12. Saturday, the 24th of May

    Continue working on formatting.php documentation.

  13. Sunday, the 25th of May

    Finish working on formatting.php documentation and functions.php, if there are still functions to document.

  14. Monday, the 26th of May

    Create file level documentation for all base directory files describing the intention of those files, as well as all other php files. Document shortcodes.php as well.

Files that will hopefully be documented

  1. user.php
  2. query.php
  3. cron.php
  4. wp-db.php
  5. category.php
  6. comment.php
  7. functions.php
  8. post.php
  9. formatting.php
  10. shortcodes.php

Files that will be left to document

These files I plan on documenting on the weekend during the Google Summer of Code, depending on when it starts. If it starts later than the 26th of May, then I plan on continuing documenting files on this list.

  1. capabilities.php
  2. category-template.php
  3. classes.php
  4. feed.php
  5. general-template.php
  6. link-template.php
  7. post-template.php
  8. script-loader.php
  9. theme.php
  10. widgets.php

Planning is never perfect

If I can fully document functions.php and formatting.php, then I think I would have done a good job during this 13 days. Those two files take up a major portion of the total WordPress library and getting them out of the way will allow for quicker turn over for some of the files with less functions in them.

My plans on to work on this roadmap and if I have extra time to pull from some of the files with less functions in them. I believe I can document 13 functions for every 5 hours, so some of the files will overlap on some days, but I’ll probably be able to get out two files in one day.

Out of the list that needs to be completed, I won’t be documenting classes.php and widgets until the very end. I’ll focus on the files which have a short list of functions to document. That way, the list will be down to about three or four files which have a longer list of functions to document.

WordPress Admin Includes directory

Once the wp-includes folder is completed, the wp-admin/includes directory needs to be documented. This directory has a shorter list of files and functions, so it won’t take as long. However, I’m not going to focus on it, until after all of the files in wp-includes is finished.

What happened to documenting everything

Truthfully, I’m trying to document all of the files, but reality probably won’t prevent me. I’ll be lucky to complete the files on the list, but I’m going to at least try.

Possibly Related Posts:


Why Write a WordPress User or Developer Manual

What is DocBook and the Advantages?

DocBook is an XML format, which allows for creating documents independent of any one presentational format, like for example (X)HTML or PDF. The focus is on the content and the fifth revision of the format allows for a lot more freedom for mixing XML namespaces, so it is possible to mix in XHTML when desired.

However, the advantage of writing in the DocBook format, is that it allows for easier translation. They only need to focus on the content between the DocBook XML tags and can easily convert the DocBook to XHTML or a PDF from that one format.

The other advantage is that with the latest revision of the standard has a project that works with DocBook, which allows for displaying the DocBook in XHTML format to see what the final product will be. Aside from the XSL project, I’ve found that converting to other formats are quite a bit more involved.

What is an User and Developer Manual?

The User and Developer Manual concept is very simple: you want the very brief, basic information to give to the user on every aspect of the application. Sure, it won’t be able to walk them through every possible use case, like the WordPress Codex would. Sometimes, you only need to shove the user in the right direction and the user will be able to figure the rest on their own.

That is the concept should allow for some what quick turn out when there is a new release, once the finish product is complete for the first time. Between each release, how much really changes? A few things sure, but the user functionality largely remains the same. Therefore, once the manual is complete for one version, you can just update the pieces that changed and add new sections on new features that were added and release the updated manual for that version.

So you would always have a manual for that version. When you compile the XHTML site and/or the PDF for that WordPress version, you can always release that version. When the next version comes out, you can just release a new XHTML site and/or PDF for that version. So, you would have both versions available for those who are slow to update but still want information on the older version.

The Hard Part

The hard part is filling the User and Developer Manual with content the first time. Also, if there is a major overhaul, then it will mean that major portions of the document will become obsolete and need to be rewritten.

However, I think that if such an effort were made, then it would have some merit to charge for such a document. Whether anyone would buy such a product is yet to be decided. I think in the spirit of WordPress, it should be free as the software is, but I find motivation for such a long and tedious project hard to come by when everything is done for free.

My Goal

I still plan on creating the User Manual, because I still need to do research on DocBook format and become competent in the format, so that when I need to use it for my projects, I have experience on what doesn’t work, what does work, and what the visual output will be while the document is being written. Also, I need to learn how to change the layout and design of the DocBook output, using either the XSL and PDF.

I want to learn how to create both the XHTML site and PDF and writing the WordPress User Manual will allow for enough motivation to actually accomplish that goal. If I can find enough people to continue the project or help out, then I’ll have the manual as completely free and GPL. Well, it will be GPL anyway, but I might decide to charge for the PDF.

Content

The content will consist of text (of course), pictures, and video. Going over the video capture software, I think it will be quicker, faster, and somewhat easier to build the entire manual in multiple screencasts and then use that material to create the content in the User Manual. People will value the Videos and of course the search engines will pick up the content and pictures.

I want to put all of my raw content out there for anyone to use, so that when I leave the WordPress community, someone can reuse the content to take off where I left off. I also want to give the RAW video feeds, so that someone who has a better voice or speaking ability can do a better screencast based off of my videos.

It will be a nice experiment and I look forward to it. However, I’m thinking it will be a Fall project. The Developer Manual portion is a lot more involved, so it will be free, based in parts off the WordPress Codex, and be GPL. I want to have every component in WordPress detailed in the manual and it probably will be a lot more focused with examples and more content.

I’m more torn on the Developer Manual, because the purpose will be more geared towards allowing ease of translation than anything. It belongs on the WordPress Codex sure and I’ll probably build the majority of content on there before converting it to DocBook. I’m thinking of using the WordPress Codex as the planning and organization of the DocBook, before I compile the content into the DocBook format.

Possibly Related Posts:


Second WordPress Plugin: Default Timezone 1.0

This plugin is really simple and aims to fix the problem where WordPress doesn’t support setting the default timezone for PHP 5.1+. This plugin, once activated will set the default timezone to GMT. The reason for this is because WordPress does a lot of calculations based off of that offset. It is better to have GMT time in WordPress at this point.

Requirements

  • PHP 5.1+
  • WordPress 2.0+

Instructions

  1. Upload to your WordPress Plugins Folder
  2. Activate

There are no options and to uninstall, just disable the plugin.

Download

DragonU Default Timezone

Notes

At some point, I will need to find a dedicated place for my plugins and where I can offer real support. For now just leave a comment and I’ll answer your support questions here.

Possibly Related Posts:


Mecha Asylum High Concept Document

High Concept

An intergalactic strategy science fiction game that takes place in another universe. The player mines for resources and attacks for land. Gain prestige and rank alone, or with the help of a team. Develop strategy between the warring factions, resource gathering, and city building.

Player’s Role

The player’s role is to protect and manage the mining station. The mining station needs support structures and people to maintain them. The player manages all of this, while also searching for new territory with resources. The player has a minimum amount of resources that have to be sent back, so the player has to meet that requirement.

The player is also a commander and can have soldiers defending the mines or attacking to gain new territory or gain another player’s land. There is a limit of how many soldiers can be produced and soldiers aren’t cheap, so it is up to the player to manage the survival and strategy to make sure that the soldiers make it out alive.

The player’s avatar is a mechanical suit that can be fully customized with upgrades to the various parts. More can be done to the player’s commander mech than the soldier’s armor. The avatar will be static and won’t be seen except for a few areas.

Primary Game Play Mode

The game has 2D top-down view of the game’s field or arena. The player can see where buildings and resources are, and other game items of interest. The primary purpose is laying buildings for mining, defensive structures, and offensive structures. The field expands to whatever the player needs it to be.

The primary mode is where the player lays objects on the field, the companion mode which is a subset of this one, is where the player can pick which field to lay objects (structures, soldiers, etc) or attack, if the field has not been captured. This mode is split into regions and more accurately described as a sky view, whereas the primary mode is closer to the ground.

The player lays buildings by dragging structures from the left side menu to the center area which holds the sections which will hold the structure. The structures can be moved and removed as needed by the player from within the center area, also by dragging.

The types of challenges the player will face are ones dealing with efficient layout of roads and buildings. Placing defensive structures that closely protect the mine, within the limit of the amount a region can hold. Not every section will be able to hold a structure (water, “cliffs,” “mountains,” etc).

The home region will expand out indefinitely, outside regions will not and the player will have to choose between the different objects that can be placed in the region to best utilize the space available.

Genre

The game is a mix of real time strategy and turn based strategy. The placement of objects and various management elements are real time, so it will be immediately reflected in the game. The attacking in the game is turn based, with a limited number of turns within a set time frame.

Target Audience

The target audiences are those that watch anime with mecha suits, sci-fi fans, and those who enjoy simulations where they manage the environment. The market will be to incorporate a wider niche of those who like mecha suits and want to experience something new and those who like science fiction type of games. Binding it all together is the sim experience where people get to manage the production on another world.

Platform

The platform will be the World Wide Web or on the browser. No other equipment will be required and should be supported on mobile phones also.

Licenses

The game will not try to use any licenses, but the “Gundam” (Mobile Suit Gundam) series might be something to explore if requested. Super Robot Wars (SRW) is another series, but it is already a game series and competes with the Gundam series.

Note:

This section was part of a school assignment and this won’t be followed through. No license will be sought for Mecha Asylum.

Competition Modes

The game will be multiplayer and support cooperative (team) play primarily for competitive modes. The focus must be on the community and while the game must support solo play, it will be frowned down on.

Game Progression

The player starts out with a single mine, a few workers, and a few processing and support structures. The player then waits until enough resources are saved to build new processing structures or upgrade old ones to process the mined materials faster. The player also builds support structures to gain more workers and increase the amount that is mined.

Repeating those steps, the player can slowly build up a good supply and can start an army to gain new territory. Once an army is built the player can attack a region, explore it and set up a mine if the region has resources. The player can keep doing this and mining more resources until the player has a steady supply and can start building bigger structures and finally gain enough territory and resources to build a star port.

Once the player builds a star port, the player can leave the planet and settle on a new planet. When the player lands on the new planet, the player can start over, but with help of the home base, which can send resources. Doing this, the player can start to conquer more territory for higher rank and power.

When the player joins a team, the player can then join forces to attack other teams and devise plans for who attacks who and when. This allows the player to continue more like warring factions and interplanetary battles.

Game World

The game world is a universe with habitable planets scattered around. The player can travel between the planets and mine each one on a hyperspace highway. The planets are of various sizes, but the home planet where all of the players start has no set size and expands with the amount of players. The other planets have a set number of regions that the player can gain or lose (the goal is that the player’s will fight over those planet’s regions while keeping the home planet relatively tame).

The planets each have different terrain, one will be mostly covered with ice, while another will be mostly desert, and the home planet will be a balanced mixed of all of them. This gives the planets different resources that can be mined for the players.

Not every one of the regions on the planets have resources. Keeping regions is good since some of them will have cities, which will supply more workers faster and provide more area for defensive structures.

Possibly Related Posts: