Earth and Air Elemental Rigs/Skins

Hey hey. I went back and built a new Air Elemental model, then realized I never posted the Earth ele!

Take a look :)

The last one's kinda... big :)

Keep in mind these are differently scaled versions of the elemental skin. Just like with the player's squad members, each unit has a variety of sizing attributes. The various types of elemental have the same parameterization. So yeah, that last one's kinda funny :)

Oh oh, and the Stone and Air bits animate; I didn't record a GIF for you though. Next time.

Update + LiveStreaming

What's new?

• I'm testing out live streaming at www.livecoding.tv/ventare. It's strangely entertaining, though I admit it isn't terribly good for actually getting work done. On the plus side the few guys that chatted with me last night did help me solve a few bugs that were as of yet undiscovered. I don't know how often I'll do this, but I may find some time tonight if not afterwards.
• I've built a couple new visual effect types, based on the materials system and mesh duplication and offsets. Am using it for some slightly more subtle weapon glows.
• Caravan, the second tutorial scenario, is in progress; the story bit and tutorial bits are written (but need polish), and the actual scenario part has begun, but only just.
• I'm working on authenticated identification of installs, so existing installations will break at some point. I'll be able to supply custom links so that I can deprecate links and authentication codes later. 
• I built some meshes in Blender! Specifically I built a skin for the main human mesh, the elemental default mesh, and specific multimaterial meshes for flame and stone elementals. Eirikr's weapons are getting UV coordinates as well, when I find time.
• I did a pass over sound effects a few weeks ago; they are better but not thoroughly better.
• I implemented a means for the server to instruct the client to do a spline-based camera flyby, useful for tutorial and cinematic sections.

Caravan Sculpting

Quick update here!

The tutorial revamp with new tech is complete. I did one sound pass (many more needed), added music queues, explosions from space, changed the ending section logic to work with the new terrain mana skills, and added some other fluff in other sections to make it a better experience.

Caravan work is beginning in earnest! I built some new editor tools to alleviate some of the pain; namely, a flood fill terrain painter, a growing sphere-based sculpting tool, and a visualizer for a layer column so we can see how deep the materials really go, and what is down there.

Here are some new Caravan pics :)

http://redtoast.net/Images/Blog/CaravanEditor1/StartView.png
http://redtoast.net/Images/Blog/CaravanEditor1/DownRiver.png

http://redtoast.net/Images/Blog/CaravanEditor1/RiverTunnel.png

http://redtoast.net/Images/Blog/CaravanEditor1/RiverFord.png
http://redtoast.net/Images/Blog/CaravanEditor1/RockCanyon.png
http://redtoast.net/Images/Blog/CaravanEditor1/MudGate.png

http://redtoast.net/Images/Blog/CaravanEditor1/Overhead.png

That's it for now :)

Mana Manipulation (and Videos!)

At the tail of the last post, I said that the incendence system and environmental magic were next. Guess what! It was next. It was complicated, but it is working and it is good :)

Let's break this down and make some new video clips.

So. Environmental Magic. This is a system designed to let the player change the terrain. We already had (somewhat stable) terrain changes, but the nature of those changes is quite a bit different from the new system. A few of the old-style changes included the bridge builder (featured at the end of the tutorial, and on Outpost), and a couple hacky commander skills that no one but I used. These will be gone soon. A second set of old-style changes are the elemental impacts system, which will be staying. It compliments the new system nicely, and will be used for non-mana manipulation skills. Any explosions or active flames and whatnot will still use the old impacts system, which works well.

The new system is built specifically to give the skills to the player. To that end it has to be limited and controlled enough to prevent the player from abusing the skills to absurd extent. Honestly letting the player arbitrarily change the terrain is a terrible idea if you want to control the gameplay. The fact we're trying this at all is a testament to pushing boundaries that oughtn't be attempted. The payoff of course, is that no one else has really succeeded in giving this style of control, so if we do succeed to any extent with it it's a mark in our favor.

So anyway, the limiters. The new system is pretty much entirely based on the concept of conservation of energy. The energy in this case is not potential, nor kinetic, nor chemical, it's just Mana. Every type of material has a mana density; how much mana they contain per unit volume. Mana, by the way, comes in 4 forms, as per classical elements. Mana is conserved. From this concept we defined 5 basic operations, which are pieced together to build the actual skills.

