[botmeister]

I wrote most of this late last night, and some of it will add to what botman has already said above ...

The UB project can be made into something that is very complex, and complex tasks tend to take a long time to complete. If the time to complete is too lengthy, then there will be a lot of developer turnover, which will delay things even more, and the project may drag on for years. A long development cycle should be avoided right from the start.

How we are organized is of great importance. Those of us who have worked on software teams before will know what to expect, so let's deal with the inevitable challenges right from the start.

The development team must be able to make difficult design choices quickly, therefore we'll need a "Project Leader" to help facilitate the decision making. I suggest that we look at the how Bots United is structured for some ideas on how to structure the development team, or at least get the ball rolling.

The bot template concept with plugins was proposed for some very important reasons that everyone should understand:

The bot must be very flexible and allow multiple developers to add their own ideas on to it without much restriction or tight collaboration.

We do not have to actually build a fully functional bot, we only have to build the template, and this will save us a significant amount of time. It is the template that will allow developers to add their own plugin functionality without having to build an entire bot from scratch.

The template should keep things as simple as possible by only providing services that the various plugins and "game engine drivers" connect to. The template should not be a functioning bot by itself. It becomes functional as a bot only after a suitable collection of plugins are assembled together.

Getting to the point where plugins can be added will be the first major achievement. I suspect that we will want to add a few demonstration plugins to get the plugin devlopment ball rolling. The UB template will automatically help facilitate collaboration across plugin developers because it provides a consistent standard to work with. For the first time, we'll see developers working on building a common bot, but at the same time not actually working on the exact same bot! We'll also see for the first time users gathering up the right mix of plugins to make their own "flavor" of a bot, and perhaps people will be encouraged enough to learn C++ and tinker with modifying plugins to suit their individual needs better.

I propose we break the project down into "phases". Each phase should be completed relatively quickly before moving on to the next phase. We won't always know what is needed, but this is expected because a lot of the effort is R&D and we'll be breaking new ground, so we'll be learning and changing our ideas as the work progresses. There will be multiple "phases" of completion which taken together mayl span several months or more, but no individual phase should span more than 3 months or less if possible.

We define what "completed" means for each phase, so that a realistic time frame can be chosen and we will know what the final result is expected to be. For example, the completion of "phase one" will mean far less than having a fully functional bot template that actually works with 20 different game engines. Perhaps all it will do is provide a crude demonstration version of the plugin capability and engine interface.

This project will have to evolve over multiple stages.

I'd also like to point out the UB project will probably differ significantly from the UA Titan project. One difference that comes to mind is that a bot must function in real time without bogging down the game play. An administrative mod is not normally cpu intensive, and the design choices made will reflect this luxury. For the UB, we'll have to pay a great deal of attention to keeping down the CPU usage and making sure that adding multiple plugins does not slow down the game play too much. Ultimately of course it will be the responsibility of the plugin devloper to make sure their plugin does not kill things, however the template interface should be built in a way that helps plugin developers build good plugins that don't bog things down. We can do all sorts of things, including diagnostic tools which identify which plugins are causing bottlenecks or other problems, etc.