Hacker News new | past | comments | ask | show | jobs | submit login
Bomberman massively multiplayer in HTML5 (bombermine.com)
1394 points by cygnus on Feb 27, 2013 | hide | favorite | 201 comments



I upvoted this because it is awesome, and it is, well... Bomberman.

But I'm genuinely curious: at what point will we stop being fascinated by what can be done in HTML5, and actually start focusing more on what is actually being done -- regardless of the technology used.

Or to put it another way: when will HTML5 games stop feeling like HTML5 games?

For example, if this were on a console, I think it would still be cool, but it's lacking a certain "game" feel to it. It still feels like playing an old school game on a PC keyboard, and there still seems to be a sort of keyboard-to-response latency that I find in most HTML5 games. Not to mention, no music/sound.

Again, I'm not knocking it for the effort. I still think it's pretty dang fun, even for an HTML5 game. But it still feels like an HTML5 game.


Web Apps set us back 20 years in pretty much every respect except ease of deployment (1992 - people are impressed that Wolfenstein 3D gets 60FPS on a 100MHz Pentium; 2012 - people are impressed that Wolfenstein 3D (in Javascript!!!!111omg) gets 15FPS without sound on an 8-core 3GHz box).

With the exponential rate of development I doubt it'll take a full 20 years to catch up, but it'll still be a while before we've completely reinvented all of the wheels...

