Caravan mission music recording

I did two new raw recordings, in theory for use in Caravan. I didn't really plan out these music selections; I just sort of played. The only constraint was the rough length (the non-combat part of Caravan is currently 6 or 7 minutes), and the combat part is expected to be from 6 or 7 to 15 minutes. I also didn't want it to be the same musical theme as from the tutorial, but a common element or two is still good.

It is raw and unprocessed but here they are:

Caravan Opening Theme: This ended up very slow and quite sad; I think there's hope in there but it takes some working up to. Not inappropriate for the mission, but it might be a little too slow. I was amused to realize a few minutes into recording it that I was playing in 6:4 time. It is not amusing in of itself, its more that I was amused that I didn't already know. :)

Caravan Combat Theme: This is supposed to be a pull from the same theme as above, but with a more pounding energy and constant tension. It bears some similarity to the tutorial's combat theme in the nature of the bass and the beat rhythm; that's alright I think.

I'll listen to them both for a while and decide if I'm gonna keep them.


Lots of Caravan and AI updates to talk about; but the current rule is that it waits for Caravan to have a successful full playthrough! Soon? SOON?! (hopefully)

EDIT: There's some funny resonances in the combat theme that are kind of painful and obviously not intended. I'll have to figure out how to fix those sometime, but I'm honestly not sure how.

Overdue update; AI and Terrain effects

Wow. September 5th for the previous post. Long time. Overdue for an update :)

AI was the task last mentioned. Guess what! It turns out AI is hard, just as I was saying in September. It is also interesting, but maybe even moreso frustrating. So what's the current state of it? Well, it works. It works and does some interesting things. We can specify AI parameters for actions we build in the spreadsheets, and it can use them; even those with complicated prerequisites. It can build sequences of steps needed for complex actions. It can forget all that and just decide on an immediate next step. It can be guided to some extent as well; the AI units can be given preferences for types of actions and considerations.

All fine and good you say, but what can it do?

It has a reasonable combat driver; it can control commanders reasonably in combat situations. It weighs objectives, current status and positioning, enemies' status and positioning, and allies'. It will retreat when hurt, rally when it can, charge from distance, advance to stay in proximity, hold when threatened.

It can reasonably find its way to a target location, even with blocked paths and terrain obstacles and complicated areas.

It can run a rudimentary protection objective, defending multiple points and sort of separating out the defense when there are multiple AIs.

It knows how to get unstuck in various ways; it will rally or use other available methods to gather its party and venture forth.

It works in a way that is asynchronous with the game, sort of, so the AI takes game time to execute rather than real time. It can be parameterized to think slow or think fast.

It doesn't sound like much, does it?

The immediate purpose of the AI is to control the caravan opponent in scenario #2. At this point it can control it reasonably well, but it still needs a few more lessons to acheive the goal. It needs to break down paths into pieces for piece-wise evaluation of threat. It needs a partially endurant memory that understands temporality. It needs to be able to be controlled to want to retreat/recover after certain actions (or it needs to decide to do so itself emergently). It needs to gracefully handle the player harassing it without a hard engagement. Still feels like a ways away.

Here's a 3 minute clip of the AI sort of succeeding a traversing the obstacle course. A couple bugs show up pretty obviously.


In any case, I decided to do something more frivolous before I return to Caravan again. I wrote in a system to have the terrain material types execute visual effects. I also changed how the terrain renders to use the materials system that got written somewhat recently. Every now and then you need an easy task with instant gratification.

I know it's not exactly amazing; but it adds a bit more life to the terrain. Here's a clip of some new layers thrown on top of the Caravan terrain as a test.

Next time should be sooner. :p

Skirmish Update

Being sick and travel does a number on productivity for side projects. Alas this means that comparatively little has been completed in the last month.

The Caravan level's introduction, dialogue, and scripting are written and working (although it needs polish of course). The main content of the scenario is next, and that was a daunting prospect. This is the first scenario where we need a somewhat intelligent enemy. Intelligent in that it can use skills at the right times, find new paths when paths are blocked, and react to the player. The original concept was to build this within the scripting system for the scenario.

But we knew in the future that we were going to want to build procedural scenarios. Procedural scenarios can't have custom scripts to control enemies. Thus was born the need for a enemy control system; an AI one tier higher than our current AIs.

