Tag Archives: Mecha Asylum

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:


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:


Mecha Asylum Code Reuse and Refresh

Reusing Old Game Engine Code

I’m finally using some of the old game engine code for the new Battle Machines/Game Engine project. The interesting thing however is that the Game Engine was based off of the old Mecha Asylum code. I’m going to also use some of the old Mecha Asylum code with the development.

The point is that I have spent a lot of time on Mecha Asylum and the Game Engine. It would go a lot faster if I just reuse those items instead of recreating them again.

Merging Mecha Asylum, Game Engine, and Battle Machines

So, what I’m doing is merging the best parts of Mecha Asylum, the Game Engine branch off of the Mecha Asylum code into the new Battle Machines code. It would be nice, since it would be easier to move the code over to Mecha Asylum when the time comes. However, I believe I’m probably going to buy a new template for Mecha Asylum before I do so. That won’t be for another 9 or 10 months. The work that I’m putting into Battle Machines and Heat of the Race won’t be wasted when I finally restart Mecha Asylum.

It would also be nice to have three games to be under Absidon Games beta status. However, it would be interesting to place the data from index.php into other files, so that index.php doesn’t have to be edited at all. Work will probably begin soon to do just that and remove instances of BM_PATH and instead use GAME_PATH and then use that for all of the files instead. Or, to use set_include_path() for the library instead. It would make things interesting, using the latter and would have to use relative paths.

The point is, that all of my work on Mecha Asylum and the months spent on the Game Engine won’t be wasted and will eventually be imported into the new Game Engine that Battle Machines will eventually use. The idea of the old Game Engine was to create everything, the new game engine is going to use other libraries where possible.

After the Merge

I suppose it would be time to delete or archive the old Game Engine and Mecha Asylum version. I suppose it would be worth the investment to change Mecha Asylum to use the new Game Engine. Even so, working on Heat of the Race is something that I really need to do and have put off for a long time. By the time I get back to Mecha Asylum, I want to have a pretty damn good idea on how to create browser games and the tools that go behind them.

I think I’ll probably rather delete the Game Engine files since there isn’t much there and what is there is pretty worthless.

Possibly Related Posts:


Races and Planets

  1. Universe
  2. Galaxy
  3. Solar System
  4. Planets

1. Universe

The universe will hold a wide range of galaxies and Solar Systems and allow travel between them. Travel between the Universes is a very long process and would require the technology to do so. The number of Universes will also grow with the amount of the people registering.

When 20 people register the second universe will be opened up. When 50 people register, the 3rd will be opened. 100, the 4th, and so on.

2. Galaxy

The galaxies hold a number of solar systems and the number of each universe will be limited to around 30.

3. Solar System

The amount of planets in a solar system will be random number between 7 and 15. They will most likely be created at the reset of every game. It will hold the planets and travel between the planets will be a simple one. Travel between the solar systems will take a little longer.

4. Planet

The planets will have a random amount of spaces predefined when they are created. The spaces allow for buildings and upgrades to be made. The amount will be between 45 and 350.

Races

There will be three races that will each give bonuses and drawbacks. The player will be able to pick which one they want and not be able to change it until the next reset.

Possibly Related Posts:


Space Warrior Plans

Game Engine

Space Warrior will need to have an extensive customization options in the admin panel, while completing the rest of the base admin panel features to finish up the Version 1.0 of the game engine (including guilds and alliances). It will also fully support buddy lists with the other parts of the game. Since the two games are compatible, I can replace the Mecha Asylum game engine files and fix the problems before I release the game engine. It would also allow me to have at least two games based off the first game engine version before it is released.

Game Design

If the game is going to be a clone of another game, then it needs to be placed in another setting and have reason to each of the parts of the game design. The game needs to be fun and have a list of improvements over the game it is based, since the owners of that game would probably easily be able to add the features of the clone easily. Anyone can copy a game, but the problem is that by doing so, you would alienate the fan base and if it is just for the money, then even more would be alienated.

The question has to be asked, “Why should I play this clone game, when I can play the completed game it is based off of?” If there is no good reason for it, then the game elements need to be focused on again. Decisions and game details need to have a purpose and if it exists in the base game, then it needs to be different from that of the game it is based on.

