You can preorder PA at the Uber Store
So I'm going to ramble on a little bit here about the engine architecture for the UI of Planetary Annihilation. This is by no means a completely description, just whatever I feel like rambling about while watching the turkey get prepped.
Game UI systems are, generally speaking, a disaster. You have quite a few choices but none of them are really great. Building UI is difficult and time consuming. Combine that with whacky tools and you can end up in a pretty bad place. Furthermore one of our primary design goals it the ability for end users to mod and improve the UI, preferably in a way that allows mods to work together with each other.
What that really means is that we can't just bake the UI into some C++ code. Even a DLL system would have issues because we are cross platform. We need a flexible and extensible system for building UI that's available everywhere. Having something that is commonly used and that has a set of existing tools is also a bonus. In addition since so much of our UberNet infrastructure is web based it's required that we have a way to embed a web browser into the game client.
So given all of that, what's a logical system for us to use? We could certainly build a custom system and embed lua for example. Or we could license a 3rd party library like Scaleform and use Actionscript.
Or we could do the obvious thing and simply use a web browser as the UI system. So that's what we've chosen to do. Basically the client is a transparent web browser (webkit) window over the top of an OpenGL context. All of the front end UI and the top level game UI is being written in Javascript. Javascript while not my favorite language by any stretch has the advantage of being the most popular language on earth. It has suites of tools dedicated to it. It's got a fairly decent JIT.
So the basic idea here is that the engine exposes a set of javascript interfaces. The web browser draws all of the UI elements and also controls issuing orders, selection etc. By exposing more interfaces we can give the javascript more control and I intend to expose more than we actually use. The planetary editor is also written the same way which means it's extensible by the community as well. In fact the planetary editor is the first real UI we are doing with the system.
Early shot of some planet editor UI. Please don't consider this a style guide for the UI as this is all preliminary in terms of look and feel. Normally we would never show stuff this early but the rules have changed due to Kickstarter. The functionality in this interface will probably change dramatically over time etc etc disclaimer etc.
Overall I'm happy with this decision so far and we've already got this running on Windows/MacOS/Linux. Over the medium term I do still have some concerns about performance and how sick of a lanuage js is. In reality though I think this is going to be the way that many games do UI going forward as the web becomes ubiquitos.
I'm going to start a thread on our Forum to discuss this.
Looks/sounds great! Good luck!
ReplyDeleteFirst thought after reading : genius!
ReplyDeleteWolfire are also using webkit in Overgrowth.
ReplyDelete"Over the medium term I do still have some concerns about performance..."
ReplyDeleteThat is more or less my concern with this approach as well.
Likewise. I find Java to be very leaky in terms of CPU usage.
DeleteHehe, quite a lot wrong in that one simple statement :-)
DeleteHere, let me help you out:
1) Java is *not* the same as JavaScript. It's one of the most confusing things in computing history that they share 'Java' in their name because they're not even remotely similar. You should know which one you're talking about - in this case it's JavaScript.
2) The adjective 'leak' in computer science exclusively refers to RAM usage, not CPU usage. It refers to when an application claims memory and fails to release it properly when it's finished with it. This can result in instability and crashing when the application eventually runs out of memory completely. It's less likely to cause immediate performance issues.
3) Java and JavaScript are both proven technologies and, used properly, neither will leak memory.
4) JavaScript is more likely to suffer from performance issues as it is generally an interpreted language, that means, the script that the developer writes is read at point-of-use. In contrast, Java is a compiled language - the code the developer writes is translated to Virtual Machine code (aka Bytecode) ahead of distribution time, increasing efficiency at point of use.
That really is a great idea, and its a pitty no one else seems to have considered it.
ReplyDeleteMMO's in particular have some pretty awful UI's and World of warcraft has given people the expectation of modding. Seems like this is a far more extensible, and heck of alot easier for designers than most solutions out there currently.
Im not a fan of JS either, but we seem to be stuck with it, JS performance is also constantly improving.
This is an amazing idea. You'd be suprised in how webkit is being used as a renderer in all kinds of oddball places - places which traditionally were always very rigid, and made with great technical difficulty.
ReplyDeleteOut of curiosity, what is it about JS that makes you think it's a "sick" language? Not trying to start a language war, just curious what features (or misfeatures) you dislike.
ReplyDeleteI've not worked a whole lot in the web world, so my only experience with it has been a wariness about the whole prototyping and objects as always-mutable arrays but a fondness for the functional support (closures and first-class functions).
Oooooo JScript is pretty sweet as a Java programmer mainly This could be pretty cool Android app to accompany PA Y/Y :P like those apps currently getting more and more popular that allow you to get more strategic in just about any game :P
ReplyDeleteIt's not clear from your post but, do you know that Java is unrelated to JavaScript? It's just an unfortunate marketing mistake that they share 'Java' in their name, nothing more.
DeleteI think this is really wise. Interface has always been a challenge for mods etc - this would really open it up! That librocket project looks interesting, too.
ReplyDeleteVery nice. With alpha blended PNG files this would be super cool. And the new CSS features to.
ReplyDelete- Very nice idea.
ReplyDelete- use ecmascript strict mode to ease the pain
- keep in mind that people may want to use *-to-js compilers like dart or coffeescript (or even the google closure compiler). That shouldn't be a problem but it won't hurt keeping it in mind.
Thanks!
The line of thinking you've followed here is pretty much what we're going through with my works product. Admittedly we're aiming less for modders and more for companies that want to give their own workflow/look and feel, but it's the same basic idea. Javascript has come a LONG way from what it used to be, makes it very easy to iterate, and if you find the performance is too poor, you can move logic into the C++ side of things.
ReplyDeleteVery nice idea but I really which this could work with Lua instead of javascript.
ReplyDeleteIf only browsers shipped with python or lua instaed of javascript.
I was a big fan of the Lua UI for supreme commander.
Could you get webkit to support lua as a scripting language? :)
I think LUA would be great as well
ReplyDeleteHey, thanks for the interesting article. It's cool to hear that you guys are building your GUI system around a web browser, and I'm interested in hearing how you plan to animate things effectively with this kind of setup. Of course you can move stuff around the screen easily, but what about when it comes to more complex things? For example, how will you accomplish reasonably sophisticated lighting, or 3d stuff? How will you do cut outs and masks? I guess you could use canvas tags for anything complex, but then you're getting into the realm of adding the complexity you wanted to avoid by using this system in the first place (not to mention performance). Or will you just design the GUI around these design limitations, and let the game engine do most of the talking?
ReplyDeleteThanks again for taking the time to write this article. Can't wait to see more of what you guys are up to.
A Graphical User Interface, that requires 'sophisticated lighting' or '3D stuff' is probably a poorly thought out one ;).
DeleteIt's an interesting idea to get the cross-platform L&F that you need. But; genuine question, why wouldn't you use something like Qt: It's a mature cross-platform UI toolkit that would give you the consistent look and feel, as well as the higher performance we all desire?
ReplyDeleteYes modern JavaScript Engines have come a long way, and Web standards have matured, however the fact remains that the 'trinity' of HTML + JS + CSS was never designed as a whole, but grew organically with the needs of the web. It's far from an optimal solution for presentation in native Apps, and was never intended for triple-A graphical presentation and animation. I'm not saying it can't work: depending on the production aims of PA it could save much needed time and resources and get a decent result. But, I would never consider this to be the technically best solution. I don't mean to be negative, Uber must have their reasons - and thanks Maven for sharing what's going on with PA development. I just felt I had to write this to explain to some readers that from a purely technical point of view it's compromise; even if a reasonable and cleverly chosen one.
ReplyDelete