The current AIs in the system behave very primitively. It manages movement and pathing, deciding on an action to execute, handling getting to a relative range of their target, deciding on a target (through aggro/threat mechanics), etc. These operate at an individual level; each unit runs these control structures independently. One of those controls is the formation follower behavior, which keeps them trying to work together and in formation. There's plenty of complexity there that had to get handled, but it doesn't have any concept of future planning or any kind of analysis.

A while back (maybe 2 years ago) I worked on a system to control enemy formations, consisting of a set of directives which were selected through a cost function and periodically sampled. It really, really doesn't work. It kind of worked, but then it didn't. If you're wondering why the current scenarios don't have any enemy formations, this is why. Those of you who have played know there is one scenario with enemy commanders, and that they are barely barely barely functional.

So the need for an AI that runs on top of the behaviors is obvious. That's the current project. I'm building an AI Planner that looks at the current state, derives its options from available actions, derives its goals from the objectives (or script), and tries to come up with a sequence of actions to accomplish it. Then, searches over the space of sequences to find the best one.

The low level planner took a couple weeks to get working at a level I'm happy with. I'm now working on integrating the planner into the actual game. As of right now, the planner runs and the plan can be executed, but all it knows about is naive movement. It can move to its goal but basically it just knows how to dumbly right-click and hope for the best.

But it's a start. I built an AI obstacle course. When it can find its way through I'll make a vid.

.... AI is hard!

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.

Just some pics

The last couple months have been full of important updates to the game with absolutely nothing visible to show for it. It's somewhat depressing :p

So here's a couple pics from something actually visible.

New Flame Elemental Skin, version 1
Angle 2
Angle 3

That's it for now. I'll do a thorough update when my head's less hurty.

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 :)

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 2014 Review!

Now that the travelling immediately post-LAN is concluded and I have returned, it's time to reflect a bit on the results of this years LANstravaganza. First the behind the scenes stuff then the gameplay results.

• Setup:
• Installation FAILURE(S). OMG the installer didn't work on fresh machines. Existing installations updated fine but new machines failed for as of yet unknown reasons. Obviously this should be prio 1 for me to fix. It's worked for so long that I haven't checked up on fresh installs. A bit of a pain to diagnose, but so it goes. Not all programming is glamourous.
• Asset acquisition. 2 machines failed to get some of the assets during play. The initial asset set on login all worked, but some were missing rig assets, and Cheryl was notably missing pretty much everything. Still can play though :)
• Server Side:
• Aside from earlier issues, not bad at all. Like last year I didn't have to touch the server nor run a single zone manually. It managed itself nicely behind the scenes, even recovering gracefully from someone putting Outpost on 'server melter difficulty'. 
• No noteworthy problems with the server. There ARE still issues with exploration mode, but that was removed for the LAN for that reason.

Now more interesting stuff:

• Scenarios!
• Tutorial
• The tutorial works good! People seemed to enjoy playing it and for the most part understood what was going on. We have a list of things to improve of course, but that's to be expected. Once the installers are working I'll recommend to anyone that wasn't here to play the tutorial and give more feedback :)
• I believe we had 5 or 6 people simultaneously playing the tut. Not bad for a 9 year old server box.
• In the end 8 people played it most of the way through. Sean didn't get a chance to finish, after he encountered one of a very few breaking bugs in the tut, which will be fixed promptly.
• Glacier
• This was Eirikr's 2v2 PvP scenario, a kill-count race with incrementally spawning units hostile to both teams, of increasing danger and value.
• We played 4 times, with varying teams. It went better than I honestly expected. PvP's a tricky beast in this game just by its very nature. We didn't originally plan to have PvP in the game, but these scenarios are just so easy to make, and are somewhat rewarding to watch being played.
• Notably, a couple people had more control trouble in this map. There are some narrower areas which tend to produce those problems. Figuring out the root cause of those control issues is a pretty high priority for me, it'll probably take some pretty serious analysis at a forthcoming TOASTnight. 
• Balance issues? It's not possible to really say there's any balance to have an issue yet, but watching Max blitz through 2 enemy players without resistance was something of a sight to behold. Mostly ignore this for now, until we're sure all the class mechanics are working. PvP counter play doesn't have all it's necessary bits yet. Improved defensive maneuvers and the focus maneuver may help out, if and when they are done.
• Well done Eir :)
• Outpost
• This is the somewhat scripted defensive scenario I've used as a testbed since just after last year's LAN. 
• The scenario plays out fairly well, but objectives aren't clear and it is somewhat exploitable.
• Allies can cross into the spawn territory of the enemies. Since they spawn incrementally for most of the scenario, this makes it way way easy and needs to be controlled or removed. Most likely we'll make an optional objective to do something across the river in enemy territory, but forbid spawn camping directly.
• Enemy scaling is complicated and occasionally broken. This scenario scales up with player count, which works peculiarly. Double the players cannot handle double the enemies in this case, which is somewhat surprising. In any case this mostly just needs more tools to allow the scenario designer to control the enemy count better. Also, more time to tune against player count.
• Anticlimax. The scenario just ENDS if you win. We need a finale or at least some fireworks :) The win screen doesn't really exist either; it just takes you back to the initial menu for when a scenario is initializing and the players get ready. This is very true of Glacier too.
• Others
• Mostly other scenarios were played in interims and only a bit
• KoboldKing, the focus of the last LAN, was basically obliterated. The enemy defensive power was mostly due to a mechanic that we removed from the base unit definitions (opting to have it be part of the scenario instead), but didn't re-add to the scenario. Sooo, the players pretty much just ran over the boss and called it a day.
• TerraTest wasn't played, it's day is probably done, which is not sad at all because it is bad. As with many others, was mostly a testbed for development.
• Maul wasn't played, it needed rebuilding anyway.
• There are no other noteworthy scenarios... yet.

