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