Planetary Annihilation Engine Architecture Update #1 - UI

Re: Planetary Annihilation Engine Architecture Update #1 - U

Yes in a perfect world you cant cheat by this approach, but I dont think it is a good idea to go about it like: "Yeah server-client will protect us from anything, nothing can go wrong" and afterwards realize that some other things turned out to be problematic.

Re: Planetary Annihilation Engine Architecture Update #1 - U

But thats all you can do. It is impossible to make the client cheat-proof, you can only raise the level of knowledge required to hack the game. (And once the hack is ready, everyone can apply it.)

Consider every data you send to the client disclosed and always consider every command you receive from the client as manipulated. Thats the only way.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I need to end a lot more paragraphs with this wonderful sentence. I happen to go off on technical rants as I watch my friends eyes drift off into a world of "not-really-listening".

Anyway, just wanted to say that it's interesting to see how web programming is infiltrating desktop programming. Kinda the opposite of what Microsoft expected? Their whole approach with .NET web programming... ugh...

We need a compromise, a cross-platform, xml-fed programming language that we can write games, webpages, applications, applets in.

I'm glad it's all local, else I'd be up in arms... xD

Re: Planetary Annihilation Engine Architecture Update #1 - U

Yes, I fully believe that the web will eventually be the platform we code for. But it's not there yet and some things could stall that idea. For example if one of the closed ecosystems "wins".

Google has their native client stuff that they are trying to push to solve this problem. I expect the eventual solution won't be native though.

Overall this was a very tough decision. In my experience though UI is always a pain no matter what you do. At least with this system we can leverage a ton of stuff that already exists. Being able to tap resources on the web and insert them into the UI is pretty nice as well (for both our services and outside services).

The logical way to do server config is using a webpage. Just embed a web server into the actual game server and let it serve config pages. The next level beyond that is you have it serve the actual game lobby as a page as well. This means mods could potentially customize the lobby *per server instance* and not have to change stuff on the client. Not 100% sure we are doing that but that's my current thinking. Research along these lines is currently in progress.

Hopefully we'll get a Pathing/Flowfield/Navigation update soon from Elijah. He's been cranking on building a whole bunch of that stuff out. We are planning on integrating it with the client/server code this week if all goes according to plan.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I can understand that, it's hard enough handling all the new problems without having to solve the same ones again and again. A lot of freely available code snippets too, when it comes to Javascript.

You never specified why you avoided Scaleform? Is it the cost of the License or a lack of Actionscript/Flash expertise on your team? Perhaps a bit of both?

The technology for Flowfield is amazing. It may seem a bit much to ask, but is it possible that the update can contain a little technical explanation of how the system is actually implemented? I'm sure I know a few dozen other programmers that it'd be helpful to.

p.s.
League of Legends currently uses a kind of hybrid/webpage technology for its "Lobby" system. And BF3 just outright uses a webpage. They seemed pretty successful, it does allow you some flexibility to adapt the interface without updating the local client. I'm happy with how Steam does it, makes it easy to share. Which also goes hand-in-hand with Social Media. Personally, I highly recommend it.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I'm very interested in this because frankly at this point, Pathing is my biggest worry, the sliding and clipping that happened in SupCom2 was one of the biggest immersion breakers for me, especially coming from FA which was wonderfully simulation based. If Elijah came make units adapt thier pathing based on nearby units while still maintaining teh similation aspect I will be one very, very happy Player/Modder/Backer.

Mike

Re: Planetary Annihilation Engine Architecture Update #1 - U

Not really. The WinRT runtime, used for writing Metro^H^H^H^H^HModern UI applications for Windows 8, does have language support for Javascript.

Re: Planetary Annihilation Engine Architecture Update #1 - U

The longer I think about it, the more I like the idea.. Basicly it also happens with all those apps for mobiles.. why code an app for every mobile OS when you can make 1 webapp which can be opened by all current and future mobile OS'es..

Re: Planetary Annihilation Engine Architecture Update #1 - U

Webbrowser-like UI system seems ok to me, as long as the actual interface is locally stored, not like in League of Legends where every single part of the menu takes a while to load.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I fear that at time when computer performance would be sufficient enough to safely ignore extremely complex and over-universal web infrastructure for major scale gaming development, web would be replaced by something else. Like direct neuro interfaces or fancy glasses with on-world projections.