Overall this year was much better! Last year I said that 'it was more of a game than a demo now'. This year this is much more true. The features added for the tutorial have really improved things across the whole game.

So what's next?

First, incorporating the LAN feedback, as recorded in this pic.

Second, more scenarios! Time to make a new scenario. Maybe an assault scenario or a reverse-escort assassination mission, or an escort mission, or...

Third, details! A pass over animations and sound would be good to do. Fleshing out sounds for the entire tutorial would be an important step forward for media. Most of the LAN played without sound so I got away without much negative feedback there, but I know what it'd be if they could hear it.

To finish up, how bout a couple images? Here's the couple I took after I finally remembered to.

Time to get started, I suppose.

New gameplay video recording (+ music)

Hi!

I made a new video finally! It's here: http://youtu.be/DR3oVZfSDVs

I meant for the music to stay backgroundy but I kinda got carried away. It happens.

Also, there's an annoying black bar I didn't notice till afterwards; it'll have to stay since I'm lazy. I'll fix it for next time.

2013 LAN Mid-Awesomeness Pictures

Monday's over. I'm allowed to run Visual Studio again, so I made some pictures :)




First, the continent mode view after the LAN, in Chrome. Each icon is a unit or a player. Most people didn't explore so they're all at the spawn.

A view in Explore mode from the southern cluster of units, looking at the spawn island. New Eirikr-Glaciers :) The pink spheres are the units; obviously they'll be rigged up as humanoids soon.

Just another view over and in some other new biomes.

The hill with the Kobold King scenario. The enemy commander just reinforces his squad and holds the area. It's up to the players to break his formation to knock out the commander.

It's worth noting that the number of units varies with the player count. This is a picture of only 1 player, but when there were 5, he has a solid hexagonal wall of shieldmen surrounding him, as well as entirely-
too-many archers and bombardiers.

Boulder throwing in Phase 2 :)











Victorious Fireworks!

A side-view of the pvp scenario map hastily thrown together. Players spawn on the left or the right from this view. The 3 capture towers are in the sandy alcove, the stone walkway, and behind the hill in the brown area.












I think that's enough for today :) I'll write up the post-awesomeness tomorrow. Also, I should've taken some screenies during the event, or even just some normal pictures. Alas!

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?

Movement revisited

I'm going to use this space today to think out loud. Er, think externally. You know what I mean. Sometimes putting things into words forces it to organize and coalesce into a concrete idea and plan, and the complication of formation movement could use some consolidation.

So forgive the stream of consciousness, and read on if you wish. Any ideas, counter or otherwise, are welcome.


It's an easy assumption to make, that movement and unit control is important. It's arguably the most important thing to get right in any game. I know it is one of Miyamoto's 3 more important things for game development (Character, Camera, Control, IIRC), so it deserves some attention. In our game, the control is somewhat more complicated, since it is neither direct nor constrained. Almost all movement is given as an intent; rather than moving the units directly, the units are told they need to move, however they can manage that given their other constraints. This is important because managing those constraints are critical to gameplay.

Anyway, what are the constraints that make this complicated?

1. Stay as close to in-formation as you can, maximally deviating by a class-specified variable distance.
2. Move towards the user's selected goal location (including pathfinding)
3. Get to a class-specified distance from your current hostile target.