First is extract; this takes a chunk of material and converts it into a less mana-dense form, while preserving overall mana. The net effect is that new material volume is created, but it is less mana-dense.
Second is draw; this is very similar to extract, except instead of creating new volume, the excess mana is absorbed into the caster, stored and usable later. The net effect is that material is converted to weaker types in the local area.
Third is infuse; this is the opposite of draw; mana is pushed into materials, converting them to more mana-dense forms without change in volume.
Fourth is compress; which is the analogue of extract to draw for infuse. Compress reduces overall volume when converting to more mana-dense forms.
Last is shift; which just moves a chunk of mana from one location to another.

Each has some mana cost; small but important.

The nature of these is that mana is conserved or lost. This enforces that things do not get too crazy on the map; There's a limit to what can be generated; implied by the original amount of mana present. If we build a map to play on that consists entirely of sand (a very low-mana material), then that by itself completely removes any possibility of manipulation. There simply isn't enough mana to do anything with. The density also limits any volume changes. The total mana of a bridge's material has to be put into the bridge to construct it, and that mana (plus expenses) has to come from somewhere.

After that we added more limiters. Extractions and Infusions and Shifts have an overall power requirement, per material. Granite is hard to work with; extra skill is required to work with it. Likewise at the bottom of the earth-spectrum, sand is complicated. This limits the player in where he can manipulate the terrain, but in a graphically obvious way that can be played around.

Then after that we have to manage reach; how far the operations can work through the ground. I invited the concept of mana-pressure; how much pressure the manipulator can exert on the terrain. Pressure travels out through the materials using a conductivity calculation that depends on their mana density. Earth pressure reaches further through earth-aligned materials, for example. This conductivity is fairly unbalanced; so reach will fall along aligned conduits in the ground, potentially extending total range in the right circumstances. You could even generate explicit lines of high conductivity material to control how the mana flow is directed.

How about some visuals?

Here's the first version of the Mana Manipulation skill tree.

And here are short videos for the various new skills in action:

Mana Draw (Pulling mana from the grass and dirt, turning it into lesser rocks. The first outward pulse represents the mana pressure, that is, the effective range of the draw force)
Mana Infuse (Pushing mana into dry mud and mud, turning into mud and dirt, then running out of mana)
Mana Extract (Extracting Gravel from Shale, and Sand from Gravel, to produce a column of material at distance)
Mana Wall Construction (Drawing a line in the ground, then infuse/extract/shift to move it into a wall shape)
Mana Bridge Construction (1) (Extract/Shifting a bridge out of the ground)
Mana Bridge Construction (2) (Building a second bridge from less dense materials. You can see that sand is getting used at the end of the bridge, since the source area is running out of mana-dense materials. This bridge could not get much longer, and when physics is written, the sand would fall out of it)
Mana Shift-Smoothing (Using Shift to smooth out the surrounding area, making it traversible)

Hope you enjoyed!

Next time I'll talk about Incitement and Incendence. It is currently WIP, maybe halfway through implementation.

Over the holidays

Time was limited of course, with moving, buying a house, selling a house, and holidays, but nonetheless a small update is in order:

• Revamped (rewritten entirely) Chat system
• We once again have an OpenFire XMPP server running on the uni server. Accounts are created by the server to match universe accounts, and some chat channels are running.
• The chat UI was rebuilt and is substantially more functional! It runs in the bottom center of the game now, has autocomplete for commands, and supports whispers, say (in game speech), channels (global exists right now, later others), and custom commands (who, reloadui, etc). It's somewhat nicely styled to allow scrolling but not get too much in the way of the camera. As always polish will improve over time as annoyances show up. 
• Whispers in chat communicate via direct message in XMPP, without the game server being a part of it at all. So you can, in fact, use any other XMPP client to join the global channel or be online for whispers (and whisper back).
• Server stability
• Did a bit of work on the server to prevent some weird hangs, we'll see if it works, but so far so good.
• Dynamic reloading
• The client can now reload the ui, reload assets, etc.
• It can also be run in a mode where it monitors the client database file, and if it changes, reloads it dynamically and reloads the zone. It makes updating visual effects fairly seamless. I can keep the visualizer open while a game is playing, save from the visualizer, and the new effects appear in 4 or 5 seconds.
• Incremental database building
• The old build from google docs for the majority of the game data would destroy everything it built previously, and build it all back up every time. I moved to an incremental approach based on the last editted timestamp of the document, so it is much much faster.
• We also have a polling system for updates :)
• It also can update live while the zone runs, swapping in changes on the fly :)
• So basically you can run a local zone and a debug client set up to automatically pull changes from the database, compile them and establish them in game in 10 seconds. This should make the editting process way way way faster. The old reload/test cycle was 3 or 4 minutes at best, the new is 10 seconds. BEHOLD progress.

That's that. Next on the docket is the incendence system and the elemental skills update, for which the above were written. And then after that finally back to scenarios :)

New panels, Web UI development

Hi :)

So the last week or so has been taken up by rebuilding the formation editting panel. Since we've been moving our UI frontend code to web tech through Awesomium, this means learning a whole bunch of new technologies to manage it. And since I'm new at these sorts of languages, it also means constant retuning and rebuilding of the code. Now that's it's a little more stable I wanted to talk about it some.

First, one of the big advantages of using the web-style frontend, is that you can use it in a browser! So, here's the new panel! Go take a look!

Commander Formation Panel Tester

This thing here is built using a pile of stuff a learned recently:

• Javascript, of course, since the web runs on javascript. I don't have all that much javascript experience in the past, so there was certainly some learning. The first set of UIs, which have been in the game's main menus for a year or so, use JS of course, but there's good JS, and bad JS, and those menus are... bad JS...
• TypeScript: I admit it, I'm only comfortable programming in primarily statically typed languages. Typescript is a nice balance between typing and javascript. While it took a bit to learn how to use it properly, since you have to compile it into JS, it's been a noticable improvement for me personally.
• Handlebars: Handlebars is a templating system to build HTML docs (or JS I suppose) from JS data. My standard coding methodology is to break things down into pieces, yes? HTML/JS/CSS don't really let you do that. Using handlebars to break the HTML bits into pieces gets me some of the way there. Most of the pages I build now use a few templates. Recently I started keeping them in separate files, loaded dynamically when needed.
• HTML5 Canvas: The main interactive area of the formation panel is displayed with canvas. Turns out that coding to canvas is a lot like using a super-primitive 2D version of OpenGL. Piece of cake :)
• JQuery / JQuery UI: JQuery of course is largely requisite for some kinds of JS development. I know it's not truly necessary and that there are other options, but I don't have a personally compelling reason to switch. JQuery UI is a bit of a different beast. We use it mostly to set up buttons with consistent styles, tabs, sliders, checkboxes, and other core UI elements. I'm not sold on it, but it does seem to work well enough so far. 

So mercifully the frontend code is becoming less of a mess. With other bugs getting fixed in the game's UI management, we may actually be getting somewhere on having a reasonable UI toolkit. 

Took long enough, eh?

Next task is the commander panel; skills and classes and customization. It used to sound like an impossible task, but I'm beginning to think it won't be so terrible. Will find out soon :)

Caravan (Scenario 2) preview images!

Eirikr's been at it in the scenario editor :)

Early WIP, but neat :)

Tutorial Test Phase 2

It's time for another phase of tutorial testing! The feedback from the LAN has been integrated, and some other mechanic tweaks are now in play. I'm going to send out email to quite a few people who haven't played the tutorial yet to get some feedback, and we'll see how it goes from there. :)

Here's some of the changes.