But yeah, for the forseeable future, "look at how I re-implemented this ancient technology with modern foundations, and it only took half the time! (And 10% of the efficiency and 100x more RAM)" is all we have to look forward to :-(


Parity is the wrong measuring stick.

Web app performance will always be playing catchup with native, and while the performance gap may shrink (perhaps to the point of irrelevance) it will never be eliminated. The OS and device makers are making the rules.

The real future is in our increasing ability to recognize and build to unique platform advantages in integrated ways. Dismissing the web platform as merely 'distribution' minimizes the value of a universally accessible, instant connection to everyone. It allows for different kinds of experiences unrelated to native performance. As the performance gap b/w platforms decreases, we may see more rich experiences for a web audience that's interacting in realtime with native or console users, broadening what's possible for everyone.


I think this overlooks all the pluses of this new "medium". How did you get your copy of wolfenstein in 1992? Travel to the radioshack, get a stack of disks, feed them one by one into your trs80? Within seconds this morning I was playing this game - with a 1000 other people simultaneously. Amazing in my book.


It's not competing with 1992 distribution though, it's competing with 2013 distribution.


I just bought my son a digital edition of Diablo 3 the other day. It was far from smooth sailing.


You had a problem with it? I haven't tried Diablo 3 specifically, but I find in most modern distribution platforms like Steam (or similar utilities from Blizzard) you just buy, click, walk away for 2 hours, and when you come back the game is installed and ready to play. It couldn't be easier to install native apps! -- when every thing works correctly.


One particular thing I noticed about Diablo is that it was playable long before it actually finished downloading. Most of the maps, video and artwork was downloaded as I played the first few levels. Pretty cool.


But is Diablo 3 played in a browser? Thought so.


In exactly what way is this question a follow-on from the parent comment? The statement was, to paraphrase: "Purchasing and installing native applications can still suck, even with '2013 distribution'." IOW, all that's been saved in 20-odd years is the drive to the retail store, the drudgery of swapping floppies and (usually) the task of manually configuring a memory manager. We're far from an instant-on, pay-and-play world for native apps (and in some cases you still need to be connected to get moment-by-moment permission to run the app you "purchased"—the internet as dongle).


I could also be playing Wolfenstein or one of many, many games in about a minute via Steam.


Wolf3D was shareware, so the preferred method was simply to make copies of the floppy and distribute them to all of your friends. I remember having more games than I could play in ~1993.


I don't remember how I got it but I'm sure I didn't go to a store. It really wasn't that hard to get either through BBSs or copying from a friend. It went viral and everyone had a copy. BTW, by 1992 PC clones had won, trs80s were long gone.


A 100Mhz Pentium in 1992? More like a 25Mhz 486 if you were lucky, my friend made it run on a 286. And you'd get about 15fps, wolf3d used to give people brutal motion sickness.

Wolf3D is also an interesting example because the rendering is done in software (so your high powered HD video card doesn't help at all) and I guess a lot of development time was spent writing asm routines/hacks to take shortcuts with the necessary math.

To be fair, a lot of the reason that people are remaking these old games is because people like playing old style games and the people building these demos are probably doing it in a very small team (or even solo).

It should certainly be possible to remake Half-Life (maybe even HL2?) entirely in javascript/WebGL or make more sophisticated 3D games. But we won't see it until some bigger gamedev is willing to risk a fair chunk of change on the browser as a gaming platform.


A 286? LUXURY! We only had a 8086 with half a megabyte and we had to hook it up to a bicycle generator to get electricity for it!


8086, you were lucky!


What did you have? A TI-81 calculator?


> But we won't see it until some bigger gamedev is willing to risk a fair chunk of change on the browser as a gaming platform.

They are, just as they're active on mobile platforms - EA, Epic and Square-Enix are notable examples. But they don't bother with AAA games (much as they like to pretend they are and attach them to those franchises), instead they target the casual player, that spends up to half an hour on a game per time, and/or that gets addicted to addicting games (w/ microtransactions). And the formula works for them; low development cost (5 - 10 dev team), high returns. Epic's Infinity Blade (and sequel) are the highest grossing games (in terms of development cost versus returns) of all time, at least, for Epic.


A 486SX 33 in my case. Couldn't afford the math co-processor at the time. :)


My family's first computer was a 486DX33 w/ 8MB of RAM. I'm not sure if it was in 1992 or a bit later though.


"wolf3d used to give people brutal motion sickness."

Most FPS still give me motion sickness, but I distinctly remember throwing up with the first Wolfenstein.


This is a naive interpretation. It's easy to imagine that "application quality or capability" is some easily measured metric tied to easy to measure numbers (like FPS or megahertz). In reality for many applications performance is not the long pole, so moving them to the web adds many advantages. I find it weird that someone could make the claim that "web apps set us back 20 years" in 2013, when web apps have transformed the world economy so tremendously (google search, web mail, amazon, online banking and investing, etc.)


> (google search, web mail, amazon, online banking and investing, etc.)

The transformative power of all of those (excepting maybe GMail) was realized in the form of cgi-generated webpages (click, refresh). Performance is not a requirement for those applications, whereas it is very much a requirement for interactive games. 20 years might be a little too harsh, but only a little.


Performance is the most important feature. Also on web apps. https://www.google.com/search?q=%22performance+is+the+most+i... 2M hits on exact match can't be wrong.


The most impressive html5 game I've played so far with nice graphics, music, and most importantly pretty responsive feedback is 'Save the day' : https://turbulenz.com/games/save-the-day/play

The first time I played it, I had assumed it was a Flash game, and not html5, based on the quality of it.


Is that really an HTML5 engine?

It forced me to download a DMG containing "TurbulenzEngineInstaller.app" which itself contains "npturbulenz.plugin" and an "install_script" that installs that plugin into "/Library/Internet\ Plug-Ins/".

About as good as you can get plugin installation to be, I guess, but it's not what I'd expect from an HTML5 game.


The site offers to install a plugin as a fallback for browsers that don't appear to offer the required HTML5 APIs (mainly WebGL). This allows the JavaScript/WebGL games to run on a wider range of browsers (particularly IE and when required APIs are locked behind a developer switch.)


that game is totally awesome!


The medium is just waiting for the game devs now: remember back in 2004 when someone wrote a brilliant pretty-much-exact copy of Lemmings in the browser? Well, it's taken 9 years and the HTML5 buzzword to start getting game devs to start poking round in the space. Now that it's started we can move past all of the basic nostalgic tech demos and start writing some more innovative stuff!

[Edit: it's back online, woo! http://www.elizium.nu/scripts/lemmings/]


I thought that Emberwind port that Opera wrote/commissioned to show off their HTML5 support was pretty impressive already (and that was in 2010):

http://operasoftware.github.com/Emberwind/


This is how we get there. HTML5 is pretty fresh and it's games like this that let us understand it's capabilities and to improve upon them. I mean, this is a mini MMO implemented in HTML5. That's a pretty big step forward from Pacman in HTML5 already.


Yeah, I definitely agree that this is a big step from anything I've seen thus far.

This was more to kick off a discussion about "are we there yet?", and if not, what is still missing?

I mean, I know what I think is missing, but I've not tried building HTML5 games to understand if HTML5 is the bottleneck, or if other dependencies are the bottleneck.


Perhaps what's missing is a good reason for choosing HTML5 over traditional technologies when you're investing in a new project.

Pros:

Runtime is very widely available

Cons:

Relatively poor performance

Monetization strategy is not clear

Browser differences increase cost of development


You also have to mess with Javascript on some level, even if you are compiling down from something else.

People who are professional game developers have invested a lot in C++ , have a lot of experience in that area and tend to see Javascript as something for developing websites with.

So on top of the other problems you have persuade them that it's something worth spending the time to get proficient in.


If you're coming from a deep machine and C++ understanding, it's not that JavaScript is tough to become proficient in, but rather, that you of all people have every reason to fully comprehend why it's such an awful implementation choice for this proposed purpose. It's not as if the PC or mobile game market is suffering for lack of cross-platform browser-based compatibility, so why switch to a suboptimal tool?


Do you still have to deal with all of the DOM stuff in html5/javascript?


Yes and no. It's all still there of course. I imagine though if you want to build a game you don't use DOM elements for sprites etc. You just create a giant <canvas> element that you draw to as you would draw to a frame buffer in DirectX etc. You could use DOM elements for the UI though I guess.


Yep. If you examine the source of this game that's exactly how they handle the game itself.


Here is a link to html5 pacman if you're interested. It was DMCA'd on github, but it's here now: http://pacman.shaunew.com/

It's broken on chrome now for some reason, but works in IE9, Firefox, Safari and Wii-U.


We need to stop excusing games being slow because they're written in HTML5. They are still behind Flash games from 10 years ago.


They’re really not. Go look at anything on (for example) Turbulenz ( https://turbulenz.com/ ) and that’s as good as anything Flash has done.


All it did was blow up my browser's RAM usage to 2GB and then deliver ~2fps.

IIRC Flash did better.


If by "better" you mean "blew up my browser's RAM usage to 2GB AND maxed out an entire core" then that's consistent with my flash experience (on 64-bit Linux, which I realise is not exactly a first-class citizen)


I agree complaints like this are currently valid in some respects, but the good thing is that feedback loops like this will eventually result in the same efficiency we come to expect from flash games on HTML5.


Eventually, but not any time soon.


HTML5 just needs a better sound API (e.g., programmatic playback, midi) so that we can make better games/apps. Many games just fall back to Flash for their sound.


The Web Audio API has already shipped on Chrome, FF and even mobile https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specifica...


I'll just leave this here.

https://www.google.com/search?q=html5+midi


The support for this is questionable. It's barely acceptable in Chrome and even in Chrome it falls really short.

The timing is awful in a lot of cases which makes it pretty much unusable for anything but maybe background tracks. I've had audio clips that had to be played in a 50ms time frame fail to play back a third of the time on occasion.

I'd rather have no sound than buggy sound.


Thanks for your link, but I've investigated MIDI support in JS. I actually work on piano/guitar apps, and would love to build a high performing, low latency app that hooks up with a physical keyboard. If you know how this can be done, please let me know! The last time I looked into this, the best solution I could come up with was a Java applet. :-(


The way forward is going to be via the Google-led Web Audio spec, as well as the complementary MIDI device spec - it's not "there" yet, though, since these specs are still non-finalized. But I'm working on building up the playback capabilities as a side project. I made a "true" Soundfont2 + SMF playback engine for Flash/Haxe, which is open-source(zlib) and somewhat usable in real-world: http://spacecreeps.com/apps/triad-synth/index.html

Now I'm working on the next generation of it, since I was still learning my way around audio with that one and made a mess of the architecture. I'm starting off with a Web Audio-for-Haxe project( early stages, you can watch it here https://github.com/triplefox/hxAudio ) - I'll be building off of that to add the synthesis and MIDI parts, so that you have pretty much everything needed for the playback parts of an audio app; recording isn't on my radar yet - especially since the specs are very early still. It will be possible to compile out the lib to pure JS, so you won't necessarily have to be using Haxe if that's not your workflow.


Aaand one of those demos killed Safari


They could always use WebGL to get a 10x improvement in graphics for the same performance requirement.


They could. But then they would lose support for 30% of their users.


I already implemented webgl renderer, but it has some bugs. I will switch it on ASAP. Both 2d and webgl renderer has the same interface, but different kind of optimizations, so there's no point to use webgl without acceleration. If your browser can draw 20,000 rects in 500ms, then bombermine will use webgl.


I've observed that people actually want old school style games but they en masse don't want to install emulators to play them. I think HTML5 is just a redeployment device to the time when computer games were just simple and fun.


> But I'm genuinely curious: at what point will we stop being fascinated by what can be done in HTML5

Go in any store that sells video games. Look at the backs of all the boxes. Find similarities.


With more and more "nativish" APIs being added to HTML5 (like the whole suite of mobile device APIs coming with Firefox OS), browsers are becoming functionally more and more similar to operating systems, just that the design is terrible for an OS. Unless browser design is revolutionized in and out, we will have to keep making compromises like this one. We need to integrate Web capabilities within the OS, not the other way round. That said, I'm off to play Bomberman now.


If you're interested in HTML5 games that don't feel like HTML5 games, I think that Kiwi Run is a great example. You can play it on the web here: http://www.icepopbeat.com/ but they also used Game Closure's devkit to deploy the game on iOS and Android; the performance looks great on all three platforms. As far as browsers though, I've only played it in Chrome :)


This is a pretty good start: http://play.goko.com/Dominion/gameClient.html


Or, you know, the less laggy and more functional http://dominion.isotropic.org/

I actually wrote a chrome extension to add a log to goko https://chrome.google.com/webstore/detail/goko-log-viewer/ka...

Post about some of the goko's issues http://www.roadtolarissa.com/speed-issues-with-gokos-online-...


Looks nice, and not only is the source code not minified/obfuscated, it's actually well commented.


I'm glad that it's done in HTML5, but man, if you try and dissect the code - it's insane. No wonder they had large amounts of bugs for quite some time.


We need to treat HTML5 games like games. We need to market them and release them and form a community around them, and then we need to release updates and make them moddable.


When will tools like Flash be created for HTML5/javascript? (with drawing tools, animation tools, etc)


Some stuff in that direction http://www.createjs.com/#!/EaselJS http://www.createjs.com/#!/TweenJS http://www.createjs.com/#!/SoundJS

sad that flash has so many issues (security, performance, etc) because there are some really nice compositional tools for creators in that ecosystem.


I think adobe is already making something like this. I'm not sure but I think its adobe edge?


Look into Red Ice, a local multiplayer HTML5 game played with Xbox gamepads.


I just don't get it - someone please smack me down and give me a convincing argument on how HTML5/CSS/JavaScript is a more innovative technology than Flash/Silverlight?

The only pro I know of is that it runs on IOS and flash does not (actually flash does run on JailBroken IOS). In 3 years IOS will power less than 20% of mobile devices. What then?

My big rub with HTML5/CSS/JavaScript and all this standards crap is that it moves sooooo slowly. I prefer innovation at whatever speed the minds of man can allow. Now we are restricted to creating frameworks built on top of (and limited by) HTML5 to create any kind of innovation (same with JavaScript) it makes me sick. I saw apps like this a decade ago written in Flash. I know that widespread compatibility is the reason that things like HTML5 win out, that and lazy developers who don't want technology to change/innovate because that would mean that they would have to learn something new more often.

What is my solution? I prefer the plug-in model. I think the spec that browsers should follow is one for an secure and OPEN Plugin architecture. If this concept was adopted, we would have a lot more (and better) options besides HTML, Flash and Silverlight to write web apps in. I think of it like this. Look at the iPhone, I picture every app you download as basically being a plug-in for IOS. Each can be written with their own completely different language and UI markup (and many are). Over 30% of IOS apps are not written in C/Objective C. There are a myriad of tools, frameworks and development environments which compile other languages and link them against the IOS libraries. This is how the web should be. That is more OPEN than following a spec that is publicly available, it gives inventors/innovators much more FREEDOM to make the world a better place.


We tried the plugin model back in the 90's. It was uniformly rejected by users and developers alike. Flash was pretty much the only plugin that managed to get wide enough adoption.

And flash is going the way of the dodo because innovation couldn't happen at top speed, because it was limited by a gatekeeper that insisted on keeping it closed.

The lacklustre support for Silverlight was a demonstration of how badly we were burned by flash.

While it's taking a long time to catch up, we're now free to expand the capabilities without being in a situation where a single party can hold everyone for ransom by refusing to support specific browsers or OS's.

There are many negatives to having HTML5/CSS/Javascript as the foundation, but they are dwarfed by the problems of the alternatives we've had to deal with.


First off, you are describing a plugin, I am not saying that the Flash plugin was not without it's problems. Only that it could do more than HTML5 can do today 8 years ago AND had almost universal penetration. Stepping back is my problem with standards and HTML5. I am not saying that Flash ever was the answer. I am merely using it as an example that proves that standards will always hold back innovation, and I think that an open plugin standard could yield the best of both worlds.

We tried the plugin model back in the 90's. It was uniformly rejected by users and developers alike.

This is just wrong. It was on 98% of desktops and there were over 1 million Flash developers. Mobile is what really hurt flash (actually IOS's rejection of it)

flash is going the way of the dodo because innovation couldn't happen at top speed, because it was limited by a gatekeeper that insisted on keeping it closed

It still managed to stay FAR in front of other web technologies which stood nearly at a standstill for over a decade. Closed is not what I am suggesting anyway. Sure someone can develop an plugin that is closed, but the plugin architecture itself will be open and adopted by all browsers who want to compete.

The lacklustre support for Silverlight was a demonstration of how badly we were burned by flash.

I disagree, I think that Microsoft's stagnation and terrible management of 95% browser share is what doomed any web UI tooling to come out of Redmond. Internet Explore was so riddled with bugs, so vulnerable to virii/malware and so stagnant that it became a stench in the mind of nearly every web developer. This was the biggest mistake IMO that Microsoft has EVER made. They could have pushed innovation and owned the search engine market at the same time. They will never get it back from Google now.

While it's taking a long time to catch up, we're now free to expand the capabilities without being in a situation where a single party can hold everyone for ransom by refusing to support specific browsers or OS's.

Having a standard for plugins in the browser would not allow this situation to happen. A lot has changed in the last 12 years. Sure Macromedia was the only one who made a viable plugin to fill up the Internet Explorer window with, but that would not be the case today. We would see open source and competing products popping up everywhere - Just like the JavaScript/CSS/HTML5 frameworks we are seeing pop up every month. These frameworks try to innovate past the limitations and cumbersome methods that the standards constrain us to. We would be a lot better off if there was an open and secure plugin architecture with access to a VM, Drawing and DOM API (Perhaps the HTML5/CSS/JavaScript implementation would even run on top of this API).


Pardon my English.

Team consists of two programmers and four helpers, we live in different cities near Moscow.

I started developing the game in April, published link at habrahabr.ru and since then i'm optimizing network and rendering.

We were preparing for Mozilla GameOn, posted a link to /r/webgames, it became viral. We're in shock :)

Game Core: Pure Java.

Game Client: cross-compiled with GWT. Angular.js for UI (scoreboard, chat).

Game Server: Haproxy -> Jetty

Web backend: nginx -> node.js

Servers are hosted in cloud and begin to slow down after 800 players.

We'll rent dedicated servers to archieve 1500 players on a map.

P.S. Langoliers are eating the time you spent in bombermine.


Hi! This is awesome from a technical perspective and was initially fun to play. Being reset when I died was a major problem, especially when joining for the first time in the middle of a round and playing against players who already had lots of stuff (at which point one tends to die quickly... and then have to start over).

I'm not an expert in game design (just psychology) but from a hedonic perspective I strongly suspect that you should not be stripping players of assets when they die.

In general, the case for "punishing" a player is weak (why cause the user pain?) and punishing them in a way that makes it hard for them to catch up in a highly competitive game is worse. The "Death" counter going up and losing your current position is sufficient incentive not to get killed, or there could be loss of points, or you could maybe strip off a single distance unit from the bombs.

In the long run you might want some sort of way for early players to catch up quickly, like drops near a player becoming more frequent when they're less advanced compared to other players. Meanwhile, ceasing to strip assets when a player dies, or stripping off only a single unit of distance (not number of bombs, having only a single bomb slows down gameplay a lot) will greatly increase game playability.

Especially don't strip the ability to kick bombs. This makes it far too easy for freshly respawned players to be killed.


Having spent altogether way too much time playing this game (so addictive), I disagree. I've played about a dozen sessions with several rounds each, so I've had the chance to play full rounds as well as entering part way through rounds, and I've certainly experienced my share of building up power and dying. I think the game would be no fun if you didn't lose stuff when dying. It wouldn't take long for everyone to build up max powerups, and then it would just be a bombs everywhere shitshow with very little going in the way of tactics or overall strategy. In addition, losing power ups is a huge incentive to avoid dying. In fact, it's the only reason I care.

I agree, however, that it can be really frustrating to spend a precious several minutes farming or searching for power ups only to lose it all in a freak accident, an unlucky wall spawn, or even just getting outplayed by someone. I think somewhere in between would be the best of both worlds -- maybe losing about a third to a half of your power ups would be a good balance. Then you don't lose all the fruits of your efforts in an instance but the incentive to not die is still strong. Yet dying will still happen frequently enough that the overall level of power ups that people have will be low enough to keep game play fun and reasonable.


I think when viewing this game from the understanding that every game lasts for 20 minutes, the dying and starting over again adds a sort of endless zen to the game.


I like games with harsh punishments - my favorite is hardcore mode in Diablo - death is permanent and when you die, you loose MONTHS of work, every item you have on you, every skill and level you have gained, everything. This really gets the adrenaline going when you're in a tight spot.


What happens when you have a blackout / internet failure / computer error, or another random problem? You lose everything as well, and usually through someone else's "fault" (and no adrenaline for you :) ).

I used to play Mario 3 on the NES, and at the time my country had a bad electrical infrastructure, I hated going back to the beginning due to a blackout.


Agreed, this can be incredibly frustrating! Has never stopped me from playing the game, though... One time I even broke my keyboard (hit <esc> with a fist), but within minutes borrowed another keyboard and started a new champion... I guess when the game is good you can make your "users" (in both meanings) suffer through anything.


The heart keeps you from getting stripped all the way. The only thing i agree with is starting with 1-bomb. Even 2 bombs gives you enough time to come up to speed (which is why the heart is so useful)


Few comments:

1. Just starting with 2 bombs instead of one would make a world of difference starting out. Especially mid-game when everyone has 5+ bombs.

2. The nuke doesn't rack up kills. Make the nuke useful and so people respect it more. Right now it just makes people want to kill you. And it makes the nyan-nuke much more tactical in nature.

3. Make depot spawned bombs "owned" by the user that set them off. If you set off a chain reaction of bombs, you should get the kills.

4. Stack treasure shield and soccer ball shield. Almost no one wastes time scoring because it is so hard. Make it stackable and people will do it more often.


Cool, another GWT game. Here's mine:

http://www.gangsta-game.com


What are you serving with node? Chat?


I assume he means that node + nginx runs the game at the HTTP level but the actual game engine and logic are in Java.


But wouldn't the game just be connected straight to Java over websocket once the client has been paired to the server?

From the looks of it I don't think they are using Node for anything related to the game itself. At best it might be used to pair a client to a server but that's basically nothing.


Not really sure, perhaps the game itself isn't web-aware and they just use node.js to pull messages in and out because it is fast?

Will have to see if Ivan replies to know for sure. :)


Game is connected to Java over websocket through haproxy. I'm going to remove haproxy as soon as i discover solution for a few backend problems.


Ah, that's pretty much what I expected. So Node has nothing to do with how nice it's running.

One more question if you don't mind: Are you doing any server side checks to make sure player movement is within bounds and then doing prediction on the client?


This is what I imagine when I hear HTML5 gaming. Just like "fun" on a PC looks different from "fun" on a console, and even more so from "fun" on a Wii, or a DS or an iPhone, "fun" on the web needs to take advantage of the nature of the medium.


In my opinion, HTML5 games (and apps) have a few key advantages that people on here would like to conveniently leave out (I COULD PLAY THIS ON PENTIUM 100MHZ etc...).

1. Accessibility. It never get's easier than typing in a URL. It's so easy that I can get my grandmother to play. At every step on the way to the game you will lose people. download Steam -> download game -> wait for download -> click on game. You've lost 90% of people right there. Being able to spread a link can create a much bigger viral effect as well.

2. Cloud based means that you can continue your game literally anywhere. I switch computers all the time, but every computer, phone or tablet has a browser, so there is no barrier to playing on them.

3. Cloud based also means that multi-player come naturally. You already have a server to serve the game, so the step to including multi-player is small.

4. Instant updates. Invalidate the cache and BAM, the user has the latest version of the game. This allows for some seriously fast iteration.

5. No walled garden app store 30% cut crap. Host your own servers and you're free from all that. Users might not find your app like they do through those app stores, but when a game is available directly through a link, do you really need app stores for discoverability? Shouldn't forums and review sites and whatnot take care of that?


"In my opinion, HTML5 games (and apps) have a few key advantages that people on here would like to conveniently leave out (I COULD PLAY THIS ON PENTIUM 100MHZ etc...)."

you sure about that?

also, none (with the exception of maybe the "walled garden" argument) of those benefits are exclusive to html 5 or the web in general.


What I found interesting is that when you "scale" a game from n < 8'ish players to n > 10 players and make it MMO style and continuously running, the strength disparity between the players who have been alive for quite some time and the "newly spawned" players becomes so large that a Quake/TF2-like system where players can instantly become "fully buffed" (by picking up an uber gun, for instance) becomes necessary.

Furthermore, I think an interesting game design challenge is what we can introduce to these scaled up games to make the psychological rewards enticing enough to have players keep playing. After the nostalgia feeling wore off after a few minutes, I personally no longer really felt like continuing to play since it was going to be the same stuff over and over again without much variability or depth.


It's not continuously running. There are rounds.


oh oops I guess I quit too fast T_T


I'd love to know how was AngularJS used in this app: not the kind of app I imagined AngularJS would be helpful in writing!


UI. Scoreboards, Chat, Single Page Application.


The langoliers are a nice addition to the game, I have to say.

http://en.wikipedia.org/wiki/The_Langoliers

(the pac-man type things eating up the level near the end of a round)


Awesome, but one exploit makes it less fun:

Smart players who are trapped by a foe are dropping their own bombs so that the foe doesn't get the kill.

I blocked a player in an alley. Right before he died he dropped his own bomb. I got no point for the kill. That means any skilled player can prevent anyone from scoring points for killing them.

The solution is to use a kill chain. When a bomb kills a player, look to see if that bomb was detonated by another bomb. Keep going until you find a bomb that is not owned by the dead player. That owner gets the kill.


We're using kill chain :)


"How the fack?" was my first reaction..Because this is so awesome! Revives old memories, yet also seems really fun (especially when you try to bomb others)!!

A few questions:

1) What backend technology do they use for real-time and concurrency? Node.js?? Scala??

2) How does one update the players' real time positions/actions??

If someone could shed some light on these questions, it would be so freakin awesome!!


1) HaProxy + Jetty 2) very tricky. I will write an article on this topic.


Thank you :)


