Artillery is building a hardcore RTS with HTML5 and WebGL(blog.artillery.com)
blog.artillery.com
Artillery is building a hardcore RTS with HTML5 and WebGL
http://blog.artillery.com/2013/09/project-atlas-and-the-artillery-platform.html
150 comments
Well, I'm a hardcore gamer and I think you're all wrong, no offense. I care for good games. Whether it's from the browser or native, as long as it's addictive and competitive I'll play it. Also, the thing about having a copy is a thing of the past. Think about Starcraft2 that you can download and already have the settings you used on a different computer. Or steam where you download the game and press play.
My personal concern with the browser is more about the freedom of game developers to tweak the app as they want. You're very vulnerable in a browser in term of how you can use the keyboards and how the client will receive what you're trying to show them. For instance, in starcraft2, you use "ctrl+1" to bind an army to the key "1". In chrome, ctrl+1 switches to the first tab. Some webapp uses hacks to go around that.. for instance, with Asana, you use the [tab] key, such as [tab]C to go to the comment section.
Everyone talks about performance issues.. but if the trend continue, it won't be a problem. But I'd agree that right now it's still hard performance-wise.
Maybe one way to solve these problems is to have a gamer browser. Could be based on V8 and even have the look&feel of Chrome, but small parts would be tweaked to make it gaming friendly. Maybe no plugin allowed, more resources dedicated to it, performance optimized for certain tasks, etc.
My personal concern with the browser is more about the freedom of game developers to tweak the app as they want. You're very vulnerable in a browser in term of how you can use the keyboards and how the client will receive what you're trying to show them. For instance, in starcraft2, you use "ctrl+1" to bind an army to the key "1". In chrome, ctrl+1 switches to the first tab. Some webapp uses hacks to go around that.. for instance, with Asana, you use the [tab] key, such as [tab]C to go to the comment section.
Everyone talks about performance issues.. but if the trend continue, it won't be a problem. But I'd agree that right now it's still hard performance-wise.
Maybe one way to solve these problems is to have a gamer browser. Could be based on V8 and even have the look&feel of Chrome, but small parts would be tweaked to make it gaming friendly. Maybe no plugin allowed, more resources dedicated to it, performance optimized for certain tasks, etc.
I real like the idea of a game-mode for browsers, or a dedicated game browser. It could disable all hotkeys, have extremely minimal chrome, and be optimized for the gaming environment.
Convenience is exactly why this is interesting. I don't buy many games outside of Steam because it's so convenient not to have to back up installers or hunt for a particular XNA version or what have you.
There's a low barrier to entry to trying something that runs in a browser. I just navigate to the page, wait for a progress bar, and maybe bookmark the game if I like it. The low barrier to entry is one reason that flash games are still so popular. http://xkcd.com/484/
There's a low barrier to entry to trying something that runs in a browser. I just navigate to the page, wait for a progress bar, and maybe bookmark the game if I like it. The low barrier to entry is one reason that flash games are still so popular. http://xkcd.com/484/
That is what consoles are for.
No, it's really not. This is what consoles are trying to become, but they're also a long way off. They're also expensive, dedicated machines.
Even assuming this IS what console are for, why in the world are you going to complain about more competition in the market for a good way to distribute games?
Even assuming this IS what console are for, why in the world are you going to complain about more competition in the market for a good way to distribute games?
No, consoles were always like that.
Fixed set of hardware, that the developers could easily target and build their skills.
For the gamers, just put the cartridge or disc, and start playing.
No need for driver updates, or whatever else might be required.
Fixed set of hardware, that the developers could easily target and build their skills.
For the gamers, just put the cartridge or disc, and start playing.
No need for driver updates, or whatever else might be required.
What does "catch-up" mean? Will they ever be as powerful as advanced as the hardcore cares are today (2013)? Yes, they will be. Will they catch-up to hardcore games of the future (2023?). No they won't.
But that's irrelevant. What matters more is if they will catch-up to being "good enough", and that is likely to happen.
But that's irrelevant. What matters more is if they will catch-up to being "good enough", and that is likely to happen.
I never said catch-up.
I personally think WebGL IS good enough to make quality games, I have no issue with it. I just don't think it will catch-on with the gaming public for other reasons. Look at how much resistance there was to Microsoft's 'always-on' feature of Xbox One, to the resistance to DRM that calls home (it is annoying if you're trying to play a game somewhere that you have no connection), and then the requirement that the developer also maintain infrastructure.
The current system, where you create something native using a cross-platform toolkit, then distribute it once, and the user has it forever - this is what gamers are used to, and what they like. And I admit, it's nice being able to play games when I have no internet connection. I don't think this paradigm is necessarily the best one, but it certainly has its merits.
I personally think WebGL IS good enough to make quality games, I have no issue with it. I just don't think it will catch-on with the gaming public for other reasons. Look at how much resistance there was to Microsoft's 'always-on' feature of Xbox One, to the resistance to DRM that calls home (it is annoying if you're trying to play a game somewhere that you have no connection), and then the requirement that the developer also maintain infrastructure.
The current system, where you create something native using a cross-platform toolkit, then distribute it once, and the user has it forever - this is what gamers are used to, and what they like. And I admit, it's nice being able to play games when I have no internet connection. I don't think this paradigm is necessarily the best one, but it certainly has its merits.
An excellent game could change perceptions though.
I'd be more concerned about how easy it would be to reverse engineer a web game compared to a native binary. If it's easy to bot or cheat, any competitive aspect will be ruined.
I'd be more concerned about how easy it would be to reverse engineer a web game compared to a native binary. If it's easy to bot or cheat, any competitive aspect will be ruined.
SC2 is easy to hack and cheat. Blizzard rarely do ban waves. Oddly enough, with this type of game, no hacks are enough to let you beat those who are truly better than you (at least with starcraft!).
Kinda neat to be honest. Doesn't stop me yelling at map hackers tho ;)
Kinda neat to be honest. Doesn't stop me yelling at map hackers tho ;)
I'm not convinced that web-based is automatically doomed among the hardcore. I think that Quake Live the most popular game in it's subgenre (Arena FPS), and it's still hanging on as an esport, with a slot in Dreamhack as well as weekly tournaments. Granted, Quake Live has the massive advantage of being a resurrected version of Quake 3 Arena--but it does make a precedent in people's minds of a hardcore web-based game.
QL uses a native binary that you install, no? Like BF3, the only components handled in the web browser are matchmaking, clan management, etc. For the actual matches/gameplay, it invokes the native client
Quake Live is a native game (that's why you have to install a plugin) that is launched through a web-based interface.
I think Javascript is too slow for 3d gaming.
If you look at this HTML5/WebGL minecraft engine, it stutters even without any other players or bots in the environment.
http://voxeljs.com/#gallery
Meanwhile Minecraft running in Java is smooth on even the slowest machines.
Benchmarks indicate that Javascript is 4x slower than Java.
http://j15r.com/blog/2013/07/05/Box2d_Addendum
The alternatives like ASM.js and PNACL are far from usable. ASM.js has no support for threads and PNACL is unlikely to be supported outside of Chrome. They also have no debugging support.
If you look at this HTML5/WebGL minecraft engine, it stutters even without any other players or bots in the environment.
http://voxeljs.com/#gallery
Meanwhile Minecraft running in Java is smooth on even the slowest machines.
Benchmarks indicate that Javascript is 4x slower than Java.
http://j15r.com/blog/2013/07/05/Box2d_Addendum
The alternatives like ASM.js and PNACL are far from usable. ASM.js has no support for threads and PNACL is unlikely to be supported outside of Chrome. They also have no debugging support.
This is exactly what they said about Java ten years ago (and I still hear it today): "Java is way to slow for games/anything performance-critical".
The choice of Java in your argument is kind of ironic to me.
The choice of Java in your argument is kind of ironic to me.
Minecraft isn't exactly a very demanding game.
Also 10 years ago Java was nowhere near as fast as it is now. If you are saying that Javascript might be an option 10 years from now, I am not disagreeing with you.
Also 10 years ago Java was nowhere near as fast as it is now. If you are saying that Javascript might be an option 10 years from now, I am not disagreeing with you.
Java has gotten faster in the last decade, but it's still not used for games where performance matters.
Actually minecraft gets pretty shaky on my mbp 2009.
My minecraft server can get bogged down just my wife and I playing. That's on a core2duo 2.0GHz with 4GB.
It plays better on my phone.
My minecraft server can get bogged down just my wife and I playing. That's on a core2duo 2.0GHz with 4GB.
It plays better on my phone.
Too slow? Then try this: http://www.endtime.at/demo.html#gamestart
Your demo was also choppy for me on 2.2 Core 2, 460m, Chrome 29, Win7.
After your experience with both native and WebGL game development, don't you think it's a little premature to make a hardcore game targeting only WebGL?
Thanks for sharing Irrlicht engine with us!
After your experience with both native and WebGL game development, don't you think it's a little premature to make a hardcore game targeting only WebGL?
Thanks for sharing Irrlicht engine with us!
In addition to all the stuttering it looks terrible graphics wise.
Your performance is not typical. Webgl performance is dependent upon drivers and system config. For other people like myself those demos run smoothly.
As a hardcore SC2 player, I'd only be interested in a native version of this game. Even the latest ASM.JS demos like Epic Citadel run chopping on my system. Hardcore gamers like myself won't sacrifice performance for a the luxury using poorly designed and immature technology like JS and WebGL.
And Epic's demo was their previous gen engine, Unreal Engine 3, which targets mobile platforms: iOS, Android, PSP...
Meanwhile, the state of the art UE4 is only aimed at next gen consoles and native PCs games.
> They also have no debugging support.
When emscripten is passed the debug flag, it will generate source maps, which will let you step through your code, although inspecting variables still isn't a solved problem.
When emscripten is passed the debug flag, it will generate source maps, which will let you step through your code, although inspecting variables still isn't a solved problem.
JS port of Box2D is dead since 2008.
https://code.google.com/p/box2dweb/ tracks box2dFlash which was last updated in 2011.
Why is that relevant? It is still a valid example of non-trivial game code.
Many people trying to make "classic" RTSes miss critical points about feel and gameplay which makes the games very unsatisfactory to play for somebody who tried SC2 with its polished engine. Partnership with Day[9] might be just the thing that they need. Graphics are passable, but it's enough. Many players play SC2 on low graphics for readability of screen already.
I saw this over on /r/starcraft the other day; as a massive fan of Day[9] I hope his input will be enough to create the F2P RTS that so many want. Balanced, fun, reasonably fast paced... We don't know much about what he's planning but we'll see!
Meanwhile, back to the ladder. Grandmaster can't be too far off... ;)
Meanwhile, back to the ladder. Grandmaster can't be too far off... ;)
I will be exceedingly impressed if they pull this off. RTS is probably the gaming genre that offers the most "interesting" problems in programming, and thus is the one that needs the most computing power beyond simply showing stuff on the screen.
Pathfinding is Hard. Maintaining sync is Hard. Unit AI is Hard. And keeping those performant is doubly so, especially using JS.
So yeah, I'll be impressed if they get anything playable out of this.
Pathfinding is Hard. Maintaining sync is Hard. Unit AI is Hard. And keeping those performant is doubly so, especially using JS.
So yeah, I'll be impressed if they get anything playable out of this.
I think the reasoning behind using an RTS is likely that the company wants people to write inherently online games on their platform as part of whatever monetization strategy they have - and the other big alternatives are the MMO and MOBA genres, which would need a lot of content to be made. Having a couple of bright programmers on call - the designer is both a Starcraft celebrity and a mathematics nerd, so he likely can chip in too- would no doubt be cheaper than hiring enough artists/character designers or voice/motion capture actors to make a respectable game in some known hardcore online game genre...
I'm not sure I'd that path-finding and maintaining sync are hard problems, especially since they are problems that in an RTS aren't quite as sensitive to latency.
Ask anyone who's ever worked on an RTS and they'd disagree with you. It's not even difficult to find evidence to support them being tough problems by googling it:
https://www.google.com/search?q=rts+pathfinding
Lots of people asking for solutions, lots of different solutions, lots of caveats.
https://www.google.com/search?q=rts+pathfinding
Lots of people asking for solutions, lots of different solutions, lots of caveats.
Even without any search, you can come up with a lot of problems: Will you calculate an alternative route as soon as a route gets blocked? What if it is a friendly unit? Should it move to open way? What if it's already moving? What if it's too slow? What if there are more, moving to different locations with different speeds and priorities (For example: A tank going to help defend the base vs. a resource gathering vehicle)? What if the blocking unit is an enemy unit? Attack it or move around? Can I attack while moving? What if I can't move around? Can I crush it? Am I part of a formation? How to pass through a narrow path? Should formation alter?
As someone who has worked on an RTS, among other games, I think I am qualified to speak on the manner.
For starters, yes there are complex problems with lots of edge cases indeed. But not one of the many problems you suggest are computationally difficult. Now there are some computationally difficult problems to deal with in an RTS but those are not among them.
Additionally, a large amount of the problems you just listed are common among any game with AI. RTS pathfinding is hard, but so is pathfinding an an FPS, and then add in how much more complicated a level is in a game such as Assassin's Creed, to the more simplified structures you can manage in an RTS, and it's easy to see why this isn't simply a matter of RTS games being simply more difficult.
And within an RTS there very many problems that are much easier, both from a complexity, and computationally then in other games. Visibility determination is one thing in particular that's considered super difficult, and very performance sensitive, that's very easy to solve with the fixed perspective of an RTS.
And then there is networking, in which case you can use a lock-step model in RTS due to being less sensitive to latency, that both vastly simplifies networking. And also makes it possible to synchronize the large amount of units in an RTS with minimal bandwidth.
For starters, yes there are complex problems with lots of edge cases indeed. But not one of the many problems you suggest are computationally difficult. Now there are some computationally difficult problems to deal with in an RTS but those are not among them.
Additionally, a large amount of the problems you just listed are common among any game with AI. RTS pathfinding is hard, but so is pathfinding an an FPS, and then add in how much more complicated a level is in a game such as Assassin's Creed, to the more simplified structures you can manage in an RTS, and it's easy to see why this isn't simply a matter of RTS games being simply more difficult.
And within an RTS there very many problems that are much easier, both from a complexity, and computationally then in other games. Visibility determination is one thing in particular that's considered super difficult, and very performance sensitive, that's very easy to solve with the fixed perspective of an RTS.
And then there is networking, in which case you can use a lock-step model in RTS due to being less sensitive to latency, that both vastly simplifies networking. And also makes it possible to synchronize the large amount of units in an RTS with minimal bandwidth.
I think I understand. I still play AoEII only so I wouldn't know Assassin's Creed. My idea is that it would be complicated if you have massive amount of units. The calculation could be very expensive when most units are moving. As I said, that's just my idea because I'm not a game developer.
This looks really great. I just think the claims of "console quality" or "AAA quality" (which I heard associated with Day[9]'s announcement) are a bit disingenuous.
I'm excited that you guys are pushing browser gaming, and what you've done so far looks great. Just please don't fall into the trap of over hyping and then disappointing customers.
I'm excited that you guys are pushing browser gaming, and what you've done so far looks great. Just please don't fall into the trap of over hyping and then disappointing customers.
CEO here: Thanks for the feedback. 'Console quality' and 'AAA' are very subjective and we totally understand your points. Our job is to make Atlas and anything on our platform objectively feel amazing and please keep in touch with us.
> Everyone deserves empathy and respect.
Respect for putting that on your company page. It's good to see core values like these!
Respect for putting that on your company page. It's good to see core values like these!
What are you going to sell - games and/or technology?
Dude, you should totally have a look at http://clara.io It is a perfect compliment to Artillery in that we are a web-based 3D content creation platform -- but we are distinctly not a game engine or a game editor. We would love to partner with you and I think there are a ton of opportunities.
Please stop spamming. I think you can find their email at the site.
Are you looking to make this run well on mobile too?
There are 2 main advantages of web over native games. The first is being able to quickly jump in and play with a friend. The second is being cross platform including all mobile devices.
These 2 reasons are why I'm building my multiplayer tower defense game http://www.towerstorm.com in javascript. I'd be interested in trying out your engine if you're looking to make it run fast on mobile along with PC.
There are 2 main advantages of web over native games. The first is being able to quickly jump in and play with a friend. The second is being cross platform including all mobile devices.
These 2 reasons are why I'm building my multiplayer tower defense game http://www.towerstorm.com in javascript. I'd be interested in trying out your engine if you're looking to make it run fast on mobile along with PC.
I'm also building a javascript game (I'm using canvas and 2d images). All the comments here are freaking me out a bit. They all keep saying that html5 games are too slow. My game has many significant features done and it seems to run fine. But I'm using tiny sprites, very few animation frames and probably 10% of the artwork I intend on having in the end.
How's your experience with your game? Is it really slow or does it run fine? I'm asking regarding all platforms.
How's your experience with your game? Is it really slow or does it run fine? I'm asking regarding all platforms.
The other comments are really talking about complex 3D games which is valid (for now at least). Tower Storm is far simpler than this and runs perfectly on PC's and runs great on most high end phones released in the last 2 years (iPhone 4+ and Galaxy Nexus+). I've even got it running on the Firefox OS phone (1Ghz cpu, 512MB Ram, 480 x 320 res) but it slows down significantly late game.
However it has taken some time to optimize the code to run fast enough on all these devices. The main issues I've come across are normal game algorithm issues (using a quadtree to find nearby minions, using hashmaps instead of arrays for some data that is always searched by id etc) and garbage collection. Garbage collection has been an annoying issue which I've somewhat solved by using entity pools. So instead of creating new entities and deleting them when they die a pool of entities is created at the beginning. Then upon creation each entity is pulled from that pool and after it dies all its variables is reset back to zero and it is placed back in the pool to be used again later. This uses up a lot more memory but it means the game doesn't have a large CPU spike every few seconds as it does garbage collection.
Canvas performance may be an issue once I turn it into an iPhone app as I've heard the canvas app renderer has far worse performance than the browser renderer (I have no idea why), but I'll cross that bridge when I get to it.
So in summary I think it's fine for simple casual 2D games that don't have complex logic (using A* algorithms to move large groups of units may be too much, or having advanced AI). But anything designed to appeal to hardcore gamers who need 60+ FPS and want in depth gameplay may be a bit much for it for now.
However it has taken some time to optimize the code to run fast enough on all these devices. The main issues I've come across are normal game algorithm issues (using a quadtree to find nearby minions, using hashmaps instead of arrays for some data that is always searched by id etc) and garbage collection. Garbage collection has been an annoying issue which I've somewhat solved by using entity pools. So instead of creating new entities and deleting them when they die a pool of entities is created at the beginning. Then upon creation each entity is pulled from that pool and after it dies all its variables is reset back to zero and it is placed back in the pool to be used again later. This uses up a lot more memory but it means the game doesn't have a large CPU spike every few seconds as it does garbage collection.
Canvas performance may be an issue once I turn it into an iPhone app as I've heard the canvas app renderer has far worse performance than the browser renderer (I have no idea why), but I'll cross that bridge when I get to it.
So in summary I think it's fine for simple casual 2D games that don't have complex logic (using A* algorithms to move large groups of units may be too much, or having advanced AI). But anything designed to appeal to hardcore gamers who need 60+ FPS and want in depth gameplay may be a bit much for it for now.
I am building an HTML5 game (canvas/2D) that is distributed both online and on mobile. It is asset heavy with total assets weighing in around 600 MB, with an initial download around 7 MB and progressive loading as the player advances. Sprites are relatively large and a fair bit of animation and effects can be going on at one time, although I try to keep scenes static to cut down on rendering. I am happy with performance, both on mobile and desktop browsers. You are welcome to check it out for reference: http://www.webworks.dk/enginetest
It's been a while since I've played games like this, but if I could just point my modern browser to a URL, subscribe for a few bucks a month, and start playing, I might just start again.
Whoa, that looks really sweet. I especially liked how simple the dev tools looked, is that in the browser as well?
Yep, all of the action you see runs in a browser -- except for the console command that uploads assets to the CDN.
How does the artillery platform work? How can we use it and what will it cost us? It looks awesome :D
Do you have a planned payment model for the game, or is it still too early?
Yep, it will indeed be free to play. Sean (Day9) discussed it a little on a Reddit thread a few weeks ago: http://www.reddit.com/r/starcraft/comments/1lsgyz/day9_is_ma...
Does anyone know how they're going to lock the cursor into the browser window?
A common feature required for RTS games is being able to just push your cursor to the edge of the screen to move your viewport. (Since it's played full-screen.) It seems like a browser game would be missing this key feature.
A common feature required for RTS games is being able to just push your cursor to the edge of the screen to move your viewport. (Since it's played full-screen.) It seems like a browser game would be missing this key feature.
Indeed! Mouse scroll in Project Atlas works pretty well at the moment. We aren't using the Pointer Lock API yet due to some input latency problems. A related Chromium issue is here: https://code.google.com/p/chromium/issues/detail?id=168459
https://developer.mozilla.org/en-US/docs/WebAPI/Pointer_Lock
:-) Developed at Seneca College in Toronto, Canada.
:-) Developed at Seneca College in Toronto, Canada.
Browser can request cursor control
Who is "Artillery"? By the headline, it sounds like that's a company I should know.
Artilley is the platform/engine on which game is built and it is also name of the company behind the platform and the game (https://artillery.com/team)
this is awesome. and wow they have been busy. devotees will remember the bomberman clone 'powderkeg' that was on the front page about a year ago. i'm even more impressed by the progress than the tech.
new favorite platform, and hopefully new favorite RTS.
new favorite platform, and hopefully new favorite RTS.
Wow. I wish I had even just half the talent of HTML/CSS/Javascript to pull something off of this calibre. I am really impressed, I can't wait to get my hands on this and deconstruct how they did it the best I can and play it too.
I think you should pickup openGL/webGL instead of that other stuff, if you are serious and not trolling. Because I really can't tell at this point in the thread.
No trolling whatsoever. My day job is as a web developer, so I really meant it when I said I wish I could do cool things like this, but given the fact I work a 9/10 hour day, 5 days a week and have family and freelance commitments learning something as complicated as this isn't really within my capability at the moment.
I'll just remain appreciating what these developers have been able to do from a distance until I can learn the basics myself. Programming these games is only half the work, it's the art direction, storyline and mechanics that make up the other 50% of the work to make a game in any language or framework.
I'll just remain appreciating what these developers have been able to do from a distance until I can learn the basics myself. Programming these games is only half the work, it's the art direction, storyline and mechanics that make up the other 50% of the work to make a game in any language or framework.
Ok, thanks for the follow up. It can be easier and less daunting than it looks, and I totally get your description on how you feel about it at this point. Having your background in webdev you are closer to being able to do it than you may think.
If you take a look at something like the Haxe language (hard ECMA influence so not that far away from javascript) with its OpenFL framework, there are these: https://github.com/dazKind/foo3D
https://github.com/wighawag/openfl-stage3d
The first produces html5 and abstracts a lot of the complexity of the low level that other approaches are based on. The second is more c++ oriented at this point. Hope it helps, or at least leads you to finding your own path to doing it. It also allows you to escape some of the js madness that happens when you interact with this stuff for browser output. It allowed me to get to a level of production that I could not imagine possible just by looking at the opengl stuff.
The first produces html5 and abstracts a lot of the complexity of the low level that other approaches are based on. The second is more c++ oriented at this point. Hope it helps, or at least leads you to finding your own path to doing it. It also allows you to escape some of the js madness that happens when you interact with this stuff for browser output. It allowed me to get to a level of production that I could not imagine possible just by looking at the opengl stuff.
This looks incredible, well done. Maybe I can end my search for a modern Myth?
Looks good. I personally really really hate installing any crap on my computer or phone (apps). If it works just as regular web-site using browser only, it's just perfect.
What does being a "hardcore RTS" mean?
I assume they use it interchangeably with "e-sport capable"
I interpret it as "Don't bother unless you can pour hundreds of hours into it".
RTS = real-time strategy. By "hardcore" they probably mean lots of fiddling and attention to detail will help you win games.
Whoa awesome and very well funded it seems.
I think Artillery.com would be a natural partner for our WebGL-based 3D content creation platform. They should check it out at http://clara.io Similar to how Unity3D is a natural partner to the desktop 3D content creations tools like Max/Maya.
I think Artillery.com would be a natural partner for our WebGL-based 3D content creation platform. They should check it out at http://clara.io Similar to how Unity3D is a natural partner to the desktop 3D content creations tools like Max/Maya.
How does real-time multiplayer work in the browser when there's no support for UDP?
TCP is great for RTS games as most use lock step networking so they need to have zero packet loss. UDP is better for First person shooters and fast action games where dropping a few packets isn't the end of the world.
Interestingly, the demo video hints that they are using CoffeeScript (see the `./publish.coffee` command in terminal toward the end). Can anyone comment about whether this is actually the case?
Yes, the command "publish.coffee" is a CoffeeScript tool which publishes a given game target to the CDN. The different colorful letters represent the state of each asset as it moves through the upload pipeline, e.g. "U" for unchanged and "F" for finished.
Our engine and Project Atlas are written entirely in CoffeeScript, but that's not a requirement of game code.
Our engine and Project Atlas are written entirely in CoffeeScript, but that's not a requirement of game code.
Can you comment about your experience using CoffeeScript? Personally, I'd love to see a whole blog post about that. :-)
Totally. I've got a "18 Months of CoffeeScript" post drafted, in fact. Keep an eye on our blog :)
Have you heard of ToffeeScript? It adds a nicer sync syntax as an alternative to nested callbacks. please take a look. I have been using it a lot but I am sort of concerned that no one knows about it so I am trying to promote it everywhere.
This is what I have been waiting for...
The music in that video was quite catchy. Anyone know what its name is?
Are you going to sell your engine and toolchain too?
What is it with these militaristic company names? Artillery, Firebase, etc. Or is it just my European mindset?
It's a strategy game; artillery is going to be a key part. It's no different from a racing game called "driver" or a platform game called "jump".
European, as in "shaped by the most peaceful continent in the history of Earth"?
[disclaimer: I'm originally from Europe, so this is self-criticism]
[disclaimer: I'm originally from Europe, so this is self-criticism]
Congratz Ian! GL;HF
[deleted]
Wow! This is mesmerizing.
These posts on HTML5 stuff that pop-up on HN from time to time hint on what is to come on the web in the near term. I think HTML5 is a huge Tsunami gathering energy and steam out there! It will and should beat all these "I-am-the-best" closed systems (already does in some areas) sometime soon, and be on the top.
System agnostic, immersive, inclusive, what not. Love it.
These posts on HTML5 stuff that pop-up on HN from time to time hint on what is to come on the web in the near term. I think HTML5 is a huge Tsunami gathering energy and steam out there! It will and should beat all these "I-am-the-best" closed systems (already does in some areas) sometime soon, and be on the top.
System agnostic, immersive, inclusive, what not. Love it.
We may be seeing the same HTML5 demos on HN, but we're living in two different universes. In my world, I always open up these demos in a browser that's incompatible. If I do manage to get them working, my reaction is always like wow, I saw better native demos 10 years ago, and those just worked.
Let's be honest. JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of. As a gamer, performance is critical and stuttering ubiquitous in HTML5 games is unacceptable.
For a gamer who disables mouse acceleration, had a CRT until low latency gaming LCDs were available, and tracks his Star Craft APM, what does HTML 5 buy me other than performance issues?
Let's be honest. JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of. As a gamer, performance is critical and stuttering ubiquitous in HTML5 games is unacceptable.
For a gamer who disables mouse acceleration, had a CRT until low latency gaming LCDs were available, and tracks his Star Craft APM, what does HTML 5 buy me other than performance issues?
It's easy to talk trash on a technology that is in its infancy. Wait... WebGL games are still not as good as game engines that have been developed for 20 years? SHOCKER.
The technology is only going to get better. The whole point of these demo's is to show what is possible even now when the specs aren't finalized and the technology is barely adopted. Give it 3-5 years and I would be willing to bet you'll need to eat your words.
The technology is only going to get better. The whole point of these demo's is to show what is possible even now when the specs aren't finalized and the technology is barely adopted. Give it 3-5 years and I would be willing to bet you'll need to eat your words.
> Wait... WebGL games are still not as good as game engines that have been developed for 20 years? SHOCKER.
That's the point, isn't it? We already have all these fast, battle-tested game engines Heck, we have 15-year-old game engines that run on the browser (or do Flash games no longer count?). Is it really worth it to toss all that out and switch to WebGL?
That's the point, isn't it? We already have all these fast, battle-tested game engines Heck, we have 15-year-old game engines that run on the browser (or do Flash games no longer count?). Is it really worth it to toss all that out and switch to WebGL?
> The technology is only going to get better
Used to think that when I was high on WebGL in summer 2011. Sure some progress was made since then but really not as much as I expected. I really thought "by 2013 this will run on ALL browsers and on MOST mobile devices out-of-box, no config flags needed". We're still not there yet by a long shot.
So you're saying it'll be another 3-5 years? That's cool by me, I'll check back in 3-5 years then. This stuff is easy enough to pick up for anyone who has a grasp on basic modern OpenGL workings anyway..
Used to think that when I was high on WebGL in summer 2011. Sure some progress was made since then but really not as much as I expected. I really thought "by 2013 this will run on ALL browsers and on MOST mobile devices out-of-box, no config flags needed". We're still not there yet by a long shot.
So you're saying it'll be another 3-5 years? That's cool by me, I'll check back in 3-5 years then. This stuff is easy enough to pick up for anyone who has a grasp on basic modern OpenGL workings anyway..
I think there are two different points which kind of render the comparison difficult to make:
- html5 games are defacto multiplatforms, since tbey must support all the popular browsers, and underlying systems (mobiles, tablets, PCs...). Compare this with the Wintel supremacy of early RTS days,
- This is technology preview material, available to a potentially very large audience. I don't think RTS did get such exposure during their development, especially during the eary days, when people wanted to disclose as little as possible to the listening competition in the gaming news channels (nainly magazines).
- html5 games are defacto multiplatforms, since tbey must support all the popular browsers, and underlying systems (mobiles, tablets, PCs...). Compare this with the Wintel supremacy of early RTS days,
- This is technology preview material, available to a potentially very large audience. I don't think RTS did get such exposure during their development, especially during the eary days, when people wanted to disclose as little as possible to the listening competition in the gaming news channels (nainly magazines).
There are some absolutely amazing HTML5 / WebGL things out there; I'm just not sure you've seen them. It's true that browser incompatibility is an issue, but say you're ONLY targeting Chrome desktops, which still has a bigger user base than most consoles--if you're doing it right you're getting hardware accelerated graphics and the performance is pretty great. Have you seen cloudparty.com? It has multiplayer in-world building, skeletal animation, particles, full screen effects... the works, and the performance is definitely up to snuff. Observe tons of realtime screencasts here: http://www.youtube.com/user/CloudPartyInc
I think that the problem is that WebGL is young and there are LOTS of ways to shoot yourself in the foot perf-wise. Only a few teams have really figured it out and the rest are making the tech look bad. But the performance is there if you're an experience graphics programmer and you know your way around JS wackiness.
I think that the problem is that WebGL is young and there are LOTS of ways to shoot yourself in the foot perf-wise. Only a few teams have really figured it out and the rest are making the tech look bad. But the performance is there if you're an experience graphics programmer and you know your way around JS wackiness.
After going through a few of those examples, the performance really isn't that good. For example, in Chrome my computer struggles to run "The Isle of Yosemite" in 1650x1050 at 30fps when looking at a fair bit of geometry. Yet I can easily play Battlefield 3 or Natural Selection 2 at 30fps, and the gulf in image quality, how much is in a given scene, and how much game logic there is is enormous.
Thus far, HTML5 games seem more like a replacement for basic 3D flash games more than anything. Whether that will change at some point in the future I don't know, but at this point I have not really been wowed by anything.
Thus far, HTML5 games seem more like a replacement for basic 3D flash games more than anything. Whether that will change at some point in the future I don't know, but at this point I have not really been wowed by anything.
"...absolutely amazing HTML5 / WebGL things out there..."
In the end of the day it's just a script running on top of Open GL.
In the end of the day it's just a script running on top of Open GL.
> In my world, I always open up these demos in a browser that's incompatible. If I do manage to get them working
I, too, like to strip naked outdoors in a Chicago winter and then complain about how the city isn't keeping its streets reasonably well-heated.
I, too, like to strip naked outdoors in a Chicago winter and then complain about how the city isn't keeping its streets reasonably well-heated.
I've come across browser games a number of times that wouldn't work in my regular browser, requiring me to switch to another one I have installed. Your analogy is not very apt.
Also unlike Steam you might have to re-download the whole thing if your browser decides to clear the cache for whatever reason. Can't play underground, on a plane or while camping as well (not a typical scenario though - nitpicking a bit).
There's work going on for better app caching systems at the browser level. This is a UI and platform issue, but there's no tricky technical aspects. The user expresses the intent of wanting to cache a web app, and it is cached locally.
"The user expresses the intent of wanting to cache a web app, and it is cached locally."
So I will use [x] to find a game in [y] and then [z] it to play.
Where: x = {Chrome|Firefox|Steam}, y = {some-sort-of-web-app-store|Steam store}, z = {cache|install}.
I guess the success will depend on how easy and rich x-y-z experiences are, but you will still have to register, pay and download.
So I will use [x] to find a game in [y] and then [z] it to play.
Where: x = {Chrome|Firefox|Steam}, y = {some-sort-of-web-app-store|Steam store}, z = {cache|install}.
I guess the success will depend on how easy and rich x-y-z experiences are, but you will still have to register, pay and download.
But crucially you will be able to buy on the app using x,y,z, and continue to play the app using a,b,c from different hardware/software vendors, unlike the situation today with say a game bought on a mac.
That's the advantage of the web over native APIs, and why I think its ethos will eventually win out - it is better for developers and users, but not for the corporations who would like to sit between the two as intermediaries.
That's the advantage of the web over native APIs, and why I think its ethos will eventually win out - it is better for developers and users, but not for the corporations who would like to sit between the two as intermediaries.
Not when deployed with something like node-webkit which I would assume would be a common deployment strategy so you can guarantee Chrome and a certain version w/ certain features enabled/disabled.
JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of
They are, but I very much doubt these guys are using the DOM or CSS. And if they're using asm.js then they're using a very different JavaScript, too.
They are, but I very much doubt these guys are using the DOM or CSS. And if they're using asm.js then they're using a very different JavaScript, too.
I was talking about HTML5 demos posted on HN. Like this one that DOES use CSS:
http://www.keithclark.co.uk/labs/css3-fps-new/
Granted, it's a terrible abuse of a CSS, but it's also a perfect example of how I'm supposed to be wowed by a buggy HTML5 demo my PC could render better in every way 15 years ago.
And no one has answered my question yet. What benefit does HTML5 bring me as a gamer? Why are HTML5 games better than native games in my steam library, especially considering DSL is my only option for Internet here?
Granted, it's a terrible abuse of a CSS, but it's also a perfect example of how I'm supposed to be wowed by a buggy HTML5 demo my PC could render better in every way 15 years ago.
And no one has answered my question yet. What benefit does HTML5 bring me as a gamer? Why are HTML5 games better than native games in my steam library, especially considering DSL is my only option for Internet here?
The same benefit the web apps generally bring:
* The ability to play the game without installing anything
* The ability to play the game on other peoples computers
* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)
* The ability to play the game without installing anything
* The ability to play the game on other peoples computers
* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)
* The ability to play the game without installing anything
Obviously you haven't played any HTML5 games. They all make you wait to download game data. And if the Internet gods have been good to you, it won't be cleared from your localstorage next time you start it up. Steam is far better.
* The ability to play the game on other peoples computers
So can Steam.
* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)
10-20% of the games on Steam have Linux ports, and most of the others run fine under Wine.
So 2/3 are better on Steam and the 3rd is primarily a benefit for the developer.
Obviously you haven't played any HTML5 games. They all make you wait to download game data. And if the Internet gods have been good to you, it won't be cleared from your localstorage next time you start it up. Steam is far better.
* The ability to play the game on other peoples computers
So can Steam.
* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)
10-20% of the games on Steam have Linux ports, and most of the others run fine under Wine.
So 2/3 are better on Steam and the 3rd is primarily a benefit for the developer.
Apples and Oranges are being compared here. The difference between Steam and web games is like the difference between video files and Youtube. Youtube is always of inferior quality, but it can play almost anywhere anytime. You don't need a windows machine with administrative rights.
[deleted]
HTML5 may not bring any benefit to you as a gamer, but it has the potential to bring the games to millions of other people who don't use Steam.
I don't see HTML5 being used for creating cutting edge games. I do see it being used to create smaller, less graphically intense games that easily hook users.
I don't see HTML5 being used for creating cutting edge games. I do see it being used to create smaller, less graphically intense games that easily hook users.
>> What benefit does HTML5 bring me as a gamer? Why are HTML5 games better than native games in my steam library, especially considering DSL is my only option for Internet here?
more people making games and more people playing them. i don't think anyone thinks the browser is the end all be all platform to deliver a game. just like some games run on OS X and some don't, and some games are on Steam and some are not. some games will be in the browser and some won't.
i hear you on the technical concerns. lots of problems. but the vendors recognize this and have a vested interested in fixing it.
ps - how can we start an hn sc2 group
more people making games and more people playing them. i don't think anyone thinks the browser is the end all be all platform to deliver a game. just like some games run on OS X and some don't, and some games are on Steam and some are not. some games will be in the browser and some won't.
i hear you on the technical concerns. lots of problems. but the vendors recognize this and have a vested interested in fixing it.
ps - how can we start an hn sc2 group
Think about why we build browser apps instead of native apps today. All those reasons apply.
Because it's easier, so the programmers to build those apps are cheaper?
Not a really good rationale when it comes to game development.
Not a really good rationale when it comes to game development.
[deleted]
> I saw better native demos 10 years ago, and those just worked.
Agreed. But you're missing the point. In those 10 years those of us who played in the native universe will not be the target market any more. Just like we listeners of Pink Floyd and Metallica aren't the target buyers of Justin Biebers and Lady Gagas of the day. The latter are as successful, immersive and relevant to those who matter.
> JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of.
Now this is an opinion based on the current_level_of_performance (which I agree is not at the expected level.). But it's not a great way to judge what the future could hold. It's definitely a bet, like you said let's be honest with this.
Agreed. But you're missing the point. In those 10 years those of us who played in the native universe will not be the target market any more. Just like we listeners of Pink Floyd and Metallica aren't the target buyers of Justin Biebers and Lady Gagas of the day. The latter are as successful, immersive and relevant to those who matter.
> JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of.
Now this is an opinion based on the current_level_of_performance (which I agree is not at the expected level.). But it's not a great way to judge what the future could hold. It's definitely a bet, like you said let's be honest with this.
>Now this is an opinion based on the current_level_of_performance (which I agree is not at the expected level.). But it's not a great way to judge what the future could hold.
Native will always fundamentally beat non-native, that's a plain fact.
Native will always fundamentally beat non-native, that's a plain fact.
Native will always fundamentally beat non-native, that's a plain fact.
Consider the barriers to browser performance:
Hardware acceleration - already there with WebGL and for video codecs The JS language - this can be swapped out for something more performant - various options exist but it will take time and a brave vendor to do so. Rendering speed of HTML etc - this can be improved, both by simplifying things like the box model and by improving the renderer, we've already made huge strides int this area for standard UIs.
These are solvable problems - eventually web properties could easily be compiled (in a sandboxed language or VM), and become native. I don't think there's necessarily a difference between a sandboxed process in a browser VM, and a sandboxed process on the desktop. Just because browsers are still developing and in the past have not been performant in comparison to native APIs, doesn't mean things always have to be that way. So while the present performance comparison of native to HTML means native wins (as long as you don't just do everything in webgl say), things don't have to stay that way.
The greatest strength of the web platform is that it is simple, open, and extensible. This also makes it a bit of a mess of competing standards and leads to a problem with legacy cruft (like the reliance on JS), but it has held up remarkably well, and has proven flexible, simple and incredibly popular. It's difficult to charge people money for content on the web, but not impossible and that's more to do with culture than technical challenges. It's also difficult to lock people in on the web - that's something people hate about native which isn't going away.
Eventually I expect the internet, and the web in particular, will reduce operating systems to a badly debugged set of device drivers (Andreessen was prophetic in that regard), and operating systems will be replaced as a concept and become simply the interface to hardware, which implements some standard APIs for the web and acts as a container for the VM which runs the code. We're not far from that situation already, and it is preferable for consumers and creators/developers. The only thing standing in its way are the vendors of large ecosystems (hardware and software) like Google, Apple, MS and Amazon, who have a vested interest in corralling and controlling their customers and keeping them inside an area where they set the rules and can take a cut on every transaction.
I'd argue the resurgence of native mobile platforms is the last hurrah of native, and simply another attempt to lock people into an ecosystem controlled by one company, it will fail as people start to realise their loyalty to say Apple is not rewarded. We'll probably see these companies grudgingly adopt the web, while still trying to corral their customers (it's what companies do when they get to a certain scale), but on the web that is much harder to do, because it's an open API, controlled by no-one.
Consider the barriers to browser performance:
Hardware acceleration - already there with WebGL and for video codecs The JS language - this can be swapped out for something more performant - various options exist but it will take time and a brave vendor to do so. Rendering speed of HTML etc - this can be improved, both by simplifying things like the box model and by improving the renderer, we've already made huge strides int this area for standard UIs.
These are solvable problems - eventually web properties could easily be compiled (in a sandboxed language or VM), and become native. I don't think there's necessarily a difference between a sandboxed process in a browser VM, and a sandboxed process on the desktop. Just because browsers are still developing and in the past have not been performant in comparison to native APIs, doesn't mean things always have to be that way. So while the present performance comparison of native to HTML means native wins (as long as you don't just do everything in webgl say), things don't have to stay that way.
The greatest strength of the web platform is that it is simple, open, and extensible. This also makes it a bit of a mess of competing standards and leads to a problem with legacy cruft (like the reliance on JS), but it has held up remarkably well, and has proven flexible, simple and incredibly popular. It's difficult to charge people money for content on the web, but not impossible and that's more to do with culture than technical challenges. It's also difficult to lock people in on the web - that's something people hate about native which isn't going away.
Eventually I expect the internet, and the web in particular, will reduce operating systems to a badly debugged set of device drivers (Andreessen was prophetic in that regard), and operating systems will be replaced as a concept and become simply the interface to hardware, which implements some standard APIs for the web and acts as a container for the VM which runs the code. We're not far from that situation already, and it is preferable for consumers and creators/developers. The only thing standing in its way are the vendors of large ecosystems (hardware and software) like Google, Apple, MS and Amazon, who have a vested interest in corralling and controlling their customers and keeping them inside an area where they set the rules and can take a cut on every transaction.
I'd argue the resurgence of native mobile platforms is the last hurrah of native, and simply another attempt to lock people into an ecosystem controlled by one company, it will fail as people start to realise their loyalty to say Apple is not rewarded. We'll probably see these companies grudgingly adopt the web, while still trying to corral their customers (it's what companies do when they get to a certain scale), but on the web that is much harder to do, because it's an open API, controlled by no-one.
A couple of things:
Most things running on the desktop aren't sandboxed. Whether they should be or not is a different matter.
Hardware acceleration will by necessity be limited when one is required to sandbox, as in a web browser. It's the difference between accessing an array item by "arr[i]" and accessing an array item by "if i>arr.len || i < 0: crash, else arr[i]". Some checks can be compiled out, but some cannot. And there will always be cases where a human can identify that something cannot happen but a compiler cannot prove it. Look at the number of cases in the Linux kernel where there's assembly macros, for example.
As for the web being a "simple, open, and extensible" platform, I'd argue otherwise. Simple? Have you looked at the amount of mostly-duplicated css required to just do a simple cross-browser gradient? Open? Good luck using anything besides HTML/javascript/CSS. Even Java is blocked by default now. Extensible? Only if by extensible you mean "you can have any language you want, as long as it's javascript."
I agree that native locked-down mobile platforms are the worst of all worlds. That being said, I don't see why non-locked-down native platforms are bad.
Most things running on the desktop aren't sandboxed. Whether they should be or not is a different matter.
Hardware acceleration will by necessity be limited when one is required to sandbox, as in a web browser. It's the difference between accessing an array item by "arr[i]" and accessing an array item by "if i>arr.len || i < 0: crash, else arr[i]". Some checks can be compiled out, but some cannot. And there will always be cases where a human can identify that something cannot happen but a compiler cannot prove it. Look at the number of cases in the Linux kernel where there's assembly macros, for example.
As for the web being a "simple, open, and extensible" platform, I'd argue otherwise. Simple? Have you looked at the amount of mostly-duplicated css required to just do a simple cross-browser gradient? Open? Good luck using anything besides HTML/javascript/CSS. Even Java is blocked by default now. Extensible? Only if by extensible you mean "you can have any language you want, as long as it's javascript."
I agree that native locked-down mobile platforms are the worst of all worlds. That being said, I don't see why non-locked-down native platforms are bad.
There are good points, though I would say they're not insurmountable in most cases. I think desktop is moving towards sandboxed too, and will inevitably become more restrictive following Apple's lead. I think that's a good thing and we have the resources now to get that increased security without losing much performance.
Simple - I do think the simplicity of the web is is its greatest strength - it does limit what you can do with the web, but it also means it is not too hard to either produce content or create a browser (though nowadays the browser part is pretty challenging). CSS gradients are a good example in fact of the messy web process of experimentation, consensus, and eventual convergence - you will soon be able to use the prefixless style and not worry about several prefixed versions. Personally I'm not sure prefixes are a good idea anyway, but they do go away eventually.
Open - I meant as in anyone can contribute to the standard, and any vendor can write a browser, no one party controls it, as they do native platforms. I'm quite happy Java is blocked given who controls Java :) On the server of course, you can use whatever you want, whatever framework, language and paradigm you like, which is quite liberating when compared to say creating apps for iOS.
Extensible - well the standard actually allows for other languages, and JS being the only scripting language is more a quirk of history than anything else - there have been moves to allow byte code instead (Nacl), and I suspect that's the way things are heading - to a sandboxed VM which will run any compiled language. When that happens then a huge range of languages will open up, just like server side.
That being said, I don't see why non-locked-down native platforms are bad.
The biggest reason they're bad from my point of view is that they don't cater as the web does to hardware not invented yet (as the web does), obsolete hardware, or to other hardware platforms and are locked-in to a particular chip and instruction set, even if not locked down to an API. The other disadvantage is that you are locked in to whatever API (and typically language) the platform has chosen - everything must be written with that language, or with glue code interfacing to that language.
That's the big difference with the web - it defines a limited reference platform (the browser) which can be made for any hardware, and anyone can target using any server side tech they want. There is a clear division between client and server, and both can change completely without invalidating the other. That's a very powerful abstraction and one which I think gives it an advantage as a platform against any native platform which rivals it.
Simple - I do think the simplicity of the web is is its greatest strength - it does limit what you can do with the web, but it also means it is not too hard to either produce content or create a browser (though nowadays the browser part is pretty challenging). CSS gradients are a good example in fact of the messy web process of experimentation, consensus, and eventual convergence - you will soon be able to use the prefixless style and not worry about several prefixed versions. Personally I'm not sure prefixes are a good idea anyway, but they do go away eventually.
Open - I meant as in anyone can contribute to the standard, and any vendor can write a browser, no one party controls it, as they do native platforms. I'm quite happy Java is blocked given who controls Java :) On the server of course, you can use whatever you want, whatever framework, language and paradigm you like, which is quite liberating when compared to say creating apps for iOS.
Extensible - well the standard actually allows for other languages, and JS being the only scripting language is more a quirk of history than anything else - there have been moves to allow byte code instead (Nacl), and I suspect that's the way things are heading - to a sandboxed VM which will run any compiled language. When that happens then a huge range of languages will open up, just like server side.
That being said, I don't see why non-locked-down native platforms are bad.
The biggest reason they're bad from my point of view is that they don't cater as the web does to hardware not invented yet (as the web does), obsolete hardware, or to other hardware platforms and are locked-in to a particular chip and instruction set, even if not locked down to an API. The other disadvantage is that you are locked in to whatever API (and typically language) the platform has chosen - everything must be written with that language, or with glue code interfacing to that language.
That's the big difference with the web - it defines a limited reference platform (the browser) which can be made for any hardware, and anyone can target using any server side tech they want. There is a clear division between client and server, and both can change completely without invalidating the other. That's a very powerful abstraction and one which I think gives it an advantage as a platform against any native platform which rivals it.
> Native will always fundamentally beat non-native, that's a plain fact.
The problem of WebGL is simply it has very low penetration. By my research, currently only 35% of desktop users can use WebGL with GPU acceleration (FYI, Flash 10: 95%, Flash 11: 75%; Flash 11(Stage3D with GPU): 70%). Now that IE11 is supporting WebGL, this might be a matter of time. However I foresee it would take 5 years or so to achieve 80%.
And, note that WebGL only has functions of OpenGL ES 2.0. Currently WebGL2, which has functions of OpenGL ES 3.0 is being developed. On the other hand, native games already utilize OpenGL 4.x. What API is used in native games when WebGL2 becomes popular? I imagine raster-based rendering might be obsolete at that time.
And I think people already know the web can't handle Oculus Rift, probably one of the most interesting, innovative and fun gadget in this decade. Of course you can use it on browsers with a NPAPI plugin. Oh, hey, the web people said plugin is obsolete and evil! Don't use plugins!!! Don't play with Oculus Rift, you, PLEASE!!!
I admit the web platform has some value on some points, but if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.
The problem of WebGL is simply it has very low penetration. By my research, currently only 35% of desktop users can use WebGL with GPU acceleration (FYI, Flash 10: 95%, Flash 11: 75%; Flash 11(Stage3D with GPU): 70%). Now that IE11 is supporting WebGL, this might be a matter of time. However I foresee it would take 5 years or so to achieve 80%.
And, note that WebGL only has functions of OpenGL ES 2.0. Currently WebGL2, which has functions of OpenGL ES 3.0 is being developed. On the other hand, native games already utilize OpenGL 4.x. What API is used in native games when WebGL2 becomes popular? I imagine raster-based rendering might be obsolete at that time.
And I think people already know the web can't handle Oculus Rift, probably one of the most interesting, innovative and fun gadget in this decade. Of course you can use it on browsers with a NPAPI plugin. Oh, hey, the web people said plugin is obsolete and evil! Don't use plugins!!! Don't play with Oculus Rift, you, PLEASE!!!
I admit the web platform has some value on some points, but if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.
* if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.*
I don't think anyone could argue that - the web is a messy consensus, and definitely doesn't include cutting edge, innovative tech (except perhaps server-side if you want). That's not its strong point but I think the other points in its favour do make up for it.
Re WebGL, I suspect if we see killer app(s) come out using it, penetration will spread quickly and it will be kept up to date by browser makers. At present it's a bit of a chicken and egg situation.
I don't think anyone could argue that - the web is a messy consensus, and definitely doesn't include cutting edge, innovative tech (except perhaps server-side if you want). That's not its strong point but I think the other points in its favour do make up for it.
Re WebGL, I suspect if we see killer app(s) come out using it, penetration will spread quickly and it will be kept up to date by browser makers. At present it's a bit of a chicken and egg situation.
> Native will always fundamentally beat non-native, that's a plain fact.
I believe so, yes.
Assuming there will be 9 billion web users sometime into the future, non-native will be enough for most of the stuff though.
I believe so, yes.
Assuming there will be 9 billion web users sometime into the future, non-native will be enough for most of the stuff though.
Native will always fundamentally beat non-native, that's a plain fact.
In quality, perhaps. In sales, profit and market share, I'm not so sure.
In quality, perhaps. In sales, profit and market share, I'm not so sure.
I think the web or HTML5 is the most closed platform ever.
Let me explain. You want to program for the web? Javascript. You want to do 3D? we have you covered, you can only use webgl. Don't like it? Sorry but we need to remain open! want audio? We have an API for that, why would you want to use something else? use Audio API, it's open.
can you imagine if linux, or microsoft windows or OS X only understood one programming language? Or if DirectX were the only 3D thing you can use? or if to use audio, you had no choice but to use one library?
The web is just that, and no, being available on all the platforms does not make it an open platform. It's one big closed transparent prison available everywhere. Once you go in, you are stuck with the onboard equipment.
Let me explain. You want to program for the web? Javascript. You want to do 3D? we have you covered, you can only use webgl. Don't like it? Sorry but we need to remain open! want audio? We have an API for that, why would you want to use something else? use Audio API, it's open.
can you imagine if linux, or microsoft windows or OS X only understood one programming language? Or if DirectX were the only 3D thing you can use? or if to use audio, you had no choice but to use one library?
The web is just that, and no, being available on all the platforms does not make it an open platform. It's one big closed transparent prison available everywhere. Once you go in, you are stuck with the onboard equipment.
Your comment is similar to saying "to program on windows, you have to write assembly".
You can write for the web in Java, C, C++, and a bunch of other languages that all compile to JS.
The bad thing is that there will be no technology competition. Just HTML and JS for everything? Boring...
JavaScript is no longer the only language. I wouldn't be surprised if JavaScript is used at all for large projects in the future. With things like Dart, TypeScript, CoffeeScript, and asm.js JavaScript is becoming more of a compile target.
> I wouldn't be surprised if JavaScript is used at all for large projects in the future.
This is actually a scary prospect, considering how consistent JS is as a language, let alone as a bytecode replacement.
This is actually a scary prospect, considering how consistent JS is as a language, let alone as a bytecode replacement.
All it would take to replace JS would be for a large vendor maker (or ideally 2) to get behind a common byte code, and support it in parallel with JS. Suddenly a whole world of languages would open up for web use.
I expect that to happen sooner rather than later, it is not an impossible problem, and it is far preferable to trying to use JS as a compile target.
I expect that to happen sooner rather than later, it is not an impossible problem, and it is far preferable to trying to use JS as a compile target.
"Just C and C++ for everything? Boring..."
I seriously doubt that the world will stagnate at HTML and JS. Thing will evolve!
Though judging by adoption and advancements from W3C, it might be thousands of years ;).
I seriously doubt that the world will stagnate at HTML and JS. Thing will evolve!
Though judging by adoption and advancements from W3C, it might be thousands of years ;).
Definitely. It's amazing to watch a technology accelerate this quickly.
Yeah, scripting an OpenGL game engine. First time ever.
100% agreed.
>System agnostic, immersive, inclusive, what not. Love it.
Yay! Let's cheerlead the democritisation (read: degeneration) of computer programming! The "open", democratic people got everything wrong, which is why the browser has such a laughable hodge podge of features. Hooray for people who took web programming instead of OS design at college. WOOO!
Yay! Let's cheerlead the democritisation (read: degeneration) of computer programming! The "open", democratic people got everything wrong, which is why the browser has such a laughable hodge podge of features. Hooray for people who took web programming instead of OS design at college. WOOO!
> Let's cheerlead the democritisation
I think you meant democratisation, or was there some subtle reference to a [famous greek philosopher](http://en.wikipedia.org/wiki/Demokritos)?
I think you meant democratisation, or was there some subtle reference to a [famous greek philosopher](http://en.wikipedia.org/wiki/Demokritos)?
For one, C++ and the native toolchain is still more efficient. But it mostly comes down to perception and convenience. The perception of web-based games is that they're casual and cheap. And most hardcore gamers like to have a copy of the game on their computer - they paid for it, they want a copy that they can keep (and at least store on their hard drive) for years. They don't want to stop playing a game because the dev decided to end its life...
This is why platforms like Steam, Xbox, HumbleBundle, etc..., still rule for distributing games (both AAA and indie).