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 :-(
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.
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.
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).
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.
> 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.
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.
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.
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.)
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!
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.
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?
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.
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.
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 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.
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.
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.
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 :)
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.
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).
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.
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)
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.
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.
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.
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.
"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!!
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
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.
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.
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.
>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]
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.
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.
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.
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..
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
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.
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.
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...
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.
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...
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.