Power Play

So, Exasperation has hit the ground running. He has already cleaned up a ton of my messes, mostly having to do with how mobs are spawned down below (a place I rarely traveled during the last 6 months).

I had a fairly productive day, but a lot of that was chasing bugs. I think I'm learning the value of efficient debugging.

Why units refuse to lose their abilities

So, if when {CLEAR_VARIABLE unit.abilities}-ed a unit, it didn't always drop their ability. This was very troubling. I had Dwarvish Guardsmen with bucklers that refused to give up steadfast along with Fencers wearing armor who could still skirmish. This totally wasn't the case ever for player characters. This code, inserted into the start event of the tutorial, confirmed it.

Hypothesis #1: It has to do with the fact these NPCs are canrecruit=no.

Nope. Tested it in the Tutorial. It did the same for Konrad (if I made him a Dwarvish Guardsman).

Hypothesis #2: There's a [modification] that needs to be removed.

Nope. Not in the save file.

Hypothesis #3: Abilities of regular-ish units need to be removed via [object]/[effect].

Damn, this one worked, but there's no way to just clear them all like that.

Then I talked to zookeeper who, as always, had brilliant insight. In IRC:

zookeeper: could it be that removal works on abilities which are no inherent to the unit type?
zookeeper: that'd be my first guess; that the game would see something missing and would recalculate it...like if you removed unit.hitpoints then the game would recalculate it (probably means fill them up to max)

Oh, so I just put a dummy [abilities] container in after clearing it and it worked fine. It turns out that PCs never had an inherent ability, so it was never an issue.

I was really scared this would be a roadblock, but it turned out not to be, thanks to good ol' zoo.

Abilities mostly done, valuation mostly done, now for items gain

I've come to a resting point for valuation. Some abilities, specials, and traits are all that is left, and I would mostly just be throwing random values at the algorithm for each one.

Instead, I'm focusing on how to make the item move to and from the players and the environment. I'll have to scrap a lot of the old way of doing things, but I can replace most of that with the NPC valuation now.

I got PCs giving shields to NPCs working. It was great to simply create a second copy of a unit, give it the new shield and see if the valuation algorithm thinks it is overall better or worse than the original. And, it's working good. A Thief is worse off with a shield while a Thug is better off, so the thief refused.

The difficult part is going to come when I try to give a unit a weapon when it already has 3 equipped.

I've also given most weapons negative evade adjustments, and most armors' negative evade adjustments have been lessened. A weapon, simply depending on its type, will have either 0, -1, -2, or -3 evade adjust. I'm a little unsure about this, mainly because you would expect a heavy club to have more of a penalty than a light one, but it's not like strength has ever found itself into the evade equation from the start.

Not So Bad

Fortunately, the new release of Dwarf Fortress is more buggy and the docs on how to play are less complete than I had anticipated. This means less time it will be sucking away at my soul and more time on Wesnoth.

I think I have the multiple-attacks-of-a-range system down well enough now.

I need to get abilities now, but Trolls and Fungoids (consider them underground Woses) have natural armor, which means they won't be nearly as weak as the units wearing tattered versions of whatever they wear. This means it's going to be difficult to give a value to regen.

I need to get back into the project because I'm daydreaming of making action games again. I've got a unique setting nearly fleshed out any everything.

Second attack of a range

I have the value of a second attack of a range down, but I'm rather unsure of the result. There are parts that can be tweaked, but I'm having trouble deciding their values. At I can say this much: having an extra attack of a range, no matter how small, will be valued higher than not having it, given everything else as constant. In the process of making this, I even got to use a little knowledge about sorting from a really simple coding course I'm taking.

As soon as the abilities are in, and they shouldn't be too hard, I'll be provisionally done with the valuation algorithm. Non-mainline specials.abilities can wait for later.

Next will be the hard part (again?): advancement path finding. I guess the best way to go about it is to make logical trees to try, give the unit maybe 3 chances to try them and look for the highest value.

Ugh, and then there is Exasperation's code that I need to replace, which lets a unit decide for itself whether or not to pick up/equip weapon/armor. I need to make sure if a unit that doesn't have evade and has cheap armor will still wear the armor rather than going naked. Let me add that to the to-do right now.

Valuation Again

This value algorithm isn't nearly as grind-y as I thought it would be. It's actually going down really, really easily. Part of the reason for that is I can usually just assume a unit's usefulness goes up with each aspect of it. For example, a unit with 6 moves is going to be well enough better than one with 5 moves, given everything else is the same. There are no "tits on a bull" aspects to units. Movement, terrain defense, resistance, hitpoints, attack power. Having one low aspect is going to seriously hurt the unit, but there doesn't seem like there is one combination that is hugely better than another.

