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

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

FINISH IT ALREADY !!!!! :smiley: :smiley: only kidding. On a side note, the bombs in NY / NJ were bad.

I like the idea of a robot going through the field (brings it closer to real life ;)) Timer would definitely be good as you said "because of the pressure" again a real life scenario. What about the background too? on the "robot" version you could perhaps have a "Afganistan" style layout where it moves around and tries to find IED's :slight_smile: a slight twist on a classic game :smiley:

What is the problem here. You know where we are if you need help :wink:

1 Like

Unfortunately, this is a spare-time project. It's going to be slow. The good news is that a new version is online...

This version adds a timer. I also fixed some issues and cleaned up the console log comments. It's very descriptive. High Scoring is next.

That's the original plan. I was picturing Super Nintendo era graphics. But since the graphics are to be vector (SVG), it might be more modern looking. Before I can focus on design, I want to get the programming straight. Heh, I'm trying to avoid a repeat of the title screen.

But there's something I've noticed with today's design. Graphics are simple. I'm considering just leaving the game as boxes and basic shapes. I'll play it first and then see. At 197K, the game is exceptionally small. (Heh, that's by today's standards.) If I add graphics and sound effects, the game could get much larger. I'll have to see. I was imagining a desert and city as terrains. If I do the standard mix of environments... city, desert, lava, snow, grassy, jungle, ocean... there could be seven different terrains.

If I limit the tiles to about 100K per level, the game will be around 1MB. If I add some short sound effects, and short audio loops for music, the game could be around 2-3 MB. I don't think most people are going to worry about the size of that.

Since this could be the first of many games, I'm thinking about publishing games with a code of ethics...

  • Internet Not Required
  • No In-App Purchases
  • No Metrics Gathering (App doesn't collect personal data)
  • Tiny File Size
  • Content Friendly / Kid Friendly

I think one of the greatest challenges now is not playing the game. I'm actually having quite a lot of fun playing it...

In order to test the end-game sequence, I needed to beat the game. I got all the way to the last few tiles and I was getting nervous that I would have to guess. Then I figured it out. I was happy to see that I could beat the game, but disappointed that my end-game code needed more work. HA!

Also, I'm considering the idea of a launch party. :smiley::tada:

1 Like

I’m working on making the game more responsive. It’s supposed to work on an iPhone or iPad. Unfortunately, the default options for background in Hype are a little bit limited. I wanted to repeat the camouflage horizontally, while stretching it vertically.

There were some issues…

  • I couldn’t use “Scale Behavior / Zoom Contents”, as this dramatically hinders game performance.
  • I couldn’t use separate elements, as a line would appear between elements when scaling.
  • The SVG wouldn’t stretch like a PNG. It was maintaining its ratio. (This is especially funny to me, as I previously had the opposite issue with Hype – background SVG images would stretch when I didn’t want them to.)
  • I created a new SVG that was designed to repeat horizontally and vertically, but I was still getting a black line at the seam. It didn’t appear all the time, but at enough screen sizes to look bad.

So, I ended up coding the background manually. It looks something like this…

<div style="width: 100%; height: 100%; background: url('${resourcesFolderName}/camouflage-640x360.svg') repeat-x; background-size: 50% 100%"></div>

However, that doesn’t work unless I add the following to the SVG image…

preserveAspectRatio="none"

This is what I hate about modern web design. It’s not enough to make something look nice at a single screen ratio. It has to scale to fit so many different screens. It gets frustrating. I wasted a lot of time on this part. But, it’s a critical feature. It’s still not perfect, but I’m at least making progress.


Update #1 - I’m beginning to think that the ratio idea is not a good one. There are just too many ratios…

Mac laptops are 16:10 and not 16:9, so I’m not sure how I’ll manage full screen on Macs. My original idea of scene scaling helps, but it doesn’t work with classic mode. Right now, fullscreen works (pretty much) with the title screen. I’ve been thinking of customizing the size of the tiles, and the number of rows, for the classic mode. The other two modes (Although, I’m not sure if there are going to be three modes in total.) use a camera and scrolling. That should be easier to make responsive.

I uploaded a newer version… https://photics.com/games/broom …but not much has changed. I continued working on the High Scores today, but it’s not quite ready yet. I’m nearing the end of classic mode though, so the real challenge begins soon.


Update #2 - I was wondering if I needed to minify the JavaScript. I looked at the broom_hype_generated_script.js file and found out that Hype does some minification.

@jonathan and @Daniel – I think an exported Hype project could be reduced even further in size by being more aggressive with minification of custom JavaScript. As an example, the comments in the JavaScript were included. They probably don’t need to be there.

Good idea! Hype's own javascript is minified at build time, so we don't have presently include any minification tools to run on your code, but there's no reason this couldn't happen in the future.

3 Likes