• Overall Game Updates
• Maneuvers have more reliable cooldowns and behaviors. Hold, Reform, and other instant maneuvers instantly start their cooldowns, so should be available sooner and more consistently. Movement based maneuvers now have a delay after first contact before stopping, so the final contacts should be more reliable.
• Retreat is revamped a bit. Retreat grants a short burst of speed when initiated, same as before. But now, if you redirect retreat, you get another burst of speed at the cost of morale.
• Movement and animation has been seriously updated; Unit legs should be more under control. Units should move much much more smoothly than before. Units shouldn't wiggle as they go back and forth along the hex grid. Units will do some extra animating when running fast, and the locomotors have been largely rebuilt. Unit knockbacks are animated much smoother as well.
• Application Updates
• Asset downloads are now retrieved from S3 instead of the universe directly. This took some magic but should pay off. In the end this means faster asset downloads with less impact to running zones, and more reliable fetching.
• Main menu minor updates: When you have no commanders yet, the 'New commander' menu is skipped. Also, when you create a zone, you now enter a new menu mode, and automatically join when it goes live.
• Tutorial Updates
• Many paths have been shut down to prohibit Joey from breaking everything.
• Many sections of the tutorial are now done in cinematic mode to prevent the user from bypassing sections while talky talk is happening.
• All dialogue is slowed down substantially, and the player can now hit spacebar to skip most dialogues. Space will also skip the big dialogs, but only a few seconds after they show up.
• Retreat section partial rebuild. The Glacial elemental's abilities have been slightly changed.
• The final section now introduces Morale (and HP) and Special attacks. Also the raised platform is destroyed when claiming the Legacy.
• The 3 learnable terrain manipulation skills are more reliable and less crashy, not that anyone used them :)
• Known Tutorial Flaws
• Animation for the swordsman dance at the beginning has messed up timing. Shieldman knockback is a little desynced too.
• Hold section spawns still don't QUITE do what I want them too, but it works better than before.
• Retreat still weird but let's get some feedback on that.
• Final fight still a total and complete chaotic mess; but I don't mind that really.
• Doesn't create permanent commander when complete, yet.

All back up and onward!

Lo, did the server crash. The existing build.redtoast.net has died a thorough death, the main HDD auto-eviscerated itself into oblivion. Very sad.

And lo did a new server be created to take its place. Newer and shinier (in theory) and decidedly not sitting behind my couch.

The server's back on Amazon's cloud! Yay. It's back up and running most of the prior services. Subversion is back up, the debug universe is running as before, and the web deployment scripts are there as well. This time it doesn't run a local HTTP server though, it deploys all the files to S3, which also serves the seriously terrible http://redtoast.net.

So that all took some time of course. Subversion history from the first half of this year is pretty much the only loss. Sad but not a problem.

Since then I've written a few new shiny things. Since I was all Serious for the LAN prep, I decided to take a week or two for some Nick-fun features before diving back into scenarios.

