Cargo Bridge Game. And Implications.

Awesome Game: Cargo Bridge

While trolling the internet one day, I found a really (really) awesome game called “Cargo Bridge.” It was created by a game designer named Limex (whose website is here).  The goal of the game is to get your “worker” across a “chasm” to retrieve items on the other side.  To accomplish this goal, you have to construct a bridge out of beams and walkways; the bridge has to be capable of supporting itself, the worker, and the item he’s retrieving.

The game can be found at Limex’s website here, or where it is hosted at another game site, here (At that second site you can put $ in a tip jar! Great game, Limex deserves to be paid for it!)

There are two modes of “view” within the game.  The “blueprint view” is where you lay out beams in an arrangement of your choice, using the anchor points visible in the blueprint. Then you can switch back to the “test bridge view” in order to ‘run the simulation.’ At this point, you will find out if your design successfully supports the worker and the item he is retrieving…  Or you get to discover that you have epic failed at bridge designing and the bridge snaps with your worker plunging to his death (Though I have to admit: the highly distraught “plummetting-to-doom-shriek” of the workman is pretty funny).  Here’s a video someone made of one of the game levels, in action.  A very janky design; but it worked!

The game is five boatloads of fun for anyone with a mechanically creative bent and is almost limitless in playability.  There are 24 levels and, after that, a “challenge round” where you see how wide of a span you can cross with the anchor points given to you.  Beating the 24 levels doesn’t mean that there is no challenge remaining in them either…  Since the game tallys up your building material costs, you can play the levels again to see just how cheap your solution can be, while still allowing you to complete the level.

 Awesome Underpinnings: Engineering

(If the technical jargon of this analysis section bores you, you may just want to skip to the final section on Implications/Future of Engineering)

Cargo bridge employs a few analytical models from engineering.  This is probably flagrantly evident to anyone who has taken an engineering statics or physics mechanics course, but it deviates from simple static truss analysis.  Aspects of vibration theory are incorporated.  Incorporating gravity and bridge deformation into the simulation/graphics actually makes the game way more fun.  At the extreme limits of the “challenge” format of game play, this dynamic loading is what you have to design for; the weight of the worker is far less than the forces occuring in the structure due to the structure itself sagging and wobbling due to gravity. 

The first analytical model which Cargo Bridge employs is nodal truss analysis, an engineering theory which is typically taught in engineering static mechanics classes.  “Truss” structures according to Wikipedia:

“a structure comprising one or more triangular units constructed with straight slender members whose ends are connected at joints referred to as nodes. External forces and reactions to those forces are considered to act only at the nodes and result in forces in the members which are either tensile or compressive forces. Moments (torsional forces) are explicitly excluded because, and only because, all the joints in a truss are treated as revolutes.”

Truss analysis employs trigonometry and the assumptions listed above.  “Revolutes” mentioned above are “pin joints” which, like the theoretical truss members described, can only bear tensile or compressive forces and cannot carry or transmit torsional forces.  In truss analysis, vector summation of forces can be used to compute the force along each of the members, joined at each node.  If the force along a member exceeds a specified failure load chosen by Limex, that member “fails” by breaking free at that node.  The simplest truss analysis case is that shown in the diagram in the screenshot below.  I’ve modeled this truss system in the excel file shown, which can calculate the reaction forces at nodes “A” and “B” and the member forces in length AB, BC, and AC (you can use this website to calculate unknown angles and member lengths).  Unfortunately, wordpress.com won’t allow me to upload the excel file for your use, but I’d be happy to send it to you if you need it, email me at justin dot ketterer at gmail dot com.

It’s worth noting the nature of the reaction forces supplied by the supports depicted in that diagram.  One is a “pin” support (the “revolute joint” mentioned earlier–which can provide reaction forces in both the x and y directions, no torsion) while the other is a “roller” (only can provide a vertical reaction force, while lateral movements are permitted/does not provide a lateral reaction force).  This is a key assumption which allows the forces in the members to be calculated, and, unless both ends are rigidly fixed, yields good agreement with empirical observations (technically, the “roller” assumption keeps the system from being statically indeterminate; in MathSpeak, that means the system can be represented as a system of equations with the number of unknowns equaling the number of equations, refer to this part of the Wikipedia post).

