Lessons Learned from HTML5 Bug Hunting

Armelline

Asked by a publisher to see if an HTML5 version of a game would be possible, I spent the afternoon testing and troubleshooting an HTML5 version of my latest game, Sand. I don't work with HTML5 output often, and the game was no designed with it in mind. So there were bugs aplenty.

I thought I'd walk through three of those bugs, and how I found and fixed them. Each is caused by fundamental differences in the the native engine and the HTML5 engine. By that I mean the HTML5 engine is less forgiving of my lazy logic...

I hope this will help people learn from my mistake, or at least give a little schadenfreude! This is not a request to have these things fixed or a complaint. The problems (at least with 1 and 2) were mine, not GS's.

Bug 1: The Case of the HTML5 Image

HTML5 projects care about the case of letters in image file names.

How do I know this? When first previewing Sand as an HTML5 project, there were a bunch of issues immediately obvious. The most immediately obvious was that a lot of background images just… not there. I did the usual troubleshooting steps. First I created a new project, added an actor, threw on the same image and tested it. Worked fine. Went back to Sand. Still didn’t work. I tried putting a new actor in Sand, making it identical to the background actor in every respect, put it on the scene. Worked fine. I deleted all other actors from the scene to be certain nothing else was causing a problem. My background was still not showing up. It didn’t happen on all scenes, but it happened on a few, and all backgrounds used the same actor prototype, which made it even more confusing.

After another hour of trying everything I could think of, I resigned myself to the job of replacing every affected background actor with a new one. Only then did I notice… The actor that wasn’t showing up had an image named “L1-entrance”. The one that was showing up… “L1-Entrance”. Native preview doesn’t care, it just looked for "L1-entrance", found "L1-Entrance" and was happy. Works fine on iPhone and Android. HTML5, though… HTML5 cares about the case of letters in filenames.

At some point I’d corrected the lack of capital in the file name, imported the newly named image into the game and replaced the old file. Because native preview doesn’t care, I never noticed the actor's image name didn't changee to match the new image name. I groaned when I realised how stupid I’d been in my troubleshooting this issue.

Most annoyingly, this is quirk of the HTML5 engine I’ve encountered before and gone through the same troubleshooting steps to identify. It was just long enough ago I simply forgot and my bad memory forced me to do it all again…

Bug 2: That’s Not The Scene I Asked For…

Most of the navigation in Sand is handled by a single prototype actor - “Navigate Area”. This actor looks for a “Touch is pressed” and when it receives one it moves the player to a new scene. To be a jack of all scenes actor, though, it needs a fair bit of information. What scene does it need take the player to? Are there any prerequisites before it will allow the player to use it? (For example, do they have to open a door before they can go through the door?)

I was a little lazy in how I programmed this. I would blame how forgiving the native engine is, but that would be a bit of a cop-out. One of the prerequisites checked for was a self attribute called “Override”. If this attribute was not zero, a table would be checked at the given row. If that table cell contained a value other than 0, the player would be taken to a different scene. At least that’s what I intended. To do the check, I simply said “If tableCellValue(table,self.Override,5) is 0 go to scene X, otherwise go to scene Y.” If the self.Override attribute was zero, this check would return 0 as there was no table row 0 to check.

When I previewed in native or on devices, this worked just fine. When previewing in HTML5, though… every time I tapped on a Navigate Area, I’d be taken back to the Introduction scene. Why that scene? If the check failed, and the otherwise was called, the Change Scene behaviour there would send the player to “self.OverrideScene+2”. Since self.OverrideScene would be 0, this would send the player to the second scene, the introduction…

Thankfully it didn’t take long to pin this down to my attempting to check a 0 table row, and rather than rework all my code to only check the override row if self.Override was not 0, I just added an extra condition to check if self.Override was 0 and changed the rule to “Any.”

...continued in first comment due to post length restrictions.

Armelline

Bug 3: Rotations Are Not All Created Equal

The HTML5 engine handles rotations very different to native preview and devices. This one is easiest explained with examples.

This example is simple. When touch is pressed, we rotate the actor by 45 degrees.

This is all we need to highlight this engine difference. I actually have two blocks of code I'm going to use in this example: this one and another that’s identical in every way except one uses a self attribute that’s an angle and the other uses a self attribute that's an integer. From now on I’ll refer to these blocks as Integer Rotation and Angle Rotation.

If you’re previewing natively, this is what you see when you run the Angle Rotation code:

https://i.imgur.com/ZYpz0NL.gif

If you’re previewing natively, this is what you see when you run the Integer Rotation code:

https://i.imgur.com/i2RCFgz.gif

In both cases, when the actor reaches 360 degrees rotation, that rotational value is immediately converted to 0. So, when the next touch is registered, the actor is at 0 degrees and it is told to rotate to 45 degrees. After many, many years of using GameSalad, this behaviour is pretty deeply ingrained in me.

The HTML5 engine, however, is less forgiving, and actually more flexible. Whereas with the native engine there is no real difference between using an angle attribute and an integer attribute (in cases like this), there is with the HTML5 engine.

If you’re previewing with HTML5, this is what you see when you run the Angle Rotation code:

https://i.imgur.com/Q5TUyqB.gif

This is… not what we’re expecting. Since the actor’s rotation remains at 360, when the actor is told to rotate to 45 degrees it has to rotate backwards to get there, causing this odd spinning effect.

If you’re previewing with HTML5, this is what you see when you run the Integer Rotation code:

https://i.imgur.com/lbBYdtB.gif

This is again different from the native engine. The actor’s rotation value doesn’t get limited to between 0 and 360. Instead, it just keeps increasing. This lets me fix the issue in my game with minimal effort, though, so this is what I went for. All I had to do is change the rule that checks if an actor’s rotation is 0 or 180 to instead check for mod(rotation,180)=0. It still works with the native engine, as the two values we’re looking for are essentially mod(0,180) and mod(180,180) instead of mod(360,180) and mod(180,180).

I’m not sure which direction I would want this bug “fixed”. One of the engines must be wrong, since they both handle it so differently. The HTML5 engine gives more flexibility, however, as there are two options compared to the native engine’s one (the same effect can be achieved in the native engine, just not quite as simply), so I’d be inclined to go with making that the HTML5 behaviour default. Given the number of games potentially reliant on the native engine’s current behaviour, though, I suspect the best thing to do here is nothing.

Anyway, that's my afternoon's bugs. The HTML5 engine is forcing me to make my game better, so I guess I'm thankful for it being such a hardass! These are what I found in only the first level of the game, so I expect I've got more to discover and fix!

adent42

Thanks for reporting all this! Once I'm back into HTML5 mode, I'll take a look at scheduling fixes for these issues.

Armelline

https://forums.gamesalad.com/discussion/comment/617785#Comment_617785

I honestly wouldn't consider any of this bugs for you to fix. The table issue is me attempting to check row 0 and HTML5 going "errr... no. There is no row 0, fool." Which is what it should be doing, surely. The image name issue is harsh but fair. They are two different image names. The bug there is more in Creator for not updating the image name in the actor XML. And the rotation one... I don't know enough about the intended behaviour to know if the bug is in the native or HTML5 engine, but as I muse at the end, this does make the HTML5 engine more flexible.

These "bugs" are more due to how lenient the native engine is for sloppy logic, not any shortcomings in the HTML5 engine.

I'd far far far rather see your time going to fix the call freezing bug :D That's the one that I've had to convince publishers to let slide in the past and has led to clients getting some bad reviews for their games.

adriangomez

How do you replicate the call freezing issue? Is it an HTML build issue only? I tried replicating it yesterday on iOS build with no luck.

Armelline

https://forums.gamesalad.com/discussion/comment/617787#Comment_617787

It used to happen on every game with every call received on iOS. But it's been a year since I specifically tested it - maybe it got fixed without anyone noticing! Or now that I think about it, maybe it was side-stepped when Apple changed how incoming calls are displayed to no longer take up the whole screen? What iOS version did you test on?

Edit: It is indeed no longer an issue on iOS 15. I guess instead my most-wanted feature is the new resolutions for testing in Creator 1, then :D iOS new version adoption is normally high enough that I don't think it's a priority to fix an issue that only affects 14 and below.

RThurman

@Armelline -- thanks for sharing your findings! This will be very helpful.

uptimistik

Great job finding and detailing these issues man @Armelline this should help the GS team a lot.

Armelline

Bug 4: Nothing vs. Nothing

If you add a change attribute behaviour to your project and set the attribute to self.Position.Y (or presumably any similar integer/real/angle/non-text attribute), but add nothing in the expression, the native and HTML5 engines will handle it very differently. The native engine will just ignore the Change Attribute and do nothing. The HTML5 engine will treat the blank expression as a 0.

The only code in this example project is this:

When previewing with the native engine, the actor I placed roughly in the middle of the screen remains where I put it:

When previewing with the HTML5 engine, the actor moves to Y position 0:

It is of course my error to have such a change attribute in my project, and thanks to this bug it's been spotted and removed. Like with the others, I have no idea which is the intended behaviour.

adriangomez

I have noticed this "bug" also when I was working on the HTML build. Not sure if it is a bug though.

Armelline

http://forums.gamesalad.com/discussion/comment/617801#Comment_617801

No idea either. These are bugs in my game I’m pointing out and what I learned from them, since I don’t work with HTML5 that often. Not bugs in GS. I have a whole different list for those :D