Planetary Annihilation Engine Architecture Update #1 - UI

Re: Planetary Annihilation Engine Architecture Update #1 - U

So if you are using Webkit and Webkit can support both Javascript and Dart, would it be possible to use either one for modding?

Re: Planetary Annihilation Engine Architecture Update #1 - U

If the unit behaviours related UI mods are not prohibited in the ranked matches, then hope the server side could has a apm limiter or something similar, so we won't get any starcraft 2 micro bots like automation that would break the balance.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I think the idea is wonderful, although I don't like Javascript any more than the other ppl here.

I also suggest to the uber guys to use the ecmascript strict mode to get a slightly better behavior of the language.

Also, if *-to-js compilers work for modding like neutrino hinted, that would be awesome. Think of dart, coffeescript, there are even haskell-to-js compilers. I like it!

Re: Planetary Annihilation Engine Architecture Update #1 - U

Haven't read all the stuff in this thread, but first thing that popped to mind: Have you considered using the V8 JavaScript Engine?

http://code.google.com/p/v8/

Or instead of Web, Scaleform, etcetera: Qt?

Here's an awesome example of how the Qt GUI Designer is used to convert its result to LUA (hell, this can even be JS): http://forum.mtasa.com/viewtopic.php?f=91&t=27739

Re: Planetary Annihilation Engine Architecture Update #1 - U

I suppose the only question I have is, how well is it going to work to place UI elements in 3d space, in a manner that is highly performant?

Supcom had those range rings which they struggled with quite a bit because it just killed performance. Are we going to be able to draw on the terrain via the UI? Are we going to be able to use vector-based imagery?

Re: Planetary Annihilation Engine Architecture Update #1 - U

Yes, that would be possible, as UI's in traditional games are always a layer on top of the actual 3D canvas, using math tricks to get it all in the right position (think about names above players in FPS', it's called projecting).

Not too mention, not EVERYTHING has the be done with web-overlays, the engine itself can still take the burden of drawing circles and all, it's just the JavaScript that tells the game when and where to do it, how it should look, etcetera (the JavaScript interfaces neutrino talked about).

Re: Planetary Annihilation Engine Architecture Update #1 - U

And yet, most huds are blue, most people like blue, and starcraft and halo and such.

Personally, I am in that catergory. Xept the starcraft and halo part.

Either way, I don't see what you COULDN'T change with this system. So you could have it pink and purple with MLP graphics if desired.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I share those concerns. While webkit is one of the faster browser engines, it still might be unable to render a fully dynamic HUD fast enough.

This approach is great when you want to present styled GUIs with forms and alike, or short term: If you use the browser engine for tasks you could solve with a regular website.

But in this case, the GUI consists of much more than just the "static" part, e.g. all those panels which are placed in a single 2D plane. Trouble are all the context sensitive informations you would want to show along with actual units, like health points, DPS and status icons. Think about enhancing the strategic zoom and try to show only 1.000 additional elements, one for each unit.

You can't do that with a browserengine. First of all, 1.000 "elements" are going to be much, much more elements for the browser, you will end with like 10.000 actual elements the browser needs to render. Thats already quite a number, but it's still possible, at least for static content. It causes high load on the CPU and it becomes only efficient because browser engines use a "dirty area" approach which allows them to only render those parts of the "picture" which have changed.
But now imagine what happens when you change the perspective? Almost the whole screen becomes "dirty" at once (because like every element was just moved), forcing the whole GUI to be redrawn. That takes at least a few hundred milliseconds with that many elements on screen.


Conclusion: The approach sure works well for the "static" part of the GUI and dialogs (e.g. everything where the position of the GUI element is not bound to the position of an ingame property), but for everything else the overhead would just kill the performance.

Possible solution? Access to "native" graphic functions from JS, best with the ability to hook a HTML5 canvas to a texture which can then be assigned to a location in the world or units, like drawing straight onto the strategic icon from JS but let the actual engine do the composition for such elements. It's just way faster and more flexible to create a texture (or other primitive elements like lines etc.) for the render engine than to try and do the projection and composition in the browser.

The combination of HTML5 and JS for the GUI isn't such a bad choice either. It allows for fancy GUIs without much knowlegde and JS+HTML5+CSS3 as well as the HTML5 canvas element (you can create images and maybe textures on the fly) give possibilities which would be almost impossible to achieve with other scripting languages.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I think, if the main UI just calls the engine to render the 3d shapes, it may be fast enough. So you'd have a javascript call to render an arrow from point A to B, and then the engine itself does the work to make the arrow curve around the planet. That would mean though, that the 3d stuff would be non HTML / CSS, and not subject to modding without changing the rendering engine itself.

Although it occurs to me that the entire UI could be sitting inside a rendered OpenGL pane, which would allow you to do some really cool things like attach a UI to a factory - as you zoom in closer to the factory, you would see the UI and be able to manipulate it directly, rather than the traditional select-first-then-change UI options.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Using JavaScript is a great way to enlist the help of as many people as possible with UI modding, as many have said in this forum.

Using WebKit will provide a bright future for the game's UI since it will also suppor the Dart programming language. For those who already know JavaScript, there will be a low barrier to writing UI mods. For everyone else who doesn't want to use JavaScript, there's a superior, compatible alternative.