1) They're using HaProxy + probably NodeJs ( i'm 99% sure )


How can you tell they are using HaProxy?


Thanks :)


This excites us developers, but sadly the gamers couldnt care less. Sure it doesnt require a plugin, but thats not really a dealbreaker for most web gamers.


I think you haven't given it a good look, this game is SOLID, awesome and fun

Yesterday I've played it for like 3 hours straight and had a blast, gamers will care(and are probably already caring since the servers are full) because it's fun and that's it


Aaaaand it's midnight and I'm meant to have written a 1,000 word post.


This such a great example displaying the power of HTML5. I'm going to be playing this quite a lot!

Is this going to be open sourced any time? It'd be neat to see how this works on the server etc.


I wonder what they're doing about cheating? I guess this type of game is not so easy to 'cheat' with but I'm sure it is possible.

I was thinking about building an Unreal Tournament clone in WebGL, but I'm still not sure what to do about cheating.


This is not a problem specific to HTML5. Although it's a lot harder to mess with a binary than some JavaScript, everything that runs on client side is fundamentally compromised and untrustworthy.

The trick is to have as many checks and balances on the server side as possible (to prevent walking though walls, warping, etc).


Very true, however I am not aware of a specification that, for example, makes it easy to check the scripts/resources that are being used are the correct ones. Of course any system to do this can be broken, but it strikes me a much bigger problem with Javascript in the browser than a binary.

