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.

The Crunch Begins

I've started with the Ruffian/Thug line to compare the simplest units that I can. All of the relevant aspects of these units are the same, except hitpoints and melee attack.

What's interesting is that wearing the light armor that these units do, they have a resistance rating of 47% (quick and dirty: take each resistance, convert to scale of 200, subtract 50, divide by a modifier that takes in account usefulness, add them all and divide by 6, you get a rough scale of 1-100), however, their terrain defense on flat is also 47%. Weird.

What I plan to do is see what exactly makes a the Ruffian jump from 6 gold cost to 13, when it becomes a Thug. Then, I'll see if that cost formula roughly holds true in the jump from Thug to Bandit, and so on. After I have something that works for them, I'll use it for Spearmen, make some tweaks and then make sure those tweaks still work for the Ruffian/Thug line. Then do the same with the Footpad line, and so on. Going to take a ton of testing and tweaking.

No way out but through

First, I finished the markup changes (for now). I'm going to want to deal with macro-ization of spell/usables descriptions later.

I fixed a bug where NPCs weren't getting their ranged attack. I'm beginning to think there's a WML goblin messing with my code, because that's honestly the third or fourth time I've fixed this.

Finally, I dabbled a little with the npc value system.

Questions:
-What is the value of a secondary melee attack? Having one melee attack valued at an arbitrary 10 and another one, with a different damage type, valued at a similarly arbitrary 10 certainly wouldn't double the value to 20. Would it be more like 12? What is the value of diversity in attack types? If a Dwarvish Fighter is valued at 16 gold what would be the value of one that doesn't have his hammer? To think about it another way, if a unit has two 5-5 melee attacks of different damage types but has one 7-5 ranged attack, which is worth more, the ranged or the melee attack? If I keep reducing the stats for the ranged attack, at which point will they be valued as equal?

Breakthroughs:
-Whichever attack range isn't the strongest, that range becomes more important for defense than offense. Think about it. Your Elvish Archer is usually always going to attack with his bow and will most likely be attacked in melee range. So, I'm thinking about making the attack value of the weaker range do some math with a unit's defense values rather than its attack value, and vice-versa.

Anyway, I don't think I can work on anything else until I solve the NPC valuation system. It's going to take a lot of math, guessing and testing.