Wednesday, August 8, 2012

Meta-Work

Long time no see!

Why no videos, updates, etc? There's a good reason for it. It turns out that a lot of the work involved in building a complete system is... really really boring!

At least, it is to the player. I've always been kind of secretly entertained by the 'meta-work' needed to build the complete system, so the last few months of productivity have been somewhat enjoyable for me. They don't, however, make for exciting videos or complicated subject matter.

So what's actually been done since the last updates?

Game stuff:
  - Motion pretty well works now. The last post was all about movement. It plans therein didn't 100% work, but they got things moving in the right direction. In conjunction with fixing a few low level bugs, units seem to move fairly predictably and controllably now. There're a few things that could improve still; for example, if you command a move with a new formation orientation, should the group rotate or move first? Turns out to not be a simple implementation detail. It makes sense to say 'if retreating, move first' and 'if attacking, rotate first', but it's not entirely that simple.
  - Some scenario stuff. Been working on a more heavily scripted scenario, so things like triggers, unit details,  player triggers, custom units, etc, have been improved noticably in the scenario editor. As noted above, though, showing the scenario editor is not exactly rivetting entertainment. When the scenario is complete I'll video-up a playthrough. Maybe with multiple people.

And Meta stuff:
  - Wrote new Universe server, with lots of sub-servers:
    - Scenario server; maintains a list of available scenarios and can launch them; they're each launched into a new instance of the zone server, each of which can have updated EXE/DLLs and game databases. This means code updates can apply to a live server.
    - Accounts server; this replaces the old one, as a part of the universe. Account/player/commander/primary data is now stored more simply as well; just as local (server) files. This removes the pain of the unnecessary link to SQL, and simplifies deployment. (See? Deployment is a boring word, but it is important!)
    - Assets server; this is an entirely new and complciated system:
      - The game client no longer ships with ANY content; it only downloads and installs the DLLs and EXEs and maybe a config file. Upon load, a set of required assets are pulled down from the universe server's asset system. Later, when game assets are needed, they are loaded on the fly, with a temporary asset put in place while loads run in parallel.
      - The server and client both SHA1 hash their asset data, so when the client starts it can do a simple comparison to know if its content is up to date. No unnecessary transfers.
      - So in the end, the server can update the game database, animations, textures, terrains, models, etc etc, withOUT requiring a new install or patch of the client. The client only has to push an update for code changes.
      - Obviously this is a big and complicated (and awesome) piece of architecture, which I'm quite happy with. This doesn't make it interesting to show people though. :) "Oh boy, my units are boxes! Oh wait, now they're people again" isn't terribly exciting, but it IS useful to me :)
   - Lastly, cloud deployment of the universe and content. 'redtoast.net' now points to an Amazon EC2 micro instance, which runs the universe (as well as other services like apache). I've built scripts to run on this instance to auto update from source control and rerun the universe, re-deploy the client, etc. It's neat! It's boring, but it's neat!
   - Because of the cloud deployment, everything now works without my home machine running the custom servers. Maybe this means I can have a more publicly accessible pre-pre-alpha....

Some new game data will come soon, with the new scenario (soon), and then some new universe related neatness!

Party on.