There are a few exceptions to this. Skirmisher gets a ton better the more the unit can move around. But, even at 1 movement, Skirm is going to have some value. Steadfast is good only if the unit has some positive resistance. It actually is at its best at 25% resistance and then gets less and less valuable as the resistance nears 50%. These exceptions are few and pretty easily managed.

Managing terrain defense and movement cost has been a bit of a trial. For some reason, Elvish Archer is being valued less than Elvish Fighter. That probably has more to do with the Archer having one less movement point than it does with the terrain issues.

A few days on the grind

Working on the valuation algorithm. It's going surprisingly well, though I've only made it work with the most regular units possible (e.g. Thug, Bandit, Heavy Infantryman, etc.).

One challenge: Low-level units are constantly being under-valued. There's an imbalance between Wesnoth's Mainline gold value of a unit and its value if upkeep isn't involved. A level 5 unit in Wesband will use as much upkeep as will a level 0 unit (none). Perhaps I should say that the average scenario in Wesnoth is 20 turns long, so the actual value of a Spearman should be 14+(1*20). That is to say, a units true cost is its initial recruitment cost + (upkeep * turns in an average scenario). So, instead of a Peasant being valued at 8 and a Spearman at 14, it should actually be 8 and 34 respectively. Ouch. As I'm writing this, it hurts, because that would mean most of today's work was for nothing. Haha.