“Is the feature I’m adding going to be used by the player or is it just something I would like to see?” If a feature isn’t going to be used by the player at all, or the majority of players aren’t going to touch it, then there is no point wasting time to create the feature. The game design is based off another game, and by playing the other game, a person can sort of find which features they would like to change. Whether they should change these features based on how they feel or how everyone else feels is a matter that should be addressed.

Sneak Attack, by using the suggestion forum, one can sort of hand pick features not included in the base game and add many of them. At the very list add support for it, but then again, it comes back that the original game can go back and easily add the features also. So the point comes to adding support for many of the features and fitting it in to the new game. By adding support for many of the suggestions, then you can secretly add the items and if they add the items to their game, then you can just add the rest of the features in the suggestion list. It would then become a game of cat and mouse, until they either stop or unleash a newer and better game. Once the suggestions have been used, it would be impossible to go back to their forum again to take suggestions from that game again. Care also has to be taken to keep from breaking any copyright or plagiarism laws.

Technology

I’m going to create the technology and add support for many of the features in the game and for new features down the line. By both creating an easy way to add items to the preset features and making it easy to add new support for future features. The game itself shouldn’t take more than two months to complete and that is only part-time, while I complete other elements, such as fixing the rest of the game engine parts.

Possibly Related Posts:


Mecha Asylum: BETA v1

Balancing:

I need to continue to balance out the power levels, the city population and earning credits, and earning cities and mines.

I also need to continue to work on balancing out the attacking and how a player wins and loses. I need to make it harder to destroy a player and even out the powers based off of mecha weapons and armor compared to enemy mecha suits and defenses.

Attacking:

Need to add support for the Buddy List.

Spying

I need to finish adding support for spying based on the colony level and perhaps add little mecha spy bots for creating better power level calculations.

Attacking

I fixed the perimeter bug, so that it should be easier to find out which cities should be given to the winner. I haven’t added support for gaining cities as a reward.

Group Wars

Once I add groups and alliances, I need to add war support based off of the group and alliance features.

Final Version:

All of the balancing has been evened out and the prices are finalized.
All of the bugs are worked out and there are no cheating exploits.

Possibly Related Posts:


Transporting between Planet and Moon

Transfering between Planet and Moon:

Transfering won’t happen automatically and will need to be upgraded before it works instantly. For mecha suits to be used on the planet they need to be transfered to the planet base and for any attack in space, they need to be at the moon base. It makes sense to transfer the two back and forth.

Levels:

  1. 24 hours
  2. 20 hours (256,000 credits)
  3. 16 hours (512,000 credits)
  4. 12 hours (1,024,000 credits)
  5. 8 hours (2,048,000 credits)
  6. 4 hours (4,096,000 credits)
  7. 2 hours (8,192,000 credits)
  8. 1 hour (16,384,000 credits)
  9. Instant (32,768,000 credits)

By my calculations, it would be almost impossible to get teleportation and I may eventually use tech trees to create the teleportation and better transport ships. Right now I’m depending on levels and basic upgrading.

I will need to create the cron job to run every hour to decrease the time and how far the transport ship is from the planet. The reason for this is, so that I can eventually create an attacking option for attacking transport ships. I don’t think it will be that hard to do this, but it should take at least four hours, and I’m going to do it before I start the attacking features.

Attacking

I still need to do attacking, which will have to allow a few more features than just attacking the base. It has to allow the colony to spy on the base and show what the player has. I need to log that so that the player can see it later. Besides spying there are other attacking options that I need to work out.

  • Attack a section of the player land
  • Attack all of the player land.
  • Try to steal a city.
  • Try to steal a mine.
  • Spy on land
  • Attack with Colony

Some of the options won’t be available and others will be dependent on having a colony. I haven’t decided on some of the options and I don’t know if some of the features will be available in this version. The ability to attack the colony and moon base are useful because it allows a player to be weaked once they have gained a lot of power.

Beta:

Power and the Cron Jobs need to be balanced during the rest of the alpha and on in to the beta versions.

Future:

I want to add attacking for taking out colonies but right now since it cost so damn much, I think it would be a better option to probably add health and have the colony take damage until it is destroyed. I also want to add something where you can attack the planet base, but right now it doesn’t seem likely that it will happen.

Possibly Related Posts:


Progress Report: 10/19/2005

City Management:

I completed the city management, which wasn’t that hard since all there is to it is adding the name and changing the taxes. The underlying CRON job code hasn’t been finished yet, but I think I know how I am going to do it. I’m pretty damn sure that people will recognize the system pretty quickly and understand how to exploit it. There will be other stats that work decide how many people will be born and die.