For those who don't know, Dart is a new programming language made by Google that's meant to replace JavaScript for web development. It won't have all of the terrible cruft that JavaScript does.

Re: Planetary Annihilation Engine Architecture Update #1 - U

So yeah java script can be a bit bleh sometimes. And I have been meaning to learn Dart.

However.... there is a lot of stuff that primarily uses java script. All the new HTML5 stuff is kind of tied to javascript. JQuery is pretty convenient and makes everything a lot easier. And lately I have been playing around with WebGL which is OpenGL that runs in an HTML5 canvas object with javascript, which will be really nice if the planet generator stores everything as a JSON object (which is one of the main ways WebGL loads in external models)

This means that anyone with a bit of programming experience (and is willing to power through some WebGL tutorials) could probably whip up their very own 3D planet viewer to peek at their generated planets in a locally stored web page in an afternoon's worth of coding.

OK so wild guessing here.

The user will effectively see two layers on top of each other that will make up the game. The bottom layer is the 3D game world where the actual game happens and is written in C++ or something. Then there is this 2D layer on top of it for the UI that is sort of this faux browser that is loading in all your javascript. And then the 3D game world C++ stuff will either broadcast and listen, or get/set global variables, or something so that the 2D javascript browser-esque layer can communicate with the game?

So for example to display your mass energy gauges over the game. In your 2D layer you make a transparent div or something that floats in the upper left part of the screen. Then in your javascript you poke at the 3D game layer to get the player's current mass storage, energy storage, mass input, and energy input. Then using those numbers you put some cleanly formatted text or some nice graphics in your div.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Sounds about right Zachb. The only thing to add is that you'd be able to host multiple windows, each one with its own UI layer, and I'm assuming that you'll be able to resize / position those windows in 3d space.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Javascript ... I haven't used it a whole lot, but it is definately better than coding in french. *rimshot*

Re: Planetary Annihilation Engine Architecture Update #1 - U

JavaScript is great language if used properly. Last part is hardest part, though.

My only concern is about "some 3d parts" as it would be cool to have "all 3d parts", i.e. it would be cool to completely redefine UI both 2d and 3d. I mean, if I want to implement mod that will allow rally points in plan-mod I need to add decal for "rally point", implement resize, link and selection by 3d cursor and other stuff. It couldn't be done in webkit and handling all this issues via javascript (callbacks?) seems just weird.

P.S. Webkit? Isn't it a one huge memory-hungry bloat doing a dozen xml-parsings in second? Strange selection for lightweight UI library. HTML is good for business-applications where memory footprint and speed is not so much relevant, but in gamedev, i dunno...

Re: Planetary Annihilation Engine Architecture Update #1 - U

Does "We use Javascript" actually implicitly mean "The GUI will be designed in HTML"?

Re: Planetary Annihilation Engine Architecture Update #1 - U

Precisely. At least the static part of the UI.

And thats not a bad thing at all, the combination of html5 + css3 + js allows for almost any type of GUI you could imagine with far less effort than with every other GUI framework.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I am very curious to see that work in action + the underlying code as well.
Sounds very weird.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Awesome, well I really hope this transparent browser runs HTML5. There are a lot of really useful things introduced lately.
http://www.w3schools.com/html/html5_intro.asp

So let's say you were writing a tutorial for the player, you could with one line of code pop up a little video showing them how to click on stuff, then play an audio file as they click around on stuff. Then you could store a session variable keeping track of what they clicked on a long time ago.

Also there are vector graphics now, so anyone could design a UI that would perfectly scale to any screen resolution they had. And poking at CSS is a lot easier so it'd be easier for someone to dynamically change the look of the UI during the game.

There is that new Web Worker thing that allows all your scripts to run asynchronously so that one script doesn't lock up the UI until it's done running.

And there is the new Server-Sent Event Notifications which the game will have to do anyway to talk to the 3D OpenGL layer, but I assume there is some sort of advantage (speed, reliability, or compatibility) in using the native HTML5 SSE.

Then there is the new canvas object that i am not quite sure how it would be useful, but I'd bet someone will find something to do with it. Maybe you could find a use for drawing a line from one point on the screen to another?

This shouldn't be a problem if all mods "live" on the server. So if you join a multiplayer game the only mods you'll get to run are those that the server doles out to everyone. And if you are just playing a game on your computer at home, you are your own server and can launch your own mods.

Re: Planetary Annihilation Engine Architecture Update #1 - U

UI-Mods dont live on the server, they only change the way the UI of a player is displayed.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Uhm, and how should a UI cheat mod work with the server-client approach?

You could cheat in SC:FA because the whole gamestate was replicated across all machines so you actually had access to it, but with the client server model, the server will only give those information to the client it is allowed to display.

So you CAN'T cheat. You have neither direct access to unit properties nor do you have information about invisible units or projectiles. They simply don't exist for you.

That means, that the JS interface may give access to a LOT of features and it should.

As mentioned earlier we also need direct access to the actual engine, especially the option to modify textures / to replace ingame graphics or we won't be able to add usefull information. Just drawing with primitives like lines is not enough.