Build a comic engine, or use existing tech?

To put this decision in context, I had build a prior project with comic pages, animated speech bubbles, voice and music and had made hundreds of comics using an existing technology: Adobe Flash. A ubiquitous technology used by literally everyone. It was great, it was safe, it empowered my project.

Then Apple decided that Flash should not exist, and killed it – taking out the best technology for what I was doing, with NO replacement. Just dead. It burned my project and years of my work. And it was part of why my project didn’t survive. I have to recognize my bitterness and distaste for Apple will never end.

So, now I approach another attempt with a similar goal – animated comics with voice and music. Since it has been 15+ years, Adobe has a new technology to do similar things but without requiring their plug-ins, so it will run in modern browsers. And the natural path would be to learn it and use it. I can use the timeline, layers, and more that I did before, it would feel very similar, and comfortable.

Then I got one of my little ideas. I could create my own comic engine using standard HTML, CSS, and JavaScript. If I build it myself, then it would survive the whims of the tech companies who change their minds, go to war with each other, and burn creative people’s projects to the ground in the wake. And, as a tech person myself, this sort of idea tends to spike quickly and bristles with possibility… So, what would I need?

  • A timeline per page that is variable per panel as well
  • Panels to appear in a specific order, in a specific x/y location
  • Panel reveal animated options like fly in or spin
  • Sound effects in the panel, timed to background music or voice
  • Background music for entire page, but panels can turn it off/back on
  • Different panel options based on other game engine features (choices, decisions, character progression)
  • Build using CSS/javascript to avoid technology limitations or get tied into a platform
  • Option to pause, go back/forward panels, to give readers control
  • Dialog balloons to be coded and allow for localization
  • A way to automate taking a full page with panels and having it carve (or mask out) panels and create the page flow automatically as a baseline
  • A way to take a second image of just dialogs and carve those and time them to the page flow

As you can see, the list starts quick and then gets fairly complex. Implementing this with an eye towards making it as quick and easy as possible drives the project into a space I don’t want: spending a huge amount of time -not- on content building.

And, as I’ve found in the project already in every decision, I need to weigh the goals with my time and I conclude that I should really learn the Adobe product of today and take yet-another-chance that the technology survives for the years it will take me to finish the content. I have to check my bitterness and my tech capability at the door and focus on the goal.

And, just maybe, Apple has limits on what technologies they can destroy for their own interest? And, I suppose, to hope that Google or Meta also don’t target Adobe for another kill shot. But, in the end, the only way to stay clear of that risk is to spend a ton of time… too much time.