The Tl; Dr;

.Net wasm development has been maturing nicely over the past couple of years so I thought i'd take it upon myself to get my creeps able to C#.

After an initial PoC with mono I have the begginings of an initial swing at full C#ness up on github here here (not much to see, watch this space) built on top of blazor.

Initial Findings

So far I have experimented with three approaches, none of which are particularly screeps-ready.

Mono Wasm

• Build environment can be be finnicky to set up
• Build output (.net libraries + mono 'runtime') is above 5mb
• Allows use of the .net dlls (broad strokes here) practically as is

My first working versions have been with the base mono wasm implementation.I expect that as time progresses mono will in the short term create the most usable 'core' for screeps as they continue to work on mixed mode (AOT + IL side by side) compilation.

Blazor

• Built on top of mono
• Easy to set up & deploy
• Makes major assumptions about deployment environment (hint: it isn't screeps!).
• Requires custom harness that ignores almost everything that blazor puts on top of mono.
• Continued blazor development keeps causing issues with the harness.

Why use blazor if i'm going to ignore most of it? It's a (mostly) stable target that tightly integrates with the core visual studio experience with very little extra footwork needed. I messed with mono/corert/blazor simultaneously but blazor is simply the first past the gate to work on the public (ptr) server.

I do however expect the blazor team to keep optimizing for browser deployment which will only make its use harder for screeps. For example I've already discovered two removed methods that I relied on removed as they push towards release (Removed for good reasons, mind) .

CoreRt Wasm

• Aims to be AOT optimized - theoretically better size & speed
• Furthest from feature complete in regards to wasm
• No inbuilt javascript interop as of writing
• I found it easier to set up than the mono wasm stuff, but it has more steps
• Currently less overall documentation for wasm builds

Long term this is probably the most promising for .net wasm in general not just for screeps. Their work is mindblowing* but utltimately I just ended up happier for something easier to use and build against (blazor)

*Not to say that mono/blazor isn't fantastic, i'm just most familiar with the inner workings of corert... not that that is saying much.

@kyralee Then NPC orders can be re-introduced if/when such a thing becomes a problem.

--My 2c of a lot of the talk i've been seeing on this:

I like the idea to remove NPC buy orders for minerals. There's certainly enough player demand for T1 minerals it seems. If NPCs only buy these new materials player demand will only go up for T1 minerals.

In particular to the concerns i've seen from players on Shard 3: I'm currently in the process of setting up an outpost on the shard to access the market and I know i'm not the only one. Regardless, my code can't tell the difference between an NPC order and a player one without looking at the room and it should be the same with your code.

The concerns i've seen for inflation are not unfounded but there's enough knobs on this system to tune it so that doesn't happen. Ideally this should be self balancing.

Finally processing these materials are far simpler than labs, and if i'm understanding it correctly even powerless players have access to T0. I just don't see how newer players are excluded from this at all.

@davaned Walls out seems to be a becoming more viable approach in order to protect the sources; the most dangerous unit (power creeps) can just duck into a room for a single tick anyway.

Ultimately at the highest level of attack/defence I expect more complicated strategies such as moving towers and multi-room spawning of defenders (for flanking) to be practically necessary.

But I hardly take part in combat so what do I know.

The most basic (and seemingly common) way to achieve it is to have one creep (typically a healer) constantly moveTo a leader creep (typically a dismantler or attacker).

The most complicated way that I currently have in my code is a 3x3 grid with pre-coded movement patterns. Eg. Turn, swap rank etc.

@davaned Power efficiency is a tricky thing; I can't make use of all powers all the time even with an infinite amount of ops.

Specifically:

• Operate_Tower requires a target (or need for inefficient repair)
• Operate_Spawn requires filling infrastructure (and a demand for more creeps).
• Fortify is only of use in a siege
• Disrupt_(X) ditto
• Shield is more generically useful but I cannot see it being used whenever it is off cooldown.
• Others, depending on economic situation and code maturity

I feel that 'sometimes' powers like these are great powers to level to keep a creep 'ops neutral'. Even a creep that only generates ops most of the time can gain value from being level 25 thanks to powers like the above.

Selling ops would be a good way for newer players to get credits too, as apposed to simply selling that power. So I don't expect ops to be terribly expensive. (If an op is worth more than the minerals it can generate i'll damn well sell them)

Finally while I can appreciate that YMMV (not everyone likes spreadsheets) I like the added challenge of balancing ops use & generation with the powers I want to use.

There is simply no need to send energy across the map. Buy local or just set up an ORDER_BUY.

If you need to estimate credit/energy overhead costs to maximise profits you can use the energy sending cost and multiply it by the cost it would take you to buy more energy (Highest buy order + 0.001 in my case).

The market is fine IMHO; just one more programming challenge to overcome.

@smokeman said in Ramparts should be weaker than walls and they both need a nerf:

Hence, my base position that the max settings are 10 times too high.

So some people are unwilling to make the investment is the reason we should set the cap lower?

Wherever you set your cap (or lack thereof) for walls is all about your priorities. I'm starting to be more energy hungry and leaning on my active defensive more so I simply don't want walls that high and have the luxury of thinking about where I want to set them.

The argument that seems to be being made is that rooms are too hard to take, with walls maxhits being the most visible cause due to the players you are facing. Rooms being hard to take is currently being addressed in other ways (controllers got the dev spotlight recently).

Another real problem I feel (due to the opponents I tend to face and where my offensive code is at) with taking a room is that as long as you can get energy into the walls it's an uphill battle on top of all the other mechanics that favour defence, wall maxhits included.

Nukes help since you can wipe out a room's creeps but as it stands now to attack a room you effectively attack however many rooms are supplying resources to that room, all the way up to the alliance level. Perhaps even up to the shard level thanks to the market and the deep credit reserves some players have.

But that is me just shining light on yet another mechanic that works in favor of defence. Every player you talk to is probably going to have different opinions about what makes defence so strong.

So a few things:

I've seen higher level players opt to not upgrade past 30mil because of the heavy investment 300mil takes(1). That is exactly what is going on; up front cost for a payoff down the line. The thing is they have to upgrade every tile to 300 mil. An attacker only has to punch one hole.

Is that balanced? I don't know but it's important to keep in mind.

Nurfing walls/ramparts will do nothing for the imbalance between new players and old since there is already very little difference between two players in regards to walls (sans time upgrading) when taken on their own. Active defences and tower placement are king.

It will make a room take less time/investment to crack for sure but i'm not sure how much easier it will be to crack any given room unless you render walls/ramparts worthlessly weak.

Nerfing can also make it harder on newer players. Anything less than what will go down in a few creep lifetimes puts a massive amount of pressure on active defences to pick up the slack.

Hell I would argue that even if they where logged on at the start of an attack they couldn't write the code fast enough against a coordinated(2) attack. This is of course assuming they have the time to get the walls upgraded, newbies and all.

Put it at anything more than a few creep lifetimes and the players with well written defences won't even notice the difference against all but the most determined of attacks. And that's if they even bothered to build their defences all the way up anyway.

Changing upkeep amounts is the only workable suggestion i've seen so far. But strictly speaking a lot of defensive layouts have a lot of 'fat' that could be trimmed(3) and I feel there are unexplored strategies that could prove even more optimal than present(4).

We could just end up back where we where in the attack/defence with a new, dare I say, scapegoat. The problem is systemic and while walls are a part of the problem they are not the problem.

Use the extra GCL you have over them (due their massive standing investment) to level a couple more nukes at their room or something.




(1)Starting to lean towards this camp myself. But interestingly my code starts to break down for varying reasons if I where to try to use it.
(2)I'm talking your typical boosted squads. No matter how you slice it defensive code takes iterating and quite likely, boosts both take time. Many players simply do not work on defence until the enemy is at their gate.
(3)Solid lines of ramparts work well for some things but are not the most efficient design for energy use IMHO.
(4)Eg. New bunker designs, moving towers for walls out, exploiting unreleased mechanics etc. Actually I'm convinced that some combination of walls out & walls in simultaneously is the most optimal defensive (if not economical) solution.

Which shard is affected?
All shards

What happened?
Related: https://screeps.com/forum/topic/2285/after-intershard-travelling-placed-on-a-portal

A creep was placed on an active portal to shard 3 after moving through a shard1->2 portal.

What should have happened?
Creep should be placed in open space.

How can we reproduce this?

Have a large number creeps navigate to another shard. This other shard needs to have two close portals.

It is possible to see me attempting this at https://screeps.com/a/#!/history/shard2/E10N30?t=10111162

You can see my creeps making it to shard 3 here: https://screeps.com/a/#!/history/shard3/E10N40?t=20560