Season #2



  • @bogden said in Season #2 concept:

    The reason I say this iteration on seasonal may be a step in the wrong direction is due to the added element of required social interactions with other players, meaning diplomacy, deal making, backstabbing, and more. Screeps is primarily a game for programmers, by programmers, and I believe that these forced social elements will further deter new players from joining the game.

    Or old players from joining the season. Personally I feel a player's performance should be measured by how well their code performs, not how many freinds they have.

    IMO most of the calls for co-op in the previous thread were calls for global co-op, where everyone cooperates toward a single goal and there are no winners or losers. I think that might be interesting. Team based eco-wars, which sounds like this is heading toward, sounds a lot less interesting to the point whether if the rules outlined in the OP were used I'd be at most 50-50 on participating, probably leaning toward not bothering. If a pre-made team of 5 players beats a team of 3 players by virtue of having 5 players instead of 3 that's not really very exciting. The game scales too well with player-count-on-team (GCL, CPU). It would have on season 1 as well had it gone that way and I think it's a step in the wrong direction to encourage rather than discourage this. For example: if all YP players decided to co-operate I think we'd see YP players 1st and 2nd. That'd be decided before the round even starts.

    So, global coop would be ok. Some other system to allow new players to participate safely. eg. as suggested in the thread, a world with non-uniform scoring resource distribution so the top players would be forced together leaving the larger and less valuable areas to newer players. Forcing co-operative co-operation is not good IMO.


  • Dev Team

    Global co-op, where everyone gets the same reward, is not something that we are in position to discuss within the current idea of the Seasonal World with the Access Keys entrance fee. If everyone gets the same reward, then the reward will be tiny, since we cannot reward 200+ players with some significant resources. And if nobody is rewarded with significant resources, then paying Access Keys to join will be much less appealing.

    We have to only stick to ideas that imply that only a few people get significant reward.

    👍

  • Dev Team

    @bogden said in Season #2 concept:

    From a design goal perspective, I believe a couple of things would be good for the game's long term prospects:

    New players feel comfortable joining, learning, exploring, and improving their code in a safe environment.

    New players can spend time working solely on code and not interacting with other humans until they feel ready.

    This is valid only for the Persistent World (or even a private server). The Seasonal World is different, it's a competition, you are supposed to interact right from the beginning, and as much as possible.

    👍


  • This post is deleted!


  • @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.



  • Could make it so the more of 1 symbol you score, the less score you get, forcing you to get as many as possible to obtain the highest score you can

    👍

  • Dev Team

    @squishproxy This is interesting! We need to figure out a proper implementation for this mechanic though.



  • Possible Co-op incentive to consider:

    Make it so scoring in a depositor you control yourself gives you 60% of the score for your deposit, but that depositing your score into a depositor owned by someone else gives you 80% of the score and gives the owner of the depositor 20%.

    This incentivizes not only for you to co-operate with others to get more score, but incentivizes players to let others deposit.

    (This is much less interesting then player made "taxes" schemes but more accessible for newer players since the taxes would be guaranteed.)

    👍


  • Maybe so that transport creeps have the distance to make it to allies decoders and back, make transport creeps get renewed to full TTL when they turn in score?



  • @artch Although you've created the Seasonal world as a competition, I believe it has the potential to be so much more. It's an excellent sandbox to test out new and innovative things, and give you full liberty to try some really creative explorations outside of the realm of regular screeps gameplay.

    As far as new player goals are concerned, I think seasonal is a wonderful format to get people started in a friendlier and safer environment without totally messing up the core gameplay of regular screeps.

    Alternatively, you could potentially create an entirely separate fully co-op MMO world, but this is a significantly larger undertaking.

    @artch said in Season #2 concept:

    We have to only stick to ideas that imply that only a few people get significant reward.

    As far as paying for season in general, I'd caution leaning too heavily towards the feast-or-famine reward model, as it strongly disincentivizes participation from all those but the most elite, which isn't good for the long term health of the game.

    For a global co-op season, I think you might be underestimating the willingness to pay for access keys to a fun and interesting coding challenge as its own intrinsic reward, again, particularly among new players. Doing a marketing push on coding school platforms could potentially do really well.

    I'd also suggest that limited edition cosmetics are always an enticing reward. Giving limited rewards as CPU tokens could additionally go a really long way towards converting non-paying players into lifetime subscribers. $10 in access keys as an entry fee, $3.50 in CPU tokens as a reward, plus a limited edition non-transferrable cosmetic. Choosing to scale the reward up or down based on time to goal completion is entirely optional, but a fun incentive to put up for players.



  • @artch If you keep the score separately for each type, you could sort them by value DESC. Each index would increase the multiplier to reward having score equally in as much as types possible.

    Example: Player AggressiveNoobSlayer wipes everyone and gets 1k score op type A. His score is 1000.

    Player FriendlyNeighbour works together and gets 500 A, 250 B, 150 C and 100 D : 500 * 1 + 250 * 2 + 150 * 3 + 4 * 100 = 1850.

    Those are extreme examples of the multipliers but make it easy to explain. Also: Have you considered sharing the score between the room owner and player that turns it in? This would prevent an alliance boosting a single player which is the biggest concern with enforcing team play IMO.

    This would force me from wiping everyone around me with the proposed rules to actually work together. Please don't forget about the players which actually want to see FFA gameplay, maybe alternating the seasons with FFA and teams?



  • @bogden said in Season #2 concept:

    As far as new player goals are concerned, I think seasonal is a wonderful format to get people started in a friendlier and safer environment without totally messing up the core gameplay of regular screeps.

    I think this is an interesting point. I think the opposite: seasonal should be a competetive environment compared to the tame MMO experience that most people have. MMO is friendly and safe. Seasonal should be more competetive.

    The challenge is to have it competative at the high end and at the low end. I think season 1 struggled there. It's not yet clear to me whether the rules proposed will change this: eg. a strong player has little incentive to keep a weak player with a score type the strong player (or a strong players' alliance) already owns alive. The rules heavily favour pre-season organisation, which I think leaves a lot of weak or new players behind.

    I still think the best way to achieve competition across all levels is to make the world non-uniform so there are good regions where strong players will want to be, and worse areas with less reward where lower level players can only have other low level players as competition.

    👏👍


  • @tigga said in Season #2 concept:

    I still think the best way to achieve competition across all levels is to make the world non-uniform so there are good regions where strong players will want to be, and worse areas with less reward where lower level players can only have other low level players as competition.

    For non-uniform world, my issue is that it leaves bigger parts of it less-usable and discourages respawning into 'worse' zones. Weaker players are not much affected by that since they don't have codebase with features that would get impacted by that. For 'medicore' players that starts to be a bigger impact.

    So from good player perspective 'Center' makes sense, for weak-player there's no difference, for medicore one it's either center/close to center and then respawn into worse area after wipe, or just start in worse area and have a boring/limited play



  • @gadjung said in Season #2 concept:

    @tigga said in Season #2 concept:

    I still think the best way to achieve competition across all levels is to make the world non-uniform so there are good regions where strong players will want to be, and worse areas with less reward where lower level players can only have other low level players as competition.

    For non-uniform world, my issue is that it leaves bigger parts of it less-usable and discourages respawning into 'worse' zones. Weaker players are not much affected by that since they don't have codebase with features that would get impacted by that. For 'medicore' players that starts to be a bigger impact.

    So from good player perspective 'Center' makes sense, for weak-player there's no difference, for medicore one it's either center/close to center and then respawn into worse area after wipe, or just start in worse area and have a boring/limited play

    Why would it be boring/limited? You'd still be competing against others in your neighbourhood and it would be more fair competition and more likely to be fruitful as you're likely competing for similar scoreboard positions.


  • Dev Team

    @qzarstb said in Season #2 concept:

    If you keep the score separately for each type, you could sort them by value DESC. Each index would increase the multiplier to reward having score equally in as much as types possible. Example: Player AggressiveNoobSlayer wipes everyone and gets 1k score op type A. His score is 1000. Player FriendlyNeighbour works together and gets 500 A, 250 B, 150 C and 100 D : 500 * 1 + 250 * 2 + 150 * 3 + 4 * 100 = 1850.

    So this is only the final result, but how do we display the ranking during the season? We somehow should display score for every symbol then.

    Have you considered sharing the score between the room owner and player that turns it in? This would prevent an alliance boosting a single player which is the biggest concern with enforcing team play IMO.

    How exactly would it prevent that?

    Please don't forget about the players which actually want to see FFA gameplay, maybe alternating the seasons with FFA and teams?

    Absolutely. We have just started to experiment with different ideas, and future seasons will introduce more such experiments. For example, we might want to try some global co-op mechanic in Season #3.



  • @artch Chronicle would still show total score (but perhaps periodically cached values in stead of real-time). The type-specific amounts could be shown when you select the deposit structure.

    Sharing score with room owner/depositor does not fully prevent in-alliance boosting but it would at least be limited. The "boosted" player would only get half the score from everything he deposits in rooms owned by his alliance mates. This would also result in the small players getting score on the board if an aggressive neighbour forces them to give their score (like what smaykit and I have this season).


  • Dev Team

    @qzarstb said in Season #2 concept:

    @artch Chronicle would still show total score (but perhaps periodically cached values in stead of real-time). The type-specific amounts could be shown when you select the deposit structure.

    We cannot display properties of a player in the info panel of an object. Actually, we don't have a place in the UI to display these separate score, it would be accessible only through the API (like Game.symbols).

    Sharing score with room owner/depositor does not fully prevent in-alliance boosting but it would at least be limited. The "boosted" player would only get half the score from everything he deposits in rooms owned by his alliance mates. This would also result in the small players getting score on the board if an aggressive neighbour forces them to give their score (like what smaykit and I have this season).

    What about scoring in my own rooms?



  • @artch before you do a coop season I think you're really going to need to implement a way for player scripts to send messages to each other directly. The public segment is ok for alliances, but it's no good for more ad-hoc interactions, and creep.say() is far too limited for this purpose.

    Edit: "public segment", not interShardSegment!



  • @systemparadox I don't see how public segments or terminal.send descriptions don't fulfill that role.

    👍


  • @robalian said in Season #2 concept:

    @systemparadox I don't see how public segments or terminal.send descriptions don't fulfill that role.

    Public segments are a pain to work with. You have to constantly poll it instead of receiving an event. There's no way for the other side to know that you got the message unless you setup some sort of acknowledgment system and they also poll you.

    If you've got two people closely cooperating you can make it work, but it becomes messy fast if you start to involve more people. Everyone has to parse the entire segment all the time, even if most of it is meant for other people, which is a waste, it's confusing, and there's no privacy - everyone can see everything in the public segment. If you've got a large alliance the best option is to designate some as a "master" to coordinate everything, but then that person has to poll everyone else, and you can only read one at a time so now it's really slow.

    It's completely useless for ad-hoc communication. If I want to setup something where my bot will automatically negotiate and provide some service for exchange or fee, I can use controller signs or creep.say to broadcast this and public segments to provide information. The only way someone else can engage with this is to move a creep into my room and use creep.say, which is far too limited.

    Descriptions for terminal.send do nothing to help this (as an aside, why can we only add descriptions to terminal.send and not terminal.deal?). Why do I have to waste terminal cooldown time to send a simple message? What if I don't have a terminal, or any resources to send, or I'm busy, you know, using it to actually trade!!? Or you don't have a terminal, or your terminal is full?

    Besides, terminal.send isn't even an option in seasonal, as it's disabled between players.