Thursday, November 17, 2011

More renders done over night.

Set my machine to render a dozen or so more similar shots as yesterday's post.

Gonna use these to make the Toast 2011 shirt fronts. Back will probably be the same as 2009's.

I wish I could get that lighting quality in the game engine, but these took 40 minutes each on a state of the art GPU renderer, so I don't think that's too likely. I can dream though; it makes the programmer art boxes look good :p

Wednesday, November 16, 2011

Thursday, September 29, 2011

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.

Sunday, September 25, 2011

Bigger Update :)

Well, there has in fact been progress, despite the painful lack of updatery. Here're some images.

More combat.

I'm honestly not even really sure where I left off. The main development arc for the last couple months has been the rewriting and utilization of the Titan character engine, which I created long ago but never really used. We've now got a way to build a rig, add animations, and drive them from the game data.

The enemies don't have their anims assigned, so they're zombies, pretty much. The first four classes are rigged up with a single attack and an idle, but that's it so far. I've touched up the effects system as well. Rigs can setup binds and add rig props (the bows, swords, shields in the pictures), and visual effects can use the props' binds as well. I made a new arrow effect with a nice clean trail, too, instead of the particle trail from before.

In general the game runs faster, smoother, and plays better. Lots of small things really add up.

Now that the animations are mostly complete on the code side (not by any means 'done', but good enough for now), I'm moving on to scenario development and scripting. It's time to make an interesting setting and prove that the game is fun.

But first, more bug fixing...

Next time. :)

Friday, August 5, 2011

New stuff incoming, but denied by travel!

So, I've been waiting to post the update for awhile. Reason is, it's a pretty big one for the client. New neat things; things I've been wanting to include for years but never mustered the will to do.

Unfortunately, weeks of work travel have impaired the finishing of this segment, so you'll have to live with just one screenie.

Thursday, June 9, 2011

Blaarg Status Update

Though be it a long time since the last update, things have been written:

  • New targetting method: None. That is, enemy units are automatically selected now. No more requisite constant boxing.
  • New enemy panel: Shows health/morale of all enemies, and allows using the new:
  • Focus ability: Used on targets to increase the chances your units will attack the focused target, and units will always target their focus with special attacks.
  • New commander ability: Consonance: Allows nearby units to share health, healing nearby hurt units at the cost of their own health and morale. Certain types of units modify the effectiveness of this effect.
  • New data parsing abilities: New entity creation summons, new AoEs, Group-Buff.
  • Fixes to proximity auras, general fixes to piles of actions.
  • A couple boss enemies. :p
I bet there's more; it's funner now.

Monday, March 14, 2011

2 New Tracks

Recorded two new ones today: The first is along the lines of my normal fare, but I tried to give it more impactful energy. The first 3 minutes goes with no key changes; just jamming with rhythms instead of key changes and harmonies.

The second is completely different. I've occasionally been playing songs as if I was writing for the game soundtrack; trying to explore different emotional feels rather than musical complexity. This one's more backgroundy, a little ethereal, and with a little bit of cycling between angst and excitement.

Or something like that. It sounds silly when said out loud.

You know what I meant.

Friday, February 11, 2011

World Update, BIG version!

I decided to do something I haven't done before. I want to lay out what I've done on this project, and document the state of things right now. And This Time, with Pictures! This isn't about the code (unlike normal), I just want to show what we've got. Turns out we kind of have a lot, but scattered about in many directions. This may take multiple posts...

First the Servers:

That entirely uninspiring image consists of my normal system tray, plus two extra special Nick-made Icons. The far left is the accounts and login server, and the second is the server directory server. These are probably the smallest bits of the World infrastructure. The accounts server is used to save characters and setup accounts. It's mostly a small blob of networking code and interaction with the MySQL database. The Directory is a record of what zones are running where; kind of like a tracker for a torrent. It's kind of unused, but it'll get more use very soon.

The tray icon lets me bring up a text display of the server without it being a stock console window, and has some controls to shut it down. Amusingly, they don't respond to SIGKILL, so computers can't shut down until they are manually killed. I laugh.

The more important Server, version 1:

That's a Zone server. Specifically, it's the editor/viewer for a zone during execution. That's pretty much the first executable written for the system, and as such is kind of.. raw. It allows raw access to the states, attributes, etc that run a zone. It has no concept of the game you are playing; it just knows how to execute it! This makes it... user hostile, I suppose.

It has a pile of ways to view each entity in the system. It can view an entity in detail, including all current stats, states, actions, and components. It can view the state of the states. It can change them if it wants. It can totally mess with things that should not be messed with. Like, say, revoking the 'Alive' state on a particularly nasty enemy. That doesn't kill them. It just removes the ability for them to die. So much fun.

The zone it's running in that image is one of the current test scenarios; it has a small forest to set on fire and some rocks. Very exciting. Will get there later.