Another challenge: What is the value of a secondary attack of the same range as another attack (e.g. Dwarvish Fighter's hammer attack)? Sometimes it can mean a slightly better attack, but other times it's useless. How would I put a gold value on versatility?

Introspection

So, I've taken a crack at fully designing THS: Full Sail. There are more than a few problems with it all. I originally planned to have it allow for more than one player ship. The problem with that is if I want to zoom into the non-main ship I would have to expand the map hugely. That sucks. The best idea, I guess, is make any fights that happen off of the main screens happen in the background, with generally the same outcomes but it would be automated. What that all adds up to is a much larger scope of a game than my original "finite" project idea.

With all of that thinking, I had to take a hard look at what I'm doing here. Am I giving myself a break from the setting of Wesband? Am I avoiding hard coding projects? What do I really want out of all of this?

Here's the realization I made: Wesband is an awesome idea. It's an awesome game. Wesband devs have said so, even if no one else has. Do I really need a break from it?

Then I approached the questions from another angle. As a gamer, how did I feel when developers lagged in development? How did I feel when they took side projects? I know the answers all too well.

Infantry will forever be a sad subject for me. Perhaps it was unfair to expect more out of it than what it was, but I loved the core gameplay so much that I couldn't help but imagine what it could have been. I wanted so much more in the core zones of Mech Skirm, Hardcorps and Eol, but instead got side-projects such as Cosmic Rift and Tank-O-Drome. I wanted more depth, more variety and more experimentation on all of these fronts. But, for many reason, my wish was never fulfilled.

This is all incredibly sad. It's sad in the same way, I'm sure, that Wesband will be if it doesn't live up to its potential. Besides, I'm not going to dev like this for Wesnoth forever. Really, the end goal is to churn out some awesomeness and then move on (to action games, my first and last love).

Nose to the grindstone.

Full Sail

I've taken a (very) short little hiatus from Wesband to make a more finite game, THS: Full Sail. Bob_the_Mighty made a multiplayer scenario, The High Seas, a competitive naval game featuring piracy and swashbuckling. When I played it I, like any good dev, began to pick apart 100 things I think could have been done better. In the end, it gave me an idea for a naval scenario of my own, that would act somewhat like Bob's scenario, but would have all the things that I wanted. Here's a list:

-Less right-clicking. I didn't like how you had to right-click all of the time to assign gunners or to man a rig. I think this kind of thing should be automatic. For example, if you place a unit on a cannon and it starts its turn there, the effect is present for the rest of the round. This brings up issues of realism (no one is on your cannons, so how can you still shoot?), but I think speed of gameplay far, far, far outweighs that issue.

-Zooming in for combat. This one borrows from TL's Imperium scenario. Ship-sized units (ships and sea monsters) would be able to fight each other on the main screen, but if a fight is initiated between a ship-sized unit and a smaller unit, the smaller unit would be sucked into a zoomed-in map of the ship. That smaller unit would then fight whatever is in the ship. Then, you can have ship-sized units grapple each other, connecting the maps of the two. Or, if it's a kraken versus a ship, if the kraken tries to grapple the ship (first thing to do if it doesn't want the ship to sail away), the ship and the kraken still fight each other in the main screen, but the kraken sends tentacles to the zoomed-in screen to harass the sailors.

More than TL's Imperium mode, this dream comes from countless hours of playing Ultima 3: Exodus. Every battle in that game was a zoomed-in battle. It just so happens that ships were involved, and any side starting on a ship would see that ship in battle. But, rather than having only one section of the map in combat at a time, all sections could fight at once. Cannons will be flying at the same time swashbucklers are dueling it out.




This is where my biggest problems are going to be. What happens when a third ship wants to grapple with a ship already in combat. What about a fourth? How much space do I have to leave in the zoom-in area for each ship?

-Putting the setting in the world of Wesnoth. I understand why Wesnoth add-on developers want to avoid the restrictions of creating stories in a world they don't have full authority over, but a naval scenario is a great opportunity to explore regions in Wesnoth's geography are defined yet haven't been full explored. The Great Ocean, to the west of Wesnoth, will be the setting of Full Sail. The waters are open and just about all of the kingdoms in the game will be able to participate.

-More emphasis on supply and demand. Of course, as a M.U.L.E. fanatic, I will be adding my own flair for economics into the game.

-More emphasis on diplomacy. Trade embargoes, privateers, etc. This goes along with the emphasis on supply and demand.

-More Cattan-like objectives. Rather than having a potentially infinite score, players will scores like: Largest Fleet, Most Wealth, Most Ship Sinks, etc.

-Option for an adventure mode. Want to play by yourself or co-op with a friend? It doesn't always have to be competitive.

Anyway, back to work.

The Quest for Lua

I've been picking some low-hanging fruit that got introduced in recent releases of Wesnoth. I was taking the letter "o" on the end of terrain to denote my no-gold versions of villages. It turns out that Gg^Vo is a village tile for Orcs, so I went through and changed all of the terrain strings to have the number "0" instead. I doubt that will be redundant with anything anytime soon.

EDIT: Blogger has 0 (number) and o (letter) looking exactly the same. Weird.

I also fixed a new issue with the saved overworld map not being recalled correctly. With that, I went ahead and made it clear all of those useless labels that get set by [generator].

silene gave me a great answer to my question about using Lua commands to debug stuff in game. Unfortunately, that stuff is still over my head, so I'm going to take the next month at least to try to get a handle on Lua by reading the LuaWML page and the Lua reference manual. Should be fun.

No more base unit container variables

My hunch was correct. Wesnoth developers confirm that all utility variables should be put into a unit's [variables] container. This is fine, but now I can't use debug commands to alter talentpoints and gold like I used to. However, Lua is going to help with that and it isn't going to be as bad as I thought, with the right preparation. In this thread silene details how to set up a Lua function to do the debug manipulation that I want, with the result being really short commands, i.e. modu("Ken_Oh", "talentpoints", 100). That first value is supposed to be an id filter, which bugs me. I'd rather still use the cursor's x,y, which I bet is still possible, so I asked and am waiting for a response on that.

I would, however, perhaps still like it if the native debug modification could be expanded. Consider this: unit variables.inventory.weapon.melee[3].damage=10 . That would be much simpler to work with than making a new function every time I want to alter a variable at a certain depth. If/when I get the know-how, that's one of the things I wouldn't mind adding to Wesnoth myself.

Anyway, so I went through the grueling process of transporting every last instance of unit base container variable functionality to being inside [variables]. I may have still missed a few that have to do with henchmen and temporary statuses, so I'll look for those next time.

Gotta do more, gotta be more

The holidays weren't restful or productive. It's always hard for me to work without a set schedule. On the upside, my girlfriend bought me a netbook for Xmas, which means I can code anywhere. I'm back into a schedule and I'm pleased with how much I'm getting done, in all aspects of my life.

So, I cracked open the new Wesnoth v1.7.12. That's the fifth stable candidate, which I think is a lot. Some things in Wesband are being broken with these releases. For one, my Gg^Vo no income village is has the same name as a new Orcish village. The "o" was supposed to stand for zero income. I'll have to see if "0" is an acceptable character to use and then convert everything over to use that.

I noticed movement wasn't getting refreshed on moveto events with no enemies around. I debugged this down to $unit.simple_action not being initialized. It turns out that no new variables or containers may be created in units now, other than expected ones, such as [attack]. I asked zookeeper about it and he thinks it's a bug, but I'm beginning to suspect it's a feature and that the devs want all miscellaneous unit variables to be set within [variables]. On the other hand, there's absolutely no mention of this in the changelog. I made a thread asking about it and will have to act depending on the answer. I think all that would need moving is talentpoints, simple_action and personal_gold, but I might be forgetting something. With the inclusion of Lua, one can actually alter unit variables in higher containers than the base one in debug mode, so it wouldn't be too limiting for debugging purposes. It would, however, make me really wish there was an equivalent to DOSKey in the debug command line.

And, the dungeon tries to create an empty unit upon entry. This one might actually be our fault and not a problem with Wesnoth.

Oh, and Exasperation made a small contribution over the holidays. Go to see he's still thinking of the project.