Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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)

share|improve this question
up vote 8 down vote accepted

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.

share|improve this answer
They used telnet for the tweak variables on MotoGP too:… – Kylotan Sep 9 '10 at 11:17
+1 I love this idea. Great for small screen platforms. – Justicle Sep 9 '10 at 18:45
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. – ZorbaTHut Sep 10 '10 at 7:23
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. – Kylotan Sep 10 '10 at 14:46

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.


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.

share|improve this answer
@Kylotan: You are missing the point. You are modifying the actual source code, which gets parsed at run-time. The persistence is through the modified sources. – Oskar N. Sep 9 '10 at 11:55
Yeah, somehow I missed that in skimming the article. I'll delete my comment and re-read! – Kylotan Sep 9 '10 at 14:51
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_code Sep 9 '10 at 19:32
@caspin: You can use plain variables and instead have H(int, myvar, 5) and when file changes you replace the myvar in memory. See – Oskar N. Sep 29 '10 at 19:11

AntTweakBar is really useful for what you want to do, however, most of the time, you'd want to have methods that 'compile away' in release with some macros or similar.

share|improve this answer

From a question about real-time debugging, comes David McGraw's answer about AsyncSocket for iOS developers. See his answer for more information.

share|improve this answer
although that sounds great, it's not a solution; it's a useful tool to make a solution. – Richard Fabian Sep 8 '10 at 9:37

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.

share|improve this answer
This isn't about settings information, it's about tweaking runtime variables for debugging or gameplay purposes. – user744 Sep 7 '10 at 20:10
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 Zeigler Sep 7 '10 at 20:16
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. – Kylotan Sep 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. – user744 Sep 13 '10 at 15:20

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.

share|improve this answer
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-bang Sep 14 '10 at 21:30
I don't understand the benefit of having it on your phone rather than on the computer you are actually doing development with. – user744 Sep 17 '10 at 12:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.