the idea for this #JS library came from the experience of learning javascript by way of D3js, the well-known data visualization library by Bostock. When D3 came out, it triggered an incredible upswell of interest in the science and the art of data visualization, which (similarly to music) is one of the aspects of science that bridges the rational/creative or left/right brain kinds of divides. the reason i built Vizflow was because of the failure of a previous effort!
... well, i took it upon myself to find out :) I mean, after all... D3 is mind-blowing, and really interesting at the level of coding, science, art, and maybe even philosophy. like, seriously: what were these guys smoking, because i want some :-P
anyways, i was just guessing and I really didn't know JavaScript that well at the time, and D3 seemed like like this all-powerful tool. But, after implementing a #gamedev toolbox using D3, it turned out that D3-based games ended up performing badly!
now if you started doing D3 long enough and are old enough to remember, the HTML5 and D3 rollouts were very much overlapping. so, HTML5 was still getting out there when D3 kind of made a splash.
In the early days of HTML5, there was incredible optimism for web apps completely obviating any other type of software stack. this was nirvana! finally, everything could be defragmented, using WWW standards.
the biggest question was: "can HTML5 games perform well on mobile?" and the answer for a while was "¯\_(ツ)_/¯"...
well, as someone who feels that visualizations and games are ultimately the exact same thing, and who likes both a lot, i wanted to try to answer this question for myself!
so, i set out to make some games using D3. That effort ended up failing, due to #performance (#perf) reasons, but it inspired me to make Vizflow :)
ES6 is partially based on CoffeeScript
darn, it looks like the Bostock et al IEEE paper link for ProtoVis (the predecessor of D3) is broken. here's the updated link:
... anywho, what's cool about Vizflow is it abstracts all of the animation components of D3 so that they can work with ANY JavaScript Object, assuming they have the appropriate decorations, and ingests these as elements of the visualization. It basically pulls the "transitions" out of D3 and de-abstracts them, as TransitionObjects, that can be attached to any VisualizationItem. That way, you can modify the transition functions attached to each item in the visualization, with no added complexity
... so, the final lesson here is that too many abstractions can impede the implementation's performance! many software abstractions introduce computational overhead, if they are not *very* carefully tailored to the application at hand. for something like mobile gaming on low-power devices, you need to treat each byte of processing energy with a high level of respect. that is what Vizflow was designed for #performance #perf #software #engineering #science #visualization #dataScience #art
... as you may have noticed: Vizflow has *NO* dependencies.
That's right: zero.
Vizflow is built using vanilla JS. Also, it has the necessary polyfills built-in to the (optional) helper functions, to make cross-browser compatibility much less of an issue!
so did Vizflow achieve the goal of great mobile 2D game engine performance? as Election Fighter shows, our first demo... yes.
but, is Vizflow designed as a game engine? no, it is application agnostic. it is a general purpose visualization engine, with low overhead but D3-style transitions :)
in conclusion: the success of Vizflow was due to the failure of a previous effort. it was only by failing in this previous effort, that Vizflow was able to succeed! :)
@katchwreck whoa, looks awesome. :)
@lea thanks for checking it out! it would be fun to kickstart some more demos and documentation... not enough hours in the day!