@o4kapuk said in Season #7 announcement:
Upper areas are teeming with resources, while the lower areas present a more challenging landscape
So this seems to be ~2/3rds 2 source rooms up top, vs ~1/3rd on the bottom.
Does this include score spawning more at the top, less at the bottom?
Does score choose a room, then a spot in the room? Or does it choose a spot from non-wall spots? That is, does a room with more walls get the same or less score than a room with fewer walls?
It sounds like you're bashing something you don't understand, while trying to create a competing product that you don't seem to have any progress on in the last 3 months.
Literally nothing in your comment there makes sense. The whole point of the game is that your bot plays even if you don't have the game open.
What is touch abuse? I've never heard of any claim bugs. By deals do you mean market? Market works fine.
IMO @o4kapuk should just delete this whole thread, you're clearly way out of touch. Again, I'm normally one of the first to go after the devs for issues.
It's an excellent game!
I think with Seasonals, Arena and now Discord the game will grow well.
Were you ever able to find anyone for this? Would be nice to get one last snapshot of slack
Did this ever make it into the game?
Sorry but in my opinion (as someone who often has a lot of opinions on game devs), the devs are actually doing a great job.
Seasonal is really the only path forward for World.
Arena is the future for the game to grow overall.
World & Shards are already in a decent place. Could there be more balance changes? Sure. But adding too much more to them just increases complexity in an already complex game. There are plenty of rooms to start your bot in. Even if you get murdered occasionally, your progress is your code, not your RCL. Even GCL doesn't really matter.
Per discussions in slack:
Portals should start rare/short range, and increase in frequency towards the end. This helps accomplish many of the goals I talked about previously for smaller maps.
Energy gets very abundant at some points. However, "temple" rooms and power creeps - the two ways to increase energy use - aren't very feasible in season due to the time limits lowering their time horizon. Should seasonal see the removal of the 15e/t cap at RCL8? Or incorporate energy into scoring (eg having to process it first like power) to provide a new sink?
A further idea - being able to change a symbol using energy. It would cost X energy and Y ticks in a lab reaction to turn one tick in either direction per the wheel. This would provide an energy sink. This would allow better solo play, while retaining co op as the most efficient path. Good decoder choice would still be important, as the further away on the wheel the symbol is, the more lab time and energy it takes to make compatible. With a good choice of rate cap on a decoder, it may not be feasible to force 5 different symbols into it anyways.
Finally, a lot of us want to see the convoy lifestyle that would arise from no terminals at all. What if symbols couldn't be sent thru terminal? This would increase the value of locality of decoders. I think this would create an interesting counterbalance to the "maximize remote sources" meta of MMO, which was amplified by the "maximize score gathering reach" of season 1. This would mesh well with being able to modify symbols - with a far decoder, do you pay energy to transport, or to modify?
Even prior to the amazing CGP Grey video (https://www.youtube.com/watch?v=thOifuHs6eY) hexagonal grids have been known to be a better coordinate system for non-continuous grids.
https://www.redblobgames.com/grids/hexagons/ covers that in depth
Arena has already gone in the right direction eliminating rooms & adding persistent objects, let's complete the trifecta and get hex tiles!
Obviously some debate over how much effort, etc but the long term health of the game will be benefitted tremendously. Squircicle coordinates introduce a lot of 'jank' to the game, and jank limits playerbases.
@Gadjung Read what I wrote. Not GCL 22. 22 symbols. I went on to state that the idea I was putting forward applied to whatever style of alliance secured their symbols - few big players, mix of big/small, etc.
@Bogden If players want a publicly hosted safe zone to learn in, they should go to a novice zone on shard3. That's why it exists. Attempting to create global co op is entirely in contradiction to what makes seasonal interesting - the competition.
@Bazsi1224 I think you'll find this mechanic better for avoiding wipes. Anything that gets added to push that further is going to be artificial and to the detriment of overall gameplay.
I think overall, it's perfectly fair to say that seasonal does not need to explicitly cater to new players.
I do think it would be interesting to have a rolling shard that resets every 3 months. No leaderboards. Relatively large map. No rewards of any sort, but very low access token entry that gives 'subscription' to that shard independent of MMO shards. Gives new players another option of a place to start out & learn. But, this would be totally separate & independent from seasonal, which is on a good track right now.
@gadjung said in Season #2 concept:
@cribbit said in Season #2 concept:
A good economic bot should get you in the top 100. Your combat code should determine top 10.
There's ~140 players in this season with less than 50% having scored.
Yes, and this new seasonal mechanic solves that bottom 50%.
@cribbit said in Season #2 concept:
In a large map, a top-10 player is only able to indirectly compete on the leaderboard by exerting total dominance over their holdings to maximize gains.
That's not true. in large map top10 player needs to cooperate with smaller players to get access to highRCL decoders.
All that matters is # of symbols accessible. Once you reach 22, the benefit of pushing anyone else out will inherently always outweigh the cost of letting them stay, if those are the only options. By introducing a 3rd option - direct combat against the players close to you on the leaderboard - you gain interesting interplay. Only in a small map do you have the 3rd option. This rationale stays the same no matter what the alliance is comprised of.
In small map there is high risk of alliances, created by season1 top10-15 players, that will determine most of ranking.
Hypothetical Example
- 3 teams of 4 top15 players decide to take 6 sectors (2-3 sectors/player for optimal GCL-7/8 room setup), wipe anyone else within and 4-8 rooms around it, split code picking into assigned zones and do not fight with each-other (best in alliance wins, since breaking/fighting within alliance is too risky from ranking perspective for every member)
With big map it should reduce chance of top players clumping together. Example:
- Each of top15 players creates it's own kingdom with some smaller-player vassals as to not have to share code-picking with other top10 players
We are acting like anyone getting wiped, ever, is a bad thing. Wipes happen. This game has PvP. The question is whether those players are able to find some area to exist after being wiped. Even if we disagree on how map size impacts that being able to happen, the seasonal mechanic guarantees that vassal states will exist.
A smaller map is more interesting, period. We agree that a larger map means less fighting between players that are close to each other on the leaderboard. This is a bad thing.
Seasonal does not need to allow bottom 50% players to exist in ignorance of the rest of the server.
This concept is perfect. It give the co op that so many of us asked for, while also providing some nice natural ways for the lesser players to still have fun & score.
I am always in favor of smaller maps, as it gives more meaning to controlling territory. In a large map the question is not how to secure a given bit of score, but to spread as wide as possible and avoid all combat. The cost/benefit of fighting for what you know vs just spreading in the other direction is too far towards 'just spread'. In a large map, fighting just means both you and your sparring partner drop in the rankings, so you avoid fights. In a small map, everyone has to fight, and you have to figure out how to fight well. A good economic bot should get you in the top 100. Your combat code should determine top 10.
A smaller map benefits smaller players. In a large map, a top-10 player is only able to indirectly compete on the leaderboard by exerting total dominance over their holdings to maximize gains. They must maximize these gains better than their other top-10 counterparts, as that is the only path to victory. However, if portals and map size make them neighbors with their true competitors, then they can compete via directly fighting over rooms and score.
Finally, I think that when you allow lower players to score, even if they get wiped often, they will still enjoy the season. This mechanic will give them the option to be taken under the wing of a bigger player if they want a higher degree of safety. Even if you think a larger map makes smaller players not in an alliance less likely to get wiped, it's not necessary.
Also, an increased amount of score spawning will make it rapidly apparent that you need access to as many symbols as possible to be competitive. Alliances of larger players can hope to negotiate amongst themselves who places how high and wipe all the small players near them, but that won't remotely cut those players off from spawning elsewhere near more amenable players, which is all that matters. Seeing the wipes of this season, and thinking it apply under this new mechanic, is at best misguided. The incentive structure is completely different.
Why would I need an apology? He never got combative, just... not great communication about the desired outcome.
As was said by the devs in the other thread, they do not want pixels to be generated via an in-game thing.
@artch said in Game.cpu.generatePixel change:
I still think we need a simple elegant solution here, not a whole lot of new API and inter-tick state data. Currently only two alternatives are on the table: cancelling intents or 10000 CPU cost. Let's discuss them.
Definitely.
I would like some clarification on game mechanics though.
My understanding is:
You have 20 + GCL * 10 CPU for the tick
If you go over, you can use up to 500 from the bucket, if available
If you go under, any excess is given to the bucket, which is capped at 10k
So a 10k generate pixel would nuke your bucket, but you'd still have your CPU for that tick?
If so, I think that is the best solution. It introduces interesting challenges around your bucket not always being there.
@artch said in Game.cpu.generatePixel change:
@cribbit But then you will lose the entire tick, and not just intents?
Do we not get CPU allocated per tick?
I thought it was:
You have 20 + GCL * 10 CPU for the tick
If you go over, you can use up to 500 from the bucket, if available
If you go under, any excess is given to the bucket, which is capped at 10k
So what I'm saying is:
generatePixel costs 10k from bucket, plus however much CPU you do not use that tick (eg 150 CPU given for that tick, you use 50, the last 100 does not go to bucket)
So the tick you generate pixel and the tick after you cannot use bucket, and the ticks beyond that you have to be careful to gain some buffer back before you do anything big.
That, to me, would be a much more interesting challenge, and one that goes to the core of the performance question of the game. (it also doubles pixel generation cost, which I think would help with their pricing)
I think the only concern with that setup is it does not play nice with VM resets, so we would either need some indicator that a reset is coming (which I'm assuming can't be done?), or be given an arbitrary higher CPU cap on a VM reset tick.
@artch said in Game.cpu.generatePixel change:
Another suggestion that we discussed initially as an alternative for this new cancel rule is raising the bucket cost from 5000 CPU to 9900 CPU. What do you guys think about this one? Can you survive the next tick without skipping it after
generatePixelcall?
I like that a lot more. Tbh even make it the full 10k, and extra CPU from the generation tick isn't given to bucket.
@raskvann said in Game.cpu.generatePixel change:
Gadjung was suggesting adding a new game object (new structure) to cross-highways that facilitate getting pixels, artch was saying they weren't considering adding new game objects (or structures) to the world for this. You're talking about two different things.
Pausing every object of yours isn't a good idea, don't get be wrong. But artch wasn't contradicting themself.
It says challenges that involve world game objects not implementation of new objects. This is pixels interacting with "world game objects." It is blatantly contradictory.
Also, other self-contradictory statements:
@artch said in Game.cpu.generatePixel change:
Just a routine balancing change, no big deal.
vs
@artch said in Game.cpu.generatePixel change:
There is no "problem" we are trying to fix. Quite the opposite, we want to create a new coding problem here for those generating pixels. We want to create more coding challenge in it besides simple CPU consumption.
We understand some may get upset since more coding efforts now should be put to continue generating pixels. But this is exactly the idea. Challenges are fun!
Is it a balance change, or is it trying to create a challenge?
If it's a balance change, what was out of balance?