• New Physics based Animations system: We can add limited dynamic bodies as props and stuff: Cloth, ropes, combinations thereof. This means that commanders now have their proper banners! 
• On top of that, Teams now have optionally assigned team colors and logos, and player accounts have a logo/icon assigned as well. These logos show up on the banners (and will in other places in time). The Whirlwind is my logo, until I make a custom one.
• Inspiring Commander Banner
• Personal Commander Banner
• Timing update: The sync code between the client and server was written in 2008 and unchanged. It kinda worked but wasn't very good. I wrote a new one. I also wrote a massive change in the client side movement code, and an important change in how locomotion is computed, and an importanter change in timing of animations. End result is massively improved animation stability and much smoother unit motion. Stills can't do it justice. I'll need to movie it up to show. Should do a movie soon anyway, been years.
• Universe related tools. I made myself some new server entrypoints for viewing logs and stuff. Like this. It's not a big thing. OH, Don't hit those launch buttons. (I expect you to hit them, it probably won't break or anything though)
• Fixed the busted installer from the LAN. Wee.

That's pretty much that for now. Finishing up tuning on the tutorial before I blast a request out for more feedback, then starting production on scenario #2!

LAN 2013 Prep

So, this past weekend was perhaps the biggest playtest I've had in some months. Accordingly, I spent entirely too much time world-ing in the hours and days and weeks prior. On top of that since I left work 3 weeks ago means that really an awful lot's been written. In fact, I exhausted myself so bad before the LAN I instituted a self-ban on Visual Studio for 2 days after it. Since I'm still disallowed, here I am writing :)

So first, an update, in long form. In a later post, a postmortem on how the LAN behaved w/r/t World.

New stuff coding and otherwise:

• Awesomium integration! 
• Awesomium is a wrapper library for Chromium/Webkit, meaning, it's a library to help build front-ends using Web UI languages. I'm converting over our menus one by one to use html/js/css instead of my old homebrew DirectX hackery. The main menu's been converted entirely, and some new modes' menus are all Web UI of course. 
• This means that a lot of the UI works in a normal browser now. Not enough to do anything yet, but it's substantially closer to having parts of the game work without installs and directx.
• Beginnings of the Continent game
• The project has always planned on being a two-tier game. The combat/skirmish level has received pretty much all the attention, but there's always been a plan to have the overarching world driving the scenarios. Most of the terrain work from earlier this year was written in preparation to begin the top-level, which executes the world as a whole.
• The basic idea is that the continent game is where the player navigates, builds, explores, discovers, customizes, and then finds or builds scenarios. When found the scenarios are then joinable by the player in skirmish mode.
• Rebuild of the Universe Server
• The universe is the meta-server. The previous version had components to handle account storage (player data), scenario launching (which didn't realllly work), a list of live scenarios (which worked), and assets to check for updates and download.
• The server interfaces are mostly unchanged, but the backing implementation is now completely different. The server executes a Zone the same way that the skirmish server does, but that Zone is running a different game database; this one represents the continent behaviors as a whole instead of handling combat. Players, commanders, primaries are all stored in this continent-zone, rather than having separate storage. This gives them position and behaviors at the continent level.
• Continent and Explore Modes
• The universe now can serve up the terrain data for the continent, as well as pre-rendered overhead imagery. The client can view the overhead imagery using a custom map built with the google maps API, either in the game-browser on in a normal one. The imagery is rendered as a part of universe generation. 
• The map also shows units that exist on the map, just as icons at the moment though.
• From the continent viewer the game can enter explore mode, where the player jumps into first person to explore the world as their player-entity. It's veeery rudimentary at the moment but does render the terrain from the universe server. It's a start!

And more esoteric things:

• Installer fixes; the installer needed a lot of attention to handle the Awesomium libraries, as well as resolving some directx related install hackery. Awesomium's libs are sadly somewhat large, and now account for 80% of the install size. (50MB total now)
• Lots of assorted bug fixes. We did some testing a few days before the LAN and had a somewhat painful series of obnoxious bugs that had to get dealt with. Some were install related, some related to downloading assets failing, some with awesomium state changes, some with scenario restarts, mid-scenario joins, rejoins, second joins, crashes on quits... OMG the list went on and on. That list is why I'm tired and banned from VS for two days :p

Lastly, as a matter of laziness while updating terrain systems, I broke the old scenarios and didn't care to resuscitate them, so I had to make new ones:

• The basic testing scenario has a couple paths, with some enemy commaders, flame elementals, spiders, and some earth elementals. There's a flame commander group that charges the player that can be gamed interestingly, and a Ogre at the end. It's mostly testing and a little complicated to be a learning scenario, but it's reasonably fun for solo play.
• The main new scenario is a single enemy commander on a small hill, surrounded by his minions. He makes a circular formation rather than a line, but never moves the formation. He has units of each type, shields, swords, scouts, archers, and the counts scale with player count. When the commander is killed his followers immediately die and he becomes a single-mob boss, just for fun. He throws enemies out of melee and throws boulders that mod the terrain. When he dies there is fireworks :)
• A new practice scenario that's just flat with some target dummies that I forgot to make immobile. Supposed to be to learn how to move and play and stuff.
• A hastily thrown together Territory Control map with 3 capture points and some terrain variety. For PvP :)

And lastly for the Update, Eirikr made some new biomes and terrain tile types. Sadly since the continent/explore mode doesn't have any gameplay in them yet, noone saw them :p

I'll make some pictures for the next post to go with the post-mortem. You know, post-mortem sounds kind of depressing. How bout post-awesomeness?

Cleaning up the World

Last time on the World Update was meta-systems programming, so what's this time?

The last two months have brought primarily 3 things: A new scenario, massive performance improvements, and some new unit action design in progress. It's been a surprisingly meaningful set of improvements, worth pondering how it came to be. So let the prose commence: :)

1. The Watchtower Scenario

I wanted to make a defensive scenario; one where the players hold an area for a known amount of time under considerable attack, and succeed if their target lives long enough, and otherwise fail. Turns out there was a lot of new tech required to really pull it off well enough to play.

First, Map triggers.