There're two more versions of the server executor; One that runs as an icon and one that runs in a console. Useful in different cases. It's not like a live server would sit in an expensive window and waste resources.

The current Client:

Same server zone executing as above, just from the player perspective. That's a fairly large group in a kind of football-like formation. It's mostly melee so that makes sense. My units and actions are down the left, my selection on the bottom, and some enemies in the distance. You'll note the real lack of graphics. My next big task is to address that. It's not like I don't have the experience to do so, I just need the time.

But, despite the relative ugliness, the system does work. Actions are usable, formations can be built and saved, all the movement types can be executed.

The second image is just most of my guys on fire. Fire is bad.

Oh, and those are all placeholder icons, of course. They're only mildly borrowed for temporary use. I ain't gonna ship anything with recognizable iconnery.

And just to illustrate a point:

That's the system usage during a fairly large fight. The server's using a whopping 4%, and the client's eating up a full CPU like it should. I'll note there are massively unoptimized sections of the server and its still quite light. There are two pretty major timesinks that I know how to remove. The last profile showed them at about 90% of the CPU time usage on the server. I can probably cut them to 10% or more without too much effort.

And lastly the Tools: 

For a long time I was trying to build the database with my own editors for the raw data. That didn't really work too well. So, instead, we built a way to more meaningfully represent the game data, and then wrote a tool to parse it and build the low level zone data to implement it. It's kind of like a compiler for actions and states. The data sits in a couple spreadsheets in google docs, with a few pages in each, and can be compiled into the game data in about 20 seconds. GDocs lets us collaborate very easily too, which is a noteworthy plus.

The builder doesn't really have a UI, so no pretty pictures. It does, however, have a lovely error output text file that Kol and Eirikr have grown to hate.

Eventually that wasn't quite enough by itself. We needed a way to compare abilities and see what happens. And, hey, why not make something that lets us iterate on that super fast too? So, I built a simulator. Er, it's not really a simulator, in that it isn't simulating. It just runs zones in super-fast time.

In any case, we have a document that specifies a combat, and a program that executes the combats and aggregates the data back into the same spreadsheet. AND, it can rebuild the database inbetween executions, so you can tweak the database documents in between runs and see the changes super-fast style. Since the database rebuild takes 30 seconds or so, and a full 200 sims takes about 10 seconds (and 10 seconds to save the data back to GDocs), this makes a pretty fast iteration time.

Here's a link to a published version of a simulation page. Less flashy but useful.

But that's not all! More and more tools!

Here's the server database editor for the server and client side datas, as well as the state machine editor. Most of the server side logic is handled in behaviors in state machines, so the simple visual editor is essential for building the low level mechanics. The state machine shown executes the 'Pressure' mechanic; where units back up uncontrollably if they're too heavily engaged. (Edit: Oops, that's the state for 'Pressure Bravery', which increases, temporarily, the threshold for pressure to act, for a few seconds after stepping away)

Pretty much only I edit the low level database stuff. It's kind of nasty, in a massively simple kind of way. (What I mean is; it's so simple it doesn't do anything for you, so using it is complicated. Does that make sense?)

Arg! There's 2 more still!

Visual effects tools!

This is a tool built for editing a subset of the client data; the visual effects drivers. It repeatedly executes the selected effect, making it pretty easy to tune one up, at least given the constraints of the visual effects system so far. :)

That's a fireball V1, for reference. Not available to normal players. :p

And lastly, the most recent and most useful: the Scenario Editor:

Even more complicated than building the database is building a bloody scenario. It was so obnoxious to do we played the same scenario for about a year and half... Yeah seriously. Got kind of tired of it.

So yeah, another tool to build the maps. It's necessary to setup the new maps grid structure, as well as setting up regions, unit placement, teams, etc. While that's about all it even 'can' do right now, it's setup to handle unit behaviors (patrols, groups), unit scripts (for bosses I guess), and more complicated scenario objectives.

So in the end, the scenario editor executes the scenario builder, which uses the data produced by the skirmish builder from google docs, which populates the client data, which is editted with the visualizer, all of which is executed by the zone server, which communicates with the accounts server and ARG ITS COMPLICATED.

But it works. :)

Wednesday, January 12, 2011

Finally setup another recording.

Just another simple track. I wanted to try mixing guitar and piano. The setup worked well, but it's strikingly obvious how much better my piano is than the guitar. Nonetheless it was fun. :)

Piano only version:
Mixed version:

The basic pattern is an ABCB. The A is calm but building, B is energetic piano work with guitar backing, in C I let the piano take a background to see what I could mess around with on the guitar, and I finish with a bit more energetic piano stuff.

Wednesday, January 5, 2011

Breaking everything!

This is partially another progress update, but I might go into a bit more detail this time. (Turns out after writing it is mostly prose, not so much an update. :p )