One idea that's just crossed my mind is the idea of serving different Javascript to each client? It could be obfuscated uniquely every time someone loads the page in a detectable way. I,e you can serve IP x.x.x.x with obfuscation seed y and then you know to expect a certain behaviour. Variables and program flow can be changed to confuse nieve would be hackers, but important the structure of the network communication can be changed in a subtle way. Any hack scripts would need to counter for this which would make things far more complicated.

I wish my university term would be over so I can start hacking away on this idea! :)


You will still fail to prevent cheaters using an approach like this one. Even a game that is only distributed as a binary but with no or few checks on the server for cheating will be compromised very fast. It only takes one person to figure out how to do it and then release a proof of concept.

It is, in fact, not a bigger problem if the code is readily readable. Someone with the technical chops to read the source code and figure out weaknesses that can be exploited for cheating wouldn't be stumped by a binary blob for very long. My usual approach when trying to figure out "cheats" for most such things is to bypass the client altogether and analyse the network traffic to figure out the underlying protocol. Then come up with a client that reproduces those(simple replay attacks at first to see what works and what doesn't) and as my understanding of what does what evolves make it more sophisticated and flexible.

Having your source code fully available to any would-be attacker will force you to not make the mistake of hoping that nobody figures out how things work to be able to attack you. It forces you to pay attention to server-side checks to enforce the constraints of your game(what? that guy just changed his position in a way that's way too fast? not possible!).


Very true, no security through obscurity. Anti-cheats should be just another category of development topics under game development. So you wanted to be a game developer...


The way you prevent cheating in a game like this is that the game itself runs on the server. The client side is merely showing a representation of the server state. If people want to edit the scripts to show an invalid state who cares. Granted latency becomes a huge challenge, but in a perfect world (no latency) having the scripts on the clients side and having people edit them isn't a big deal


Easily said, but the challenge is making absolutely triple damn sure that the game running on the server is bulletproof against malicious input by the client. It took years for early games like Diablo and Everquest to get it right in ignoring a client sending position updates to move a character faster than nominally allowed by the game logic. And that's the tip of the iceberg.

You also have the problem of hidden information. Most games have a fog of war or simply walls that should obscure some part of the game state. If this is sent to the client, somebody will expose that information: maphack. It's not at all a trivial problem to define and send only exactly the slices of the game state that the client should have access to.

And any game where timing matters is subject to auto-aim bots and other such cyborg-style assistance to the players. Bomberman is subject to this: imagine a browser plugin that automatically moves your character out of range of a bomb in the last few instants before it explodes.


The "fog of war" is actually really easy to do. And most games that use "fog of war" already have parts in place for this.

Checking client input is rather difficult, but it's no more difficult then developing the game itself. Just a lot of hassle and checking.

Even if you do all this stuff, people can still break it. Look at pretty much every game made. There are ways to cheat.


In this case they don't have any trouble with cheating because the game logic seems to be entirely server-side.

Also cheating is only trouble when it degrades other player's experience or when they are hacking/hurting the monetization.


In this case it seems okay, but not in all cases. Consider an FPS. Javascript tweaks could be used to automatically change to a shotgun when close range, assist in aiming, highlight players behind walls, etc. I wonder what the most effective ways to combat such cheating would be?


You won't be able to prevent Javascript aim bots. The best you can do is server side detection of aim-bot-like behaviour, but this will always be a losing battle (better aim bots) and you may punish good players.


"I wonder what the most effective ways to combat such cheating would be?"

As stated, if the logic is performed on the server-side then the only way a client can cheat is by modifying the inputs.

The one thing that makes it hard for client to know in which way to cheat the inputs is... Randomization.

Do not make something where players are recompensed when doing a super skilled move, like a headshot. Or you'll have aimbots. As simple as that. Player has a shotgun? Make it fire 30 miny bullets at once with some server-side randomization (that's how many shotguns work btw).

