Ideas For Hype 5 Features…

It's surprising that we're nearing the fifth anniversary since the last major Hype update. The software is not done. Clearly there are lots of new features that could be added. Here are some ideas…


  • Bones / Joints — Used to create puppets for easy 2D animation
  • Lip Syncing — Great for voice overs, making characters speak
  • Advanced Vector Shapes — Currently no holes, so can't even make donuts :doughnut:
  • Custom Loading Screen — For large projects, like games, long loading times can't be avoided. However, the default “loading” bar needs to be customized to maintain the attention of viewers. Perhaps there could be a title screen / loading screen scene, where the progress bar is displayed. (Maybe this is a JavaScript API thing, but people without programming skills need to do this too.)

Cross Platform

  • Windows / Linux — Why only Mac?
  • iOS / iPadOS — If only Apple devices, why not these?
  • Web — Hype could run in a web browser, most straightforward path to cross platform support.

Elements / HTML / CSS

  • Grid / Flexbox
  • Details / Summary — even better if Hype manages accessibility improvements (expand all)
  • Vertical Alignment — Sometimes text needs to be centered vertically
  • WebVTT — Captions for video (easy) or perhaps for whole Hype animation (difficult)
  • Meta Tags — It could be easier to set the page language. That's a nice dropdown for the Document pane.
  • Columns, with column gaps — This a newish CSS feature, but great for text layout.
  • Position Sticky — Great for creating menus, like with the Hype Book splash page…
  • Subresource Integrity — Useful for verifying third-party resources, like the Hype runtime hosted outside of the project.
  • SVG Favicon — Specifying an icon is useful for PWAs. But also, search engines may look for a favicon or other icons.
  • Open Graph — …for when Hype projects are shared or linked on social media websites, like this one.
  • Dark Mode — Styling support for both Dark and Light mode.
  • Lazy Loading

Basically, a lot of the stuff mentioned here…


  • Continuous Collision Detection — CCD doesn't work in Matter.js. Either improve Matter.js or switch to Box2D.
  • Momentum Loss — This is a bug where objects can't bounce indefinitely.
  • Built-In Collision Detection — This is difficult to do with Hype, but a big part of making games
  • Spawning — Add or Remove symbols to scene dynamically… like bullets, enemies, power-ups.
  • Simplify Physics API — Instead of needing five lines of code to do something, the API could be reduced to one line, as shown with the photics-physics-bridge…
  • 3D — Make it easier to do AR/VR project with Hype, make it easier to add 3D models to Hype projects, there's lots of tech in this space… WebGL / WebXR / three.js
  • Keyboard / Controller Support — Even just basic support for WASD or Gamepad API as actions could be dramatic encouragement to use Hype to create games.
  • Particle Effects — Snow, rain, glitter, explosions, fire, smoke


  • Export Video With Audio
  • Drop Internet Explorer support — streamline runtime
  • No tabs setting — Spaces instead of tabs for code
  • Code Cleanup — This is one of the main reasons I prefer to code in Visual Studio Code instead of Hype or Whisk.


  • PWA — Exporting a Hype Project to a Progressive Web App, skip the whole App Store Drama
  • Export To App — This is possible. I'm not sure why it's not part of Hype.
  • Export To SVG — This might not work with the whole project, but it should be easier to export vector shapes if something beautiful is drawn.
  • Export To ePub — I'm not sure if this is possible, but what if a Hype project could be exported as an eBook, that could be amazing… not as a Widget, but a whole book, where scenes are treated like chapters. In other words, what if Hype was like iBooks Author but way better?
  • Lighthouse — Basic web testing could occur inside Hype.

That's an impressive list… I'd be happy with modernization, so here are my requests:

  • Animation Engine allows animating any DIV
  • Remove .HYPE_container_elements and add all the goodies it prevented (Flex, Grid, Blend modes)
  • Reworked copy/paste/import of symbols (merge conflicts)
  • Index-based scene addressing
  • Allow including any JS in the Resources in the generated JS with an order attribute (like priority minus values before and plus after, sort by priority)
  • Some official extension API (in builder)
  • HypeDocumentLoad as an official hook in the UI
  • Drop IE
  • Store symbols in the exported JSON/JS only once instead of repeating them (see Hype Compressor for a discussion on that topic)

I'd be happy with that alone. The rest could be delivered over time in the form of extensions, keeping Hype 5 slim and modular.


Amazing list @Photics!!!! Thank you for the time to write all this up and priorities. There's a lot on there we agree with.

(Likewise the same @MaxZieb!)

I suppose that raises the question… what don't you agree with? :smirk:

It's tabs for code formatting isn't it? :smile:

I can see Tumult not being a fan of App exporting (but it doesn't have to be that difficult since Hype has scripting), and Lighthouse is not really a requirement since people can just do it themselves with a web browser that supports it (but it seems like a nice way to expand the warning section, which is kinda useless lately now that the web browsers have more parity), so I'm not sure what else is even debatable?

Is it IE support? :smile:

Is it cross platform support? After reading this, I'm shocked Hype is still an exclusive.

1 Like

What would also be amazing, although less of a priority would be a component library.

Most of the time I'm setting up my image/text elements in html/css, paired with a bunch of javascript functions. Would be amazing if I could save my own elements, and quick add them in the projects I need them for, to mix and match what elements I need specific per project. The same thing with scripts and custom css fonts etc.


You can save symbols and add them to the foremost project by double-clicking on them. Just avoid importing them twice, as that's the mentioned merge problem, which will duplicate all dependencies, including functions that should theoretically be unique by name. This can lead to redundancy and some odd outcomes, with projects becoming messy.

1 Like

Pretty much what you speculated + some of the physics improvements unfortunately aren't likely going to be addressed anytime soon.

But IE is toast :wink:

1 Like

It would be cool to have a built in library

But in the mean time checkout ta work around.

Which is working really well for me and make things more productive.

A snippet library within hype would be great

But im also wondering about if hype also had its own shortcut actions to import , convert import, load symbols, export ...( thinking aloud )

It goes without saying. A labelling/ argument system on timeline actions that call javascript would be really handy in conditional function calls. ( yes there are hacks but a native system would be better)

Gonna say it.
Better coding support.
One of the only reasons I will ever edit a function outside of hype ( and because I hate having to go outside of an app to do a task I should be able do within the app) is to try and find the end or beginning of a closure.
Such a simple thing but one of the most common errors is an unexpected ')' or '}'

Yes a lot of the time this us because you are cutting or pasting which lets be honest we all do...

But finding the error can be ten times as hard to figure out without being able to find closures beginning and start.


That's why I use Visual Studio Code with my Hype projects…

• Cleans up the code formatting instantly
• highlights code errors
• Removes pesky tabs! :smile:


That implies at least some physics improvements. :slightly_smiling_face:


Fc@k .. yes please..

1 Like

That snippet tool is already very much what I’m looking for! Thanks

Ofcourse it would be neater if it was something within Hype, but this is nice already for adding in all the dailies


Here's another idea, just throwing out there… Should the Hype runtime (or the whole Hype Project) use strict-mode?

The article says this…

Fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that's not strict mode.

Faster sounds nice. :smile:

1 Like

Here's yet another idea, just thrown out there… export to single file.

This idea was sorta discussed here…

I've been thinking of a topic for the next Photics book. Since ePub is the focus, I was considering the possibility of interactivity. To start things off, I simply tried getting the current time with JavaScript. It was pretty easy.

But when I tried to add the “Timing” template… Free Template Tuesday #30 – Tumult Hype “Timing” – …as a test of what's possible with ePub, I couldn't get it to work.

The problem is that Hype has a directory structure… specifically .hyperesources …but I couldn't add directories in the Calibre. I'm going to experiment with that some more, but it just seems like it would be more ideal if Hype exported to a single file… probably a single HTML file …similar to .swf when Flash was popular.

UPDATE — I was able to flatten the directory structure, so that's not a problem. Yet, I still wasn't able to get a Hype project to work in an ePub using Calibre. So, I suppose those are two separate features.

  • Single file exporting
  • Export to ePub — which was mentioned above, but I'm not sure if it's possible.

There was some discussion about exporting to ePub… Export scenes to EPUB3 …but it was centered around OAM Widget & InDesign.

1 Like

I've considered this, but it is a pretty low priority since the runtime is big enough that any possible performance benefits are unclear from the outset. There's of course other benefits, but it's the type of thing that just can become a big rabbit-hole when the project didn't start this way.

Definitely, I think my question is on appropriate guard-rails. (Like you wouldn't want a large video to be inlined!)

Hype can't export to XML natively, so any ePub export would be pretty opinionated about how it decides to wrap the Hype HTML export and provide lots of settings to setup the book. (Not saying no, just that I know any first version won't be able to handle everyone's use cases...)

1 Like

Also, I'm not sure if i'm the only one, but I'm ending up using the Hype rectangles more and more to write out big pieces of Html and css. It would be super if we would be able to to get a bigger more convenient code editor for this just like the head part, or even options to edit it with an IDE just like editing scripts.


Me too,
Im using rects to do this all the time.

One reason but not limited to, is I do not have to keep jumping back and forth between the head and the scene.
It would be great if we had a css editor pane. But with room to see what you are doing rather than the small and limited area like the attributes editor.
Wordpress has such a panel in its customise setting settings that is a strip

Honestly would be a boon, and I would not object if it opened up on the left hand side of an Hype Document as is done with WP.


While the concept of a dedicated CSS tab may seem similar to the existing Head HTML functionality, there are several feature requests that, if implemented, could offer a more versatile solution:

  1. The ability to utilize Hype in a multi-monitor setup by allowing the undocking of tabs such as scenes or Head HTML. This would greatly enhance the user experience for those working with extended desktops.

  2. The option to designate specific files for integration into the generated JavaScript. This could be within the *_hype_generated_script.js file or embedded inline, as determined by the advanced export settings or an export script. The advantage here is the flexibility to bundle any JavaScript or CSS files from resources directly. For CSS integration, currently, one would need to employ JavaScript to insert the code into Head HTML. However, this process could be streamlined if the runtime were equipped with a feature to handle it automatically. The inclusion order would probably need management (either order or priority), though.


Totally agree with. ( 1 )


I had hummed and erred about spelling that out :grinning:, as I took it as a given that with the inclusion of using a side panel as shown, it would be a given to included the css into the head inline at export time or a generated resource linked file again export time or a direct integration within the *_hype_generated_script.js at export time.
So absolutely yes, that's the idea , but I did not want to get into the possible pros and cons of fine detail of what would work best for to Tumult consider doing this and honestly I would be happy with what ever thy did (I think) as long as I got the css panel. ( and yes a add/edit css option in the resources much like the functions option)

1 Like

Certainly, you can cause significant disruptions with CSS in the current version of Hype, as the layout presently relies on the cumbersome use of inline styles and even more problematic container divs. This setup would lead to a nightmare of specificity and layout shifts since the bounding boxes aren't integrated into the HTML WebKit but are instead superimposed. As a result, calculations are based on known values rather than dynamic lookups, such as getComputedStyle. Consequently, any alterations to the layout would necessitate the use of !important, leading to a misalignment with the Hype interface. Moreover, achieving the correct stacking order would prove unfeasible. The level of frustration would be intolerable without a comprehensive overhaul. Although it's a relief that CSS can be loaded as it stands and is effectively applied within the IDE, realistically, the prospect of this advancement being incorporated into Hype seems slim in the near term. However, a significant modernization in Hype 5, potentially even with some disruptive changes, would be welcome. In my view, such an update would be beneficial, allowing older projects to remain accessible in Hype 4


There seems to be some activity going on with Matter.js. There's a "Performance" branch. Also, something about "sub-stepping" was mentioned in the Continuous Collision Detection thread.

The bouncing issue is still open, but there's been some discussion about workarounds…