71–80 of 211 posts
"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!!
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…
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.
It's broken on chrome now for some reason, but works in IE9, Firefox, Safari and Wii-U.
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.
[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.
Earlier quoted context omitted.
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…
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 cod…
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…
The first time I played it, I had assumed it was a Flash game, and not html5, based on the quality of it.
Earlier quoted context omitted.
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.
IIRC Flash did better.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
Do you still have to deal with all of the DOM stuff in html5/javascript?
Earlier quoted context omitted.
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…
Catastrophic mistake, isn't that a bit exaggerated?
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.