Do not want to give info about the other side of the map so that a rogue bot cannot shift to the correct strategy automatically ? Use server-side fog of war. That way the very info needed to "map hack" simply is NOT available on the client.

It is hard to combat all forms of cheating. But maphack can definitely be mitigated and randomization can really help with many aimbots.

Regarding the "highlight players behind walls": two things to do. 1) do not allow to fire through walls (unless the first Counter-Strike, which was totally silly in that you could fire through 2-meters wide wall with a simple pistol) and 2) server-side fog-of-war. Do simply not send to the client the info that would allow the client to determine that an ennemy is behind the wall too early.

Sure, at one point you need to give the info: give it as late as possible and make is so "super crazy high reflex" are not rewarded in an insane way. For example make it slower to "switch gears", etc.

It all comes to a balance between fun and anti-cheat but many things can be done to make cheaters life way harder and, most importantly, way less efficient.


Very interesting ideas, thanks for your reply. :) I'm really excited to start working on this idea now! xD


Game logic is entirely server-side. I do not think that the bots will survive in this madhouse with lags and lot of randoms :)


Server has been bombed it seems. All game servers dead.

No idea whether it was HN related or a separate issue.


It did well on Reddit a couple of days ago, well on Twitter yesterday, so I think it's spread around quite a bit and picking up traffic from all over.


