B.R.O.O.M. - Bomb Removal & Ordnance Obliterating Machine

I figured while waiting for Physics to improve in Hype, I should try making some games without it. In the golden age of gaming, developers didn’t have fancy physics engines, so I should be able to make something. That’s when I realized that one of my game ideas was a pretty good match for Hype.

It’s called B.R.O.O.M. - Bomb Removal & Ordnance Obliterating Machine

Basically, the objective of the game is to control the robot through a minefield (left-to-right) while saving stranded soldiers.

I figured I’d post what I have so far. Apparently, that’s not as easy as I thought it would be. I didn’t have much trouble with Drupal, but WordPress didn’t work as expected.

I even watched the official video explaining the process…

Side Note: Tumult has a great narrator for their videos. He’s like a modern day James Earl Jones.

When I tried pasting in the HTML code, I got an error…

The XSS Auditor refused to execute a script in 'https://photics.com/?page_id=3437&preview=true' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

I’m not sure what that’s about. Previously, I had a Flash/Stencyl game working on my site, but then it stopped working. I’m not sure if the new SSL certificate (https) is the problem.

So, I’m just using an iFrame right now. The game doesn’t have a responsive design right now, so a fixed width box is OK.

The arrows move the main character. By using the arrow keys, the page moves. HA! This project is more tedious than I thought it would be. Surprisingly, the actual game development is OK. The main character can move and I’ve started working on the arrays, which should eventually control the location of bombs, soldiers, empty spaces and the general look of the field.

Here’s the progress so far… https://photics.com/games/broom/ …it’s not much, but it is a good start.

The XSS Auditor refused to execute a script in 'https://photics.com/?page_id=3437&preview=true' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

I’ve only seen something like this when loading a JS file from a different domain or different protocol. If your generated JS file is loaded over HTTP or from a different domain (while the actual page is HTTPS) you might be seeing this.

To specify what your cross domain policy is (what kind of exceptions to grant) you’ll need to add a small XML file to your server. Here’s a bit more info on that. Unfortunately some browsers are more strict than others.

Looking forward to seeing Broom progress! And thanks for the kind words on your blog.

1 Like

If I’m understanding this correctly, the file “crossdomain.xml” is uploaded to the root of the website…

<?xml version="1.0"?>
<allow-access-from domain="*" />

At first I tried to be specific with…

<allow-access-from domain="*.photics.com" secure="false" />

Neither method seem to help.

Also, here’s the HTML code I’m using…

<div id="broom_hype_container" style="margin:auto;position:relative;width:100%;height:100%;overflow:hidden;" aria-live="polite">
 <script type="text/javascript" charset="utf-8" src="https://photics.com/files/games/broom/broom.hyperesources/broom_hype_generated_script.js?90343"></script>

It’s using https. The protocol should be the same. I noticed that this website doesn’t use HTTPS. I think https makes running a website more complex and more expensive, but that seems like the right thing to be doing these days. Apparently, there’s an SEO bonus for HTTPS vs HTTP. Also, for sites with logins, it’s nice to secure the forms.

I deleted the crossdomain.xml file because that seems like a bit of a security risk. I don’t want to allow outside code on the page. I don’t third-party services on my site… no Google Analytics, no YouTube videos, no advertisements.

Currently, an iFrame seems to work. That’s what doesn’t make sense. Why would the browser care if it’s loaded from an iFrame or in a div tag? It’s code coming from the same place, loaded on the same domain.

Not really sure why this is. When loading from our site, I don’t see any XSS errors:


Likely something your web host could answer for you. If iframe works for you then probably best to keep it that way :slight_smile:

I restarted B.R.O.O.M. from the beginning. So far, I have a title screen… https://photics.com/games/broom/ …I was ready to move on, but I was getting a seam between the two copies of the background.

What happens is that I end up putting everything in a group, so I can preserve the 16:9 layout of the game, scale it fullscreen, but that tends to make Hype run very slowly. I’m also thinking it’s not the best for performance.

I also learned a lot about scaling. Apparently, the crisp vector graphics are lost when scaled up. It seems that the SVG is rendered to a bitmap, so I had to change some things around. The idea was to use SVG for all the artwork, so it would look great on any device – Retina / HiDPI or not. Unfortunately, it’s not that simple.

I returned to this project, to get tripped up on the same issue that frustrated me months ago. Hype doesn’t seem to do well with large scrolling backgrounds — especially if those backgrounds are using SVG files.

It’s well over 100% CPU usage, which creates poor performance. The background doesn’t move smoothly. I probably wouldn’t have noticed, but it creates a thin seam that scrolls.

I tried wrapping the texture, having it only repeat horizontally, using two separate elements to repeat the background, it just doesn’t produce a clean result.

It’s debatable if Hype is a game development platform, but this isn’t specifically a game development issue. It’s simply a scrolling background.

I haven’t given up. Although, I might have to redesign the title screen. In the current design, it’s just too performance heavy. This game is meant to be lightweight and run across multiple platforms.

Well, I’m still fighting with this project, but at least there’s some good news. At least there’s a quick way to get to it…


DuckDuckGo is a search engine that values privacy. It also has a cool feature called “Bangs”. A new bang (!pho) was created for Photics.com. So, if you use… !pho broom …in a DuckDuckGo powered search bar, it will automatically lead to the game.

This really inspires me to keep fighting. Maybe, one day, there will be a huge library of games at my website. That’s where a feature like this would be really useful. But create a huge library of games, that means I really should finish a game project. HA HA :smile:

Update – I tried a different technique to scroll the background…


It was still choppy, but it totally removed the seam.

I don’t know, I feel like the splash screen should be more flashy. It just seems boring with the Camouflage just sitting there.

Also, about Flash, that’s looking pretty dead… http://blogs.wsj.com/cmo/2015/08/31/google-chrome-will-begin-blocking-flash-web-ads/ …which wouldn’t be so bad, if Google didn’t also kill Swiffy… https://developers.google.com/swiffy/

Hype is the closest thing I have to a Flash replacement. A new golden age of online gaming could begin. Unfortunately, I’m having trouble getting started.

@Daniel and @jonathan — any news on the next version of Hype? Will it become more of a Game Development platform? Will the Physics features improve?

I wasn’t planning to play with B.R.O.O.M. today. Instead, I was playing with a new “Free Hype Template” for this week. Progress was slowed, as I was getting a strange error…

SyntaxError: Unexpected token ‘.’. Expected ‘;’ after var declaration. — index_hype_generated_script.js:4

I didn’t understand what this meant. I was wondering if the recent Hype update broke something, as I couldn’t trace the source of the error. I even turned off all of the custom JavaScript in my project and I was still getting a problem.

So, I decided to test a different Hype project, to see if I was getting a similar error. Nope, but I did see a different problem. The error counter was going crazy, constantly adding new errors. It was searching for something that wasn’t there, as I made major changes to my project.

Here’s what I learned…

  • Sometimes it might be better to start from scratch, as old code can cause a problem.
  • Running lots of JavaScript events, concurrently with heavy animation, can severely tax the CPU.
  • This stuff matters. With the death of Flash, HTML5 represents a new golden age of online gaming. One of the big complaints of Flash is that it crashes and killed battery life. HTML5 projects are not immune to these issues, so performance testing is important.

I knew something was wrong when my iPhone SE was heating up – like really hot. That’s one of the most powerful iPhones around. A scrolling background, even with an SVG file, shouldn’t be that much of problem.

I turned off the JavaScript for that scene, as it’s just a title screen. That code is not needed yet. I turned the scrolling animation back on. The updated project does put some strain on the CPU. On my Mac Mini, it’s about 62% CPU usage. That’s much better than over 100%. The iPhone SE does get warm after a few minutes, but not as hot as before. Also, with a title screen, the user should only be there for a few moments. The game itself does not have constant scrolling.

This is a concern, as I’m not sure how I could create side-scrolling games with Hype. Perhaps improving the physics options could help…

I watched the CPU usage while scrolling the scene in the Matter.js demo. It seemed fairly consistent. (Although, that’s without textures or a large SVG background.) This might be an alternative to the current setup.

I conducted one more test. I felt this problem might be related to scaling…

It totally was! This is bad. This very bad!

By turning off scaling, in the scene settings, the CPU usage dropped to a tenth of what it once was. This basically tells me that I shouldn’t be scaling scenes.

@Daniel and @jonathan – I think this information is useful to you. As you add features to Hype, you don’t want to recreate the issues that caused Flash to fail. Performance seems to be a problem with scene scaling. Perhaps a Matter.js view is a better alternative.

You most likely have a line that is declaring a global var ( window. ) but also have the var declaration before it.

var window.foo = somecode.do.stuff

you need to remove the var declaration in this case.


Wow, you’re very good.

Global variables caused the problem. I did figure it out, but it took me a while. That’s because I couldn’t track it down at first. Even though I removed the settings that load the JavaScript, it seems that it was still being used. I had to remove the JavaScript files from the resource folder first. Once I could determine which JavaScript file was the problem, I fixed it.

Yesterday was fairly productive. I had fun. The template is ready. It should automatically be available on Photics.com tomorrow.

This because the Javascript is being parsed even if it is not being called. So syntax errors like this are caught early on at the runtime.

1 Like

So, I tried making some progress with this project today. I wasn’t very successful. I was trying to use CSS to “zoom” the scene to the appropriate size. I figured that I could JavaScript events to update the size of the scene whenever the browser window size was changed.

Here’s what I learned…

  • This really isn’t necessary on mobile. The “Viewport Width”, “Document Width” option automatically scales the scene to the proper size. Without Hype’s scene scaling option, it runs smooth.
  • So, if page zooming gets the performance desired, why not just zoom the page on desktops? It’s not quite that easy, as Firefox does it differently than Safari. The “zoom” style doesn’t work on Firefox.
  • That’s when I learned something else. This performance issue seems to be a Safari thing. FireFox didn’t seem to care too much if I ran the project with Hype scaling or by adding CSS.

Here’s the code…

z = 2;

document.body.style.zoom = "" + z;
document.body.style.MozTransform = "scale(" + z + ")";

I was able to get the performance I wanted in Safari by using the “zoom” style. I’m not sure if I want to go that route though. It’s a lot of extra work, just for one desktop browser.

@Daniel & @jonathan – I’m not sure if that information is helpful to you, but maybe that’s helpful in fixing the scaling performance issue. In general, it’s just weird that I have to group elements and then click all the scaling settings. It’s probably better to manage this on the document level… a “Shrink to fix / Scale to fill” option for the whole document. (Does that make sense?)

I did check this issue with the Safari Technical Preview - https://developer.apple.com/safari/technology-preview/ …and the game’s title screen seems to have somewhat better performance / lower CPU usage on the newer version of Safari. It’s still pretty high though.

1 Like

Sorry for the late reply on this - do you mind sending me a zip of the game? Especially on one where you are using the scene scaling so I can get a better idea of the specific usage?

Very useful information. In general using the flexible layout mechanism in Hype will cause more CPU usage because it is doing a lot more work to calculate positions and sizes, potentially leading to relayouts and repaints. A simple top-level scale will be less processor intensive.

We’ve also definitely seen performance issues with SVGs, this is really more of a browser issue than anything we can typically do.


There’s some bad weather creeping up the east coast.

What’s normally a holiday celebration could get rained out. So, I’m turning it into super-nerdy weekend. My goal is to get some real progress done with B.R.O.O.M. over the next three days. I already got started.

For those following along at home, I already sent the B.R.O.O.M. template to @jonathan about two days ago. I probably could have waited for a reply. But like @DBear says, it’s better to have Tumult focus on making Hype better. Yet, one of the biggest problems I’m having with B.R.O.O.M. is related to a problem I’m having with Hype — Scene Scaling.

I think I fixed it…

function zoom () {
z = window.innerWidth / 640;
document.body.style.zoom = "" + z;
document.body.style.MozTransform = "scale(" + z + ")";
document.body.style.MozTransformOrigin = "50% 0";

window.addEventListener("resize", zoom); 

So, when the scene loads, run JavaScript. What it’s doing is checking for a change in the size of the browser. If there is a change, or when the script is first triggered, the zoom is set to the width of the browser window, divided by the width of the Hype document (640).

This is much easier than grouping every item and then setting the scaling settings. It’s also much better for performance. I feel like this should be a default option for Hype.

The performance is so much better now.

If Tumult doesn’t make this a default option for Hype, I’m thinking about spinning this into a template. This is important! One of the reasons why Flash was so successful was its ability to scale. With vector graphics, a SWF game could stretch to fill the screen. With Hype, it wasn’t so easy – until now :smiley:

Update #1 - I noticed some problems. The first is that scrollbars might appear. They can simply be hidden…

document.body.style.overflow = “hidden”;

Also, this shows an issue with the Hype “Layouts” feature. Using this approach renders them useless. Perhaps there should be a “ratio” option for Layouts, such as 4:3 (iPad / old TV), 3:2 (original iPhone), 16:9 (iPhone / TV) and 1:1 (square). (Those are just landscape ratios. Portrait would add more.)

This is still possible with the current version of Hype. It just needs more scenes. The correct scene is loaded (with JavaScript) based on the ratio.

I’m planning to port this to iPad and iPhone. If I’m feeling ambitious, I can support all three iOS ratios. If I require iOS 10, then it’s just 4:3 and 16:9.

The problem with this approach is that I haven’t figured out how to center the game vertically, for those monitors that are not quite an exact fit for a standard ratio. But considering this is primarily an iOS game, I’ll probably be OK. (If Android support is added, or full-screen on MacOS, then it could get complicated.)

Update #2 - I added a version number to the game, so I could be sure the latest version is showing. It seems that I was having some trouble with an older version of the game being cached. If I don’t see today’s date, then I know it’s not new. HA!

0 - Means it’s not finished.
16 - Is the year, not Y2K compliant. (I should be done before the year 2100.)
9 - It’s September. Where did the summer go?
2 - Two

That’s it for tonight. I think I can finally move past the title screen. It’s probably not final, but I think I got the technical issues figured out.

If you’re following along, pressing “f” (after clicking the scene) should activate fullscreen mode.

Update #3 – My approach to this project hasn’t been following the way of the programmer. Ideally, if there’s tedious work, just write some code to automate it. Yet, I’m having trouble visualizing what I want to do. So, I just manually added 200 divs. Hype does not like that…

As more divs are added, the slower Hype gets. This is especially true if symbols are used. I’m also noticing a conflict. Hype adds styles to the divs. If I want to add my own styles using HTML / CSS, I have to use “!important” to override what Hype is doing. This adds unnecessary code to the program.

Ideally, this will all be done programatically. That way, I can add or remove tiles as needed… such as increasing difficulty or matching the screen size. But to jumpstart this project, I found it easier to just add the divs.


The weather wasn’t that bad last weekend. I actually went outside more than expected. However, I was able to focus enough to make some real progress on this project…

Classic mode is almost playable. There are only a few things missing…

  • Automatically clear “0” squares
  • Randomly assign bombs (Ideally, after first click.)
  • Flags
  • Ending sequence (Show all bombs when one explodes / reset game)
  • Menu (Number of bombs remaining, return to home screen, settings)
  • Settings (Change color of tiles)
  • Sound effects (I’m not sure if I should add this.)
  • Multiple screen sizes (It’s OK for 16:9, but what about different ratios… or different sized tiles?)

Right now, the game is quite small, so I’m not sure if I want to add images and sound effects. Although, that might make the game more appealing. I did test out background music for the title screen. It works. I’m just not happy with the music I have. I’m thinking this game should have a 1940’s military theme, like the old camouflage on the title screen. Heh, but B.R.O.O.M. is a robot, so I might have to change that idea.

Music and auto-clearing would be great as would showing all the bombs. I’m no minesweeper person but was happy how much I cleared :slight_smile:.

1 Like

I have mixed feelings about this. I’m glad to see that the game is playable, but then I think of all the development time that could have been put into Hype. HA HA! :smiley:

I added Flags and Auto Zero Clearing.

I think the game is almost playable now, so I’ll work on the menu and ending sequence next – but that’s it for this weekend.

1 Like

All work and no play makes Hype a dull product! ;).


I’ve been feeling like I’ve been working too hard. Perhaps I should be playing more. Yet, working on this project is relaxing. At least… it is after I get past that initial lack of motivation. Every time I stop, it’s hard to get back into the zone again.

There was a bug with Auto Zero Clearing. It should work properly now.

There’s an issue with scene scaling. It works fine on desktop, but it doesn’t work on iOS. When placed in an iFrame, the game doesn’t want to scale. I tried just placing it on the page, but I got the XSS Auditor issue again. (I’m not sure if I should fix it. The idea is to sell this app on the App Store.)

New feature - When a bomb is clicked, the remaining bombs are shown.

I’ve been looking into sound effects and music, but right now the game is quiet. I’d rather have no sound effects than bad sound effects. The graphics are extremely lightweight so far too. Instead of adding images, I’m using emoji. Aside from the SVG on the title screen, the rest is just HTML.

The original idea was to create artwork for this game. While I have strong design skills, it’s difficult to separate the two different professions. Right now, I’m just focusing on development. Here’s the updated to-do list…

  • Randomly assign bombs (after first click)
  • Menu (Number of bombs remaining, return to home screen, settings)
  • Settings (Sound effects on/off, color tiles, maybe change difficulty)
  • Sound effects (Click, flag, remove flag, boom, title screen music)
  • Multiple screen sizes (16:9 & 4:3)

The plan is to finish this game by mid October, so I can release a Christmas app by Thanksgiving. It’s an ambitious schedule, so I might not make it.

Here’s a link to the game again… https://photics.com/games/broom

1 Like

I noticed a little problem with scene reloading. Sometimes, data from the previous game leaks into the current game. I’m still working on how to fix that. I just woke up, so my mind is a bit cloudy. Apparently, it takes 15 minutes to get back into the zone after being interrupted…

Last night, I made some more progress. The menu is taking shape. I also started the groundwork for customizations. I found that I liked the game more in black and white, while other people might like colors… such as pink or blue. That’s easily done with filters.

document.body.style.filter = "hue-rotate(90deg) saturate(0%)";

So what I did was start by giving everything a greenish theme. That way, the game could be color shifted with “hue-rotate” or have no color at all by setting “saturate” to 0%.

The good news is that the game can be reset now. You don’t have to refresh the page to restart the game. It funny (and frustrating) how a simple feature can cause problems.

Update #1 – Whoops, apparently there’s an easier way to get the ID of the element that was just clicked. I was using the mouse position to determine the clicked tile. This is a lot easier with…


The reason this is significant is because I’m generating the divs with JavaScript. That means I’m not plugging into Hype events. But now that the settings are ready to go, I’ve been trying to figure out a way to disable tile clicking while the settings are being modified. Since I can easily detect the ID of the settings element, I should be able to do it.

Update #2 – If you’re manually adding event listeners, sometimes you might need to remove them. I noticed that unusual things were happening when a scene was switched and then the game was restarted. I saw in the console log that a message would double… then triple… then quadruple… etc. After trying to figure out what was wrong, I realized that unnecessary event listeners were running. So, now when a scene changes, listeners are unloaded. The game is more stable as a result of this change.

Update #3 – Just when I think I’m almost done, I started cross-browser testing. The game is a bit messy on Firefox. I’m still working on fixing it.

This was especially problematic when preparing the game for iOS. There isn’t a right-click on iOS. So, I decided to add a “longpress” feature to the game. Now, a flag can be placed or removed by long pressing a tile. The problem is that this doesn’t quite work on Firefox. If you try to remove a flag, it then tries to clear the tile. It does this on right-clicking too.

I’ll probably add a way to prevent this, but I’m getting sleepy.

I was also surprised at how much trouble switching scenes could be. I decided to start the game in “pause” mode, to prevent erroneous clicking. This should be helpful with the randomization of bombs, as the game should be set before a tile can be clicked.

I think the easiest way to avoid clicking a bomb on the first square is to simply move the bomb if it is clicked on the first turn.