Tag Archives: Battle Machines

Licensing Woes and “I don’t need Open Source”

Posted by santosj on December 15, 2006 3 comments

*Updated* I rewrote most parts for clarity.

Sigh.

I had a recent discussion about using Astrum Futura for Battle Machines and Earth 3045 with the lead developers of the projects. It did not turn out as I had expected. Really it boils down to that the original developers don’t want to have their product open source and available for free download. It isn’t in my power to persuade the developer of Robotechnik (aka Battle Machines) to switch over to open source. The lead developer already has a team of developers for it, so there isn’t anything right now that I can offer.

The conclusion of both conversations was mostly what is in the title, “I don’t need Open Source.” I won’t be able to change their minds, so for now I would have to remove both games from the planned rewrite over to the Astrum Futura engine. My priorities for next year will be changed because of this.

I am perfectly fine with writing open source software and content with working on the Quantum Game Library and Astrum Futura. Both projects are actually something that I enjoy.

Earth 3045

The plan for Earth 3045 has always been to salvage the parts that are usable and scrap everything else. Mostly the only things that will remain are the general ideas of the game. I also had planned on adding my own ideas in the mix to make it a little bit more unique. There is a reason for changing the gameplay and I will get into that.

When I was told of the idea, I was excited because I had never heard of such an idea. I should have done my research, because a game exists similar to the design of the game. Earth 3045 even has a similar name. I wasn’t happy, but I had already set motions into what Earth 3045 could become and decided not to end the project.

The general basis that you are a member of society and work in that society will stay. I had already developed a prototype for job based game play and thought I could put it to use in this game. I still plan to do that and add some AI in the mix to allow people to decide how well the player is doing.

One of the primary reasons for using Astrum Futura for this project is the navigation and mapping that Pádraic Brady is coding. The thought of doing all of this myself probably would have set the game back a year or so from other coding priorities. The Quantum Game Library will also have components that will make coding games easier. Perhaps the hardest part is the math and already the QGL is strong in that field (for the mapping).

The reason for allowing the coder to continue is to allow him to learn how to program so that he would be able to help once the new system is up and running. I think he will be okay with the changes if the game is better than what he currently has finished. It would also be good to move him away from the Gamer’s Fusion style of coding to a better separation of business logic and presentation layer.

The current engine for Battle Machines and Earth 3045 would require you to rewrite the page, including the HTML to add a new feature. Everything is bunched together and I often worry about security, because I doubt any filtering is done in Earth 3045. The legality of Robowarz (the game built off Gamer’s Fusion) is murky, since technically it should of had its source open and downloadable. The history is also kind of vague but the copyright was all but removed from all pages, except one. This kind of mistake, whether intentional or not will not be repeated.

The lead coder says that all of Earth 3045 is his, but I can tell that it has similar file names to Robowarz, which technically holds the GPL license of Gamer’s Fusion. I would rather be sure that the game is legal and use something else. The Astrum Futura engine would be a good candidate since it has most features that I want. It would also be quicker to add new features, which is one of the leads reasons for not open sourcing.

I’m pretty sure that when the lead sees the final product of Astrum Futura, he will want to use it.

Battle Machines

I may end up losing Battle Machines. Honestly, I would hate to see it go. There can be no compromise, either the lead wants to use Astrum Futura or he doesn’t. If he doesn’t, then no big deal, I’ll still support Battle Machines, since it is a good game. I would rather it move from its current coding style to something a little bit more maintainable.

The Battle Machines is a good game and could become more popular than it is now if it had the right set of features for it. I would have liked to worked on it to give it that push to where it is fun and has better features. However, I don’t want to work with the current code base and had plan on rewriting it.

The idea of making a closed sourced library to use with Astrum Futura would violate the GPL and wouldn’t be workable. I do plan on writing my own code that allows for similar features of Battle Machines, but in doing so, I may break Robotechnik away from Battle Machines. If that happens then there would be two similar games, but like Earth 3045, I hope the lead sees how much better Astrum Futura engine will be over the current one.

The owner has the option of moving or removing it from Absidon. Most of the Absidon support for it is domain and hosting, which costs next to nothing. The owner already has a group of developers which help on the source, so he doesn’t need the help of the Astrum Futura developers or mine. The decision and option is up to the owner of Robotechnik.

Money Model

The developers think that they can make a game and people will want to pay for it. Doesn’t really work that way. The games that do make money had a lot of work put into it, more than the short development cycles that the Absidon games have had.