I see what you did there!


The workspace has been shutdown here, too many bombermen.


The play button seems to have stopped working; and the number of players seems to be shrinking slowly. Something broke?


Still not working at 12:52 AM ET.


The game is back to working now. Really solid job man. It's really smooth in Chrome on my low end desktop.

My only concern is that there's no client side prediction for movement? Every input key feels delayed by my ping and is most noticeable when moving diagonally by pressing 2 keys at once.


Anyone got any background on the backend tech involved?


Answering my own question but:

>Thanks :) Follow us @bombermine — we have plans to write an article about how game works. In few words: java, jetty, gwt, javascript, node.js, html5 [1]

[1] http://www.reddit.com/r/WebGames/comments/199urs/bombermine_...


I wonder what parts of their code is using Java. Really looking forward to reading that upcoming article.


Honestly, not only is this incredibly fun but also really innovative and clever. Well done.


man that is really fun!! we did a bomberman on a hackerthon, but only for 4 people each time, i like the mass multiplayer idea...

are u planing to put it on github? will be awesome to host in our own server to play against company people only


Oh god, have work to do. Must resist urge to waste entire afternoon..

One thing that always seems to be missing from these web games is support for gamepads for that authentic console experience however.


Game pad support is in a bit of flux in browsers. I added game pad support to a game jam game I made[0] but only for Chrome and possibly only the Xbox 360 game pad works properly. A project I plan to tackle soon is really good game pad support for browser games.

