The absence of a save/load system at launch understandably generated a lot of forum chatter. Having defined the save/load framework as part of the development of the Location Editor, in the last two weeks we've extended it to include all of the objects in the tutorial. We're about 70% done, with the final 30% involving test cases to check game state is correctly restored. So hopefully not too much longer until players can save games in the tutorial.
With each new patch there is however a chance we may need to purge previous save games. Obviously we'll avoid doing so unless absolutely necessary, but when we do launch the feature, please bear in mind that it comes with a caveat due to the nature of being alpha that the shelf-life of a saved game might only be a few weeks.
Location Editor / Tower Defense Mini-Game
In the previous dev blog we mentioned Aron was integrating the new tile-based navmesh pathfinding system into the Location Editor. In today's blog we're able to take a closer look behind the scenes at what's going on. In the image below, the top and middle windows show the same scene with and without the purple navmesh geometry and the cyan shape-cutters for trees, while the bottom window shows a top down isometric view better highlighting the individual square tiles.
The shape-cutters are required for props that populate a scene, for example trees and chests. We don't know where players will want props in their location designs, so at run-time we perform a boolean operation using the tile's source navmesh and the shape-cutters to produce a new re-triangulated navmesh. If during gameplay the player constructs a building spanning several tiles, the building's own navmesh overrides that of the tiles ( which is temporarily disabled in the event of the building being destroyed ) and connects itself automatically to neighbors. Of course all of this is hidden from players who's focus can remain firmly on creating a great location design.
|Tile-Based Navmesh Pathfinding|
With responsive UI being critical to user-adoption and productivity, we've been cleaning up the next iteration of UI windows. First impressions count, so it's important resizing, locking, scrolling, snapping and depth swapping are all glitch free to avoid putting players off.
Aron has also been performing a peer review of the entire programming code base. Having been the sole programmer for two years, it's invaluable to get a fresh pair of eyes onto my own code and to implement some of his ideas for improvement.
Art Assets: Hunter's Lodge
Following on from the concept art presented in Dev Blog 10, the three tiers of the Hunter's Lodge are now complete.
Animation: Quadruped Skeleton / Horse Riding
Both the stables and the cavalry military unit require horses be added. Using a rough working model that the art team will later shape to match the final horse concept art, Tom has been working on the quadruped skeleton required to animate the horse. It's early stage but once it's finished we look forward to sharing some video footage of the horses idle, trotting and galloping animation loops.
|Quadruped Skeleton for Horses|
The same skeleton also drives the deer, which the Hunters shoot with crossbows and carry over their shoulders back to the Hunting Lodge for skinning and filleting.
Pre-production visualizations completed this period include the Stables, Fisherman and Stablehand. A number of the designs are too modern and need a heavier bias towards medieval styling, so they'll undergo a final iteration before 3D modelling begins. Hopefully it will be interesting to show in future blogs how characters evolve from the pre-production sketches we've shared thus far to a final painted 3D character in the game.
I did discuss with our Art Director whether we should produce fully painted concept art pieces from these base visualizations, but I'd rather him spent that time painting the final character texture. It's a much better use of time and money.
|Character Concept: Stable Hand|
|Character Concept: Fisherman|
|Building Concept: Stables|