3. Use handler events for updating animations, font colour, sound etc.Basically, instead of "Switch animation for actor..." you may want to use a custom setter "Set animation requested to...". The separate handler will then check if the requested new state is different from the current state, maybe remember the current state as "previous", check additional conditions and only then do the hauling part and actually switch the animation. Besides improving performance, it allows to easily tweak the code in one place without sifting through your whole project.
4. Pre-load sounds on separate channels if the files are large and you switch them often.FH has a lot of sounds. Some are very short (clicks, thumps, horse neighs and such) or only play occasionally (e. g. "new day" jingle). These don't really affect performance, so I can group and play them on the same channel (e.g. all UI sounds on Channel #4, all jingles on channel #3 etc). Other sounds, specifically ambience loops for the map (forest, swamp, desert etc) are switched every time the hero moves to a different tile. In this case, consecutively looping and stopping them on Channel #0 created visible lags in movement of hero avatars on the map. Investigation with hxScout proved that the engine was retrieving the sounds from files every time, which was creating the lags. So instead of two sound channels (one main, second for fade-out of a previous loop) I introduced as many Channels as there were ambient loops (currently around 15). All these sounds are looped on individual channels while the scene initialises, are immediately paused and remain in RAM for the whole game onwards. Yes, it permanently occupies 30 MB of RAM instead of 3 MB, but the difference in UX is amazing.
(And because I had a separate "sound handler" event, changing this logic was quite quick
.
5. Use procedural animation if possible. I have a simple dying animation for my monsters and heroes. It erases the character image (sort of "the Infinity Gauntlet" wind effect). I initially stored these animations as actor animations (roughly 20 frames per character x 18 characters = 360 frames, 240 x 240 pixels each, with 5 default scaling variants Stencyl includes). The way Stencyl works, all of these are loaded into RAM at the start of the scene (I couldn't exclude some characters via memory atlases, because my game has procedural generation and I need all the monsters in my scene). What I did instead was: create 1 animated Eraser actor (left-to-right + right-to-left variants, 17 frames each, 120 x 240 pixels), leave only 1 static image for each of the 18 characters, and use the "clear image using image" block "every [duration of the eraser frame]". This is almost 350 sprites less than the original solution and uses 10x less RAM and disc space (at least 20 MB saved immediately).
6. Crop transparent borders from your sprites.Texture Packer can do this really quickly and efficiently.
7. Use the native Stencyl functions to draw text (If possible).Stencyl's text engine is extremely basic. No kerning, no grid fitting, no alignment, no text wrapping (list goes on). When it comes to Serif fonts like my main font, Eagle Lake, the look is horrible. I mean, playtesters started complaining and all. On the upside: it's fast, the glow / offset effects look great, and you can apply styles (bolding / italics etc) even when the original font file doesn't support this style.
I'm using a custom Stencyl build that can display text using the "Open Flash Textfield" blocks. It makes perfect spacing between characters, and the result looks crisp. Unfortunately it seems to come with a tiny extra tax on performance. So I ended up using the "Open Flash Textfield" blocks for big chunks of text (narrative, item descriptions, tutorial prompts etc) and use the native "Draw" blocks for UI button labels.
8. Use hxScout to monitor performance.Detailed guidelines in Merrak's thread
here. Side note: the telemetry / hxScout monitoring process taxes your memory too - so the framerate it shows is not exactly the framerate you'll have with telemetry disabled (though it's probably pretty close). In other words, you cannot measure framerate without affecting the framerate!
9. Use Visual Studio to debug runtime crashes if the native Debug mode doesn't help.Guidelines by Justin
here. If I read this thread when I started developing my game I could save myself at least a hundred hours (likely much more). I'm really perplexed why Stencylpedia doesn't have a section on properly debugging runtime crashes.
10. Avoid creating important actors in scene editor if you continue adding behaviours to your game.While refactoring the code I ran into a bad Stencyl bug. If you add a new behaviour to an actor type, it may not get added to the actor instance you had previously placed in the scene via scene editor! It took me a whole day to figure out why my pointer stopped working, until I found that the pointer instance didn't show a new behaviour I recently attached to the pointer actor type. As soon as I removed the pointer from the scene and created it procedurally at scene start, the issue was fixed. Note it's a confirmed issue planned for fixing in future Stencyl releases.
Show Posts