First off, I spent the week before christmas on a big big change to a fairly low level in the codebase. It took the better part of 3 days (with probably 5 to 6 hours of work each day) to just get the system compiling again, let alone fully functional! We're talking a low level change here. The full system isn't fully functional again yet, even though the core is working correctly, so you know it's a pretty fundamental change.

Here's the skinny. We've got a good 4 sizable and separate layers of the server side implementation. The lowest level manages definitions of game data (the game database). The next implements that data (the zone implementation). There is another layer to construct that data from a more user-friendly format (stored in google documents, actually). Lastly there are various communication layers built on top of the zone implementation that provide specific functionality that can be consumed by the lower layers.

Most of the layers have very few concerns. (As an aside, it's odd to many people to anthropomorphize code, assigning it thoughts or concerns. To me it's important to constrain sections of code by their concerns, so that no section internalizes too much complexity. It makes a large system possible and maintainable when done correctly, even if it sounds silly and doesn't belong in master's theses).

Ahem; Most of the layers have very few concerns. The bottom 2 don't even know what kind of game we're running! In fact, the server and communications modules don't know either, so half of the 3rd major layer doesn't even know it is running an RTS. The obvious boon for this is that we have a game-agnostic engine. We could use this to make another game! But, er, why? Are we actually going to do that? I can't finish 1 game let alone multiple. No, the real benefit is that the code is simplified when it uses fewer assumptions. The foundation of this engine is simplicity; an entity in the game consists of only 3 concepts; data, states, and actions. Everything can be broken down to these 3, which keeps the zone implementation and game database layers very focused.

Now all that's all good, but it makes elementary interaction with the system complicated. For example, imagine some very very high level code that operates the formation system. This system is extremely dependant on knowledge of the skirmish game. But, since it operates on the skirmish-agnostic data, it has to contain a great deal of additional code to translate the low level data into the higher level data. That makes things crazy hard to work with at the top level!

Relatedly, it turns out that building a scenario is extremely complicated. The nature of spawning enemies, teams, groups, formations, scenario organization, respawns, etc etc, is very complicated! The editor for the zone implementation, since it doesn't 'know' anything about a skirmish, is incapable of making these operations clear. Of course, we could just break our rule and make it aware, but that just makes that one layer extremely complicated, since it has to now know the full details about both layers.

Anyone who's played the game within the last 2 years knows we only have one level. Perhaps that's clear why now. Even I really, really didn't want to have to make another.

So it's time to fix that. I'm building a scenario editor. This is a higher level layer that represents data specifically in skirmish-level constructs, and is then compiled into a zone implementation. The compilation process is the only small bit that needs to understand both layers, and is segregated away from the data manipulation. It loses some power in the process, but it gains orders of magnitude in simplicity and usability.

But just building the same kinds of scenarios is boring. There are a pile of necessary, low level features we've been lacking for too long, and its time to figure out how to include them. The first obvious one is to have terrain and obstacles, rather than an infinite empty plane. This, is what took those 4 days.

So. Originally the world system was built without movement constraints. There was no collision, no intersection prevention, no pathing. Everything could move anywhere. But, when we started implementing the RTS mechanics, we found that horribly lacking, and needed to control space better. We opted for a hex-grid based system, which works well for RTS games. The zone implementation was given a higher layer for managing separate spaces. Some objects used the free mover system (non-game entities, spawners, some ground effects), and units used a hex system.

But this then colluded the hex system away from the core assumptions of the zone implementation. The hex system couldn't be assumed, so a great deal of code had to be written to translate between those layers. Complicated! Hacky! It also means that any collisions have to be done on all layers, and between layers, which is just way complicated. Adding navigation, obstacles, and heights to the combination of systems would be largely impossible.

So I settled on implementing the hex map as a core assumption of the engine. It would no longer be implemented 'on top of' the free mover system. Position of entities would no longer be given in 3d coordinates, it would be strictly in hex-space. Everything from proximity detection, range checks, and basic movement would be done directly on the hex-graph. This meant, well, rewriting everything.

But it means that the graph is the de-facto declaration of the world space. Removing cells from the map or adding new ones controls space. So, if I want a bridge, instead of doing some intersection test or complicated movement logic, I just remove the cells around teh bridge, and everything works. The graph is the world.

But yes, changing over the system was difficult. First, the old scenario no longer even makes sense. It doesn't have a grid, and all the positions are in the old system. The old zone is dead! A new way of building zones needs to be built. So then, obviously the next step is the scenario editor. It's started now, but can't do most of what is necessary. I can create a flat network of hex for the map, but that's just to get us back where we were. I cannot place units yet, nor setup start positions. I can setup the scenario type, btu that's about it.

So we have no scenario. :p But we have a kickass new nav and motion engine! That we can't see.

Back to work with me.

That was kind of rambly, wasn't it...