Bomberman massively multiplayer in HTML5
bombermine.com
bombermine.com
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.
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.
Pros:
Runtime is very widely available
Cons:
Relatively poor performance
Monetization strategy is not clear
Browser differences increase cost of development
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.
It's broken on chrome now for some reason, but works in IE9, Firefox, Safari and Wii-U.
[Edit: it's back online, woo! http://www.elizium.nu/scripts/lemmings/]
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-...
IIRC Flash did better.
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.
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.
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.
Most FPS still give me motion sickness, but I distinctly remember throwing up with the first Wolfenstein.
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 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.
Go in any store that sells video games. Look at the backs of all the boxes. Find similarities.
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.
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.
sad that flash has so many issues (security, performance, etc) because there are some really nice compositional tools for creators in that ecosystem.
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.
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.
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).
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.
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.
Will have to see if Ivan replies to know for sure. :)
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?
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.
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.
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.
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.
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?
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.
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.
http://en.wikipedia.org/wiki/The_Langoliers
(the pac-man type things eating up the level near the end of a round)
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.
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!!
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
Is this going to be open sourced any time? It'd be neat to see how this works on the server etc.
I was thinking about building an Unreal Tournament clone in WebGL, but I'm still not sure what to do about cheating.
The trick is to have as many checks and balances on the server side as possible (to prevent walking though walls, warping, etc).
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! :)
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!).
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.
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.
Also cheating is only trouble when it degrades other player's experience or when they are hacking/hurting the monetization.
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.
No idea whether it was HN related or a separate issue.
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]
[1] http://www.reddit.com/r/WebGames/comments/199urs/bombermine_...
are u planing to put it on github? will be awesome to host in our own server to play against company people only
One thing that always seems to be missing from these web games is support for gamepads for that authentic console experience however.
I usually use Joystick Mapper on Mac and JoyToKey on Windows.
Now you can waste your entire afternoon!
There are quite a few PC games with gamepad support, about half of the games on my Steam list are playable with a gamepad.
Hopefully I don't do the same to my keyboard.
[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.
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?
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..
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.
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.
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".
Web Audio API is not supported in this browser
TypeError: this._context is null
https://gritsgame.appspot.com/scripts/core/soundManager.jsI love Bomberman. Looking forward to try it.
> 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.
And nice to see that it's build on Node (among other tech).
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...
Here is what HN users have commented on your game http://www.infocaptor.com/bubble_viz/newsycombinatorcomitemi...