4
\$\begingroup\$

Runtime Storage (hardcoded) vs Static Storage (file storage)

(original question)

I extended my engines GUI from procedural style to object orientated style, but I still have to create menues, buttons etc. So I got the choice to create each menue via a class or have a static main class which loads menues from a XML file. My problem is that I actually like to have static and external storage in XML because it keeps the code and the project clean. But if a GUI Object is created e.g. a button I want to have delegates/callbacks/events on it, but I think that isn't possible with loading and creating GUI Objects by XML files that only contain ints and strings.

The question is when do you hardcode parts of your game and when do you store them locally.

Runtime Storage

+ You safe time while you do not have to write a parser or something similar.

- You lose a lot of flexibility in late development

Static Storage

+ You gain a lot of flexibility in the late development

- You spent a lot of time into a system to read and write, and also handle the storage

\$\endgroup\$

3 Answers 3

3
\$\begingroup\$

Well, the rule of thumb is: "If something is going to change a lot, use config files or dynamic scripting. Otherwise, hardcode".

The idea is, hardcoding saves you time now, and soft-coding saves you time later.. provided your config files can be edited more easily than code. So, if your GUI is relatively simple, and you're not going to change it a lot, you're better off hardcoding it. If you want to change GUI rapidly, use XML or some kind of dynamic scripting, but be careful. These systems quite often turn out to be actually harder to read and write than code. Xml is especially prone to that.

\$\endgroup\$
3
\$\begingroup\$

My rule of thumb is that if it has double quotes around it, it should probably be in an XML configuration file, unless the double quotes are being used to index into a configuration file.

\$\endgroup\$
2
\$\begingroup\$

You need a higher level of abstraction there. You can create a fixed set of functions that can be executed from your GUI elements (OpenMenu, ShowWindow, AddControl...) and then tag each one with a constant string. Then, when adding that property to the XML of the control, you will know what in-game code to execute.

Or, you can extend it with a script/plug-in system that allows bidirectional communication between your game code and your XML files.

\$\endgroup\$
1
  • \$\begingroup\$ very good idea, didn't thought about that, because I created the GUI system before I made the actual game logic, so I hadn't any functions to link to. \$\endgroup\$ Commented Oct 28, 2010 at 16:59

You must log in to answer this question.

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