Live data from Hacker News

Artillery is building a hardcore RTS with HTML5 and WebGL

blog.artillery.com

141–150 of 151 posts

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#141

Earlier quoted context omitted.

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.

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 vehi…

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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#142

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.

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 program…

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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#143
post #46

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…

JS port of Box2D is dead since 2008.

https://code.google.com/p/box2dweb/ tracks box2dFlash which was last updated in 2011.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#144

Earlier quoted context omitted.

>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. 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 th…

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 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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#145

Earlier quoted context omitted.

>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. 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 th…

> 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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#146

Earlier quoted context omitted.

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 c…

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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#147
post #118

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…

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…

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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#148
post #134

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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#149

Earlier quoted context omitted.

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 th…

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 As for the web being a "simple, open, and extensible" platform, I'd argue o…

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.

Re: Artillery is building a hardcore RTS with HTML5 and WebGL

#150

Earlier quoted context omitted.

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 th…

> 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%.…

* 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.

Post reply on HN