The current approach, so far, has been to compute an 'ideal' location for each of the criteria, then use that to weight each currently-adjacent cell, thereby determining which direction to move (or not, if at the ideal). Even computing the ideals for each is complicated, let's ponder that first.

1. Compute the current estimated formation location of the squad as a whole, and from that compute our ideal offset. 
2. The user's goal location is set for the formation as a whole; finding a relative position to this is not compicated. When obstacles are included and pathfinding is required it becomes a mess, since individual units may opt to take a different path to the ideal location.
3. The attack-distance ideal can be defined as the closest location to the current location that is the specified distance. This one is pretty easy at least.

So given three target locations, how do we decide which to use? So far the subtleties in this decision have all resulting in problems. If 1 is too important, then the units cannot move to the target location. If 2 is too important, the units deviate from each other and the formation mechanics break down terribly once combat is engaged. (Oh, if we're not in combat then most of this is easier, so we're ignoring that condition for now). If 3 is too important, it is impossible to retreat, since units will stay at combat range. Anyone who has played the game at various points has probably seen all three of these faults.

While we're making things sound dire, a few more complications: Pathfinding that accounts for formation offsets is complicated. That is to say, if you want the formation to move around a corner while staying in formation, the individual paths are substantially more complicated than a simple A* will find. Each step would need to determine the 'radius' it accomodates, but this would have to have some directionality to it. Units on the right edge of a formation would need no extra space around right turns, but lots of space on left turns. Can this be computed efficiently? Each cell could retain 6 'wedge distances', perhaps, which represent the distance within each hex wedge that is walkable. Currently we retain a single 'free radius', but there is no directionality to it. (This radius is used to limit occupancy by large units, and was used in some formation movement tests already).

A second option for formation pathfinding is to compute the path at the squad level rather than the individual unit level. This could solve the problems with diverging paths as well. The question is how and when to compute the next step. It could be recomputed every time the estimated current formation location changes, and set to a few cells forward on the path, perhaps. If computed this way, the singular occupancy radius could be used to generate a smooth formation path, which should keep the units together.

See? That was an idea. I hadn't thought of that before. This is useful. I like this experiment.

So I suppose now we have a coherent answer for the ideal locations. Back to resolving the decision making once the ideals are known.

It feels like, rather than a weighting function, a sequential deciding criteria may work. Consider:

1. If the unit is not within tolerance of the current formation ideal, move to that, otherwise:
2. If the unit is not within tolerance of the target formation ideal, move to that, otherwise:
3. Move to the target-distance ideal.

Could something this simple just work? The current approach uses weighting functions rather than a decided single purpose for each move. Maybe it is worth a try. 

It's worthy to note that when I started writing this last paragraph I started by assuming this approach wouldn't work, and I began writing reasons. I failed, but isn't it interesting to note where one assumes incorrectly, without even noticing that one is confused?

Recapping the movement process:

• Component 1: Formation estimation
• The formation leader maintains an estimate of the current formation location. Whenever this location changes cells, a new path will be calculated to the user's target location, using formation-width weighting to round corners. The new target formation location will be set a few cells down this path. (Setting it to merely 1 cell away will should result is some nasty stutterstepping and un-smoothness, but given earlier mistakes, I will TEST this when implemented).
• Component 2: Per-unit movement step
• Compute the current-formation ideal location and leeway. If the current location is outside of this leeway, move towards the ideal and finalize decision.
• Compute the target-formation ideal location and leeway. If the current location is outside of this leeway, move towards the target-ideal and finalize. NEW IDEA: If the location towards the target-ideal violates the current-ideal leeway, STOP motion and wait one tick to re-evaluate. We don't want to cause cyclical stepping between target and current in the case that the current is 'stuck' away from the target.
• Scan neighbor locations for the cell closest to the target-distance ideal. If a better cell exists and this cell neither violates the current-ideal nor target-ideal, move to this cell and finalize.

For now I'll use A* for the pathing, and I'll ignore efficiency entirely. (Early optimization is the root of all evil, after all)

I can do this. Let's see what happens.

-------------

Here's an image of the scenario editor showing a variable-width path. I rigged up the editor to show me the pathing calculations; easier than expected, even though it requires bringing in server code to the editor. Apparently the mapping subsystem isn't coupled too tightly to the rest.

-------------

Aftermath 1: They dance around a bit, but in they at least get around, eventually. The twitchiness will need to be addressed, but I believe it is in better shape than beforehand, at least.

