Battle Machines (Robotechnik) Design Document

I’ve been planning on developing or at least getting the PBBG up for a while now. It has been down for about four months and the longer I take, the more time it is going to be offline. So I’m going to finally get around to it. Here are the plans, the overall, the goals, and the stages for how the game will be implemented.

Design Documents don’t have to follow a formula, just write your ideas. The important element of the Design Document is that you write the design document. If you don’t, then you will forget features and ideas that you have for the game. If you have ever forgotten a feature, then you know that feeling where you know you had a really awesome feature that would knock the socks off the gamers.


The license is going to be GNU Affero General Public License, version 3. This means that you can extend and do whatever you want with it, sell, build modules, make money, and whatever. The restrictions are mostly that you don’t say that you wrote the application and make the source available. It also means that if you change something, then I will get that change.


The front-end will include the average features that allows you to see the game before you play it and register and authenticate in to the game. It might not seem like much, but the front end will probably take at least two weeks and I’m going to allocate up to four weeks towards the completion of the front end.

The features are going to be:

  1. Pages – The administration will allow for any amount of pages to be added and the navigation will automatically be built to include those pages.
  2. News – Kind of newbie-ish, but I think it is neat to give your players and potential players updates about what features are added to the game and what is happening. Leaving people in the dark isn’t very exciting and giving players tastes of what is to come and what has been implemented can be interesting.
  3. User Module – Registering, signing in (logging in), forgot password, and demo are going to be parts of the game. I believe this is going to be the majority of the time spent for the implementation on the game.

Administration (Back-End)

The goal for the administration is to allow for every aspect of the game to be managed without having to access phpMyAdmin. It is really insecure and doesn’t give very good reports and information having to do custom queries. Also things tend to screw up when you have human interaction and repetition. The administration is going to have to be developed along side the front-end, because the entire front-end is going to be dynamic.

Something that has been of interest to me lately has been reports, so I want to have graphs of usage, graphs of active vs inactive members. I want to have graphs for paid members vs free members. I want to try to have as many opportunities to let the administrators and moderators to see visual what is happening as well as manage the game. Managing isn’t very “fun,” but graphs, graphs can be fun depending on what they are for.

Something else, I’ve experimented in the past has been cheating detection, but the algorithms are slightly tricky. I want to try it again, but it will most likely be a stage 3 feature. I’m going to try to apply as many hooks as possible to allow others to add it once I release the source.

As for everything else, the main features here, will be managing what items are available in the game, the price, and what everyone has. There will also be permissions, so that not everyone will be able to change someone’s info.

I also like playing my own games, but I think there is a disconnect with having an administrator play the game, because some one is going to feel that the administrator is cheating. Therefore, I’m thinking of preventing the administrators from playing the game and forcing them to create a new account. There will also be logging as to what administrators do and when they did it, so that if someone does question the administrator actions, there will be a log backing the action up.

Game Interface

To be honest, it has been a while since I have played the game, so I’m sort of going to make this up as I develop the game. My main focus will be on the front-end and the back-end. I’m also going to attempt to implement as many current features as possible in to the new foundation.

The game is a robot wars type of game, so you build a robot or many robots and then fight them against other player’s robot(s). The goal, I think is to add more JavaScript and interactivity to the game. I suppose the problem I’m going to have, is that I’m going to be limited in the terms of graphics. However, if the game takes off, then I plan on finding someone who can develop the graphics for me.

Therefore, these features are going to be the main starting point for the game aside from the games past features:

  1. Modular User Interface

    The navigation will be at the left side, of course, but there will be other “modules” that the player will be able to open (show) and close (hide). For instance, there will be an AJAX chat system, which will allow the player to chat with their team and with other players. This can be locked and kept open going to page to page or it can be closed and open per page. I want to allow the user interface to allow this.

    The game will not be completely AJAX, because I want to allow those who don’t have JavaScript enabled to still play the game. It is just that the game will be a lot more interactive, if JavaScript is enabled. I also don’t see that many players without JavaScript, so I’m not going to limit the game for those 1%-2% that don’t have JavaScript.

  2. Store

    The player will be able to build, upgrade, or sell their robot(s) here. Most likely there will be a table (at the start) with the different areas on the robot and allow the player to pick and choose the part they want to buy for that area.

    At the start, the player will be given a set amount of money and allow them to create their first robot. This should allow for customization, but also be fair for every player. So if the player starts out with an awesome body, they might not have enough for any weapons, so the player is going to have to make sure they customize correctly to allow for the best stats for the robot.

  3. Battle Arena

    The game is slightly different per other games I have built in the past. Different robots are going to have different stats, therefore, it only makes sense to allow any player to attack another player. The other player will be allowed to decline or accept and then pick the robot they want to battle against the other. After that, the attacking player has to confirm. The battle will then start and the results will be instant.

    In future versions, I want to allow for real-time battling, if both players are online. In terms of getting the game out the door, I am not going to focus on this feature and just implement the basics.

    The winner will receive money for winning and the loser will lose money. Also given, how long it can be before battles will be fought, it might allow for other players to bet on the winner and then pool that out to the winners of the bet as well.

  4. Training

    The player will be allowed to pit their robot against a computerized opponent with random, but with attributes close to that of the players. This will allow the player to see how they will fare against opponents of like systems. Also it should help with developing their robots and guessing what the outcome will be against like enemies. I’m unsure at this point whether the training will also include missions, which will allow the player to make money.

    I also have ideas on creating AI opponents for while the game doesn’t have many human enemies to make the game interesting. AI is difficult and always time consuming, so I’m unsure at this point whether I’ll be able to get around to implementing it. If I do, then it will be a stage 3 feature.

  5. Teams

    The focal point of any robot war game is a team going against another team. This will be fought much like the battle arena, but the team leaders will make the decisions with the players accepting them. I always want to add as many features as possible to this, but I’m going to keep this simple. The teams will have registration, description (team and player), site link, chat, and battle logs. I plan on extending the team features as the game is developed, but at this point, I only plan on the game taking two months, so while this is a stage 2 feature, I plan on implementing it before the game is released.

