For the last week, I have been working on improving the UI and navigation graphics so that it is simpler and looks better. All the visual editing features for the navigational programming are practically done and I had planned on implementing the underlying evaluation of that navigation game mechanic but felt a strong urge to wrap up the graphical bits before I delved into that.
The main menu has changed also, but most of the effort went into cleaning up icons and unifying the previous two UI elements. There were separate UI windows for the navigation and the text editing for the programming. But, now there is only one. Fewer UI windows and simpler interface. Better for maintenance and performance.
The only remaining item for the graphical icons is to place them up into an atlas, so that I can put them all into the same material and collage them into the same object. Keeping draw calls to a minimum is very important for the performance of the rendering engine. The small batch problem is the biggest problem of computer graphics and most of its algorithms and engine configurations are to batch up the objects into as few items as possible with as few state switches as possible. Allowing the graphics hardware to run uninterrupted for as long as possible is what keeps things running smoothly.
I’m going to try and explain all the components and nodes you see in the picture above. There are 10 different nodes that give you control over the movement and the movement choices of the machines or player. Like a very high level, domain specific, visual programming language.
A) Is the navigation point node. This tells the machine, if it can navigate and move at all, where to go. But these are ordered, so that the nodes that lead from one to the other do not become active as targets to the machines unless the parent node has been reached and that option has opened.
B) Is a state node. This is a persistent flag that you can query to see if a particular set of conditions has been met. Has one machine reached its end point and is another one in close proximity, as an example.
C) The event node. These will trigger when certain events are reached. Such as a particular navigation point has been reached, or some custom event has been fired through a script.
D) Logic gates. These are the 7 different most common logic gates that can be used to create more complicated test conditions. They can be laid out in sequence to create a tree of inputs and outputs that converge into a navigation point or any of the other nodes that accept an input node.
E) The timer. This will trigger when the time has reached zero. Right now I only have the option for 60 seconds. If you need many minutes, you can use this in conjunction with the counter node and set the timer to loop.
F) The counter. Just like the timer, but it will only increment when it gets a signal, from an event or some of the triggers.
G) The proximity trigger. This trigger will set when a machine enters or exits its perimeter.
H) The script. This event can only be attached to a navigation point node and will be fired when the programmed machine reaches that node. From there you can run various tests, set states and post events. Spawn threads, communicate between threads and basically do whatever the programming world has enabled you to do for the last decades, if you like to dive deep into that option. All these scripts will run in their own sandbox, in separate processes with very rigid pathways back into the game. Some data will be written into shared memory for the scripts to access. Messages passed to and fro using high level message passing frameworks such as ZMQ(I am actually looking into nanomsg, to see if that might be a better option for me) and stdio, so that I can throttle the buffers of the child processes that lead back into the game. The language option by default will be Lua, with some built in utility functions and other low level tools.
I) The look at direction. This is a simple directive which will tell the machine when it reaches a particular navigation point, in what direction it should be facing.
J) The activation switch. This is a trigger that is both visible in the programming mode and the normal game mode. So that the player can press it and activate the navigation and programming routine when playing.
The main evaluation of these navigation trees will be in a separate process so that bad configurations should not affect the game. Anything that could be tied into a loop or stall some aspect of the game will be spawned in a sandbox, where the game can monitor, suspend or kill when needed.
The last week has been a lot of work in Photoshop and I must say that I am getting very comfortable with creating complicated shapes with it in pretty efficient manner. One thing that did help in that regard was this website. The only problem I have with it, is that I can’t turn off the system or browser hot keys while using it.
Next week, I will need to finish up those buttons in the programming menu for selecting and controlling what object I am creating or editing. Those are those ugly green things at the top.
When that is happy and done, I will move into the actual evaluation of the navigation tree.
So, as far as this navigation features goes. I got a good run into it, but did not manage to quite finish it before the end of May, like I promised myself I would.
Stuff needs to work correctly and it needs to look really good.
Tata
V 