I'm Chris Eck, and I'm the tools developer at HBS for the Battletech project. I've recently been given permission to write up articles about some of the things I work on which I hope to post on a semi regular basis. Feel free to ask questions about these posts or give me suggestions for future topics. However, please note I am unable to answer any questions about new/unconfirmed features.
This week was even more performance work as we were gearing up for a cool live stream demo and we were hoping to show off some new Urban Warfare maps. The performance strike team made some huge gains in various areas and I think the stream went really well - I still need to watch it because I was on the road heading to a Blood Bowl tournament at the time.
In addition to performance, I was helping other people with various tasks: UI, Serialization, code reviews, etc. But one awesome thing that I did was solve a bug that has been plaguing us for about two years. Often times the longer it takes to track a bug down the stupider or easier the problem is to fix. At the 2-4 hour mark it's usually something like a typo or capitalization issue.
The bug that wouldn't die
So we've been having this issue where maps would just unpublish themselves seemingly at random and for no good reason. The problem has been happening for YEARS. And Friday I FINALLY found the problem.
Many times in programming - the longer it takes to find the problem - the stupider the problem is. This was no different. We build all our procedural encounters in a test_encounters Scene and make our prefabs there. Well we don't want to publish those test encounters so we make sure to exclude them from the build in that scene. This value is stored on the Encounter Layer itself so when changes to the prefab get applied it would update the prefab value. Any prefab instance that didn't manually override the prefab value would then unpublish itself in the next build.
One of the biggest problems was I could never see it happen on my machine. I'd have the designers check in these changes so I could try and identify what was happening. But at that point, the designer had already changed the publish value on the prefab instance so it always worked correctly when I was looking at it... GAH!
After finding the cause of that issue I got SUPER jazzed. I love solving problems and when it's a persistent one like this it just feels so gooooood. It was a great way to end the work week.
More Encounter logic
Let's talk a little bit about the classes and scene hierarchy of Encounter Logic. At the top level I have an EncounterGameLogic. This is the base class for any object that the Encounter Logic operates on and the important bits are: a Name, an EncounterObjectGUID (unique id), some State Management (active/inactive/ignored) and some corresponding lifecyce functions (OnEnterActive, OnExitActive, etc)
The topmost object in the Scene is the EncounterLayerParent. There is exactly one of these in each Map and it holds a list of Encounter Layers. As an example we might have three different battle encounters, an escort encounter, an attack base, and a defend base encounter all implemented on the same map. The Encounter Layer Parent manages which Encounter Layer is active since only one of those can be active at a given time.
In the case of procedural missions (Battle, Escort, Attack Base, etc) these are all created as prefabs. To implement a new Encounter Layer on the map, a designer just has to drag the prefab into the scene, position all the spawners, regions, encounter boundaries, etc. Play test it a few times, mark it for publishing and then it'll be incuded in the next build. When the Combat Mission loads, it tells the Encounter Layer Parent which Encounter Layer to activate.
The Encounter Layer contains a list of Encounter Chunks. A Chunk is a collection of Encounter Objects and sometimes prewired logic that I talked about in my Previous Journal Entry. EncounterChunkGameLogic inherits from EncounerObjectGameLogic and its only real job is passing along its Activation/Deactivation signals to its children. Chunks that have actual logic in them derive a child class and expose some configuration to the designer so they can tweak different things about them.
Underneath chunks are where the actual Encounter Objects live. Things like Regions, Objectives, Dialogue, Lance Spawners, Routes, etc. Some of those like Regions, Routes, and Lance Spawners have further child objects underneath them (Region Points, Route Points, Unit Spawn Points). Each of these objects contains the Encounter Logic for its purpose and inherits from base classes where appropriate. There's an Objective base class that handles pretty much everything except for WHAT the objective is tracking: methods to CheckForSuccess, Failure, firing off messages when it succeeds or fails, populating the UI, etc. And everything overrides its own validation function that report helpful errors: Objectives need to be configured appropriately, Encounter Objects need to be within the boundaries, etc. The object Hierarchy looks like the image to the right.
So most encounter objects exist as children of Chunks under the Encounter Layer. Obstructions are a special case though. They just exist in the level. Since we want things like rocks, foundations, and targetable buildings to exist for every Encounter Layer of a given map, they can't exist underneath the Encounter Layer. Otherwise we'd have to have copies of all the obstructions for each Encounter Layer and it would make creating prefabs difficult.
Hopefully that was a decent overview of the Encounter Layer structure. I'll save Map Data and Contract Application for another day.
Blood Bowl Tournament
I started to write up some notes about my Blood Bowl tournament experience, but it got big enough to be its own blog entry. If you're interested you can see how Grubsnik's Greenskins fared here. I will say that I had a blast and I finally got to meet my friend Kent in real life. (Publishing Blood Bowl journal soon)
https://www.gamedev.net/blogs/entry/2267186-blood-bowl-4-diamonds-cup/
Tips from your Uncle Eck
The longer you spend attacking a problem and something just DOESN'T make sense, start checking the simple stuff. Maybe it's a typo or casing issue, maybe you forgot to implement a function, or maybe it's just not plugged in.
