Sponsored By

Recursive Development

It's better to code around "real life situations". But what if you need to code something that you are not in the stage of having good requirements yet?

Ofer Rubinstein

December 22, 2009

2 Min Read

I have been working on a little language to represent GUI objects placement for the TRG project.
This allows me to write a text file with a certain format and syntax, so the game will be able to parse it and place the GUI objects on the screen. It allows changing the GUI without recompilation and removes the need to hard code some of the GUI logic inside the C++ project. I also plan to build a tool that will allow me to drag and drop GUI objects on the screen, and to save it into such text file.
Here is an example of an early stage of the parsed GUI, first the result and then the GUI text file:

GUI Example


GUI Example

Draw4Text (x, y, dy, n){

	Text (x, y, "Text "+n+".1");

	Text (x, y+dy, "Text "+n+".2");

	Text (x, y+dy+dy, "Text "+n+".3");

	Text (x, y+dy+dy+dy, "Text "+n+".4");


Error1 (){

	Draw4Batch (512, 384, 30);


Draw4Batch (x, y, dy){

	Draw4Text (x, y, dy, 1);

	Draw4Text (x, y+dy+dy+dy+dy, dy, 2);


The problem? I don't know what I want to have in TRG's GUI yet. I believe it's better to develop code around "real life situations", rather than guessing what features I will need. My solution is to use the tool as an example of the requirements from the little language. With the tool I will be able to build GUIs, but the tool itself need to have a GUI. I will build the GUI of the tool with a text file, and after I will have the first version of the tool, I will build the next version of the tool's GUI with the earlier version. Sort of a recursive development. The tool will be used as both an example of what I need and both as the tool to create the next iteration.
It is a sort of a compromise, but I think it's better than just guessing.


Read more about:

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like