Welcome to our first installment of the Battlehouse Dev Blog, a place where fans of all Battlehouse games (Thunder Run / Days of Valor / Mars Frontier / War Star Empire / Battlefront Mars / Firestrike) can enjoy regular behind the scenes peaks into the mind of at least one Battlehouse Developer. This week we’ll be getting to know our Developer a little bit better, after which point he’ll dive deep into some detailed Engine Development updates. So without further adieu, everyone meet bh-nirgal:
About Your Developer
Hello, all! Your blogging developer this month will be Nirgal. My professional background is in cybercrime investigations and computer forensics. I served as a police detective for fourteen years prior to joining Battlehouse. Aside from my developer role, I also work as a computer forensic scientist and forensic software developer.
I joined Battlehouse in May of 2018 as a junior developer. My first project was the anti heavy armor mine. In September of 2018 I became the lead game developer. At that point, I mostly worked within the confines of existing engine features. I had prior experience as a Python developer, but no experience in JavaScript or HTML5, meaning I had little knowledge necessary to work on the browser engine. Thanks to constant immersion in the code and a passion for education, I’ve learned enough JavaScript to make adding features to the engine a regular part of my work. My responsibilities gradually morphed to the point where I’m now responsible for a lot of the game engine and server.
My goals for all of the games have been to improve the chances of defenders by increasing the variety and strength of base defenses, and to make new content for attackers more mechanically interesting to play.
In this blog, I’ll be discussing contents that are currently being developed and the reasoning behind the developments. I will also be discussing planned next steps that have a timeline, and discussing possible future development that has no set timeline. Reader feedback is strongly encouraged.
Engine Developments
Our HTML5-based browser client has been the focus of several recent developments that have affected most of the games. Most of the changes currently in development have been focused on how crafting and upgrading works “under the hood.”
Landmines, which are currently featured in Thunder Run, Days of Valor, Battlefront Mars, War Star Empire, and were most recently added to Firestrike, were a significant problem area for us. Many of the data objects in the game are able to define an item or unit at every level the item or unit has. For example, a level 1 Rifleman in TR or DV is the same data object as a Level 14 Rifleman. Landmines were unique because they required three separate data objects for each level of the landmine: one for the mine itself, one for the mine’s explosive, and one for the engine instructions on crafting and delivering the mines. In TR and DV, this meant that anti-infantry mines had 54 separate data objects. In Firestrike, three landmine types with 215 levels each meant that there were 1935 data objects in landmines. Each data object duplicated data needlessly, and was resulting in larger downloads.
This project was completed first for War Star Empire, and has since been deployed to all other games.
This migration process uncovered problems with how our battle log and battle replay system were designed, which will have to be addressed in a future engine update cycle. Our current plan is to leave the legacy data online until March of 2020, then deprecate battle replays that predate October 2019. If you have an iconic battle you’d like to save, be sure to record it with video software before it’s gone forever.
The second update involves armed buildings. For the longest time the only armed buildings have been landmines and turrets. Each of these use a special crafting interface that other portions of the game don’t need to use. I altered the turret crafting interface to support three other types of armed buildings. During this process, I came across a similar problem faced by landmines. Any turret that consumed power while crafting required a separate data object for each level of its crafting instructions and the turret itself. In Firestrike, the three turret types only required three data objects each, but in Thunder Run each turret required two objects per level, resulting in 56 separate objects per turret type.
Engine Future Plans:
There’s a laundry list of UI tweaks and bugfixes that need to be addressed, but the next major feature change is the grid crafting system. Currently, only landmines use the crafting grid. I’d like to make it so players can craft ambush point equips on a grid, and building security nodes on a grid. We added the inventory tab system as a bandage to the warehouse size issues, but I’m hoping being able to craft what goes into a slot will help players who currently use these features. Currently, interface limitations mean the grid sizes are hard capped at 28 slots. I intend to add support for scroll buttons, allowing us to raise the cap. To be clear, mines, ambushes, and security nodes would all have their own grids. Mines need to be rebuilt, so a “rebuild all” button will be added both to the mine crafting interface and to the base repair interface. Once this is done, I hope to add these features to games other than Thunder Run and Days of Valor.
That Laundry List of Bugs:
Mine crafting queue freezing: This looks like something related to how the building repair code interacts with the crafting queue. It will take some research.
Lack of Hardware listing in the repair UI: This is now fixed!
Battle Replays: A lot of data doesn’t get snapshotted properly and becomes buggy when the state of the game changes. The whole system needs an overhaul to take better data snapshots and not rely on the current gamedata. We will probably have to automatically sunset replays older than one month to keep the replay data storage from becoming unmanageable.
That Laundry List of UI Changes:
Allow access to building leaders and stats while the building is building/crafting/repairing: This should be doable. There’s some logic that decides which buttons to show for a building. There will need to be some additions to hide certain menu buttons once you’re viewing the building if it’s busy building/crafting/repairing.
Allow buildings to be moved while under construction: This shouldn’t be too hard, but there may be some surprises under the hood.
Allow buildings with an instant build to bypass the construction timer. This will require some significant logic restructuring to implement and will be a low priority.
Toggle enemy AI picture: I want to make it so you can show/hide the enemy AI at your leisure. It will still have to appear at the start of an event.
Toggle base advisor picture: I want to make it so you can show/hide your base advisor, though it will reappear during important announcements.
Show ONP as a resource: I plan to show it next to Hardware. Mirroring the count in the warehouse will be fairly simple. I will not be able to remove it from the warehouse inventory without a much more significant engine overhaul that would require changes to both the server and browser client.
Damage indicators: I intend to update the hovertext over UI damage indicators to show the modified DPS against a class of unit.
There are many other excellent suggestions on UI overhaul, but I’m not adding them right now. For one, I’m not a UI designer, so I’d probably botch it. For two, I don’t even have an inkling of the time investment necessary, so putting them up here as in the works would be disingenuous.
Vague Future Plans:
I want to overhaul the multiplayer map interactions. Accusations of cheating on the multiplayer make up a significant amount of our fan interactions and customer support tickets. Since actual player vs player is currently beyond our engine’s abilities (and may always be), I have come up with some theoretical changes that are in line with our player vs AI-owned-by-player model. None of these are in the pipeline or definitely happening, but player feedback is encouraged:
- Make it so battalions can’t be attacked while a player is online, but also that the battalion can’t block a path while a player is online. In other words, no jailing, and no PvP between players online at the same time. This would probably be the simplest to implement, but also the worst idea.
- Make it so battalions can be attacked and block while a player is online, but only if the player “garrisons” the battalion, causing the battalion to dig in at their current position. Turning off the “garrison” action takes half a minute of real time, but the battalion gets a defense boost while garrisoned. Garrisoning could happen automatically when logging out, or logged out battalions could still require manual garrisoning. Two options for how garrisoning could work:
- Battalion deploys a few fixed defenses in the form of a small minefield and turret deployment which is generated on the fly and disappears when they de-garrison.
- A defense and range boost is applied to a garrisoned battalion, which is turned off when they move. It also gets turned off if a lower-level player attacks a higher-level player’s garrisoned battalion (to discourage “jailing”).
- Make it so battalion strength is boosted or nerfed based on relative power levels of the battalions, to a certain degree. If a squad of fully equipped L15 TOS-1As attacks a pair of L3 Riflemen, it’s going to be a massacre regardless, but if twelve L14 Riflemen attacked six L7 Riflemen, the stats might wind up being closer to twelve L14s vs nine L11s. This would be tricky since it would require comparison of stats on the fly. It might work better to calculate average range, total DPS capacity, and total HP, and boost the defender by 50% if their total capacity is less than 50% of that of the attacker. This would probably wind up being too finicky to turn into a workable idea, but I included it to share some of the places my brain goes.
And that’s about as deep as we’re going to go into the engine today, but check back at the same time next week for a more in depth dive into Thunder Run and Days of Valor, where Nirgal will give us behind the scenes insight into projects he’s currently working on, and how they fit into the bigger picture of the games.
Like what you see in this Dev Blog, or have suggestions on things you’d like to see Nirgal talk about in the future? Let us know over on our Thunder Run Discord Server (for Thunder Run players), or on Clan HQ (for all other games). See you all next week!