User Management

The user has to be able to change their password, see their stats, etc. They will do it here, separate from the game interface. I don’t want to implement the interfaces to where they are cluttered with different details. I want players to focus on the game and those who want to edit their user info to focus on that on only display links that go along with their user info.

You could say the different areas are much like a forum, except that instead of a big forum with posts and replies, you have a game.

Game Engine

The game will be built using Yii (PHP framework), QGL (PBBG class library), and jQuery (JavaScript library). It will be developed completely for Battle Machines, with foundations in set to have the game part stripped out and the game engine used as a foundation for other games. It is just that the game engine and the game will be developed side by side and built for each other.

Stages – Roadmap

I usually develop full game projects in three months. That was when I didn’t have a 40+ hour a week job, so I’m unsure how that is going to translate to how long it is going to take to finish this project. Most likely I’m going to cut back features and just stop after the time has past. I’m expecting the project to be done within the three month time frame. If not, then I’ll return it to later. The most important part, for me, is the game part, which is the second stage, so I’ll have a chance to go back to the user features and administration later.

  1. Stage 1 – 2 weeks (+1 week for Yii Framework)

    Stage 1 is building the front end and the back-end to allow for managing the front end. I suspect this will take around two weeks to fully implement. I’m allow allowing one week to get the foundation with Yii up and running before the first stage even starts. I haven’t used Yii before and I will need to get familiar with it. I think one week should be enough time and I’m expecting that it will only take a few days before I can start implementing the main features.

  2. Stage 2 – 6 weeks

    The game features will take most of the time and I’m going to focus on the above features as well as taking the current features and porting them to the new framework. I’m going to be using a lot of JavaScript, but I have been using jQuery for a while and I’m fairly proficient with it. I’m thinking I’ll be able to prototype the features fairly quickly and get the features fully developed quickly. I’m going to estimate a week for each above feature and an week (or any time left) on any current game feature that isn’t implemented above.

  3. Stage 3

    This will be the stage to pack as many features as possible before release. If there are still incomplete features from the first two stages, then they will be completed or polished during this stage. The main point is not to add many features as possible, but to add features that the player isn’t really going to use all that often. If the player is going to be using it, every time they play, then the feature belongs in stage 2, so that it gets as much time as possible to be developed, tested, and polished before release.

    I have already stated several features that will hopefully be in stage 3. The other features are allowing for desktop applications to interface with the browser game, so that you can have a 2D or 3D playing experience on top of the current browser implementation. Well, actually that is the only other feature I can think of, besides porting the rest of the current game features to the new system for this stage.

I like to do rapid develop as much as possible. That is just how I roll. I also like using old code (that doesn’t suck), so I intend to build upon this version’s code base when developing the second version some time next year. It really depends on how well this game takes off. I want to get at least three games out by the end of this year. Hopefully, I’ll be able to bring the previous developer back to further develop his game. This will allow the game to be worked on after I’m “finished” with the current set of features.

The other two games are Farmer Sim and Mecha Asylum, which will be built off of this game foundation (game engine), which should hopefully shorten the time for those games and enhance this game with better front end and administration features. I’m going to be writing design documents for those games after I finish this game.

Wish there was more?

I'm considering writing an ebook - click here.



Tuesday, March 24th, 2009 design
  • Hey,
    I played your game when it was quite new
    Please could you email me when it's back up?

    Also if you need help with any code/artwork/anything email me, since I would like to help.

  • KarnEdge

    Long time reader... first time poster, I think. Great work, can't wait to see this in action. BTW, I was wondering if knew of any good resources for more tutorials or how-to's for developing PBBG's. This is the best place I've found but you can only do so much at one time.

    I like forums but that's still a bit limited. Anyway, if you have any suggestions: thekarnedge AT gmail DOT com.

    Keep up the great work!

  • Miroslav Vojtu┼í

    Very nice work. I've learned really much how to develope PBBGames :-)

blog comments powered by Disqus


Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.


Got Something to Say?

Send an e-mail to, or get in touch through Twitter at