Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
1  
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. –  snake5 Nov 16 '12 at 9:52
    
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. –  Eric Nov 16 '12 at 14:29
    
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. –  Peter Taylor Nov 17 '12 at 12:25
    
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 –  user1107412 Nov 17 '12 at 14:23
    
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. –  user1107412 Nov 17 '12 at 18:51
add comment

2 Answers 2

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
share|improve this answer
add comment

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.

share|improve this answer
1  
the thesis: theses.fh-hagenberg.at/thesis/Plank08 –  idefix Nov 16 '12 at 13:35
    
No problem, I can read German as well –  user1107412 Nov 16 '12 at 13:35
    
The thesis itself is a great reference btw –  user1107412 Nov 16 '12 at 13:38
add comment

Your Answer

 
discard

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.