Hello, we apologize but forum registrations are non-functional at this time. This issue should be fixed around mid-December. Until then, please stop by our Discord channel if you'd like to get in touch with the team. Thanks!

Proposal: Constants Management System

For discussion of the code running behind the game

Moderator: Staff

Post Reply
User avatar
Posts: 8669
Joined: Wed Jun 16, 2004 12:07 pm
Location: Austin TX

Proposal: Constants Management System

Post by Roots » Sat Aug 15, 2015 1:21 pm

There's been something that I've been thinking about as I've been implementing new designs and we're about ready to start balancing and testing new features for next month's release. There are a lot of constants used throughout the various modes of the game that are defined in C++, and some of them have binding code written for them so that they are available to Lua scripts. For example, the various sprite movement speeds in map mode.

Having all these constants in C++ presents somewhat of a problem for game balancing and fine-tuning. It is much more difficult to be able to see all of the game's various constants together and be able to quickly and easily tweak them to test out changes. Furthermore, constant tweaking can take unnecessarily long, because these constants are often defined in utility header files that are included by a lot of other code, so making changes to these requires several additional files to be compiled.

I'm imaging a "game constants" management solution. The constant names and values are defined in Lua. Probably in the file global.lua, which is opened when the game boots and remains open until the game exits. Here, we have a naming scheme for constants so that it is clear where they are intended to be used (ex: MAP_SPRITE_SPEED_FAST = 34.0; BATTLE_MAX_IDLE_WAIT = 1000;). When the game boots and opens the globals.lua file, we read a table of constants in there and build a std::map in C++ with string key/value pairs. The constants are accessible via a call to the GlobalManager (GlobalManager->GetConstant("MAP_SPRITE_SPEED_FAST");). The C++ code that uses these constants (eg MapMode) can either make repeated calls like this to access constant values (not ideal due to the look-up overhead) or make the call once and build an internal data structure holding all of its constants. On the Lua side of the code, the constants would already be available in this space, so we wouldn't need any binding code and furthermore don't have to have long qualifying constants in Lua like we do now, like: hoa_map.MapMode.MAP_SPRITE_SPEED_FAST.

There are a few potential issues with this design though:
  • There is no native support for constants in Lua. We would have to use metatables to get around this (I don't think this is a huge deal though)
  • Implementing this system will take quite a bit of work, and doesn't provide any immediate payoff for us other than making balancing and tweaking an easier process to do
  • While we would be getting rid of the code for binding constants, having each mode have some constant management code could get tedious and redundant. Maybe we could write something in the common code that modes could use and configure for constant management? :shrug:
  • Going through all the various code and picking out these "design constants" would take a while to do. We wouldn't want to put all constants here (some are constants for UI coordinate positioning, for example). Not only would we have to remove these, but re-define them in Lua and make changes to existing C++ code to use the new constants management design instead of just using the constant name directly.
This is not a terribly high priority right now, but it is something to consider doing for the future. If the implementation of this system was straight forward it would make more sense to get on this sooner than later, but I think we're going to have to kind of figure out this sort of system as we go along. For now, I just wanted to get these thoughts out there and see if anyone had any suggestions, thoughts, or criticism.
Post Reply