To be clean, I implemented a somewhat generic triggering system for the scenario editor, and tied the win condition of this scenario type to a trigger. In this case, it's just a timer. I also wanted to be able to control the start conditions and start time of the attack, so there's another trigger required, and one that the user has to be able to execute. I then needed to be able to control waves of enemies spawning, so, more triggers. 

It turns out trigger/response systems are pretty nice; they're the obvious alternative to some kind of embedded scripting language. Lots of games go this route and for good reason; it's simple, powerful, and not error prone. I set up trigger possibilities for timers (triggered from other triggers), for the scenario starting, for entering a region/map cell, and for entities that are triggerable. Oh, I also implemented entity grouping, so that I can trigger off an entire group being killed.

The next problem when building the scenario is that there are lots and lots of enemies. The first version had 495 spawns on the map. Managing that number was so impossible that I just deleted them all and started over when I wanted a change. In fact, instead of rebuilding the scenario's enemies to adjust difficulty, I just changed the spawn mechanism to allow spawning multiple units. Yay! Now it's just a number.

So now spawns can make many units; turns out that complicates a lot of logic that watches spawn counts and spawners. Figures.

So while I was at that, I decided to make it harder and make the spawn count variable. No sense making it easy on myself. Variable in what way? Well, how bout adding a spawn count for each allied player, and for every enemy player? That gives us a way to scale difficulty with player count. It also lets us make allies contingent on player count, which is neat (base line 4 spawns, -2 per player, =2 spawns when alone, none if 2 or more players). On top of that, let's add a difficulty parameter to the scenario, let the user control the difficulty when triggering the attack, then multiply the spawn count using that. Fun! 

Well, briefly fun. I hit the hardest mode I set up and the first wave spawned 164 easy kobolds, and 30 allies for my team. Turns out the game can't handle that kind of load, and it.. well, it doesn't work. In fact, nothing moves at all since its so slow. On the plus side, my base was still alive after 10 minutes, so I won. :)

In any case, this brings us to:

2. Performance

Alright, actually I'm lying. The very very first time I made the scenario, with 15 kobolds, it completely died. Yeah, it didn't take 140 to bring it to its knees. 15 lousy kobolds was enough. Why now? Because the kobolds are attacking, rather than waiting for you to get near, so the path calculations are very long, and very slow, and actually just completely broken as it turns out.

I spent a good month just working on performance, and probably all but a week on one singular task. The first profiling yielded some useful information; 99% of the time was being spent on map traversal code. This includes evaluating area of effect, moving to range, estimating action range, and most importantly, path finding. (Somewhat surprisingly, the AoE calculation was 35% of the time, because every unit pulses a 20 hex radius aoe effect every 2 seconds, as part of the code game mechanics. More later).

So path finding. Lots of literature on speeding it up. A* is the common algorithm, but we were already using it, so...

Actually it turns out we were only 'technically' using it. We were actually using 'it badly'. Okay, that didn't work. Whatever. The algorithm was broken on many levels. If I could count the ways I would but I don't want to because I'd feel stupid.

I made some unit tests to help iron out the kinks. That wasn't enough, I updated teh scenario editor to show detailed debugging information on the paths. I wrote heuristics and double checked. I allocated 40 or 50 megs of ram to caching pathing information (oh, and wrote the caching). I bla bla bla bla fixed it.

Before, my test path took 60ms to compute. (Hopefully you're thinking 'Wow that's terrible!', and not 'Wow Nick is a terrible programmer!'). After, it takes .1 ms. Also, the cache hits about 98% of the time over the new scenario playthrough, and the cache lookup is faster than that even. Needless to say it's better now.

So it's faster. Turns out it's WAY more than that. There were some interesting side effects. 

First, the old algorithm would scan the entire map if a path couldn't be found. This sounds uncommon, but note that any time any unit is on their destination spot, there is no valid path! In this case the units would take the directest route possible. In addition to making it super super slow, this meant that units would not path around their allies, leading to single file lines of extremely stupid enemies that get stuck a lot. This worked against the player's units in interestingly broken ways too.

