Ted, this frustrated me recently and has before. I was extremely disappointed that you backed out of leading what might be an excellent chance for reconciliation between the devs and us. If the goal is to improve the state of things, you can't just raise issues and attack without being willing to take steps to solve them.

Honestly, you have some good ideas and do a lot technical things for the community, but I think the tone you take has a tendency to turn discussions into arguments. I do think we've got a great opportunity on our hands though.

Hopefully artch will aim to deliver what the community wants, so if others share how we feel then they'll want to do whats best for their players. I have faith, I think this game is really cool and we all want it to succeed here. Part of how we get there is keeping things civil.

artch I do want to make sure that everything remains open to the public so we can see the raw survey data.

@knightshade Agreed, and thank you. In the end, we the players want to play a game that is fun and rewarding, and the developers want to create a fun and rewarding game. That requires mutual collaboration and understanding.

@artch Excellent! Glad we are on the same page. I think having data open to the devs and users on what the overall playerbase wants will go a long way to reducing the friction that has been developing lately. Transparency is always good! I'm excited to see the results.

@artch I just arrived at the same conclusion in the general slack an hour ago, that we need real data. We are working to put together a survey in the #survey channel to go out to all screeps players. We want to make sure its a collaboration, so we should work together once we get further along in drafting it.

@eduter Definitely not haha. I have mine running at 5 ticks a second

If you make a mod for it I'm definitely willing to give it a shot! I think almost everyone's bots would die a horrible horrible death as their owned rooms get deleted from the errors everywhere.

To keep everyone up to date, we are currently in a testing round. People are free to spawn in, develop code, and debug. We'll begin the next round in 1-2 weeks.

Hey @artch and @o4kapuk , thanks for the responses!

I think we should be a little more concerned than "Sometimes it just happens." when it comes to the gameplay. It would be valuable to do some serious research into it to make sure that we maintain a stable playerbase. The reason many of us are invested in this game is the very active community. If that starts dropping away I think we'd see exponential player loss, so always something to keep in mind.

I think this game benefits from something few other games have, which is a very strong technical knowledge base among the players. Many of the people attracted to this game would be fantastic resources to draw on for overcoming technological challenges or assisting with the implementation of features. Almost no other game gets the opportunity to leverage that outside of mods! I think @tedivm has the right idea here where it should be given at least some test features that the community can open source contribute to. If it doesn't work out nothing is lost.

My question 4 about pros vs noobs: Right now we've seen the downsides of new players joining the game. Shard1, supposedly a zone for new players to thrive, is instead of bloodbath for everyone who is not an established player with advanced code. I think shards would be a fantastic opportunity to have a shard focused on allowing new players the freedom to grow and practice against players of similar level.

Finally, my largest personal concern: the tick rate. For me, and for the friends I've had that quit the game, this has been the number one negative experience. The long times make it very hard to develop, as you need to block off multi-hour long time frames just to see if your code is working. Trying to make attack code or check if a major change is working usually means you update your code, get an email about an error hours later, and then when you're next free you have to struggle through broken room history to find out what went wrong. Please, reconsider the tick times. As a player, without perfect room history or reasonable game speed, development is an incredibly frustrating experience. I tried to show a couple of friends the game to get them interested. They were excited to hear the concept and I showed them some attack code. I sent a few creeps to go attack a neighbor and then said we can check back in an hour when the creeps get there and they looked at me like I was crazy and instantly lost interest.

Thank you both for taking the time to respond.

We had a detailed discussion on what players are looking for moving forward. I copied most of the messages that were most upvoted in the slack channel in the image above. We ran into a few main points:

1. What is the target tick rate for the majority of shards?
2. What are the main reasons for players losing interest?
3. Is there anything that devs feel a fully automated code base should not be able to do that a ui player can?
4. Should the core world be balanced for newbies or veterans?
5. Different rulesets for shards. Should we have a shard specific to newbies only, and have endgame shards with automation only?

Further discussion covered a variety of incentives to help maintain and guide new players through the game. The best ideas were milestone rewards. Examples:

1. On reaching RCL 6 first time, receive an email with a quest to build a terminal. Player is rewarded with some credits and a brief guide to the market when they complete it.
2. Players receive a reward when they hit milestones like GCL5 (growing up), GCL 10 (force to be reckoned with), GCL 20 (big leagues)
3. Players receive a large reward when ending a month in the top 100 of the leaderboard for the first time (a few days of subscription time?)

How about not having a min cpu but instead have a baseline bucket that lets your code execute for a few ticks. That will let your code request more cpu when it sees that it needs to, allowing isolated code execution rather than each shard managing the other ones.