Proposal: Constants Management System

For discussion of the code running behind the game

Moderator: Staff

User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Proposal: Constants Management System

Postby Roots » Sat Aug 15, 2015 7: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.

PROBLEM
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.

PROPOSAL
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.

ISSUES
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.
Image

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 11 guests