Posts made by vrs

It will certainly affect me (I assemble T3 from its base minerals in one pass, except for the ones using G)

I'm not sure this will help much to stimulate fights. It mostly encourages stockpiling and increases the power of large coalitions. (a small nimble group of players will run out of boosts faster).

I would have preferred having unbalanced mineral respawn rates (perhaps by shard or general area, to encourage trading and inter-shard commerce) or have to some recipes use more then one mineral (ex: 4X + UH2O -> XUH2O), again perhaps with some random element over time to avoid the market balances out.

If it's to reduce the DB load, which I suspect, I'd prefer a change that increases both reaction time and minerals used at the same rate (ex: 10 X + 10 UH2O -> 10 XUH2O with a 50 tick cooldown)

If I would have to choose between slack and discord, I'd choose IRC on one of the big networks.

benefits:

• open standard
• won't get fired for using it at work
• lots of clients to choose from (and some of them don't eat 2GB of RAM)
• no walled garden
• tons of integration options exist
• easy to archive
• venerable
• can ignore others
• no signup required - much lower barrier of entry
• high nostalgia value, includes trout slapping

drawbacks:

• not owned by a startup desperately trying to make money or go public before funding runs out

getting this one occasionally:

[10:25:09 PM][shard0]RangeError: Array buffer allocation failed at new ArrayBuffer (<anonymous>) at typedArrayConstructByLength (<anonymous>) at new Float64Array (native) at new Heap (__runtime__:33218:27) at Object.findRoute (__runtime__:33024:13) at Object.findExit (__runtime__:33114:30) at Object.findExitTo (__runtime__:14667:29) at Object.findPathTo (__runtime__:14831:32) at Object.moveTo (__runtime__:36365:29)

Ok, got it running now.

minor nitpick, in the UI, the top right CPU/Memory might have some rounding issue. I'm seeing values like these: 60.799999999999955 / 290

that's great news !

I'm sad to report that I'm unable to use it on PTR. With an empty main loop, no other files and empty Memory, it's still returning [3:56:35 AM][shard0]Script execution timed out ungracefully, restarting virtual machine.

I haven't made my mind up on the question itself. On one hand, I'd love to have a larger universe. On the other, it's pay2win-like, and may cause even more stagnation.

However if it would be explicitly permitted, it should be done in a controlled manner; e.g require players to register their extra accounts to be linked to their main account, and ban those who don't (if there is sufficient suspicion). This has numerous benefits:

• it's possible to limit the amount (e.g max 3) or usage (max 1 per shard)
• it's possible to avoid lots of 10cpu clones (a drain on the rest of the community)
• it could be made public, to warn possible attackers (like GCL and alliance membership is an indication now)
• permits integration in the game if needed (auth keys, billing, rank, ...)
• could help avoiding "toxic" effect (new players being surprised it's allowed because the docs don't mention it at all, unfounded allegations of being an alt, less chance of "trolling" since alts are not fully anonymous, ...)
• keep track of how widespread it's use is
• limit interaction with new content like the arena minigame to the "main" account only, if needed for fairness.
• ...

basically, keep the door open to tweak and extend it later.

I too am concerned about the rate limit of 10 per hour on uploading code. It's way too restrictive.

Thinking back to when I started, I remember several days of furious coding in which I commited far more then 10 times per hour, after ditching the ingame editor. I believe it's the way most people learn a new language: change one line, commit, see if it works, rinse and repeat. it will also interfere with "printf" debugging.

I understand the devs might want to prevent excessive use (such as an external bot continuously changing code), but that should be addressed differently (increase CPU cost of uploading, use more elaborate limits, or just ignore it for now and monitor + warn players that do that)

looking great!

One suggestion: I'd love it if the shard-portals were way more rare, and if they not only occurred in highway rooms. It would add strategic value to holding certain rooms and zones for alliances. It will also help in making shard populations evolve independently from each other (other players settling the same space). As it is now, new players in shard1 may get squashed often by their upstairs neighbors.

For clarity, I'd also suggest using different naming, like "conduit" instead of "inter-shard portal", since their mechanics are very different.

ok, thanks for clarifying, that sounds reasonable.

is this an account wide limit of one deal/send every 10 ticks, or a terminal limit ?

Meaning if I own 20 rooms with a terminal each, can I still do 2 deals per tick on average (by using all available terminals, taking cooldown into account) ?

I'm sure it's a tricky balance.

I disagree with removing it entirely, as ultimately we need a way to discourage bad code because too much of that will impact everyone (longer ticks, higher server costs ...)

I do believe we need improvements to the way it's reported to the player and perhaps also its fairness (now, it's sometimes caused by things outside of our control. this is very demotivating) but I understand they're working on this. It should have a higher priority then developing new features.

that is great news

I propose a single flat universe, partitioned in concentric zones centered around the core.

Z0 zone (core): anything goes

Z1 zone: anything goes, except any power creep is temporarily "downgraded" into it's Level 1 equivalent (until it returns to the core zone, where it's reinstated)

Z2 zone: powercreeps have no abilities at all.

Z3 zone: T3 boosts have the effect of a T2 + the restrictions of Z0 to Z2 apply.

Z4 zone: boosts have no effect.

etcetera. essentially, like the "zones of thought" from Vernor Vinge series.

Every now and then the zones expand.

Advantages:

- new players on the outer rims don't need to deal with the full complexity. However if they survive in one place long enough, they'll be forced to.

- experienced players can't project their full power to any point on the map though portals or jump rooms, it's restricted (based on the skill level of the neighbourhood)

- there suddenly is real estate worth fighting for. Being in the center has economic advantages (as well as risks)

- outer players can fight the center on equal footing and gradually test new things (even if boosts have no effect, they can still be applied outside, and become active inside. same for power creeps)

- easy to explain, easy to reason about, increases game depth, and (I think) reasonably easy to implement.

This mechanic offers lots of room for further tweaks to balance gameplay.

For example, it would be fun if zones can change shape unpredictably or due to in-game events (lots of creeps lost in a block -> downgrade the zone. lots of GCL praising -> increase it. etc)

Zones could have different levels of minerals and power, etc.

"But the need to compete with established strong players will push a lot of new players back from theze zones. -- Artem"

I do not understand what you mean here.

This is what I'm afraid of:

1. new player starts, joins a Novice zone

2. never gets seriously attacked, so very slowly (with pre-boost code and limited experience in battles) reaches 4

3. gets wiped by an established player once Novice zone drops

4. is forced to start in a murder zone and suddenly has to deal with a greatly increased game difficulty.

5. after several bad restarts, quits the game.

Basically, the difficulty increases (even more) steeply then today.

This feels a bit like an engineer's reaction on dealing with laws.

To me there the rules should be based on broad principles (don't cheat, use common sense, etc), not narrowly defined use cases set in stone.

If a clever loophole in the rules or inventive use of a game mechanism allows one player to amass vast and disproportional amount of "power" (not the resource) to such an extent that it's not fun for anyone else, the devs should be able to step in and change it to balance the playing field.

However at this stage, there is no evidence that your approach is feasible. How many people would like to pay for a completely afk game ? Also, perhaps the rest of the players will band together and squash any clone popping up.

I'm all for experimentation, so to me, sure, go nuts and implement a clone swarm. And when (or if) if becomes so successful and wide used that it effectively breaks the game, the rules or game mechanics should get changed.

One possible change to make clone swarms harder: put on each player page a "is a clone" % likelihood indicator (perhaps based on comparing code snippets - I realize this cant be done with 100% accuracy) + disallow deliberate code obfuscation.

GCL4 is a pretty low value, with some luck its easy to reach in the first playthrough in a Novice zone.

Could the GCL requirement be increased or can it be dropped altogether as requirement ? Not having a room limit is already a significant incentive to choose blue instead of green. 

I fear that the blue zones will become awfully crowded after a while with still fairly new players. After all, Novice zones can only contain <4 GCL players, so the aggression levels there will drop.

Additionally, it feels weird that having a higher GCL becomes a drawback.

Agree, and I can't think of any reason not to (besides the effort for the devs to implement all of this)

To balance it cpu-wise, I would propose that if user code bypasses "userland" checks and then fails the intent in the server layer, it could be penalized with a large constant cost.

I'd love to have more options to write efficient code.

Ideally they should come with trade-offs such as direct access to intents idea (lower cpu cost, more challenging to use right) with a penalty for getting it wrong (higher constant cost if conflicts do arise)

As a new player this opinion may not hold much weight, but I'm going to disagree with the notion that raising GCL once past 28 has currently not enough benefits or that the 7 top players who did achieve this should be catered to specifically. First, being high ranked is a status thing. Second, the increased room limit past it does have (some) benefits. It can be used to own an earlier reserved room without fullly developing it, which means:

1. no reservers are needed (smallish cpu saving)
2. reduces the dropoff distance for remote sources using a lone termina (smallish cpu saving)
3. an extra source-keeper-free minerals (smallish cpu saving, also makes balancing minerals easier)

Instead of investing time in changing or developing things that benefit a few players, I'd be happier with progress on general improvements that benefit everyone equally (or give everyone reason to rewrite their codebase, such as the visual thing)

On how to stay engaged once hitting the ceiling: I don't have any ideas. I suspect this is a problem that can not be solved using game mechanics, every MMO has it in some way. No matter what improvements for the players past 28 are added, at some point they'll hit a new ceiling. Even if the restrictions on GCL and cpu were to be entirely removed it'd get boring after a while (infinite growth at a linear rate)

I hope that the power creeps, other future enhancements and the excellent user community are enough reasons to stay engaged for now