Hey, As Mavor said in the PCGamer interview, the networking will be arranged through a server-client system, where a powerful multicore server will calculate all the simulation stuff and your computer just local things. First, this sounds really cool as it would mean no more lag and slowdowns as you have them in Supcom. But I can imagine that such a powerful server cost alot to lease/maintain and the budget of Planetary Annihilation is not the biggest. So my question is, for how long do you think you can finance the server with the budget and do you consider a "server-financing-pot" where the community can donate to?
This is not surprising, and probably just means the host will need a beefy rig while everyone else is just worrying about UI. Achron does this as well, actually (not that anyone here has probably heard of it). Another big upside is that it can prevent cheating (by players other than the host) by only sending what data the clients can reasonably see. The only difficulty is that it becomes trickier to arrange replay distribution (since not everyone can record their own replays) and may require some more router setup to host.
I would think that just anybody can create a server on his own machine(which should be quite powerful) or if he so chooses on some dedicated server. Uber will probably just run a server for matchmaking, a list of open games and chat-stuff. Which is btw really important @uber: you need a good multiplayer-client from the start, please! Replays could be just distributed from the server to the clients after the game ended? A replayfile is small, it should not be a problem to transfer it. For supreme commander ANYONE needs to set up his router properly, so actually it is better if only the server needs be properly reachable.
I was even thinking of a possibility where Uber works with the FAF community and developers, who already have a pretty well-established community and interface. GPGNet was able to have a single chat for multiple different games (demigod and Supcom), so why not FAF? I'd be interested to see what Ze_Pilot thinks about it.
my honest opinion: FAF may be nice and all, but technically I think it is not exactly the best interface ever. Like it still is terribly laggy when resizing the window or switching chattabs and thinks like that. Plus I think that FAF does not work on Linux, does it? Plus it probably would result in quite alot of work for ze_pilot.
FAF is not laggy for me, perhaps your computer is at fault? I think Zep's done an awesome job, and Uber could do a lot worse than seeing if he wants to get on board.
my computer is quite a beast, way more complex programs run just fine. open up a personal chat tab and switch between that tab and the mainchat alot. you will notice it is quite slow. also did you ever try to size the window in a very specific size? takes quite a while to resize it horizontally. sometimes it also lags while entering chatmessages, like the whole program just freezes, probably because it waits for some kind of networking-stuff, which should not be done in the same thread as the gui. It really is a great thing that pilot made faf, really I love it. But I honestly think that a professional company can do better if they put their heart to it. And I hope uber will.
I honestly didn't saw that coming I take it as a compliment, but Cola_Colin is right : FAF is an amateur project (even if some pro did work on it on their free time), and specifically designed for FA (although the client itself is pretty agnostic if you remove all the FA-related icons . Just for precision : - The "lag" was fixed today, and not before as I wasn't even aware of it. Seems that too many lines in the IRC windows made QT lag a lot to reformat this block of text (and some people stay for more than 20 hours connected . As I'm using a IRC Client most of the time, never noticed it myself - The code itself can run on linux without trouble (in fact most of the code was developped on a linux station), but I rely on the win32com API to setup uPnP and others stuff. That can be ported to linux easily, but I don't want to support linux as FA does not (too much extra work for me - amateur remember ? - . Now, PA will run on a tight budget, and I think it can relate to FAF on that side. I had to do it simple because of my available time, PA will have to do simple because of the budget. I won't say I have the Truth about what should be done (and after all, I've just copied what Spring did), but it's easy to overdo things, like I think GPGNET did. Using IRC for chat was a huge time-saver. Using a solid, existing GUI API like QT with a nice high and low-level network API made me saved weeks if not months of work. Using web back-ends for the map vault, leaderboards, ... Was also a decision I did not regret. Not a huge time saver to do, but it's now really easy to "upgrade" without editing the client code. (again, QT and his webview browser with a complete client/web communication API was a great time-saver). I'm certain that Uber have some coders that do a way better work than using existing stuff like I did, but is it really needed ? What the advantages of re-doing existing things ? The time saved on these things made me able to integrate many functions that I've considered out of scope at first. Of course, if I could make FAF compatible with the Uber server, that would be wonderful, but I don't think they should bother with that kind of dream Whatever their decision is, I really hope they will stay away from steam "way of doing things". The browser server,... work perfectly, but the community spirit -chat,...- ... Not there. And that's really a important thing for a (multiplayer) RTS.
FA does run on linux with whine, afaik. The leader and founder of vow actually wanted to play it on linux, but since neither GPGnet nor FAF work on linux he wasnt able to. About the lag-bug: I thought you were aware of it, as a "laggy gui" was a problem even month ago and I reported it to thygrrr, who did improve a few things on it already. I just thought he didn't get it all right up until now. Crying about a bug in public with the developer not knowing about it the bug wasn't nice of me
By the way it still not great. I will do a proper fix today. The problem is not really making a port for Linux (some guys proposed it), but to help people with it. When there is a question in the tech forum, I know they are on windows. If they can be on win or linux, I have to ask first their os, and do linux maintenance (and I did that at my job, it's not something I like).