Secondly, because of this fix some aspects of the autoattack algorithm became obvious. When things can path around each other successfully the AI's decision making because more obvious. It turns out the AA would only ever try to attack the highest threat, even if it was inaccessible. This made the game feel incredibly slow, as everything shifted around (unsuccessfully) to try and act, and inevitably didn't. The game would even get into 100% stalemate situations with 20 units all in a jumble trying to move around each other. LAME. 

So I rewrote auto attack. While I was at it, rewrote the movement control AI for players and enemies, and the special attack code (same as auto, really...) Also rewrote the trigger for the AA. Previously it was timed (instead of using attack speed), and now it actually acts when the Attacks come off cooldown.

Honestly its amazing these things went so long without even being noticed. The game is COMPLETELY DIFFERENT after these fixes. It just... behaves! It's.. .like it actually works! It's 100% amazing to me how much better the game plays now. I'm really struggling to convey JUST HOW satisfying it is when the behaviors start working like they should, and JUST HOW stupid you feel when you realize how long there've been seriously broken issues that just weren't quite explainable. The game always.. felt right before? But it really wasn't.

Now it is.

One last note...

The defense scenario, the first time I ran it, was extremely easy. After all these fixes, the attacks are faster, the enemies close better, the ranged attacks work correctly, and your units are more dependent than ever on positioning. The game got a lot lot harder, but harder in lots of really good ways. 

I did more than just these main things, and we've got more stuff we're trying (I did mentioned a third thing up there, didn't I...), but that 'Now it is' line was just too good not to (try to) end on.

Peace. More soon :) It really needs a movie to show the unit motion and count... Tomorrow night maybe.

Post-Lan

So, this last Saturday (the 19th) was one of the bigger playtests of World in recent memory. I took the excuse of a Diablo 3 LAN and made some peeps play the game.

For this purpose, I decided to make a new type of scenario to hopefully make the game a bit more dynamic. Actually I wrote a whole bunch of new stuff, so it was perhaps good for inspiration to work if nothing else. I think this post will be a combination mini-postmortem and World Update.

New stuff written for LAN:
  Territory Control scenario type:
     Team score / Team score boosting actions / Team score winning conditions
     Auto-join smallest team.
     Mid-scenario respawn for dead commander groups / players.
  Database functions:
     Can make interactions from GDocs.
     Interactions can channel.
     Added 'SoloGrant' effects, which grant an ability to the target, but when granting to subsequent targets will remove the grant from the first (so that only 1 has the grant at a time).
     Units can join the commander now via interaction (territory control points use this).
     Built two new types of enemies with some new tech needed: Earth and air elementals, they use a different rig and have some different abilities (which were too strong)
     Added per-enemy grant state that stacks for every hostile player in the game. This scales up enemies for multiple players.
  Mapping:
     Updated logic that connects gridcells together; it can now span empty area for knockback/projectile paths, so non-infinite slopes can still have knockbacks/projectile fired over them.
     Did a lot of cleanup work to allow building a fairly large scenario map.

Stuff written that I probably haven't mentioned:
   Primary units can now res unconscious commanders by using a long channeled action. The commanders' action bar is replaced by a button that grabs any available primary to do the res. This channel is 'weak', and is interruptable by any damage, in addition to normal interrupts.
   Maneuvers update; no longer transition between formations.
   Out-of-combat idle animation switch.

How'd it go:
   AAAAAAAGGGGGHHH.
  The scenario was too big and the client chokes. The ray intersections needed to run locomotion for all the entities, even just the ones in close proximity, brought it to a painfully low frame rate. I think I'll get rid of loco. For the LAN I just had to remove a pile of units, making it boring-er. On top of that, the scenario map was probably a good 3 times too big; it's really easy to mis-estimate size when building maps. Traversing the map would've probably taken a good 2 minutes at normal walk pace, withOUT enemies killing you en route.
   The navigation and pathing code for formations broke pretty bad too; that system may need a fundamental readdressing, rather than tweaks. Occasionally groups just stopped behaving reasonably.
   And, the scaling was WAY WAY off. Each single enemy was massively massively overpowered with the per-player buff in place. As in, a single kobold being nigh-unkillable, rather than dead on arrival. The elementals in particular were extremely unforgiving. A higher level group (10ish) with some game knowledge, can fight them and its hard. Level 1 groups (since the kobolds were too hard and I removed most of them, noone levelled), with introductory players? They died. A lot. At least they have respawn :p
   BUT. Aside from one server bug that I patched up really realy quick, the server managed running the scenario with 4 players without too much trouble. The combats worked, even if they were unbalanced. The new mechanics written for the scenario worked, even if they weren't terribly relevant.

