[Pretty Please] Let me have a Dedicated Server binary

So I'm totally good with uploading logs after playing games with my brothers (who live across the state) but I would like to have control over our experience a little more directly. It's frustrating to be subject to what is doubtlessly either 'noisy neighbor' or 'constrained provisioning' with no recourse. Having the simulation lag with many units is a sad thing!
Please let me have a binary. I don't care if it's Windows or Linux - I'll run it on my Server 2012 R2 machine or I'll make a Hyper-V linux instance and run it there, just give me a way!

Pretty please?

You and thousands of others! ;p Uber has very good reasons for keeping the Server Hosting stuff back until Release so we just need to wait it out unfortunately.

It will come, just not yet.

Mike

Unfortunately, the server is not going to be released until release. Uber wants to be able to see stats and crash logs easier as well as control the versions.

I feel your pain too. Big games always become laggy by the end. :/

Surely they could use logs and feedback from technical users! I'm a SDE at one of the 'big places' and can collaborate and help out if they only give me a chance. While I'm certain having central control is nice for convenience's sake, dang it all it frustrates everyone to give a move order and watch the game grind to a halt. I once gave a large order and 7 minutes later, I found out that my troops had killed the other commander. Pretty sure my hardware is beefier than what's getting allocated to these matches .

So I'm going to say it: Please reconsider this position! I want to have enjoyable large scale battles, or a legitimate reason why I can't!!

What would qualify as a legitimate reason for you?

Mike

Optimization issues aside, I'm genuinely impressed with what the current servers are able to do, especially since they are supposedly running each game on a single core.

So I can't wait until players with much beefier computers get their hands on the server.

One example: "Your hardware sucks. Buy a better CPU."
Another: "Your upload/download speeds are insufficient."
A third: "The server code is not well optimized."
A fourth: "The server code is compiled with debug flags and heavy logging."

I'd like to see how far 4.4ghz (even on a single core) + a gigabit condointernet line would take a game before "sim" degenerates to the painfully irritating <=3fps (around 2500 units moving). Basically, if it is still bad on beefy computers, they probably need to look at some of their algorithms and think if there are some asymptotic changes they can make. But all I'm really looking for is the chance to find that out; I'm not expecting perfection, but dang it I can't help but feel that I can do better with my hardware.

It won't happen until release. That will DEFINITELY not be changing. There is no grey area where they said maybe. You just have to be patient with the rest of us. Uber has stated a few times their reasons for not releasing it.

Yeah, well I said pretty please. I'd like the team to reconsider!

As soon as they give out the binaries it is cracked and distributed immediately afterwards, the game never sells and the entire project never gets finished let alone getting aftermarket support.

Punny little server. They are currently running the server in the Amazon EC2 cloud on C3 class servers. I don't know which one precisely, but since they have been claiming to run 8 servers per instance, I assume it's somewhere around c3.4xlarge or c3.8xlarge. That means 16-32 threads, 30-60GB RAM and SSD.

I think they are already down to asymptotic changes in the most fields, pathfinding or even just collision detection for several thousand units and their projectiles is still a ressource hog though, even when using algorithms with linear or superlinear runtime.

Besides: The server software is still crashing often and violently. And that's even in a controlled environment. The server just isn't ready to be shipped yet.

You aren't the only one who wants server access!

But there's many reasons for them to not release the server just yet. As much as I want server access, probably more than you, I support Uber's decision to not give out server access.

Yeah, that is probably not applicable here. Try another angle...

1. No. This is the (best) cpu they (might) use, and it isn't particularly earth shattering in single threaded performance - and it is shared. Bro, learn to spell 'puny.' My server can dedicate more resources to a single application thread than an EC2 C3 instance can. They are all about parallelism, and if it's true that a PA game is served from one thread, I'll wreck their setup. (Not to mention the fact that I can use high speed memory vs. their probable need for slow ecc memory)
2. Jealous? I also have SSD for my server. My disk speed is just as good. The only edge your quoted EC2 instances would have on my machine is RAM, and we don't have knowledge of PA's server-side memory model.
   
3. Your guesses about which instance type they are using are useless.

I think you mean sublinear trying to make your point, and assuming you do mean that - it still depends on a lot of things. I don't think you know what O() means in this context, so I'll just point out that even for a costly algorithm (their pathfinding algorithm appears quite trivial), if you don't recompute every tick it may be fine anyway.

I haven't observed frequent crashes. And violent crashes? So the process dies or runs away allocating memory... The paths to recovery from these are well known and can be collectively classified as 'no big deal.' The software is stable enough to run several hour long games that get large and horrendously slow, so that's probably good enough for now for intrepid folks to try it out.

I know I'm not the only one, but not many people are still asking for it. I applaud your support; in spite of the cop outs reasons for not allowing people to use the (or a repackaged) dedicated server binary, I will still ask for it.

Let's not diverge any more from what this thread is about: I was up past 2am last night watching ~3000 total universe population grind sim to 0.6 - 2 ticks per second. I think I can do better and I want my own server, for pity's sake... Pretty please?

Okay, you can ask the same question as many times as you want, people gave legitimate and good reasons for why the server software isn't shipped yet and told you when you will get it, you can keep asking like an annoying troll or just accept that you aren't getting it right now and be patient like everybody else.

Legitimate reasons I'm aware of and my position:

1. It's not stable.
   • I don't care, it's stable enough for a game at 3 man, 3 hour scale which is good enough for now.
2. They want debug info and server stats.
   • So spend a couple hours and have a server application which scp/rsync/ftp/rpc/rest/email or otherwise 'sends' relevant logs to some place for collection and aggregation. This is not a hard problem.
3. Piracy concerns.
   • If pirates want to take an alpha game, decompile it (it will be horrendous given Uber's language of choice), and make it their own game; they may as well write their own. Soon as the game is released it will be pirated anyway; every digital thing is pirated. I really don't think this too terribly high on the list of priorities given its inevitability.

What am I missing? I'm not trying to troll, I'm sorry if you don't like what I am asking for or if you simply don't like my persistence (you've conflated patience with resignment), but I haven't heard of one legitimate 'blocker' for this other than that they don't want to release it. Basically, what I'm driving at here is that their 'don't want to release it' notion is currently more important than players' enjoyment of the game. Maybe that's the case, but I'd kind of like to have an Uber employee come in here and tell me to shut the F up and deal with their crummy server setup to actually confirm that's what's going on here.

I actually do mean superlinear. If they managed to solve any of these problems in sublinear time by the number of units, well that would be rather impressive.

And why would you possibly think that the simulation is limited by the network thread thread? It isn't the network part which is causing the lags, you can verify that by seeking to a prior state of the game which is served lag-free.
Main cause for lags is currently when too many units are crowded in an area and they start pushing each other around. And that's not causing issues with the network part, but it's slowing down the entire simulation instead as this causes several position updates per unit and frame.

Btw.: I wouldn't call the pathfinding system "simple". It can actually get pretty nasty both in terms of memory usage and cpu time if the initial assumptions (many units, few distinct targets) are no longer fulfilled. Quadratic in planet size and linear in the number of goals for initial path finding, still linear in the number of moving units for each tick.

Btw2.: It's also safe to assume that the performance critical systems are already properly threaded, so not a chance of outperforming a multisocket system with your single i7. And the reason why they are running multiple servers per instance is simple too: Most games end far long before the number of units gets critical, but you can bet that the instances are at full load when a game starts lagging. And it's not necessarily the server you are on which causes the load.

Yeah, my point exactly. Your original point was kind of trying to hinge on the costliness of algorithms, even when ideal, so sublinear would have made your point stronger. Anyways... Yeah, I can sit here and conceive of ways to get sublinear group orders (sublinear in group size). Not really too impressive, just about 30 seconds of thought is all it takes. No idea what their object model looks like, but it isn't all that hard to architect something like this.

Apologies, I in no way intended to imply this. Sim is limited by something server-side but we don't truly know what - and that is all I intended to imply.

Yeah, this is one way of triggering the sim slowdown, but it doesn't require unit collisions at all.

You do have some idea of time complexity; you should be able to see that you have no clue how they implemented it. Assuming an intelligent algorithm was chosen, they would probably be able to make some MASSIVE improvements in their semantic use of edges and vertices to speed this up, as well as collective unit movements which may reduce what is VERY likely a O(planetSize^2 * unitCount) algorithm to something which looks more like O(reducedPlanetVertices * moveOrder(1)). Now, I'm blowing smoke here completely, but for 3000 unit objects to reduce their code to a quivering pile of poo, there's almost certainly a misuse (or just a quick mock up) of some key algorithms. Anyway, this is orthogonal to the server issue(but it's my job and I enjoy it).

No it's not safe to assume anything about their threading model. And multisocket systems don't come free of charge in terms of computational power. The rest of what you're describing is called 'noisy neighbor' and is one flawless example of a reason why I want to self-host.

I don't want to talk about implementation guesses anymore. There are obvious shortcomings which will doubtlessly be addressed at some point, but for now I think at least giving us the option to insulate from noisy neighbors and spec our own server hardware would be a really classy move by the team.

This is conjecture, but sometimes development software that isn't deployed isn't actually deployable- its tied to specific hardware, compiled with machine dependent libs or something of that nature. Considering they are running it on EC2, that's probably not the case, but still.

The real issue is one that I respect uber for. They have so far tried to be very fair, even when it meant some nasty backlash against them. (See early access pricing and delta commander). Your arguments are valid, if you existed in a vacuum. But most people want to access the server as well.

If they gave you the server, then this precedent would more or less require that they give other people the server as well. Now uber has to deal with another massive set of bug reports, and tons of non-technical users asking for help finding the server gui. Furthermore, it guarantees that the user base will become fragmented, with different people running different server versions (it probably doesn't auto-update), reporting old bugs, and reporting server mod bugs. (client mod bugs already get reported as real bugs all the time).

Quite simply, releasing the server to you will require at least some amount of effort on uber's part. Uber has judged, due to the fact that you do not have the server, that this effort is not worth what they get from giving you the server.

Sorta off topic, but I would really like to see how the server performs on different types of hardware too. Games are really hard to meaningfully multithread, and if they did, an i7 can still provide what, like 8 now? I doubt that a single PA instance is going to max out 8 threads at a high clock speed.

(If they give you the server, can I have a copy?)

You can ask all you want, but it's not happening for a while. :-(

Uber isn't even providing info on what the server requirements will end up being. I asked a few weeks ago.

They are precomputing flow fields, basically textures in which the favorable direction for each position is denoted. These textures are dynamically generated whenever a navigation goal is created. The size of the texture scales directly with the planets surface, and the cost for generating each texture is similar to performing A* on an endless graph. Lookup for each individual unit and frame is therefor possible in constant time, hence linear in the number of units.
Try searching the forums, they are quite talkative about which approaches they are using.