Jump to content
  • entries
    943
  • comments
    5,899
  • views
    923,763

August 13, 2011


Josh

2,126 views

 Share

Once again, I like to attack the things I haven't done in the past first. I know how to make a CSG editor. What I haven't done in the past is a visual editor for gameplay and logic.

 

In the shot below, you can see the properties editor, with the "Scripts" tab selected. I moved the name and angle editor outside the tabbed panel, with the idea that these are so important they belong in the main window, but the real reason was to break up the boredom of a full-window tabbed panel. Under the scripts tab, there's a list on the left where you can drag scripts onto to assign a script to an entity. You can also drag the scripts around within the list to rearrange the order they are executed in. When a script item is selected in the list, its properties appear on the right in the bordered area. This has a border because if the number of controls exceeds the available height, a scrollbar will appear to allow you to scroll down and access all of them. Now I personally am not a fan of this, because I think it makes things more complicated, but the user feedback overwhelmingly suggests users want multiple scripts attached to a single object. I think this is so users can combine behaviors and adjust them through trial and error. This doesn't occur to me because for me it's no big deal to just open a single script and program it to do exactly what I want. However, this isn't as trivial for everyone, and for every programmer out there, there are probably 99 non-programmers. This is a good example of why we need to understand how everyone uses the software. The resolution we have satisfies the need for trial and error design, without restricting what you can do with it.

blogentry-1-0-53279600-1313281484_thumb.jpg

 

You can drag an entity script or an entity into the flow graph editor to make its attached scripts appear. Each script has inputs and outputs, and you can connect one to another. I think I am going to put both script output functions and exposed attributes on the right, with a different icon for the two. Output functions can be linked to inputs on other scripts, while attributes can be linked along the curved line connecting the two, as function arguments. This is a cool idea I think will make it unique, and it only works due to the flexibility of Lua; you can skip function arguments, and the function call will be executed anyways without any problem.

 

I'll have some special flowgraph nodes that only appear in the flowgraph editor for logic, timing, etc. It is not my goal to make a visual script editor. I don't think the challenge of programming is because people don't understand text code. The problem is thinking in an extremely logical and meticulous manner. A visual script doesn't get rid of this requirement, it just uses a different method to display the logic, one that will baffle both programmers and non-programmers alike. Think about (most) artists trying to design "Pong" with a flowgraph; I don't think it would work. Trying to code behavior through a visual representation of script is not something I want happening in the flowgraph, except on a fairly lightweight level. People are welcome to try it, but if we expected that everyone would be able to write complex programs with it, I think it would fail and we'd be back to the drawing board.

 

My goal for the flowgraph system is to allow a designer to connect behaviors to create interesting sequences of events in a game. Individual behavior of objects will still be coded in script, in a manner designed to be as general-purpose as possible. A button opens a door, a cat chases a mouse, a switch turns an elevator on, then opens a trap door, and turns on a machine ten seconds later.

 

Leadwerks Engine 2 had individual entity scripts, but without a standard system for interactions, there's little you can code in a self-contained script, other than some looping behavior. Setting names and targets is functional but rather abstract and cumbersome when working with complex interactions. With the Leadwerks flowgraph editor, we're all working together on the same game...yet the programmer still has complete control and freedom.

 Share

3 Comments


Recommended Comments

I think flowgraphs alone don't make non-programmers programmers, although they might take about 30% of the handicap to write code away. It might be still needed to have some code prefabs, which bring the expertise of programmers to the hands of artists, and they can access those prefabs via flowgraph entities.

 

Even if people know a language, they don't necessarily know logic. Logic has has nothing to do with any language, but it must be learned seperately. Often the lack of understanding logic is seen with younger people, as it comes with life experience also, so for older people understanding and developing logic is almost trivial.

 

Code prefabs can bring also the logic to the non-programmers, as they still would understand abstract high level logic, just not in-detail logic with all their if-then, flags, timers, and states.

Link to comment

Well said. This way programmers and designers can work together. The programmer writes logical scripts and the designer makes them do interesting things in a particular map.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...