Welcome to today’s Throwback Tuesday post! In observance of what is basically a modern holiday, we will be periodically bringing back relevant posts from our past for you to enjoy. Today’s post is from early 2015 and details one individual’s journey into the world of graphical programming…through video games!
Dataflow Programming In Video Games
One of LabVIEW’s unique features is its graphical programming interface. Graphical programming (also called dataflow programming) isn’t always popular nowadays. You may hear people bashing it and others praising it. I think its usefulness really depends on the application. Under the right circumstances I’m a huge fan of data flow programming, but I realize it has its limitations.
I learned about dataflow programming early on, back in high school. At the time (2007), the video game Crysis was making waves in the PC community. It was a stunningly beautiful game, and I was enthralled by its realism.
I enjoyed playing with the game’s Sandbox editor (Cryengine2 SDK). The editor let you create or modify existing levels using all of the game’s assets. After toying around in some of the levels, I became frustrated with the game’s design; small obstacles like shacks or trees could be broken realistically, but larger objects (like the concrete walls surrounding the enemy base) were invincible. This was frustrating because I wanted the freedom to bust a tank into the enemy base if I felt like it. I decided I wasn’t going to let these limitations dictate how I played, so I set out to change the game.
Under normal circumstances, making any sort of modification to the game would have been laughably unrealistic. Given the fact I had zero programming experience and Crysis had over 1 million lines of code, it seemed unfeasible to me at the time. Fortunately the software engineers behind Cryengine2 had the foresight to add a “Flow Graph” system to the editor. The system was designed to streamline the addition of code to the game by allowing level designers to implement programming solutions with little prior experience. The Flow Graph system succeeded at this because it used a dataflow programming model, much like LabVIEW’s. As I mentioned earlier, graphical programming really shines in certain situations, and abstracting away complex source code from the user in a friendly package is certainly one of them.
Making use of editor’s flow graph system, I was able hash out a simple destructible wall after an hour or two of experimentation. The game had already come with all 3D wall models required, so I only had to write the code for the destruction animation. To show you how simple it was to figure out, take a look at a snippet of my original code.
There are six key parts to understanding how my old code functions.
1. The name of the flow graph node tells us it deals with “Destroyable objects” in the game.
2. The line below the name, indicates that a particular object “Breakable Wall 1″ has been assigned to this flow node. This means it keeps track of various things that can happen to Breakable Wall 1.
3.These outputs trigger when Wall 1 “Breaks” or “Explodes“.
4.The Break and Explode outputs need to be multiplied so they can trigger multiple inputs of other nodes.
5. For the breakable wall I wanted trigger the the “unhide” inputs. These inputs make any object assigned to the node appear when triggered.
6.Finally, I assigned rubble models to appear once Wall 1 was destroyed. The rubble models were associated with a “RigidBodyEx” node, meaning they are animated (i.e fall or can be moved) using the game’s physics engine.
That’s all there there was to it. The design was pretty straightforward due to the graphical nature of the interface. Rather than being lost in a sea of text, the Flow Graph editor enabled me to easily infer and test things until I achieved my desired results. On top of being novice friendly, dataflow programming is fantastic for implementing quick and dirty solutions because graphical nodes hide some of the technicalities associated with the source code. Ultimately, it allows users to focus on building the overall algorithm, rather than muddling around in the details. Within a week of my first breakable wall, I managed to create a breakable crane, a functional draw bridge, and much more. The code I put together for these objects was far more complex than anything I had previously done, but took relatively little time.
Admittedly the code for my Crane and Draw Bridge is far more difficult to decipher than my first example. Overlooking its haphazard layout, keep in mind that I was able to deliver a functioning solution in a week, with no prior programming experience. In my opinion, enabling users of varying skill levels to produce results fast is one the most outstanding aspects of graphical programming. You can judge the results of my code for your self in my old demo video.
As you can probably tell, I’m a pretty big fan of graphically based coding, but I’m willing to admit it has some pretty big drawbacks too. For starters, a lot of seasoned programmers find it difficult to work in. The approach you take to solving a problem in data flow programming is very different than an approach you would take in traditional programming. The skills used in both practices don’t always translate well back and forth. Another quip a lot of naysayers have about graphical programming is the organization. The visual nature of this style of programming makes implementing large projects difficult. As you could tell from my drawbridge and crane flow-graphs, the readability decreased as the complexity increased. As an extreme example, take a look at another flow graph I made.
My code was intended to function primarily as an in-game inventory, but it included some other features. The majority of the right side is dedicated to the in game inventory system which would have been far easier to implement through the source code. I ended up getting the code to work, but ultimately things became so large and messy it was impossible for me to make any further progress. On top of this, during its development, often I felt restricted by cookie cutter flow nodes available to me. Despite the fact that the editor supported a fairly large library of flow nodes, none of them quite did exactly what I wanted. Therein lies another drawback of graphical programming: customization is difficult and restrictive. In the end, the endeavor made me realize that traditional coding is far better for managing large projects and doing custom work.
Anyway, these are my thoughts on graphical programming. The style certainly has its unique pros and cons, and I don’t think it deserves to be swept under the rug like it often is. If you want try out some data flow programming, or are simply interested in video game design check, out Crytek’s latest version of their free source development kit. or grab your copy of LabVIEW! I promise you it can be a lot of fun!