[0] http://city41.github.com/cellmates -- use chrome and plug in a game pad, likely need to push a button on the pad for if to "wake up". Ugly, simple game as it was written in about 14 hours.


You can usually get around that by using a joystick to keyboard mapper.

I usually use Joystick Mapper on Mac and JoyToKey on Windows.

Now you can waste your entire afternoon!


I agree. Though my friends and I would play this game so intensely that we'd bust through a few gamepads.

Hopefully I don't do the same to my keyboard.



this is a pc game, and an mmo as well, why would you want to play with a gamepad? besides you could say the same about any pc version of bomberman ever made, i doubt any of them had gamepad support, because people rarely use gamepads on pc.


It's a console game at heart though, my earliest games of bomberman were on the SNES I believe. It just has much better feel on a gamepad. There are also APIs in browsers to support gamepads now.

There are quite a few PC games with gamepad support, about half of the games on my Steam list are playable with a gamepad.


It is impossible to love more than I love this right now.


It's cool to see AngularJS was used for the templating engine. I'd be curious to see how deeply it's being used.


Actually, this is what I believe is the place of Go (the language) in HTML5 programming. I don't know if this was done with Go on the server side, might as well be node or gevent, but Go would be faster and easier to build a multithreaded game server with.


I agree that Go is a fantastic language for writing servers that need both CPU performance and responsively handle many connections.

That said, if you write the server in Node then you can share some of the logic between client and server without having to rewrite in another language. Examples where this comes handy in games:

- If the server runs the logic authoritatively, the client can run part of that logic locally to hide lag.

- If the logic runs on the client, the server can run part of that logic to catch impossible actions and detect cheating attempts.


Do you have any examples of live web-based games that are doing this with Node?


You might want to look at grits.

It's an open source html5, multi-player PvP, 2D shooter up game with sound, built in match making, auth server and architected by a team of ex-game developers at Google using mostly free tools to create maps, package assets, etc..

Here's the source: http://code.google.com/p/gritsgame/

