Forum Discussion
(loading) speed of Storyline 360 slides
Hi all,
Does anyone know what influences the loading time of storyline 360 slides? We are creating educational games with storyline, and are trying to figure out how we can decrease the amount of loading (with the three loading dots) between slides.
I have a few ideas on what impacts the slide loading time, for example:
- Amount of layers on a slide
- Amount of objects on a slide
- Amount of images in a slide
- The length of javascript functions
- The amount of audio files
- The size of audio files
- The amount of video files
And maybe other that I haven't thought of yet..
And a few questions:
- Does it matter if you put objects / images / video / audio on timeline start, or after let's say 1 second?
- How does Storyline internal "pre-load" slide work? I have read somewhere it makes an educated guess which slide comes next, and preloads it. But, as we make a slide selection based on variables, that won't work.
- Is there any way we can feed storyline information about the upcoming slide, so it can preload it already?
I'm very curious to your insights.
I will also do some research myself the next few months, and share the outcome, but it will help to gather some input and thoughts from other users before diving in further!
2 Replies
A few first findings I had myself:
- The number of objects on a slide matters: The most objects seem to be loaded synchronous, so the more objects, the longer your loading time is. Especially if the end-user internet is a bit slower and you have big file sizes (or a lot small size files).
- All SVG files (articulate objects or your own) are loaded via a JS script and calls a function. I'm not sure on the speed on that specific function, but that can give overhead
- It does not matter where on the timeline the objects are, all objects are loaded before showing the slide.I created a clumsy 2D platformer prototype by using a virtual "sprite" object to use a Storyline image object for its graphics, and then added gravity and some top-down collision detection. I wrestled for a bit with the graphics since I didn't want to get too crazy, but landed on some freely available animated gifs of a pixel-style ninja character. All of the jump, idle, and running animation loops are easy to drop into states.
Key-down on arrow left triggers the sprite object to change its corresponding Storyline object to its running-left state, and that shows a looping animated gif of the character running, and key-up changed the state to its idle-left animation. Using animated looping gifs in this way was new to me but I'm really glad with how it turned out. I wonder what could've been through the hidden portal...
I mention it here though because testing revealed (I thought) an interesting aspect of Storyline's image states (which function more like entire new objects) in that they don't seem to actually load until called to display. I don't think I'd ever really even considered it, but I expect it'll have later implications for how I design, so maybe you too?
After my level loads, the character will be standing on its starting platform, its idle animation looping, other GSAP-animated elements in the level also doing their thing; however, when I begin pressing the arrow keys to move and jump around, there's a slight gap between when I press a key and a yet-to-be-displayed gif begins to play. To me, having some distant familiarity with the pre-loading of assets, I suspect the other-state gifs aren't fully display-ready on slide load.
Because when that sprite's state is revisited, such as RE-activating the jumping-right state, the animated gif displays pretty soon after without any break. I could understand some delay if each state's gif was megabytes each, but my source gifs are only between 1 and 6 KB.
In the short-term, a practical adjustment could be scripting a secondary "pre-loader" to cycle off-screen through all of the states of any similar "sprite" object so they're actually ready when the need arises and don't need to be retrieved, as I assume creates the delay. Longer-term, knowing the reason for the delay/gap would probably show even better (or no) workarounds.