This “truss analysis” theory is taught in static mechanics classes to undergraduate engineering students, and it can be extended to much more complex truss systems, in terms of the number of nodes and members.  However, the ratio of members to nodes to reaction forces has to be maintained for this type of analytical theory to be applied.  Otherwise, numerical or matrix methods must be used such as the direct stiffness method, which is the basis for the ubiquitous engineering analysis tool known as the finite element method.  Limex has implemented some form of the matrix method here, as there are no constraints limiting the designer to a set ratio of reaction forces / nodes / members.

The dynamic modeling aspect of Cargo Bridge is what makes it fun, and occurs when theory from vibrations is incorporated into this system’s behavior…  Where initially the structure bears no load, after hitting the “test bridge” button, “gravity” is applied to the “mass” of each of the beams/walkways.  Forces are transmitted through the nodes, and reacted to at the anchor points.  This simulation accounts for the inertia present in the system as it deforms.  Accounting for inertia, the structure deforms past the shape it would take in a static monotonic “static loading.”  The structure resonates briefly around this final resting shape until a damping factor removes the inertia from the system and it is static (that is, until your worker starts tramping across it).  Thus, the model used is not simply a number of ideal rigid beams connected by pin joints as statics theory would have us think, but a model with members formed effectively by a spring (to absorb strain energy and deform), and a damper (to remove inertial energy, bringing it to rest at the final static deformation shape).  In terms of simple engineering drawings, the previous image would now look like the following when the “spring” and “damper” are included:

The spring (black zig-zag) and damper (represented by an oil filled “shock absorber”) are incorporated into the members.  In vibrations, the “spring constant” is commonly referred to as the variable “k,” and for a solid beam, along its axial length, the spring constant is calculated as k = A*E/l (which results in a parameter with units of force per unit length, such as “lbs of force per inch of spring extension”).  In this equation, A = Area, E = Young’s Modulus, l = length.  The “E” value in that equation is the modulus of the material being studied.  “Young’s Modulus” is the material property which relates applied load to the resultant deflection; it obviously varies across materials–stiff materials have a high modulus, pliable materials have a low modulus.  In Cargo Bridge, “wood” and “steel” elements have different stiffnesses (and different ultimate “strengths” at failure too, I suspect).

In vibrations, the damping constant is commonly referred to as “C,” and affects movement in proportion to the rate of movement of the body.  The “k” and “C” terms are visible in the characteristic equation of a viscously damped, free vibrating body (where “m” is mass, ‘x double dot’ is body acceleration, ‘x dot’ is velocity, and x is displacement from the static state):

Limex has chosen the C and k values to make this system “underdamped” which basically means that the system exponentially decays to the static deformation state (technically, it means that the damping ratio is less than 1).  This underdamped behavior is visually evident in the game if you model a large enough cantilevered bridge to witness it yourself, and when plotted, looks like the following (image taken from here).:

The engineering representation shown earlier–a beam with spring and damping ability– is just that: an engineering represenation.  In real structures, the member itself is extending, or taking up “strain energy.”  This would be hard to model in a game such as this, so Limex’s game just model’s the beam or walkway’s “deflection” by expansion occurring at the node joints.

Now, how did Limex then model the evolution of the bridge deflection after accounting for stiffness and damping?  I can’t be sure of the exact process in his model, but he employed a time-step solution of some sort.  In this procedure, time is allowed to propagate a small amount and each of the members is allowed to deform/displace according to reaction forces from adjacent members and gravity bearing on the mass of each member.  Reaction forces from spring extension and damping from member velocity can be computed at the end of the time step for this new deflection.  The new inertia and force imbalance is then used in the next time-step to determine what position each member will move to next. 

