@Will The
cutesy answer is that the path from designer -> engineer is not travelled by our content, but rather by our content creators. ;)
I'm the only formal programmer at our company, and I don't do any of the work on our content — I just build tools (and... all our web services, from visual design to database optimization, /curtsy/). When we hire a content creator, we hire only for art skills, and then train them how to program well enough to add logic and interactivity to their artwork — basic procedural code: variables, conditionals, calling functions, but not necessarily even arrays or maps. That training process takes about six months (most of it focused on domain-specific stuff), but they're usually able to build simple simulations pretty much immediately. We typically have 3-6 artists on the team. We'd happily train them much further in programming, but none of them have wanted to learn that yet (can't blame them.. which is why we're all here, right?)
Our current pipeline is:
1. Draw in Adobe Animate (nee Flash) or Illustrator, with names given to various objects in the drawing.
2. Export to SVG (which forces us to only use a safe subset of drawing features, sadly)
3. Run a simple CLI tool to scaffold an interactive simulation atop our in-house
framework (titled SVGA)
4. Write some high-level CoffeeScript code to express the simulation logic, add controls, etc.
5. Run a CLI command to deploy to our site. The final result is a single HTML file that works in any modern browser. Typical build size is about 200 KB, including the framework.
It takes one of our artists about a week to build
something like this from scratch, with a fairly even split of time between planning, research, design, art, and coding. According to
cloc
, that linked simulation is about 1700 lines of SVG art (after automatic optimizations), and 600 LOC of CoffeeScript simulation logic (where the amount framework boilerplate in that is probably less than 5%)
(If you're not familiar with it, the graphical symbols we use are fairly standard in
hydraulic schematics, with a bit of our own spin to make them more amenable to animation).
That framework I keep referencing is about 4k LOC, and took probably 6 months to develop, spread out a fair bit.
Finally — the FoC project I'm building,
Hest, is intended to take us away from writing text-based code at all, to let us build these simulations inside an Adobe/Autodesk-esq graphical environment. I've been working on Hest off-and-on for about 5 years now, and plan for it to be the main thing I work on for the next decade (aside from keeping our web services alive, of course)