Aftermath 2: After adding in the post-constraints (moving to target will no longer move outside the current), it works smoother. There were some code bugs associated with the time to decide motion that got resolved as part of this.

Aftermath 3: There's a problem still remaining if the target and currents have no overlap; in this case each unit will stop proceeding. In theory this just means that the unit is awaiting the formation to reform correctly, but there are stable cases where this happens; for example, a formation directly turning around. Each unit is stuck waiting on each other; kind of like deadlock. Adjusting the formation location analyzer helped this a bit, since the prior was quantized in angle and really angle-twitchy, but the lock is still possible. Smoothly changing the rotation from start to finish may be necessary as a pathing-like step.

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 :)

 

Maneuvers

It's been awhile since I wrote a design thoughts essay post. I've been intending on writing this one since before it implemented and sequentially changed. So, without further boilerplate:

Maneuvers: 


A maneuver, in the context of a World skirmish of course, is an action invoked by the commander, used to change between formations and locations in a specified manner. The intent was that a maneuver would be used to quickly change between formations in combat situations. The end result and implementation were a bit more complicated.

Let us define the exact details of the maneuver in the Skirmish context. A maneuver consists of 4 stages, a windup (channeling, which can be broken, and an associated buff state), initiation (which triggers class specific actions), advancement (moving to the target location, which can also trigger class specific actions), and finalization (reaching the target location, also triggers class actions). Notice an awful amount of detail hooks there. Each class specifies how it behaves for each maneuver. A shieldman may conclude a maneuver with a shield slam. An archer may lead a maneuver with a volley of covering fire. The commander may provide a group buff while advancing. Furthermore, the commander will have multiple maneuvers, so each differing kind can have different per-class hooks.

Except, that's rather massively complicated. The first maneuver we made is a simple 'Charge' maneuver; run at the enemy and engage rapidly. If we make a second maneuver that is similar, should it have entirely different class actions? Nah, let's categorize maneuvers. Now, all 'Charge' maneuvers share the same actions. This lets the commander upgrade the maneuver without forcing us to re-implement all the maneuver-actions. We could make a 'Charge 2' (for lack of a better name atm) that winds up faster and provides a speed increase while running, but now it otherwise acts exactly like 'Charge 1'.

So now we can run at things and have new class differentiation points. Yay! What about other kinds of maneuvers? A coordinated retreat is kind of like a Charge, except away instead of toward, so the implementation there is easy. We make a new maneuver category to change class actions and it works without problem. A slow pressure advancement works similarly. After that we created a 'Hold' or 'Stand your ground' maneuver command. This one was different, in that there's no movement phase, and the ending triggers are different, but it still works. The same logic can be used to make a maneuver that just tries to get the formation back in order quickly.

So 5 maneuver types; Charge, Advance, Retreat, Hold, Reform. They almost perfectly correspond to the 5 formation movement modes (Charge, Advance, Defend, Retreat, Hold), which is cause for thought. Should maneuvers replace formation movement entirely? We concluded that no; maneuvers are a specific command with costs and benefits associated with. It would be silly to run with a charging sprint as your default move command. Sometimes you just move.

Implementation took a bit of effort but there was nothing terribly interesting to report about it. We've had the maneuvers in place and working for a few weeks now, so they've been used enough to know that Charging is Fun, Advancing is useful, Hold has potential but the current scenarios do not require it, retreat is occasionally necessary and the only reasonable way to extricate a group from combat, and reform is... well, a little less interesting, but it COULD be with more maneuver-actions by class.

A success? Well, sort of. Remember that part above where I said that a maneuver is a method of transiting between formations? Turns out we never did that, but we always have to specify the target formation anyway. So, why is this part ignored?

My opinion now is that the original concept was flawed, because it was based on a different pace of combat than the game actually exhibits. If you imagine a combat where units stay rigidly in formation, there is very little motion, and slight positioning different matter tremendously, then special methods to adjust inside a formation are relevant. This was in part the original concept. What we have now, however, is a massively more fluid, dynamic, and mostly chaotic combat engine. Is this good? The chaos is kind of enjoyable when you're the cause of it (which may be why Charge-ing is Fun :) ). With retreat/reform you can manage the chaos inside your group enough to not be bogged down. Advancing does a reasonable job of slowly pushing forward with a more organized wall. I think it works! Let's keep it. But what do we do about the maneuver definition?

Meh. Delete it.

We'll see how it plays without formation swapping; I bet it'll work fine.

Next essay I'll talk about Consciousness, or more specifically, lack thereof, as a game mechanic.

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!