Canceling in TRAUMA

There one thing that always gets on my nerves: games often expose players to serious loading times without ever giving any means to cancel a loading sequence. This actually turns a lot of the choices in an interface into very unforgiving time wasters. It can a very frustrating to accidentally select the wrong level. You know you made a mistake but you are still being punished by a potentially long loading sequence before you can do anything about it. Of course those problems are even more serious in TRAUMA because most of the assets are loaded over the Internet. Depending on the Internet connection, a loading sequence might turn out to be quite lengthy. Spotty Internet connection might even cause the loading sequence to fail completely. So today I finally implemented a “cancel” button on the loading screen.

Such a small button, yet it can change so much.

Unfortunately, implementing such an inconspicuous feature turned out to be quite complicated. The command of loading a level initiates a huge cascade of processes. Canceling them means you need to literally stop a chain reaction in place. You need to get an idea how far the process went, sabotage further progress and finally undo and reset the system. Things are even more complicated by the fact that a lot of the file management stuff is very haphazardly coded right now. You see, when I am coding a game, my goal is to see results as quickly as possible. I want to see results so I can evaluate if what I’m working on is worth spending more time on at all. So when the game requires a file I often opt for the simplest solution possible. And of course this solution often lacks all the proper bells and whistles a polished consumer products needs to have – canceling, progress tracking, error handling. When finishing a game, I need to go through all the code and add all the missing features afterwards. Of course, by then I can’t remember where and how I did some shortcuts. Often, my quick solutions turn out to be amazingly inefficient and complicated in hindsight. I uncovered a large piece of those old shortcuts today when implementing the cancel button. I was able to fix some of them but there is still a more exhaustive code review pending. Until then, the cancel button is in place and works well.

One thing that I was reminded of today I how much I hate the way Flash handles the removal of objects. You see, you can create new objects just fine. But the way the language works, you can’t specify to DESTROY an object. What you instead need to do is to remove all traces and references of this object in other objects and then cross you fingers that a mysterious “Garbage Disposal” process will kill the object by itself. The Garbage Disposal is completely invisible. You will never know if it worked or not. It’s an amazingly coder-unfriendly way to design a programming language. It takes away control, it’s almost impossible to debug and it causes unintentional waste of resources. Canceling a loading process is exactly one of those situations where you WANT to explicitly kill a bunch of objects and you want to make sure they are REALLY gone. So to all Flash coders out there: if you know a good way to debug Flash Garbage Removal, please let me know.