The license of Astrum Futura does not allow for admins to accept donations for rewards. An admin can accept donations, yes, but it can’t have any reward for the player doing so. Both games give rewards for donations, which I don’t agree with anyway, because the rewards aren’t worth the payment. I thought of removing that anyway.

Using Astrum Futura will remove any thought of extended premium features, but any modifications to the source has to go back to the repository unless it is a plugin. Any plugin has to be available free and open for people to use it. I think it is a better model that way, since other developers are bound to create really neat and awesome plugins later.

Their hope is that the work will eventually pay off and piles of money would flow in. I haven’t really the heart to tell them that this dream wouldn’t come to past until they really offered something in return. Popular games are popular because they are fun first. The whole concept of making a game to make money first doesn’t really suit well on the online browser world. If you have an excellent product consisting of 10 developer and a million dollar budget then you might be able to come away with some money.

In the Future Perhaps?

I just left it at when Astrum Futura is finished, that hopefully it will kick so much more ass off of the current feature set that Earth 3045 and Robotechnik has, that they would agree to sell their souls to touch upon the greatness that is Astrum Futura.

Possibly Related Posts:


Battle Machines Evolved Roadmap

Posted by santosj on October 15, 2006 Comments Off

What is Evolved

Evolved is the codename for the new game core and upcoming features. The final game will simply be Battle Machines 1.0. This is needed to differentiate from the current Battle Machines version.

Roadmap

The amount of progress needs to be measured in some capacity. These components need to be completed before the actual game code can be started.

  1. Updates
  2. Authentication (may use Zend Framework)
  3. Authorization (may use Zend Framework)
  4. Logging (may use Zend Framework)
  5. Caching using the Zend Framework
  6. Subversion
  7. Private Messaging
  8. Ajax Chat
  9. Forum integration
  10. Profanity Filter
  11. More…

Possibly Related Posts:


Battle Machines Developer Guidelines

Posted by santosj on October 15, 2006 1 comments

Background

There are three issues that are addressed here. The first one is security and developer trust, second is keeping the game site stable and working, and finally the developer tools.

When the game owner hands out FTP access to other developers there is an automatic trust established there. With FTP access, developers can destroy work, or upload anything from personal files to illegal stuff. That takes a lot, but it isn’t just the FTP, it is also access to the database, which can also be easily destroyed.

Giving access to the Repository is also a trust relationship, since the development database passwords would be on there. Locking out access to the developers and using the repository instead should not be seen as punishment. The repository will have commit hooks for the trunk and stable branches which will update the testing and live sites respectively.

It should be noted that the FTP site has many more folders than what the developers are interested in. I’ll most likely move the subdomains to the Battle Machines FTP. While for most it isn’t a major concern, on former projects, a few people decided to host files that weren’t project related. While I did discuss it with a few of the game owners, I really only want the FTP to only be used for game related files.

If you want to take the developer changes as they are:

  1. Stable live site changes to keep from site downtime, even from a few seconds or minutes
  2. Establishing developer trust between coder changes by telling who is doing what.

Subversion Repository

I like having as many developers working on a single project. However, giving every developer the same FTP username and password has security risks. It isn’t a matter of not trusting other developers, because I do. It is just that I don’t want to get online and have the message, “Um, do you have the backup of the game files? …Someone deleted everything!”

  1. If a disgruntled developer decides to delete all of the files, can I easily find out who did it? Is it possible to get every change back afterwards?
  2. What if someone decides to upload a copyrighted file and links to it? Would I know which person it was? How fast would I be able to find it? Would I even know to look until it is too late?
  3. Opps moments. “Hey I lost…”, “Could you restore…”, “What happens if I do this?”, and other accidental changes.

The point is that developers don’t need direct access to the FTP server. Only the owner of the game and I (me being Jacob Santos) do and there are some cases where I own the game.

Live Testing the repository will be exported with each change to allow for testing before uploading to the live site.

The next focus, is that I want to track the development and what other developers are doing. There, I said it. I want to be Big Brother. It has occurred to me that I should allow the other developers the option to opt out of the online repository tracking feature I’ll be implementing. However, for my own personal entertainment, it would be interesting to know what the other developers are doing. I’m sure the visitors might be interested also, which is why I’m actively working on it.

Development and Production Databases

To further increase the trust between developers and players, all changes will be made to a separate database than the one the players are running on. This means that a screw up won’t affect the players. It should minimize downtime, between when the change is made and when the feature is implemented and fixed.

This also means that the other developers, besides the owner and me, won’t have permissions to access that database. There should be no way for developers to access the database information, since it will be on the FTP and the other developers won’t have access.

There will be an Admin Panel to allow game manipulation for developers, admin, and staff. This will be located elsewhere and no one but me will have access to that.

Wiki is your Friend

The Absidon Wiki will be the primary source for game documentation, developer documentation, and proposals. Once I start writing information, I’ll most likely also start redirecting answers to there.

It won’t just be some “cool” feature, it is a tool that should be used to help other users and developers on how the rest of the game and core works. I suppose, I’ll have to be the one that will have to jump start the new documentation for the project.

Bug Tracking

The bug tracker will most likely be used more by active members than developers for posting bugs. However, this also means that developers should check the bug tracker on some frequent basis (once the bugs start coming in, I’ll let you know).

If you can’t fix the bug yourself, either do not know how, would require too much work, or just don’t feel like it, then it would also be wise for developers to post bugs to the bug tracker also.

Choosing Bug Trackers

I’m currently using Mantis, I might either go back to Trac or try Bugzilla again. I like the bugzilla dependency bug lists that neither Mantis nor Trac have. Trac also has a importer, so it shouldn’t be difficult to go back to Trac, once Trac stabilizes.

Conclusion

This article and mandatory request may turn away some would be developers. I believe that after some “getting used to” phase wears off, it will be happy sailing. Some of the list have already been implemented.

I should point out that I’m not thinking that the FTP and Production Database lock out will happen within a few days or hours. It will happen in a few months time, the FTP and Database passwords are going to change and the other developers won’t be given them.

The database changes and Subversion usage should help to minimize downtime, allow for changes to be “rolled out” in increments using version and/or build numbers, and to allow the player to play without interruption.

Possibly Related Posts:


Supporting Yahoo Auth and OpenID

Posted by santosj on October 12, 2006 Comments Off

For Battle Machines, I want to kind of move away from the whole Username/Password thing. The future is single sign on and having it will not only help the users that have it, but also the online game that supports it. There is of course, the whole issue of security and making sure that the user is who they say they are.

It wouldn’t be difficult, there are APIs for both, but testing and support will be something to think about. I was thinking of building my own OpenID service using the Zend Framework instead of the PHP 4/5 libraries out there.

It should be interesting to support them when it is done.

Possibly Related Posts:


Adding RSS and Atom Feeds

Posted by santosj on October 9, 2006 Comments Off

The development is cranking out some improvements. I was thinking about adding RSS feeds for the updates and for the repository. It would be totally cool to see if it works.

It would also be a test to see if I can get the Repository logs showing and the best way to do that. It would help with the developer pages later. The RSS feed probably isn’t going to have any database or caching backend, but that is something that will have to be added later to save computing.

Actions on the Front Controller

I did some primary work on the Front Controller to allow actions to be added. I still have to test it to make sure that it works. Probably be bugs all around the new developments. Will work on those outside of the commiting, and just commit all of the fixes at once to save from upping the revision number too many times. Other than that, the repository is going to have to be moved at some point.

Company Section

I decided that the game should have the company features in its own little section, each with a subdomain and a folder on the main site. It would allow the player to control all company aspects.

  • Creating the company (high price to pay for it too).
  • Sponsoring Players
  • Stock Market (will be dependent on sells and how many players buy the stock).
  • Parts Research and Development
  • Others

To put simplify, the current company set up allows the player to make far too much money, way to fast. Separating the company functions will allow for better play. The money in the company play will only be used for the company functions. The money the player makes from winning battles will only be used to either start up a company or buy parts. The owner of the company will receive money from the profits of sells, but the owner can’t sponsor his or her player.

Possibly Related Posts:


Mecha Asylum Code Reuse and Refresh

Posted by santosj on October 6, 2006 Comments Off

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:


Progress Report

Posted by santosj on October 2, 2006 Comments Off

After a few major setbacks, the development is running smoothly. Most of the back-end works and I only need to test out a database item class that I created.

  • Front Controller is only 15 lines and provides some protection.
  • Zend Framework paths work and the config classes are being used. The cache objects will be used next.
  • Database helper functions also work.
  • Elapse also works.
  • Update Item is also almost finished.