Mining Management:

The CRON jobs still need to be made, but I will work on that when I finish up the other parts of the game. The player can refine their metals and upgrade their mines. I added a feature that should be helpful for upgrading the mines.

Mecha Management:

I want to add what armor and weapons the player has for the mecha suits, but right now there is only the upgrading of the mecha suits. The maximum level upgrading is 50 and I have worked out the prices for upgrading. It is cheaper than upgrading other things but will still be pretty damn expensive.

Metals Market:

I finished the metals market after a long time putting it off. It was easier than that I had thought and it works really well. There are checks to make sure that the player doesn’t take or give more than they should. There are no checks for max values and letting the player buy only what is left. There is also no errors given to the player for doing stuff. I don’t think I will put those in right now and I may wait until the next revision of the RTS mode before I do that.

Armor Market:

The armor market works and it allows maximum buying and selling. It is pretty damn cool, and it requires that you use your own metals to make the armor, this will keep players from buying too many higher level armor suits.

Ranking:

The ranking page displays the players and what they have, the buttons doesn’t work because some of the features aren’t finished yet. I want to add to the display the group and alliance.

To Do:

1. Power Calculations
2. CRON Jobs
3. Weapons Market
4. Attack Log
5. Thium Bug in Metal Refining

Possibly Related Posts:


Progress Report: 10/13/2005

RTS

The RTS Prototype is moving along at a fairly quick pace and I should have it done by the end of this week, if not starting the form processing pages to take the game into beta. I have been thinking about extending the RTS version, but currently I can’t think of any good ideas of what I can add to it. Right now I’m just doing a basic RTS version where you grow your army, build your base defenses, and attack other players. The underlying code is a little bit more than that, but that is the general idea.

Besides, perhaps Group and Alliance wars, I can’t really think of anything that it needs. I will be looking for input from beta testers and people playing the game to extend the game. I may extend some parts myself after playing the game for a while and after I get a feel for what parts would be good to extend. I guess that after I make the game I will look at other RTS type of games and see what they do and see if I can’t add it myself to the RTS game.

In the next version I will be looking at adding missions and allowing players to roam the landscape. That would be pretty cool indeed, but right now I don’t have the time frame to complete those features for the RTS version. I did want to connect the RTS version and RPG version, but I may not do that after all. With the current RTS implementation, it is kind of possible to do, with the cities and everything. It would be cool to do it, but it will be at the bottom of my wishlist. I was hoping for a basic RTS version, but not as basic as it is going to be. It does kind of suck at how simple the game will be played.

I should just work to completing what I have planned so far and then look to extending in a new design document. After I complete the game engine I need to work on making both modes work off of the same game types. I also want to try to make the RTS version include computer controlled players to add into the mix. I was thinking of add that to the RPG mode.

Online Members

I need to add online members list to the core Game Engine Features. I was thinking of just listing how many admin members and regular members are online and then have a link to them. Depending on whether they are in the game or not, have the name allow them to attack the player. If in just account viewing, then have the player mail the person. I think it could work off of the member list in some way to simplify coding.

Future Roadmap

The game engine needs to function like a game engine and allow customization. Right now the game is a little too hard coded to be too much use to anyone. I will go through and add the administration pages and make the game more customizable with using MySQL and SQLite. I will eventually switch over the mysql tables to SQLite for the basic account pages. I am still going to use the finished product of the game engine for Heat of the Race and package the game engine for download. I’m not going to sell it because I don’t want to support the game engine. If people like it and want to donate cash for me developing it, then that would be great.

I think the basic tools of the game engine are great and I hope to further the development of the tools. I will keep track of features I want to add and changes I want to make. The game engine is far from being complete and seriously needs more work before I can give it out. The administration pages are nonexistant and I can’t release the game until that and the rest of the core features are finished along with the basic RTS and RPG game modes.

Versioning

Major.Minor.Bug Fix. Security Fix

The Major Rewrite is usually a complete rewrite of all of the game features from a core templating and uses a totally new system of development. The major rewrite will break every other part of the game and cause the game to be remade.

Minor rewrites are for adding new features or changing old features. Features should be bundled into one minor version. If the minor rewrite, rewrites a lot of the core features, then it doesn’t justify a major rewrite, since only a few things would be broken. Minor rewrites should focus on small changes and adding features to be added to the next major rewrite.