So what he likely is employing is a very large set of matrix equations containing all the inertias and forces currently impinging on all of the elements in the model.  This is quite analagous to the direct stiffness method mentioned earlier, used in FEM.  It’s also empirically evident that he employed a time-step method in his solution–for large bridges modeled in the game, the computer slows down, and the number crunching for each of the time steps is visible as discrete steps in the development of the deformation.  But like I said, I can’t be sure of the exact internal order of the process he used.  In addition to the necessity of maintaining the constraint of linearity between each of the nodes spanned by the members, this is not a trivial problem.  I really applaud what he has done here.

One of the things I wish Cargo Bridge had was the ability to display more technical information about your designs.  For example, a way to display the numerically quantified load at each node for adjustment of design, would be sweet.  Also, a more geometrically rigorous way to lay out your structure in blueprint view would be neat–a grid, or rise/run display of the beam/walkway length would be cool.  But these are minor complaints from a minority audience that is overly interested in engineering design…  The game is damn awesome as it stands.

Awesome Implications: Future of Engineering?

Though I wish I could dig into the details of numerically quantified behavior in Cargo Bridge, I think one of the beautiful points of the game is that you don’t have to be familiar with the engineering principles discussed above in order to see them in action, learn them deductively, and apply them.  When I think about the difference between “Design” and “Engineering” in product development, I think the difference can be summarized in one sentences: “Design seeks optimal form; engineering seeks optimal quantification of that form.”  In the Cargo Bridge game, you essentially get to play the role of the designer, while the computer performs the role of “engineering.”  You choose the bridge’s form, the computer crunches the numbers and determines if that bridge form will fail.  

In short: the game allows you to apply a model which predicts the behavior of your design–without having to understand the details of that model yourself. 

But of course, you will have a leg up if you do understand those principles going into the game.  Hypothetically, a computer program could be created that is very much like Cargo Bridge, but is “modeling” the behavior of another type of physical system.  An example: perhaps a game called “Steam Plant.”  In this game, you are given the blueprint of an industrial revolution-era factory, and in that factory, on the blueprint, there are a few production machines which have to be powered by steam.  Your job, in the role of building architect, would be to lay piping, junctions, and valves across the blueprint of the plant to get steam power to these machines.  In this game, the physical behavior being modeled might be twofold: pipe stress analysis for internal steam pressure, as well as thermal/heat loss along the length of the pipe.  Your job as the designer is to select the best pipe routing, the right grade (thickness) of piping, and perhaps proper insulation.  Optimize for cost, etc.  It is similar in form to Cargo Bridge, but is just modeling the behavior of a different set of materials.  Instead of bridge truss theory, we’d be relying on pipe stress equations, and heat transfer equations predicting heat loss along pipes.

Continuing our trip down hypothetical lane, there is theoretically no limit to creating computer-based models of material systems in the form which Limex has created with Cargo Bridge–i.e., a computer system with a “black box” crunching the engineering numbers to determine how the system you have designed will behave.  There are practical limitations: computational power, and the degree to which we have successfully captured material behavior in a model which can be automated in a computer program. 

This is exciting, a software system like this would enable a vast improvement in the availability of the function of engineering (“quantification of that form”) to people for whom it would previously have been inaccessible.  Of course, engineering currently is performed by people trained in engineering theory and capable of performing engineering calculations.  A software program which performs these calculations would likely be far more accessible to people who have need of an engineer’s abilities, but can’t afford to hire one.

This would not be as easy to implement as it sounds–a major lesson I learned in grad school is that “theory is only as good as its assumptions.”  Its when you start designing with materials that aren’t well understood (and to say that we’ve completely understood and can flawlessly predict the behavior of any material is a bald-faced lie) or you start designing with low margins of error that assumptions within most theories start to wreak havoc on the accuracy of your predictions.  And, modeling a system of trusses is a lot easier to develop a computer model for than predicting, say, where a fatigue crack will initiate in a car’s cylinder head, and how long it will take to propagate to a point at which catastrophic failure will occur.  But, with increasing computational power and smart thinking about how to make solid mechanics / heat transfer / circuit design /etc. as easy to understand and intuitive to model as possible, I think there are exciting implications for this.

Hey Google, want to hire me?  Let’s make “GEngineering” happen, and bring engineered design to the masses. 

Okay…  So I came up with the idea, maybe you can come up with a snazzier name…