And hopefully people had at least a little fun.
The final score was 200 to 198. Of the 6 control points, 3 of them were actually reached by players. There were '0' PvP combats in a PvP scenario, but there was plenty of death caused by the random assortment of PvE mobs on the map.

air elementals are fun :)

 

Video Update! :p

Lots of complicated stuff in this last month, but most of it is under the hood things like installers and nav. Also work is super busy, so Fridays have mostly been spent unconscious (mentally, if not physically).

Maneuvers and Streams are the big new visible things. They both deserve a design post of their own, so I'll leave it for later.

http://youtu.be/Nq6o-fEdI8k

Forward Progress

No new video again this week. Why? Because I'm not ready to show functioning Maneuvers yet.

Mostly I'm happy to report a fairly functional installer. I've fixed the major problems with it, up to and including fixing the missing terrain, and it's even playable! Heck, even Shalis installed it with no problems and was up and playing (albeit without terrain at the time :) )

Bug fixery bug fixery bug fixery. Maneuvers are neat!

Install?!

So, there's no video today, because I spent the night trying to find out how to build an installer for the client using ClickOnce.

And lo and behold, I have one. It works and even autoupdates. It's not as elegant as I wished on the build side, but really when is build management elegant? I'd link it here (since it's on the web, technically), but I'd like to test it with someone on the line first :)

Word! Hopefully it'll work well enough to at least make testing easier! It was always kind of an amazing pain trying to get the app on even local machines to test.

Friday movie

http://youtu.be/Zk7GfSFoCmY

This week I decided to mess around and play piano over the video, and add captions to show the emphasis and new things, rather than voice.

As for the actual code update; the UI is mostly functional at this point. Aside from side elements (like being able to change class/pick skills) the new UI is noticably more functional than the old one, which pleases me. The scenario got a small update, as did the enemies contained in it. It's still just a test scenario of course :)

I think the next plan is to get back to server implementation for a bit; It's time to write maneuvers! Kol and I have some design work to do and confirm before writing them, but I think I'll try and get myself to write up what Maneuvers will be here, concretely, before implementing. Then ideally when they work and show in the vids it'll be interesting :)

Next time!

Friday Update and Video!

Yeah yeah, a week late. I got a lot done so it's worth it.

Formation editing, formation mode commands, units icons, unit vitals, unit actions, among others.

But mostly I changed up the recording so it's much longer, and I went for it and recorded some voiceover. It might be terrible. :)

http://youtu.be/62Cj_MTade8

Hey hey! 3 in a row.

Maybe I'll be able to keep this friday thing up, eh.

While the client's getting revamped it's a pretty consistent kind of update. More stuff is working again. :)

Minimap improved, input system architected, formation editing panel works.

No audio yet, I didn't feel like hearing my voice. :p

The link is the post title, or....

Friday Update #2

Alright! Got some more protocol in there:

Commander selection and connected states are menu-ed up. Game knows how to watch the scenario's state and flip between inactive and active modes. Ready/NotReady works. Player list is shown with ready state. First version of minimap is in there, fixed the healthbars.

Not much, but the old client's guts are making their way across.

Video up at http://youtu.be/RSd6-xmJ28U

It's good practice making them. :) Maybe next week I'll be daring and include... SOUND....

Er, not that there's sound in the game yet; someday.

Small Update

Wrote a pile of new anims, found a way to use already-implemented stuff to layer animations too, so I've got a 'struck' animation that can play over locomotion and attacks. Adds a lot to see your attacks make them reel.

There're some pretty big timing issues client side still. The client doesn't really understand cause and effect, and on the server most things are instantaneous. Sooo, first you see damage, then the animation, and then the swing actually contacts. Kind of backwards.

In any case, I need to get away from animation and visuals and get onto scenario tools again. Animation is just too... instantly gratifying? Alright, I'll rig up some simple time-delays for the damage-hit event and the damage numbers. It's not cause and effect but it might be good enough.

And then I'll get to scenarios. Hmph.