Most companies have an editor, or a variable control system for tweaking stuff in games, but are there any middleware solutions to this problem? I've written two such systems in the past myself, and worked with five, maybe six different ones, but none of them were off the shelf.

Each of these home grown solutions had problems, ranging from having to keep looking up values, to not being able to save the current state of the variables.

Are there any mature Config/Runtime-variable control libraries/apps?

I generally code in C++, but I would think that a mature settings/variables editor would probably be socket based (and therefore language agnostic to some extent) as all current development hardware apart from Nintendo stuff provides a mechanism to talk to servers. The code implementation would also need to be quite simple (I do like the hot_var/TweakableConstants article shared by Oskar, but it's not a package)

6 Answers
6

I like what Noel proposed on his blog. A telnet based variable tweaker. By using telnet he was able to use any telnet client to edit the variables. Later they built a gui around the protocol. It seems sufficiently simple, that it probably isn't worth a middleware library but looking at his code might be useful.

I disagree with his anti-Lua sentiment however. A remote Lua console just seems awesome.

+1 I love this idea. Great for small screen platforms.
–
JusticleSep 9 '10 at 18:45

3

Why Telnet? HTTP/HTML, dude! HTTP is a very simple protocol and can be easily embedded in a game - I've done it before, it was well under a thousand lines of code.
–
ZorbaTHutSep 10 '10 at 7:23

3

I would say that Telnet does the job pretty well and is much less complex. You could do it in 100 lines of code rather than 1000. And it also allows for the pushing of updates rather than having to poll and pull them. But if you need HTTP for any other purpose in your game, I'd agree that it's worth using it here too.
–
KylotanSep 10 '10 at 14:46

I've actually been thinking about such a thing lately, and I think it would be a great candidate for an Android app paired with a small library in whatever language you want. The app would be a customizable set of buttons, toggles, dropdowns, etc. (any widget you want), and it would send the actions via WLAN (or USB if you wanted to complicate things) to the library. The library would have spawned a separate thread from the gameplay and would know which controls on the Android phone correspond to which variables in the game (you'd set them in your startup code) and would have a connection to the Android app.

Then, messing with your game is as easy as touching things on your phone. You could even have some textboxes on the phone which show realtime variable values from the game, or you could have the library forward stdin or stderr to a scrolling textarea on the phone. The options are limitless!

The only real concern is with speed. If speed and reaction time are crucial then you'd just hook the phone via USB and adb (android debugger) supports forwarding ports over USB to the phone. But otherwise, WLAN would only have a very tiny delay which I think would be plenty acceptable for this purpose.

I don't think such a thing as the above has been written, but I've been strongly considering writing it. (I just haven't gotten far enough into development of my own games to need it yet)

Of course, those of you that are Apple users can probably do the same with your iDevices. I personally find iOS development to be orders of magnitude more difficult than Android development, and of course the above app could easily be published to the Android market for easy distribution whereas Apple probably wouldn't allow a developer tool into the app store, so I feel the Android platform better suits this tool.

This would be sweet in an office environment. Walk over to talk to an artist, and connect to and start fiddling with the neighboring designer's running game while he's trying to set up some encounters...
–
dash-tom-bangSep 14 '10 at 21:30

1

I don't understand the benefit of having it on your phone rather than on the computer you are actually doing development with.
–
user744Sep 17 '10 at 12:21

Maybe the idea of Tweakable Constants fit your needs. It is so usable in fact that you'd think you would need a complex solution to have an effective run-time variables control, but in reality the implementation is almost too simple. The original discussion of this technique is also an interesting read.

Example:

glClearColor( H(1.0f), H(1.0f), H(1.0f), H(1.0f) );

The H macro expands to something like HotValue(x, __FILE__, __LINE__, __COUNTER__). This registers the value to some global registry. Then have a function like RefreshHotValues() that you call at regular intervals. The function looks up each entry in the registry, parses the specific source file and reloads the hot value.

As you modify the actual source code, you have persistence right there.

Obviously this will not work where H() is not evaluated every frame, but there are ways to solve this as discussed here.

You could expand on this idea to a socket-based solution, perhaps. There could be a significant performance overhead to call HotValue() every frame, but as you very easily can compile out the macro completely replacing it with the constant this is not an issue.

I might be just me but this technique feels ... icky. I think it's because I've spent so much time hating magic numbers and this will only work for magic numbers. I'd rather see the clear color be part of a config or script file. The magic the comes with the ability to hot load resources.
–
deft_codeSep 9 '10 at 19:32

Settings management seems to be one of those things that's redone from scratch for every game, probably due to how relatively simple it is and the high variability in the types of settings needed. Assuming you have a decent storage backend setup (SQL/whatever) you can code up a robust solution to settings management in a day or 2 so there doesn't seem to be much real business need for a middleware solution. Tacking it on top of whatever you use for player information storage is I think the best way to go in most cases.

Many types of runtime variables for debugging and gameplay purposes make sense to store in some sort of persistent back end. This allows the changing of them across an entire system when you deploy. SQL is just an example of a back end, you could patch the information to a file on disk or any number of other methods.
–
Ben ZeiglerSep 7 '10 at 20:16

1

The problem is getting them to change in real time. That probably involves setting up some sort of trigger on the DB, and something in the game that can handle that trigger and re-read the values asynchronously while the game continues running. Not unsurmountable, but not terribly simple either.
–
KylotanSep 9 '10 at 11:23

The code that manages that DB trigger would be the code Richard is looking for, and is the interesting/reusable part. Moving the constants to a DB rather than the filesystem or another tool doesn't make that code magically appear, and probably just makes it more complicated.
–
user744Sep 13 '10 at 15:20