Bug Fix name speaks for itself, it will be used for fixing of any bugs in the minor version. Security fixes will have another decimal devoted for it. I don’t think there will more security fixes than bug fixes. If there are then the two will be switched.

1.1

  1. Simple Plug In Feature.
  2. Adding Full Customizablity to Game Engine
  3. Private Messaging: Maximum PM count for Donators and Normal and Folders. Feature Complete (no BBcode through).
  4. Message Board: Feature Complete (no BBcode through).

1.2 – Plug In Filters and Game Events

1.3 – Additions to RTS mode.

  1. Missions
  2. TBD

1.4 – Additions to RPG mode and Changes based off of the Simple Plug In Features.

  1. Spell Handling.
  2. Missions Creation and Handling
  3. TBD

1.5 – New Installer and Plug In Installer.

1.9

  • Rewrite of core templating system and game features for adding API type features to the code.
  • Major Assessment of the game engine and its features from Research and Development.
  • Feature Assessment from Feedback and Self Development of Mecha Asylum and Heat of the Race.
  • Administration Assessment from Feedback and Self Development.
  • Work on creating the API tools and modules for version 2.0.

2.0 – Completed Rewrite of the Game Engine from Research and Development of version 1.9 and previous versions.

After version 2.0 is complete, Mecha Asylum and Heat of the Race will also be evolved to the next version of game play and features. I also hope to use version 2 to create two other games and extend the development. I also hope to sell the game engine, if I deem it fit enough to be sold.

I have a very limited time frame for completing the first version, but I want to continue development of the game engine to take it to the next level. Other game engines are being evolved and I don’t want to be left behind. In the world of free game engines, the one that has the most features and ease of development is what succeeds. Also free is great towards the success of the game engines. After Mecha Asylum and Heat of the Race, I will go back to developing the game engine and once the first version is completed, I can use the old pages and features. That way, I can develop and evolve the features from the first version in a quicker fashion than in the first version.

By the second version, I also hope to have most of the version 2 core features finished by the time version 2 comes out. Some of the core features won’t be evolved beyond the basic features. There is only, so much one can do, before you can’t do any more. When that happens, I can look away from that feature and focus on a new one or improving an old one. I continue to debate the Message Board and the use of it. There are many forums that far extend anything I would ever be able to do.

I do need to focus on adding BBCode or something like it to the game engine. I don’t really think it is that important, but it would be something for an API to focus on. For the Message Board, I want to add support for linking to the forum. I suppose the first one would be phpBB, since it is open and free. It would also be the easiest to do because of that. Or I could work on making a skin for it instead. I don’t know, I could just work on making my message board as good as I can and then finalize the features and not work on it any more. When I make the API for it, I can allow the other developers add features to it.

Possibly Related Posts:


RTS (first draft): Bases

There are three types of bases that the player can have.

  1. Planet Base
  2. Moon Base
  3. Colony

Each has its own function in the game play, and each will improve the players chances at success in the game.

The planet base is the primary defense against attacks and if it is destroyed then the player loses and has to start over. The player can only have one planet base, but can upgrade the different parts of the base to make it stronger.

    Land

Land is useful in that it is used to mine for metals, and the space can be used to build factory modules. The more land, the more factories can be built and more mines that can be found.

    Factory

The factories can be upgraded to a new level to up to five or 7 levels. The upgrade works for all of the factories and new factories. The factories will be used to process the metals, so that they can be used in other places. The upgrades decrease the time it takes and increase the output amount, the quality, and the efficiency.

    Defenses

There will be three different defenses, for the different types of attack.

  1. Barrier – against the normal land attack.
  2. Locator – looks and spots spies as they try to get in.
  3. Shield – protects against colony attacks.

Moon Base

    Transportation

The mecha suits on the moon have to be transported to the planet and back. There are two ways to do this and the player will have to buy the equipment needed.

The transportation will be in upgrade levels and the final level is instant teleportation.

    Repair

The moon base can repair mecha suits that are damaged and are held in the storage.

    Factory

The factories can be upgraded to a new level to up to five or 7 levels. There will be factories for building new mecha suits per day. The upgrades, increase the amount of mecha are made by each factory in the moon base.

    Defense

Defenses are built for protecting against space attacks.

Colony

- Creates Spy Bots.
- Has Laser to attack the planet base.
- Factory for creating weapons and armor.
- Can’t be attacked.

Possibly Related Posts: