John,

You've described why the game isn't true permadeath; GCL (rooms, CPU), code, and credits come with you during respawn.

If I respawn it takes much less time to get back to RCL8 because I can aggressively grab rooms and remote mine. Once hitting RCL6 I can start buying/using boosts with banked credits, etc. I use (as Artem says) private server to test early game code.

However, Artem/etc; I still want to push that the more active of a player I am, the more people unsubscribe. Private servers are a fundamental tool for this game, but having my foot in the game world as "production" to push to was most of why I stuck with it early on (when "PS" was just "the room sim").

The best thing for me to do on respawn is to find a green zone and own it, which sucks for everyone else spawning in there. They might give up.

Most of my neighbors expect me to kill them (which is true).

If you're not copying code (OCS/tooangel/etc) it can take months of casual play to implement enough features to compete, even with the private server.

Given GCL and credits surviving death Artem has clearly had ease of respawn in mind, and it is _really_ close to being good enough. Just want to push the point that it's not quite there yet, and that having safer places for simpler codebases while still getting the social aspect is a good thing.

I brought up this idea in chat a couple weeks ago. I think simplified from your proposal a bit makes a lot of sense.

There is already some level of partitioning due to noob zones, with timed walls. 3-4 universes is a bit much but 2 or _maybe_ 3 would make a huge difference.

1) No chemicals/power. Though maybe you can process power into your account. No GCL cap/modifications, but similar to noob zones you get a room cap (of say 10). The room cap limits your upgrade rate. Also possibly no SK mining. Market probably also doesn't work (energy-only trade might be a good intro to that code though?)

2) Chemicals/power/etc. Maybe allow power accrual in noob zone but you can't use it unless you respawn in here. Can still work with green zones for people spawning in.

PTR mirrors 2).

The _maybe_ for 3 could be that the existing world is left as "legacy" and 1/2 are brand new worlds that slowly expand. Other options would be that the existing world becomes 2) (though it would be hugely oversized for a while), and a new one spawns for 1).

Being in 2) gives you GCL boosts since the room cap would be gone, and upgrade boosts are available. "Speed" realm is probably unnecessary, because if world 2 could get a separate database and by nature of how few players get past that hurdle it could potentially run at a much higher tick rate.

Not perfect

As with any game this small, any sort of world partitioning can have a hugely negative effect on community. world 2 might have only a handful of players in it, or the noobs would miss their neighbors. On the other hand, every time someone new spawns near me I tend to get a tepid message asking about when I'm going to destroy them, and I've noticed at least half of the (established!) players I've killed never respawn.

If existing world becomes world 2, it could be an easy enough experiment to create world 1 and offer it to people on respawns. If it doesn't work out, stop offering respawns there and declare it deprecated and shut off after N months.

One more thing!

Some slight boosting for respawning based on GCL level would also be super nice for this same problem. I personally don't think I would mind much, since my code and GCL are retained the next respawn goes a lot faster. For people with less patience (probably most), giving an upgrade boost for N * GCL level ticks on respawn (or similar) would go a long way.

It would be great if we had a way of iterating flags without causing the objects to instantiate. That would still disallow a few ways people tend to use them now, but would at least open up another area.

IE: I only use a handful of flags dynamically. Most other flags are objects that really don't need to be checked every tick. Now I have to stop using flags for everything but the periodic checks because I have to pay the entire deserialization cost by touching one of them. (I don't have many flags; just planning ahead).

IE: an iterator or array containing flag _names_, separate from a function like Game.getObjectById() that gives you the whole flag object back.

I understand that some people are checking properties of flags on every tick and there isn't much to be done there. Caching or object reuse would help, but it seems like our instances aren't very sticky so I'm not sure how that would play out in reality.

As an aside: It sounds like you're having a lot of systems issues in recent months. Is there any way at least one of us who does this professionally could help with a few hours of labor? I'm well familiar with being on the other side of something with performance issues and having people armchair-narrate how to fix them without a full understanding of the problem.

However I've also been pulled in many dozens of times by random (very large) companies and made pretty large impacts by dealing with easy low hanging fruit. If it helps smooth things out I'm sure at least someone would be open to it (I could throw a few hours or days at it).

Thanks

Another pile-on comment: GCL*3 limit makes a lot more sense. I had to rely on single source mines to get up through GCL4 given where I started. 3000 -> 2000 for a single-source room means actually very close to zero profit unless you size haulers, add roads built + repaired, add containers, have remote mine defenders, and don't have bugs in any of that.

Having rooms surrounded by two-source rooms available for remote mines does seem to give a bit too much energy. SK's seem pretty heavy too. Some adjustment would be nice.

The mineral changes seem harsh... but not as breaking as reducing single-source mines to be profit-less.

If two workers harvest the same extractor in the same tick, do one or both succeed?

Oh, one other thing: Abandoned players with automated walls. Single-room nodes ground up to RCL7+. It's already pretty tough clearing these out if they're mindlessly dumping energy into walls perpetually.

It would complicate things even further if this became less effective if you don't push code or log in. but something along those lines: like the amount of ticks you've owned a room makes it less effective as well, with a starting cliff of multiple weeks.

EDIT: You could simplify all of the above ideas by gating it on total tick age for all owned rooms in empire. IE: (lets say 500k ticks is 3 weeks), one room at 500k ticks starts losing effectiveness every 50k ticks after that.

So two rooms at 250k ticks start losing effectiveness as well.

Larger players can try to game this by unclaim/reclaiming rooms, but after 5-6 rooms they'll never get aything to RCL7 if they keep doing that. past 10 and it's unlikelyu to work at all.

Could be _some_ downside: if a very large player is under siege and is losing rooms.. they could unclaim lost rooms to try to duck back under the counter. That might be a legitimate strategy at that point though.

Seems like some kind of scaling would help a lot here:

1) Reduce activation length by RCL of room (10k at RCL < 3, -2k per level)

2) Add pre-activation delay by RCL of room (0 at RCL < 3, +2k per level) (per n00bish/others)

3) Do one of these based on total RCL of empire (same but slower scale)

Seems somewhat easy to abuse by higher end players otherwise. IE: Go claim a thing next to someone, put up a wall, keep putting up walls while trolling as long as possible.

Or wait until a massive attack force is inside a base, then put up a wall and slaughter them (since heal parts are off) (hat tip: not me for this one)

More scaling there, maybe? If RCL (global or local) is low, putting up a wall disables those attack methods. If RCL is medium, disables boost effects, if RCL is high, disables nothing?

Seems kind of complicated.

Hi, sorry, that was the quickest way for me to test many creeps moving around.

The sim, while paused, seems to sit at 30-35%, even after I've put a number of buildings up.

Is there any chance for one more hopefully small adjustment to the smooth animations option? When disabled, could "Ambient" animation loops (energy, source keeper, spawning spawn, reserved/degrading controller, etc) only make a 1 second loop once at the top of any tick?

That would allow a full pause in animations between per-tick animations, allowing the CPU to go into a deeper sleep state temporarily. This should help a lot for laptops. In public there's a 0.5 to 1s space between animations for previous tick and the next tick starting, so this would be perfect.

Thank you! This already helps a lot.

Hi!

Just gave the smooth animations button a try on the PTR. It does seem to halve the CPU usage.

Did some quick tests in the sim as well:

45% CPU with few creeps and not much going on.

75% CPU with 40 extensions near creeps (and a few more? like 5)

85-95% CPU with 12 creeps and say bubbles.

Adding tons of roads near where animations happens ups it to 110%.

Tons of roads, 40 extensions, 12 creeps, and paused (only things animating are sources and keeper lairs) is using 50% CPU.

Re-enabling smooth animations at any point seems to max out CPU (100%-130% is as far as the browser tab goes on this machine).

Can't tell if the combination of animations or animations-near-things-that-get-redrawn are causing more of the problems. This switch certainly helps in the meantime!

Hi!

I'm fairly certain it's not a browser setup issue. My test setup:

 * A ubuntu 15.10 (later 16.04), existing machine, latest chrome. Just ublock and flash disabled.

 * A brand new ubuntu 14.04 laptop, completely fresh unaltered install + latest chrome.

 * A completely brand new computer with a fresh windows 10 install + latest chrome.

From what I can tell this is related to: If anything in the room is animating, and the number of objects in the room. In example:

Using the room history viewer, which isn't getting websocket updates, and is by default paused, look at:

1) A completely empty room (like one to my west that runs inbetween quads), CPU usage is low.

2) An unused room with a single source in it. CPU usage is a bit higher (makes some sense, something is animating)

3) Then, look at one of my own rooms with roads, extensions, etc, in it. Paused at a point where the only animations are from the sources. CPU usage is now maxed. No tower movement, no spawn movement, no creep movement (again, the "room history" view is used while paused)

When looking at timeline profiles in chrome it shows that .apply() is being called on objects nearly constantly. It appears that if anything is animating in a room, anything which could potentially have animations layered on top of it gets .apply called to it. It's difficult to troubleshoot from there due to everything being minified.

Hope this helps, thank you!

The animations are quite a lot but I have a feeling something else is going on. Even if there's nothing animating for several seconds the CPU stays pegged. Either it's (still?) catching up or it's re-applying changes to the style needlessly and causing redraws.