Nanoblobs

== Project conceptual notes, by Argh ==

NanoBlobs is an attempt to build a "new-new" RTS game, and to demonstrate some concepts for AI developers in a simple, straightforward game design.

This is a fairly lengthy (and, if you are not a wanna-be game designer, fairly boring/philosophical) description of the NanoBlobs project. If you are looking for a manual, look at the manual that comes with the mod.

I came up with the idea for NanoBlobs after putting some thought into what AIs would really work with best. AI developers for Spring were still having trouble getting their AIs to play humans well, and I thought that this design might show them some things that aren't inherently obvious- such as the relative strengths and weaknesses of an iterative code process vs. a human mind.

After some thought, I built a very simplistic game design where mobile units of a single type, capable of attacking each other, would build "clones" of one another, and then attack.

This worked fairly poorly, from a game-design standpoint. While it was ideal for AIs (after all, if there's any way in which an AI can exceed people, it's in micromanagement and automated processes), it played very poorly for people- very simply, it lacked any variety, and wasn't much fun. Thinking on this (at least, to me) fairly philosophical question of "deep gameplay", I then proceeded to map out several archetypes that are found in many RTS games:

"Serf" archetype: The Serf, named many things in many RTS games, is a simplistic, non-combatant (or very weak combatant) unit that mainly exists to provide resources. Since it isn't possible (yet) to do resource-gathering in the Spring game engine, I decided that the Serf archetype would have to produce all of the economic resources required, and I made this unit completely defenseless, easily killed, and a fairly weak builder. This unit has been renamed the "Sheep", because, like a Serf of feudal days, a Sheep is a fairly defenseless creature that can be vital to the economic health of a kingdom. That, and I didn't want people feeling I was making a sociopolitical point ;-)

"Wolf" archetype: This archetype can be found in most RTS games. In most games, these are light, fast units, capable of raiding your opponants' economy. For NanoBlobs, I picked the name "Wolf" because it stands in direct opposition to "Sheep"... and fits the general premise. Like real-life wolves, my objective was to make them work better in packs than as individuals. Thus, they are small, relatively weak attackers, but they move swiftly, and can concentrate rapidly.

"Knight" archetype: Knights are close-quarters experts, able to take a great deal of punishment. There are many examples of these units in RTS games, from the Paladin/Troll of Warcraft 1/2 to the Zeus of Total Annihilation, to the many direct equivalents found in Kohan II. I decided that I would accentuate the traditional archetype, and by using the current capabilities of the Spring game engine, I developed a unit that can heal itself extremely rapidly, that also takes damage very selectively from certain units. Knights, in the NanoBlobs game design, are powerful assault units that can break through static defenders and destroy them. Knights were/are the most difficult units to balance, in my opinion, because they required a very fine appreciation of their niche role.

"Archer" archetype: Archers can be found in most RTS game design. Whether or not they are called "archers", they serve the same purpose- long-distance fire support. My main concern with this unit, really, was that they could serve their role, but not be unbalanced. Therefore, they, along with the SpireRook and Knight, form a delicate troika of balanced forces, at the center of the game design.

"Rook" archetype: Rooks are usually boring, non-moving units in most RTS games, called "turrets". In most games, players simply "spiderweb" their opponants with these static defenses to control ground. However, last year I played a game called Metal Fatigue that, while tragically flawed in many ways, provided a better model. In Metal Fatigue, there were "mobile tower" units that could both move *and* hold ground. They were implemented very, very poorly (in short, without too much micro, you could very easily own any size of normal ground force, if you collected a half-dozen towers and a half-dozen mechs armed with appropriate weapon mixes) in that game, but they gave me an inspiration for a unit that was mobile, could do area-control, but was not fast enough to act as a tactical weapon. Thus, the SpireRook was born.

"Lord" archetype: one of the great legacies of the Total Annihilation game design, and (here I'm going to offend OTA fans, but I don't really care) one of the few areas in which TA was really all that original in concept or execution... was in the amount of special power invested in the starting unit, known as the Commander. I deliberately decided to preserve this unique unit's feel in NanoBlobs, as it was one of the better ideas in OTA, and I think that it contributes a great deal to the game design. OTA fans will see immediately, however, that I have made some significant changes to this archetype. For one thing... in the very few games that have even slightly attempted to emulate this feature of OTA, the Commander archetype is invariably slow. In addition, the unit is usually only able to build on a rough par with later, stronger builders. Turning this on its head, I made the Lord a fast unit that can rapidly move around the battlefield, seeking places to build new units and re-arrange the structure of the battlefield. I am not sure how quickly players will take to this feature, if they ever do, but I was quite pleased with the overall feel- the Lord is a strategic unit, not merely tactical, and can very rapidly restructure a warzone.

There are other units in NanoBlobs, to give the game additional structure and variety of play, but these are the primary concepts that I built the game design around. I hope that anybody who reads this gets a better idea of what went into this very unusual game design.