Don't want to disappoint you, but what you named "simulation" is actually just careful animation and movement timings taken from animation, not other way around. And SC also has slides - just take a closer look on Galactic Colossus rotating 180 degrees on same place. SC is just more accurate and better designed than SC2, that's the reason.

Also, SupCom is p2p, which means that if you are lagging behind and your units moving with speed of their slow animation, that everyone if lagging behind and their units are also very slow. It's not the case in client-server model, when your units will just jump around.

In ideal world, when your computer is powerful enough, your ping to server is low and there is no little evil gnomes stealing UDP packets along the line - it will work perfectly as long as server's opinion about units speed is taken from same animation that is used on clients.

But in real world, it would be losses and non-linear delays to compensate which client would be required to predict further movement and play animation ahead. And if your timeline differs from server's, for any reason - server given animation frames would be different from your animation frames, which would require careful blending. But, now they key phrase, this is work of animation tech and network tech. It has nothing to do with pathfinding.

I really doubt that pathfinding guys are working with something highly different from little red boxes navigating chunky world. Path-finding, 100% sure, would be done on server - it would have no idea about any animation at all.

Re: Planetary Annihilation Engine Architecture Update #1 - U

I gotta ask, how familiar are you with FA and SupCom2? Because that was in no way what I was talking about. I'm talking about how the units were programmed to move, not how the networking model affected the visuals.

Mike

Re: Planetary Annihilation Engine Architecture Update #1 - U

But simulation was a poor choice of words though.

Still, nothing to do with UI. Back on topic everyone!

Re: Planetary Annihilation Engine Architecture Update #1 - U

From experience, having a nice data driven system is great until you have something that can come along and crap all over your flow (these are things like system events causing your game to head back to the title screen or something).
There are always so many edge cases it makes you weep.
Having said that, for PC only this is going to be less of an issue, so hopefully it'll be easier to maintain for you guys!

Re: Planetary Annihilation Engine Architecture Update #1 - U

So about external services...

One of the ideas that hit me while looking at that Call Of Duty stat sheet that tells you how many bullets were fired out of which guns at swearing 14 year olds by other swearing 14 year olds.

So for work we use Google Analytics to gather information on how our customers are using our site. We can see what OS they have, what their favorite screen resolution is, and what they are clicking on.

http://www.google.com/analytics/features/index.html

So if someone was writing a custom UI, and everyone else was OK with sharing some user stats with them, they could find out what the most popular screen resolution is and where they are clicking to tell what changes to make to the UI when updating it.

By the way anyone with a Gmail account can get in on Analytics.

Oh good, I was about to ask if the game lobby, victory screen, and loading screens would be we pages too.

So for example, someone could write a co op mission that had very specific triggers in game and was expecting exactly 2-4 human players in specific slots. They could lock down the lobby to only open the first four slots, put AI opponents in the other slots automatically, and close off all the remaining spaces.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Ding ding ding, we have a winner. I basically used something like this as an example today in our engineering meeting (yes we have it on video for the doc).

Re: Planetary Annihilation Engine Architecture Update #1 - U

Units are moved by moving their model origin - there is no other way to do it, - and model origin is dictated by server. Server don't know about animation or any other kind of information required for movement "simulation", it just moves units with given speed. My point was that pathfinding has nothing to do with model animation.

Nice! But would it contain some information about 3d UI as well? Same example with custom co-op missing may require additional custom markers on screen - like outlining area where your units are in danger of being hit by some ultra-gun.

Re: Planetary Annihilation Engine Architecture Update #1 - U

It makes sense in League of Legends. All of the PvP.net content is driven by a remote database. All the images are hosted locally but the actual content is downloaded, it's a perfect compromise. Their servers are just bad.

Re: Planetary Annihilation Engine Architecture Update #1 - U

Just please make sure there's caching and/or some way to tell the client 'hey, you've seen this before, no need to wait while our server takes its time to respond.'


'Oh whoops our UI server is down, game doesn't work' is my worry. Something like the@#$# minecraft authorization servers

Re: Planetary Annihilation Engine Architecture Update #1 - U

Seriously pawz? It will be local.

Re: Planetary Annihilation Engine Architecture Update #1 - U

You were saying?

Edit: I'd also like to point out that it's NOT local if it's pulling it from the server - and if my client has to wait to download the lobby UI each time I connect to the (same) server, it would feel to me like it's slower than it has to be.