The Update Item is something that I need to test and it is some thing that I’m using to help with caching. Instead of caching a page, I want to cache each iterator item and if the item is cached, then to use the cached element instead of getting from the database.

Possibly Related Posts:


Heat of the Race meet Battle Machines

Posted by santosj on September 26, 2006 Comments Off

I plan on branching the code for Heat of the Race off of Battle Machines. This will probably mean that Heat of the Race will allow for people to register before the game is playable. However, there won’t be any advertising, so the people who happen to just stumble across the site should be minimal. I’ll probably do most of the development work off of the Battle Machines repository on a branch. By the time I import the branch into the Heat of the Race repository, most of the work should be finished and so should the template.

When I stop development on Battle Machines, I should just have to work on the game elements and not have to worry about the user components and start pages. Most of the game elements will be finished also, since Battle Machines and Heat of the Race will share similar traits with a few only a few differences.

HEAT Development Cycle

I plan on developing Battle Machines for two to three months, completing as much as the start and user components as possible. I should also get as much game features done also.

As much time as I put into Battle Machines should also translate into less time I have to place into HEAT. The development I place into HEAT should also be transferable to Battle Machines, depending on the feature. Any fixes or new features added to the start and user components should safely be able to transfer over without breaking anything.

Repositories

The usage of repositories should reduce the amount of conflicts from other developers changes. The other developers aren’t currently using the repositories, but that should change when all of the new development is switched over. As easy as it is to use Subversion, I see no reason why they can’t get accustomed to using the repositories.

Possibly Related Posts:


Non-Game Features

Posted by santosj on September 6, 2006 Comments Off

These features are the management and conversational features for the game. Some features would be optionally be available during the “game screen” while others will only be available in the user management panel. The separation is to allow for clear representation of what the game links are.

The UMP (User Management Panel) exists also for when JavaScript isn’t enabled, so that the player can still access those features. There will also be an Admin Management Panel (AMP) available for managing the game features and settings.

Private Messaging

The private messaging will get its own section on the JavaScript enabled game screen and can be hidden by default from the UMP.

AJAX Chatting

I’m going to spend a while developing this to be the best it can in the game. I want it to include private messaging, ignoring, game alerts, and other chatting events. Everyone playing with JavaScript will be added to the chatting. It will also have opacity effects, so that the background can still be seen.

The options will include, minimizing, and hiding the user list.

Forum

See previous post.

Updates

See previous post.

Possibly Related Posts:


MVC Feature

Posted by santosj on September 3, 2006 Comments Off

MVC is Model, View, Controller design pattern. The controller is page controller and this proposal will give the technical details on how it may possibility be implemented.

The MVC files will be located underneath the public domain and the main public web directory should only have one index and a folder for the images and web files. This will also allow for multiple game arenas for separating different features, but keeping the same Model

The Page Controller

The Page Controller will be simple and check for the directory and page structure. This will allow for error checking, because if neither the page nor directory is found, then a 404 HTTP error will be thrown. It will also speed things up since the logic will take less lines. New pages can easily be reordered and created, speeding up the development.

The logic will first check for the file for the last element. If it isn’t found and a directory exists instead, the default page will be loaded instead. If neither exist then a 404 HTTP error will be thrown.

The entire page controller will be contained in the main index.php file in the main public directory. The Page Controller files will be located elsewhere.

The Page Controller files will not contain any HTML and only instance the required classes, functions, and whatever.

View — PHP/HTML Pages

The HTML files will not use Smarty or Template Lite and will use plain PHP tags for the “Templating” in the view files. A templating engine will be used to replace the View PHP variables after the logic has completed.

This will alllow further separation of the page and view files, so that the logic will be contained in the controller pages, instead of in the View files.

Model — Templating

Direct manipulation of the PHP variables is quicker than using templating even with page caching. Also, caching can be done on the Page side where possible for sections that need them, instead of entire pages or page sections.

Caching will be done for data that won’t change very often. It will only store the serialized data and not the HTML resulting data. There already exists classes that handle this type of caching and they will be used instead of page caching, which would have to be done in sections anyway given the dynamic nature of the web site.

Usage In Gamehole!

When I go back to Gamehole project, this is one of the features that I plan to use to speed the site up, as well as offer greater expansion capabilities.

I don’t plan on using this type of MVC and will probably switch over to either Zend Framework, or another framework that offers MVC. The only projects that will use this setup is Gamehole and Battle Machines.

Possibly Related Posts: