Posts made by Rajecz

I know I'm really late to the party, but I'm in a commenting mood and this topic interests me so I'm going to add my 2Cents. Bots are unavoidable but ultimately unimportant because at this point every player is already competing against lots of other players of varying skills and bots are just the same. Sure it would suck to start side by side with a friend and have them do way better than you because they install a bot and you write your own code, but if not your friend then someone next to you will do a lot better than you because they already have an established code base or rooms/resources that were already built up and this will happen with both bots and existing (non-boting) players.

I think the argument is that bots ruin the new player experience, but its actually just players ruining other players experiences and it doesn't matter if that player is running a bot or not. I'll admit that I have ruined lots of new players experiences, slaughtering so many players for territory that I didn't really care about and couldn't use. It didn't matter that I was running my own code, what mattered is that players felt they were being killed and helpless to do anything about it. Sometimes its because I had better code, lots of times it was because I had more resources, rooms, time, experience. At the same time I'd like to believe that I've also enhanced lots of new and established players experiences as well, through forming an alliance and cooperation.

In the end I don't think its bots that are ruining new players experiences, I think it is other players and the solution to that is the community. As a community we have the opportunity of molding the experience of those around us and if you want to create an experience then the best way to do that is to team up with others who feel the same and work together to create that experience.

I've been around for a while, but have (relatively) recently started over from scratch trying to go with the fully automated approach, and what I have found to be incredibly annoying is the data that is available to users through the ui that isn't available to your scripts. Information on other players GLC/rooms, market data/history, being able to destroy spawns in your owned rooms, and the worst offender of all zero info on novice/respawn areas. My latest experience has shown me that screeps has an excellent api for a semi automated approach, but when it comes to full automation, it doesn't make all of the data available to you that is necessary to make informed high level decisions.

I agree that multiple accounts should be allowed. That being said, by allowing multiple accounts I think other policies would need to be in place (honestly these policies should already be in place since while not allowed multiple accounts already happen). The biggest one I can think of is explicit policy around respawn abuse/harassment. I completely agree that multiple accounts should be used to play this game, but I don't think multiple accounts should give someone the ability to attack and harass another player in a way that they could not be accomplished with a single account.

While working on a fully automated bot, I've run into serious issues while working around novice/respawn areas. There just isn't any information available on respawn/novice areas except that which is only available through the UI. I've found no way in my code to determine when the walls come down, I don't know how far the novice wall extends or which rooms are contained within the novice area. I can't even tell if I am in the novice area or outside of it. Can we expose an api call that would either A. Give us the protection level of the room i.e. "novice"/"respawn"/"normal". Or B. Give us the status of the novice/respawn areas in the world i.e. decay time, boundaries, which rooms are protected.

I think it is great that the issue of attacking the controller is being addressed because as it stands it is extremely difficult to actually take territory from another player (or group of players). While I think a lot of these changes are great, I think there are a couple of them that will have unintended consequences and it is worth taking another look at them to really evaluate if this is what we want.

"attackController applies 1000 ticks of upgradeBlocked and decreases the ticksToDowngrade by 300 * <CLAIM_parts> ticks. The claimer creep will only need 1 tick to do this amount of damage. The creep will not be able to do another attack until upgradeBlocked is back to 0."

Will have serious consequences on lower level RCL's. Being able to attack a controller with just a single claim part and having that attack block upgrading for 1000 ticks will have a significant impact on a newer players progress. Also at lower RCL's where the downgrade timers aren't especially long just a few attacks will downgrade a room to a lower level.

"Safe mode activation is not possible when the controller is downgraded for 5000 or more ticks."

This is actually the one that concerns me more because when it comes to wall layouts I only really see two types of layouts, pull everything in and push everything out. Both of these choices come with serious benefits and consequences and I feel as though each favors different situations but they are both overall even. This change will have a major negative impact on pulling the walls in the room in and make the pushing the walls out an all around superior choice. I don't think we want the game mechanics to push everyone down the same path. Where this change will force a lot of players to completely rewrite major sections of their codebase as well as rebuild many of there rooms, it shouldn't be made lightly and I think we should evaluate some of the other options available to either accomplish the same goals or maintain a balance between play styles.

I think what a lot of people are upset about (at least this is my case) is that we feel we are being left out of the loop. This is the first place that I have seen anything mentioned about the focus being moved away from power creeps. It was my understanding that for the past 2+ months power creeps were the main focus of development. Most of us were expecting to be using power creeps for a while now and in preparation of that many players focuses have shifted away from GCL and toward gathering/processing power. I think what myself and at least some others are frustrated about is that we were never informed that power creeps were going to be delayed much less delayed so significantly. I think most of us in the community understand the need to switch focus towards things like optimizations, working in the programming industry I'm sure most of us have done this at least a few times throughout our careers. However at least in my job if I gave my boss a road map for a new feature, and then a month and a half after that feature was scheduled to be released I then told him that I had switched priorities a while ago and just never told him that the feature is being pushed 6 months back. I would probably be in a lot of trouble.

What I'm getting at here is that whats done in the past is past, but in the future I feel it would go a long way with the community if we were better informed of the situation. I can't imagine that it was just 2 days ago when the dev team decided that optimizations need to be the #1 priority. While screeps is a sandbox game there are a lot of us who do play it as a strategy game and I think most of us understand the need for changing priorities, but we would like to be informed so that we too have the option of changing priorities.

Hey devs I just wanted to reach out and ask for some open communication and signs of life. With the exception of the tweet about the perimeter expanding it has been a month of radio silence. I appreciate that you guys are probably incredibly busy with the conversion to pixijs and the implementation of power creeps, but I believe the lack of communication is hurting the screeps community. For example there hasn't been a monthly review released for March and we are half way through April. I understand if there isn't enough time or manpower to do the monthly review, but if that is the case I think it would go a long way to just let us know.

In the past Artem has been the main bridge between the community and the devs, but as far as I can tell no one in the community has heard from him in over a month. Is he still with the team?

Power Creeps are a highly anticipated feature release that in theory is arriving shortly (and they may very well be on track to be released on time), but no one in the community seems to know anything about their progress. The design docs were released and it was asked that we discuss them and there has been a lot of discussion had, but it has been a long time since anyone from the dev team has been a part of those discussions. Does that mean the discussions are over? Have you guys taken any of the suggestions that were discussed?

I realize you guys are probably busy but a little bit of communication would go a long way.

I think there may be some misunderstanding about the intent of the original post (which may be my fault for writing about an example which goes against how most players understand the game mechanics to work). The intent of this post shouldn't require a "defensive post", but instead the intent of the original post was to gather additional clarification on the novice/respawn zone creation intent and start an open discussion (hopefully with Artem and the devs) about ways to update the mechanic to meet that intent in a way that isn't as frustrating for the players.

I know that the specific documentation doesn't address most of the RL scenarios and I'm not actually arguing that there is a bug in the code that needs to be corrected or that the current mechanic is behaving contrary to what the documentation specifies. I guess what it boils down to is that there is a lot of confusion around the creation of novice/respawn zones. I don't believe that the confusion around their creation is the intent or required (Artem can correct me on this if it is incorrect) and so the original intent of this post is to clear up some of the confusion(Artem and devs required for this) and maybe discuss possible implementations that would eliminate it.

If you don't know what confusion I am talking about, it is based off of "At any random time any room not reserved or claimed could be turned into a noob zone or a respawn zone."

Coteyr the problem with the current "you must reserve/claim every room that you want" solution is that this is often times not possible (or at least reasonable) because of the distance from your nearest claimed room. In order to claim a room you just need to get a single claim part to a controller with 1 tick on it. In order to keep a room reserved you need to get a claim part to the room for each tick you want that room reserved. There are many times where my claim creeps make it to their destination room with less than 50 ticks left on them which is more than enough to claim a room, but would do little to reserve the room. With the current model to keep all of the useful rooms for that one room that I would want to claim I would need an almost constant stream of claim part creeps going to the claim room and each of the rooms I would like to remote mine (some of which won't even be reachable before a claim creep times out).

At your current size I assume you've never tried claiming a room this far away from and might even think, "why would you do that?", but there are lots of motivations for claiming a room that aren't just about resources. Maximum resources keeps an empire compact and close together, but many of the rooms I claim are for position and range, which encourages rooms that are spread around and far apart.

That being said the price is what the price is, what I am bringing up here is not that there is a price but rather that we don't know what the "actual" price is. Artem has said in the feature release thread that we should automate a response to the respawn warning signs going up, but without having the rules around the creation of these novice zones clear and defined, automation isn't possible. Again what I would like to see is a clear set of documented rules around the creation of these zones. Repeatable rules that given the same parameters it will always create the same novice zone and within the same time frame.

So I need to apologize for starting the conversation that I was hoping to have in this thread derailed. The example that I included here was meant to show the frustration that is the result of what I believe to be the underlying problem.

To be direct, I believe the problem with interior novice/respawn areas is that the players DO NOT know when these zones will appear and what rooms these zones include. I think the screeps warning signs on intended respawn zones were an attempt to solve this issue but I don't think the current implementation really solves these pain points.

The reason I don't think these 2 major issues, of when and which rooms, have been addressed with the current signing fix is that in my experience (and certainly no where that I have seen it documented) the amount of time from when the signs first appear to when the blue/green zones are created is not consistent or reliable. The second issue is that when the signs appear, we have no way of knowing what effect claiming/reserving a room will have on the overall novice/respawn area.

Artem, you are our only insight into the devs and the questions I have for you are. Is this information of when and which rooms intentionally withheld from the players? Do the devs have a plan for further addressing these issues? If not are the devs open to addressing these issues and potentially even receiving help from the community in planning and even implementing a solution?

This has been a sore spot for a lot of established players and I personally don't see the benefit to doing things the way that they are currently done.What I propose would be a viable solution would consist of two parts. First, define the window of time for which the warning signs are valid, something like warning signs will be converted to blue/green zones between 24-72hrs from the time the sign appears (those are arbitrary values and can be whatever you think is appropriate). Then if for some reason no one gets around to creating the zone in the time period, remove the signs and don't create a blue/green zone. And if you want to create another one later, start the process over.

Second, from what I hear in the community these zones are created manually. I think there should be a specific algorithm used to create these zones, one that is public and can be implemented by the players so that we know what effect claiming/reserving a room will have on the overall size of the blue/green zone. There are a lot of really smart people in the community and if the dev team doesn't have the resources to devote to the implementation of an algorithm to create these zones, I believe that there are lots of community members who would contribute to this problem.

There is a similar post in the change log article article, but I'm not sure if that is still being monitored so I'm opening a thread here.

Essentially I would like greater clarification on how we can fight the creation of respawn zones. It was always a ticking time bomb of when a novice zone would appear and it caused a lot of frustration. Then with the introduction of the respawn zone we were promised a warning system for when these zones would appear, which we have been given.

The problem is that we don't have any clarification on how to combat the appearance of these respawn zones. Yes claiming/reserving a room will stop the respawn zone from taking the room that has been claimed/reserved, however for most players a single room is useless and the respawn zones clearly have no problems strangling claimed/reserved rooms leaving them with very few resources to build up the room.

As an example, a respawn zone recently appeared in W65N15. The sector was marked for respawn ~3 days prior to the respawn zone appearing. After the warning sign appeared multiple rooms that were signed were claimed/reservered and ~2.5 days past with nothing changing. ~12 hours before the respawn zone appeared the signs were removed. And now we find ourselves with a brand new respawn zone consuming the majority of that sector. While the rooms that were claimed/reserved are not included in the respawn zone, most of the remote mining that would be done from these rooms are included in the respawn zone, making the claimed/reserved rooms no longer worth having.

I think a little more clarity around these respawn zones would help eliminate a lot of the frustration that is being experienced. If the respawn warning sign would be removed from rooms that are no longer in danger we (and our scripts) could clearly see which rooms we still need to reserve in order to protect our future plans (as I don't think it is feasible to keep 4-6 rooms constantly reserved from a room that is near a claim creeps maximum distance). The other possibility is to share the algorithm used to create these respawn/novice zones so that we can also implement it and be fully aware of the effects that claiming/reserving a room will have. (If this is still done manually then an algorithm should be written for it)

I'll add my two cents to the conversation since Hive may have helped generate this particular conversation (even though I realize these same question existed long before this event and will continue to be asked long after). I don't think we want to be playing this game dominated by botnets. I don't think the intent of this particular module is to take advantage of players who have long since quit the game but it does enable that. I don't think there is anything wrong with active players using automated communications to enact basic functions (resource help, passage through rooms, defense requests) but that isn't really whats being talked about here (even if that is what is being proposed). We are talking about controlling others accounts and I don't think that is anything that we should want to allow, but I also don't think that is anything that can be enforced by the game devs or the TOS. I think this is an issue that we need to address as a community and enforce as a community.

The current Hive event is an instance of this, we in the Hive see running others code as a problem. We watch the new novice zones that pop up and we talk with a lot of new players and what we have been seeing more and more often is that these new novice zones are being dominated by new players running others code, and when we talk to the other new players in the zone we are hearing a lot of frustration with not being able to compete with these other players who started playing at the same time but simply run someone elses code. Now I don't think opening up your bot code (bonzaiferroni and tooAngel) or having a shared downloadable complete code base (OCS) is against the TOS or should be restricted by the game developers, but I do think that in the screeps community when we see what we identify as a problem, we should act on it. This means we will all have different problems and all be acting on different things (I know on at least 1 occasion I have been identified as a problem) but I think that is how these issues should be worked out.

So I'd like to ask for some clarification on the purpose of the root controller, I first saw this brought up by Artem in a discussion by Dissi about the "feed one room, rinse repeat strategy" and then most of the discussion on root controllers assumed that the purpose was 1 of 2 things. The first being to counter that "exploit" and the second being to limit the growth of larger players. Honestly I can't believe that the purpose of the root controller mechanic would be either one of those two reasons because with the first reason it would basically be the devs saying that not only is that strategy not an exploit (which personally I don't feel like it is, it is just that a strategy), it is in fact a key game mechanic and the only way to play the game because root controller essentially forces everyone to do the same thing. And to the second reason, as others have stated this mechanic would be a much larger hindrance to newer players with more rooms that need to be leveled to 8 than the larger players who normally have a lot of their rooms already at RCL8. And some would say that the root controller also brings changes to the GCL formula but at that point it is just those changes that are going to slow down larger players and it has nothing to do with the root controller mechanic. I personally don't like the idea of the root controller because like others have stated it will strongly encourage a much narrower style of game play, but I am especially against the core mechanic change because I haven't seen anything telling us what problems they are trying to correct with it. I've read in other post about feature changes that this information (purpose and statistics supporting the change) are more often expressed in the PTR discussions but as there are a lot of posts to sift through, maybe when these discussions reach these boards here we could just include a link to the previous discussion.