20
\$\begingroup\$

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)

\$\endgroup\$

6 Answers 6

8
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ They used telnet for the tweak variables on MotoGP too: blogs.msdn.com/b/shawnhar/archive/2009/05/01/… \$\endgroup\$
    – Kylotan
    Sep 9, 2010 at 11:17
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – ZorbaTHut
    Sep 10, 2010 at 7:23
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – Kylotan
    Sep 10, 2010 at 14:46
5
+100
\$\begingroup\$

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.

\$\endgroup\$
4
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – Oskar N.
    Sep 9, 2010 at 11:55
  • \$\begingroup\$ Yeah, somehow I missed that in skimming the article. I'll delete my comment and re-read! \$\endgroup\$
    – Kylotan
    Sep 9, 2010 at 14:51
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – deft_code
    Sep 9, 2010 at 19:32
  • \$\begingroup\$ @caspin: You can use plain variables and instead have H(int, myvar, 5) and when file changes you replace the myvar in memory. See mollyrocket.com/forums/viewtopic.php?p=5395#5395 \$\endgroup\$
    – Oskar N.
    Sep 29, 2010 at 19:11
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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

\$\endgroup\$
1
  • \$\begingroup\$ although that sounds great, it's not a solution; it's a useful tool to make a solution. \$\endgroup\$ Sep 8, 2010 at 9:37
0
\$\begingroup\$

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.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ This isn't about settings information, it's about tweaking runtime variables for debugging or gameplay purposes. \$\endgroup\$
    – user744
    Sep 7, 2010 at 20:10
  • \$\begingroup\$ 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. \$\endgroup\$ Sep 7, 2010 at 20:16
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Kylotan
    Sep 9, 2010 at 11:23
  • \$\begingroup\$ 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. \$\endgroup\$
    – user744
    Sep 13, 2010 at 15:20
-1
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ 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... \$\endgroup\$ Sep 14, 2010 at 21:30
  • 1
    \$\begingroup\$ I don't understand the benefit of having it on your phone rather than on the computer you are actually doing development with. \$\endgroup\$
    – user744
    Sep 17, 2010 at 12:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .