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

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

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

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>
</div>

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:

http://tumult.com/support/temporary/2015/xss/test6.html

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…

https://photics.com/new-duckduckgo-bang-pho/

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…

https://www.html5andbeyond.com/css3-animated-backgrounds-infinite-scrolling-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.
i.e

var window.foo = somecode.do.stuff

you need to remove the var declaration in this case.

2 Likes

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.

2 Likes

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";
}

zoom();
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.

2 Likes

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! ;).

3 Likes

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…

e.target.id

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.

2 Likes

Nice! Very playable now!

1 Like

The latest version is not online yet, but I’m excited to share the good news. I think this was the first time I actually cleared all the tiles on the field – with randomized bombs. The new version should be online tomorrow.

I think what’s really going to set this game apart (from others like it) is polish. It really has to be good. So, I’m reviewing the features list.

Randomly assign bombs (after first click) – I’m thinking this feature doesn’t really solve the problem. If you click a tile and a number “1” appears, it doesn’t really tell you anything. Instead, I’ve been thinking about adding an option to reveal a zero tile on start. That way, you can have more of a fighting chance.

Menu – This is starting to take shape. I like that the color of the tiles can be changed. It really lets the player customize the look of the game to match their preference.

Difficulty – I’m thinking there could be three sizes of tiles – Large tiles (50/10), Medium Tiles (200/40) and Tiny Tiles (800/160). Most of the coding is dynamic. I should be able to make the board any size. The problem is making the game playable and cross-platform compatible. I’m still sorting this out. I could zoom the whole scene to fit in the window – or I could add zooming and scrolling. There are a lot of options, but the game should be quick and simple to play.

Multiple screen sizes (16:9 & 4:3) – This is related to controlling the tile/field size and difficulty. It’s really important that this game works on Mac, iPhone and iPad. Right now, I’m having significant trouble making the game work on iOS. The “touchstart” event isn’t working.

Sound effects – I’m still considering this.

Ending – The game doesn’t actually end. I’m thinking about adding high scores (saved locally) and a timer. I don’t like the idea of adding timers in my game. I’d rather just let people play. Yet, there’s that feeling of pressure that makes it more exciting.

That brings up a design debate. Should every puzzle be solvable? Often, the randomized tiles will create a scenario where the safe tile is simply unknown. Guessing is part of the game… or should it be? I think it’s exciting, but players might find it frustrating.

Tutorial – Not everyone knows how to play this game. I think that should be included too. I think I have a really cool idea for this, which should keep the file size down. It’s also where I can really leverage Hype.

Multilingual Support – There are some words in the game. Either I convert everything to an icon or I add translations. I’m probably going with translations. Since it’s a web app, I should be able to easily detect the user’s language.

The sad part of this project is that only the “classic” mode is near complete. The real game is where a little robot drives through the field.

NY / NJ had a terror attack last weekend. It was a bit creepy to see the robots exploding bombs on TV – as that’s exactly what B.R.O.O.M. is supposed to be about. If you can defuse the bomb, go for it. If not, explode it safely. In my mind, I was trying to imagine how that would work. It could be slow and tedious, so the “Cross” and “Clear” modes could be challenging. I might need to rethink this.

Already this project is a success. I’m learning a lot of new web development skills. As an example, I used the console on my desktop to monitor what was going on in mobile Safari. (I have console log comments all over the place.) I sorta knew that feature existed, but I never had a need to use it before.

For the first time in a long LONG time, I’m starting to feel optimistic about the potential of my website.

4 Likes