Vehicle Wars: Open Progress Report #2

ID:77014
 
Jul 20 2009, 6:41 pm (Edited on Jul 20 2009, 7:42 pm)
Keywords: design
I think I'll do one of these every week until the project is complete.

Perhaps perfection is not an attainable state, but rather it is an outgrowth of something which is capable of continually adapting. In this way, the creator's universe can be perfect without being perfect. I spent most of this weekend in the design phase: adapting.

I finally started coding a bit on Monday. I actually got around to adding some nifty dynamic map generation routines that include rivers, rough, and grass - a new map every game.

Photobucket

Note that this is zoomed out much further than the game actually plays. The graphics look much better at the set 8 view. I integrated and heavily modified 3 turfs from RealQMark's MobsTurfs library. I might just add some beautification code to take off those rough edges between spaces, but I am concerned I might run up against a buffer limit.

Other things done this weekend include phasing out the idea of customizable vehicles (it's just a lot cooler to have more specialized vehicles) and adding a slew of code under the hotkey system. I think I technically could have working hotkeys now if I actually added controllable units with working functions in them.

I'm feeling good about this design. The GUI design is down pat and partly implemented. I've kept the exterior idea of defending a colony against waves of invaders that only increase in intensity the stronger your colony gets. As of today, I've established a great place for the action to take place.

Now, I just have to fill in the blanks. Future milestones to tackle:
  • Getting a vehicle added and following a movement queue. (I've done this many times in other prototypes.)
  • Figuring out what, exactly, is being fought over. My current design calls for pre-built structures, but perhaps I could do something a little more fluid.
  • Adding the opposition. I'm thinking of waves of enemies, tower defense style, but with a few interesting twists. They should be good fodder for the cannons, but they'll not be without cunning.
Jul 21 2009, 7:12 am
One point about the customizable vehicles is that it probably adds a lot of work to the design early on that only bogs down the project--you need to think about balance issues, graphics, and the customization UI. Having a few simple specialized types makes all these issues go away except for balance, which still is an issue but a much simpler one. Plus, it doesn't preclude the possibility of moving to a customizable system later--in fact you're probably better off ironing out the more basic balance issues and the core gameplay mechanics before getting into custom stuff.
Jul 21 2009, 9:03 am (Edited on Jul 21 2009, 11:16 am)
In this case, it wasn't so much the technical aspects that turned me off from the idea as it was the game design implications. It seemed to me that the customization was a bit like a skill-based RPG versus a class-based RPG:

If you give the players the choice to take exactly what few skills they want, the flexibility eventually proves moot, because they'll eventually develop templates of the best possible combinations. Classes are a little more interesting in that you can enforce true strengths and weaknesses.

Though there's a little hitch in making parts exchangeable, I think overall it's actually a little easier to have customization. It's a lot less design work for me - instead of going through the trouble of creating and balancing coherent units for the players to control, I just give them a bunch of parts with built-in tradeoffs, proclaim, "because you can assemble whatever you like, you're all equal" and they're good to go. Sooner or later, certain parts will emerge as 'best' and simple adjustments can be made (maybe even dynamically).

So I'm hoping that people won't look at this and think I'm choosing the easier but boring way. The units are being divided up into specialized roles because it's a bit more interesting that way. The world itself will not be so static - it's always been a goal of mine to introduce a level of dynamic content, and I think you'll see this in an ever-changing world.
Jul 21 2009, 1:11 pm
The idea of auto-balancing is pretty interesting. In theory it can be done by running NPCs against each other and comparing results, kind of like genetic algorithms. If the system saw that vehicles were being used more often with a certain part, or a certain part was underused in spite of being affordable, it could run comparisons between vehicles with that part vs. a different part and try to gauge which works better.

There are a few points of difficulty though. One is that the desirability of a part could have to do with many factors beyond effectiveness: Cost to purchase or maintain, energy/fuel use, difficulty of charging to full power, etc. And this is worse for parts that might only be of value at certain strategic times; you'd need a good AI to judge effectiveness in various situations. A missile launcher for instance would probably be most effective with an unobstructed stretch of terrain and a good line of sight to the target, but without an AI to know this, any genetic algorithms become useless. And players may find emergent ways to use items or combinations of items effectively.
Jul 21 2009, 1:22 pm
One thing that comes to mind is supply and demand. If there's a particularly good product out there, people will start purchasing it more. The supply is stressed, the product becomes more expensive.

As a game balancing mechanic, that works. If there's a particularly good power out here and people start using it more, you could increase the cost of it. Eventually, less-effective powers emerge as viable because they're simply more affordable to use.

This would probably be best done from a perspective where weapons are consumables. Otherwise the first-come purchasers, before the price increased, would have an unfair advantage.

As for AI judgments, I really like how the idea of subordinate/coordinator relationship seems to work out. It's not only useful for the stuff we were talking about before (e.g. the reaction of the peasants to the rabbits ravaging their cabbage farms eventually reaching the ear of the king) but this too.

Lets say instead of programming a tank AI to use a weapon effectively, we program the weapon to use itself effectively. We put the weapon on a tank, and when the tank is confronted with an enemy, it asks its subordinates (its weapons) which would be best at dealing with the threat.
Jul 21 2009, 1:39 pm
Yeah, offloading the AI to the weapon isn't a bad idea there, although I'm not sure it simplifies the problem much. An interesting limitation of the sub/co system though is that it can't make systemic decisions. The missile launcher can't necessarily tell you if it's going to make an ideal hit because its velocity is currently being affected by rocket boosters, nor can it necessarily say that rocket boosters would give it an optimal firing solution. Some of this is solved with more information, like if the main AI asks what ranges of relative speed and bearing to target provide good firing choices, then the master AI could decide on its own if it wanted to use one of its resources for greater speed.

Playing Dwarf Fortress, I've noticed the limitations in the per-object model as well; at times it'd be nice for objects to form a collective voice. For instance I recently had a bunch of masons constructing some floors, one of which was a 3xN bridge (of constructed floor tiles) from one tower to another. Because only three tiles can be accessed at a time, only three masons will work on it at any given moment. But if all the work was concentrated on just building the floor area itself, then you could have any number of masons working on it and just bringing stones to the next available floor tile. Also the design could be made friendlier to multiple masons by doing the middle row first, opening up more adjacent tiles that can be built. I had a similar thought with a 5x5 floor section, that it'd make more sense to work inwards quickly rather than merely stick to the outer edges. If construction priorities were gauged in terms of how many new accessible tiles they would open up, a project that only allowed for a small number of masons could soon allow for many more. But this involves some intermediate level of organization.

In a similar way, a really smart player might know that a certain weapon can deliver a critical hit right after a target is temporarily disabled, so they might give themselves a mini-goal of forcing another vehicle into a situation where they can use a disabling weapon, and then fire the critical hit. A good AI would do the same, knowing that one weapon enhances the strengths of another and looking for opportunities to improve the conditions.
Jul 21 2009, 2:14 pm
I think it's important that there's a two-way communication going on for an AI to work. A tank wouldn't just know its weapons, the weapon would know the tank.

If so, the necessary information to evaluate whether or not the tank is under in a particular condition that would invalidate the weapons' typical tactics should be accessible to built-in AI code behind the weapon, or so I'd think.

It sort of breaks down into a problem of game logic. Is it a good game to have rocket booster velocity a factor? There's also a problem that if you make the AI too good, it invalidates the players.

So having a weakness like being able to land a critical hit at just the right time to disable the weapon is a really good idea. Deliberately make sure the AI isn't able to protect this weakness, and now the players have a part of the game that challenges them (landing those critical hits at just the right time) that they can feel good about attaining.

The Dwarf Fortress scenario could probably be solved if there were some kind of coordinator that actually made sure the masons working beneath them would work in the appropriate areas at all times. Like you said, this "intermediate level of organization."

I think my current concept of AI calls for unlimited levels of organization with two-way communication between actor and supervisor. I wonder if perhaps this might be the way life itself functions, with cells communicating to nerves all the way up to the brain and back. Hormones get involved to set up communication conditions pertaining to unique scenarios. Ect.