They are using Node to run the game instances on the server. This is mainly because having identical code paths on both sides is highly beneficial due to how much they need to sync up to protect against cheating and have client side prediction. [Note: this isn't an opinion, I asked this question in their study group and the lead game developer told me that is why they chose Node over Go].

Think about that for a second. They created a presentation at Google I/O for the game, have a course running on Udacity building the game from scratch, have study groups at Google's offices, run the auth server on app engine and they still chose Node to run the game logic on the server instead of Go.

I wish Go could be utilized as game servers because it's clearly going to crunch numbers faster than javascript but it seems like not running JS on the server is a catastrophic mistake for game development where you plan to have the client running it in a browser with JS.


The Grits project page says Grits was designed "using Google's technology stack". Unfortunately, they mean it literally because Grits dies with JS errors in any browser that is not Chrome and the latest version of Safari. Grits requires Google's Web Audio API, which is currently only a working draft spec.

  Web Audio API is not supported in this browser
  TypeError: this._context is null
  https://gritsgame.appspot.com/scripts/core/soundManager.js


Catastrophic mistake, isn't that a bit exaggerated?


I don't know. When a professional 3D game developer (the lead guy who coded grits) tells me it's necessary that both ends use the same language to correctly calculate predictions and simulations in the correct timing then I believe him.

If your game is completely out of sync and the input feels horrible because it's delayed then your game is going to be instantly rejected. Having all of your hard work instantly rejected seems catastrophic to me.

Personally I don't understand why both ends need the same language because the server is definitely going to execute the code at a different pace than a random client, but I'm going to take his word for it because he's a professional in the industry with a really good track record.

They had every reason in the world to use Go but they didn't.


It's not necessary per se (much less catastrophic if you do otherwise), but it's certainly much more convenient. It's only necessary if you rely on simulations being identical, which would happen if you are using deterministic dead reckoning or lockstep networking. Client side prediction and server side cheat detection are normally not so strict.


I dont see the udacity course where the game is built from scratch, was it removed?


It's still there. It's the html5 game development course: https://www.udacity.com/course/cs255

This course is the entire game client. The server side will be part 2 of the course released at a later time.

There's also an hour presentation from Google I/O explaining the client and another hour presentation from Google I/O explaining the server. Both can be found on Youtube searching for "html5 grits".


My in-dev game thing (http://www.aliengrit.com) shares game logic code across the client and its Node server. If you've cleanly separated rendering logic from game logic for all game entities, it works really well. (i.e. the server just runs the same code without the graphics bit attached).


I'm sure that MMO game can be written on: Go, Java, JS (node.js), Dart, Kotlin, Scala. The point is that we need a strong backend and ability to use common code on the client and server.


(MMORPG) frontend(js) + backend(node.js) @ http://legendofkronus.com


I've been fancying building a game with Go + JS. I only have 2 problems:

1: I can't think of a game 2: Most JS libraries/frameworks drive me nuts.

However there are quite a few decent looking JS game frameworks about. Are there any recommendations?


Turbulenz[1] looks very promising and their framework[2] seems to be quite advanced, well thought out with a really nice documentation.

[1] https://turbulenz.com/

[2] http://biz.turbulenz.com/developers


Wow no kidding; I hadn't come across that one and it does look pretty swish.


Not for building the games themselves, but Clay.io hopefully won't drive you nuts on the higher level features like user accounts, leaderboards, achievements, payments, etc...

http://clay.io/docs



Looks like their servers cannot deal with the onslaught...

I love Bomberman. Looking forward to try it.


I closed the window on myself a few times with CTRL+W, whoops.


Same here! >.<


Undoubtedly the most fun I've had with one of these HTML5 games. Does anyone have any resources on how to keep clients in sync without lag?


Who's up for massively multiplayer Double Dragon?


Thanks for sharing, brings back good memories...


Am I the only one seeing:

> Disconnected from server...

UPDATE: This had something to do with my login. I just logged out and back in, and was able to get in.


Its eating up my CPU . The problem is that its an addictive game so far. Levels getting reset with the pac man is hilarious !


I'll enable webgl renderer ASAP. At this moment it have some bugs.


Definitely the best browser multiplayer game ever.

And nice to see that it's build on Node (among other tech).


We got 1500 players at US Public Server #1. 100kbit/s per user, i'm gonna optimize it.


Quick, everyone come up with the HN nicks so we can resolve the disputes there!


I grabbed jbrooksuk because I use that everywhere.


The bomb! Great game and great execution! Kudos to the Bombermine team.


It's working ok in the EU!


awesome game...wat did the developer use for realtime updates??


WebSockets


cant we see those requests in Chrome Inspector tool???


Well, there goes my evening. What stack is this built on?


All servers are down.


Massively so.


This is my first comment ever on HN and this is AWESOME!


This is an amazing game! Such good memories.


I think it just broke. The game just froze.


Broken here too. It's interesting. Even though the game is frozen and won't let me start playing the ping times and times till the server's refresh still updates.


Awesome! Loved this game on Super Nintendo!


Really well done. Love it I am 13 again !!


Why aren't you taking payments yet?


This is fantastic. Thanks :)


Beyond fantastic. I could just hug whoever made it!


nooooo, don't post this kind of link here!! my working day is over ;)


Bomberman is so addictive that I played it during 15mn while I'm on an open space with everyone seeing my screen :p


This is just over the top fun! Until I realize it's an hour past midnight :/


what other games are out there that are as neat as this ?


This made my day.


Very impressive.


Awesome!


THIS IS HECTIC!!!


OK, so how many pixels / sprites can I push per frame (and at which framerate ; ) on this HMTL5 thinggy?

Btw I was eating mode 7 for breakfast on the SNES and ruling the Amiga co-processors (eg to do copper bars), so I happen to know a thing or two about very nifty optimization that can be used in games.

I'm pretty sure a few old dogs could teach some young monkeys a few tricks in this HTML5 thing...


Awesome, I had once developed a bomberman clone for palm pilot.

Here is what HN users have commented on your game http://www.infocaptor.com/bubble_viz/newsycombinatorcomitemi...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: