I am thinking to write my Master's thesis around theorizing, and then implementing a PlayMaker or Kismet-like (building game logic by visually arranging FSMs) tool in Unity. The only thing I am still concerned about is the actual research question that I should pose.

I was kinda hoping that the more experienced game designers out there might know.

Update: What about reducing the use of visual programming to graphically designing FSM-Action-Transition flows, which can then be attached to game entities (very much like http://playmaker.com does it)?

Update 2: Regarding the evaluation of the approach: I was thinking that it would not be so practical to try to quantitatively prove that my tool is better than the competition. This is in fact not the essence of the thesis. The problem that I see myself trying to solve is more of the type of "how do we prove that the approach is easy to pickup and learn from people without specific programming knowledge" I could build a "test sandbox" - an unfinished puzzle level that each of the test subjects is supposed to complete by following a number of certain tasks. The taks will vary from simply adding a missing transition between two states, through correcting intentional mistakes in the logic, to designing entire state machines on one'e own. The evaluation will then be done based on the completion of the tasks.

  • 1
    \$\begingroup\$ The biggest problem with VSS is handling of big scripts (everything just gets incomprehensible and generally much worse than plain text). So I'd suggest you build your thesis around that, look for ways to fix that issue. \$\endgroup\$
    – snake5
    Nov 16, 2012 at 9:52
  • \$\begingroup\$ The overarching problem is that visual programming just transforms the problem of writing text to make a program to the problem of clicking blocks to make a program. The latter may be easier with a small amount of blocks, but it scales horribly (like snake5 points out) and in the general case, programming does not get easier at all when done with blocks. Only if the blocks and lines are semantic within your specific problem domain the pay-off may be worth it, e.g. data flows with Max. \$\endgroup\$
    – Eric
    Nov 16, 2012 at 14:29
  • \$\begingroup\$ Where is the evaluation side going to come from? Are you going to recruit a hundred arts students, split them in two groups, ask the first group to use PlayMaker to make a game and then do the same with your tool, the other group to do it the other way round, time them, measure their game quality against some criteria, and interview them about the relative difficulty? That seems a significant enough project without actually implementing your tool - which means that you probably can't fit it in. \$\endgroup\$ Nov 17, 2012 at 12:25
  • \$\begingroup\$ Well, it has not been my intention to evaluate by comparing/contrasting between the different tools out there. Rather, I'd simply try to prove that HFSM diagramming is easy to pickup and understand by non-programmers. I was thinking of selecting a few people from my domain, who have relative experience with Unity, but are not hardcore programmers, and present them with an unfinished game level to complete. Evaluation will be done on completing the supporting tasks, which will vary in difficulty and freedom. Something like gamifying the game design process \$\endgroup\$ Nov 17, 2012 at 14:23
  • \$\begingroup\$ Or, maybe I can get away with a purely technical thesis like "Design and Implementation of ..." which instead of arguing that "HFSM is easy to pickup by non-programmers, and I will prove it" simply describes the design and implementation side of designing and HFSM graphical editor for Unity. \$\endgroup\$ Nov 17, 2012 at 18:51

2 Answers 2


From the references of an austrian master thesis about visual programming

may this links could help you to get an start

Visual Programming 1999

Visual Programming, Knowledge Engineering, and Software Engineering, 1996.

There seems to be an book from Addison-Wesley with the german title "Visuelle Programmierung. Grundlagen und Einsatzmöglichkeiten". I am sure there is the english counterpart too somewhere. Amazon could show it if you enter the german title.


One of the major problem of visual programming was stated as the Deutsch limit, stating that

The problem with visual programming is that you can't have more than 50 visual primitives on the screen at the same time.

Now one could argue that the same applies to lines of code (you can't have more than 50 lines on screen at the same time).

The main problem, IMHO, is that many attempts to create a Visual editor makes things messy : lines of codes have a natural order. You read them left to right (or right to left in some languages) and each line below the previous one.

With visual blocks, you will end up with spaghetti code, literally, as lines will fill the space between blocks, and from that, getting a good idea of what the code does is hard.

Another problem is that most attempts aren't as user friendly as people think. I've been a Virtools teacher during 4 years (Virtools was a french 3D engine in early 2000, using visual scripting). Most of the time, students would put two blocks together, and forget links, thinking that the software would understand what it was to do. Something like writing

int i = 42; 
print(); // they'd assume that because we compute i just before, print will have to print the value of i

You must log in to answer this question.

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