> Maybe you just meant this as good-natured ribbing, but I hope you can see how it might be interpreted as condescending. Not only is it possible, it is likely. If you can't see that, then I propose that this is the root of the problem. You should probably ask yourself why it keeps happening for you.
Very fortunately for me, the incidence with you is the first time I've encountered it. I've explained things, jokes and otherwise, to vvr numerous times. Ask him.
> Not everyone gets the same story about what's happening, even when everyone involved communicates as clearly and openly as they know how
I just want to highlight on what bovius has said here, as I think it is an important point. Communication _is_ hard, and even with the best of intentions, mishaps exist. The best online communities I've seen tend to have an unwritten rule of asking members to be charitable to one another. That is, to presume everyone is acting in good faith, and miscommunication should be the first line of assumption, rather than malicious or dishonest intents.
I'd like to ask that to apply to all of us here. As it happens, saying enough things and we are bound to make fun of ourselves a couple of times. It is then fairly meaningless to pick on individual sentences/ phrases/ wordings as a justification for others' wrongdoing. Words are a meant to deliver intentions, as necessary as they are, they are not an end to itself.
Just as an example, and I don't mean to be picking on bonzai here. It's just the easiest one I can find an example of - it could have been another quote had I found one in this thread:
> With the sacking of so many rooms, each player’s sense of sportsmanship is put to the test.
Most of the most damaged players: Skorp, DT, vvr are all acting in exceptionally good sport. It probably can't be overstated that these guys had a cool head (I'd make a joke about vvr here, but then he wouldn't understand and I have to explain it to him again). The specific statement is therefore of questionable truth. But that is hardly irrelevant to the point bonzai was making: that was a shitty weekends for us.
From the principle of charitable reading above, I'd call for everyone to stop he-said she-said, as it is evidently not productive. With the latest development today, it's safe to say that we are all pretty confused. I know I do.
And this is a bit out there. But even though I called bonzai's quoted statement "of questionable truth" because of specific circumstances, it is in fact a safe prior for normal cases: as the war goes on, it is likely to be more salty (this thread by itself isn't enough to be resolving it, unfortunately). If at all possible, I'd like to have a cease-fire for 7 days for all fronts. This is, after all, a week of gratitude. And this is unrelated to any potential strategic implication in the war. In fact if anyone want (and the ceasefire is reached), you would have my words that I will not work on a single line of code related to any war plan during the week.
Yes, some might benefit from it, and some might lose some advantage. At this rate, this war is gonna end with several players leaving the game. This is coming from my experience playing other cutthroat games. And yes, that would include myself -- I take great care in interacting with others, and being called "toxic ramblings" does, in fact, bother me.
At this point, I'm more interested in still having a place to chat, and a game to play, rather than the consequence of the war. The war did expose some strange (not just in balance, but enjoyment) mechanics in the game, and that is on top of the apparent degrading in community's mood
I don't have any suggestion right now, but I would like to emphasize what heggico has said.
> What I would like to see is that its easier to take single rooms, but way harder to completely wipe a player.
Artem: thanks for the reply. I thought so about using the market too.
Realistically speaking, I can envision both case where the mechanic works out or fails. I don't think there is any way to know for sure except having it in place -- success or failure would depend on how the players adapt to it. The main risk is that being a big change affecting everyone, you really don't have much place to test it much (of course you already knew that).
So from now on, explicitly you are supposed to grow your empire together, and any lone room will just be a liability (broadly speaking) ?
@coteyr: you got your reasoning a bit backward: if there are too many limits and everyone is doing the samething, you will never catch up. Variety is how someone can gain some advantages and catch up.
Andhard: The room data can be downloaded here: http://www.leagueofautomatednations.com/map/rooms.js . It's updated daily. And if you haven't seen it yet, I'd recommend to check out http://www.leagueofautomatednations.com/map :-).
No. Containers, roads and walls are neutral structures, no one owns them.
To add on to my previous comment, I don't mind if you make all rooms having 2-source AND nerfing their energy + reservation limit to GCL*3. My concern was more on the fact there would be a lot of rooms unused otherwise, which I dislike (it would limit some kind of room design/ game play). You can tweak the energy output to get to the number that you like.
If we go with the cap of 3 reserved rooms per 1 claimed room, can you just make all room having 2 sources right now? Otherwise it's just incredibly annoying with large swath of rooms being empty -- realistically no one will ever claim 1-source room anymore, nor reserving them.
With safe mode having 20k ticks duration, can we have the safe time period configurable? Ie. `activateSafeMode()` would take a number less than or equal to 20000 and the safe mode duration will be that many ticks, optional and default to 20000.
Atavus: if a player does not have daily access to the game, the safe mode system would not be helpful for them. That reason is partly why I think this design is a bit against the theme of the game. Without safe mode any player in a war can take shot at the other at their convenient time. With safe mode, it will let the one with more consistent daily online time some advantages (imagine the changes in a war between someone that can go only twice a week and someone that can go online daily, with and without safe mode). I do not know if said advantage is significant or not.
I agree with the design of having battle and siege to be more drawn out, but is it possible at all to tune the game without adding a mechanic for it? Specifically, make it takes longer to take down wall -- may be dramatically decrease the damage AND cost of the WORK and ATTACK part on wall? Since there is a limit of space that you can put creeps on, it will just naturally make siege last longer.
There are a couple of source keepers' rooms missing source keepers, they're in lower right quadrant of a newbie zone. Check W14N44 and the newbie zone around it.
- Spawning creep isn't an issue, at least not for me, since it's still a normal creep. I didn't check in detail, but at least some of the attribute of the dummy object in Game.creeps is different than an actual creep. I think it's missing body parts, causing some small issue with my planner code. Spawning creep doesn't cause an error, dummy creep does, so I have to check for ` id ` . Just to be clear, I thought it was a good change to address the issue for new comer too. But after the code went live, several players have problems with it in one way or another.
- The inconsistencies between ` Memory.creeps ` and ` Game.creeps ` could be made clearer by making clear that calling ` .createCreep ` with memory is actually just setting value in ` Memory.creeps ` , and remove the memory clean up part in the tutorial code -- it's not necessary, and I think by the time they notice their large memory usage, they are used to the game model to know what to do.
The change is not a big deal anyway. But I'm worried we will see more new players with different bugs from that. We can wait to see if it actually causes issue.
I understand the reasoning behind trying to add those (addressing the memory cleaning issue of new players). But it seems to just introduce a couple new classes of code:
- Looping through creep, you have to check for .id always (it's a new mandatory check, and those types will cause bug for sure)
- "Why is dead creep still alive?" -- Because players try to spawn before checking for dead-ness. We actually had like 2 people with this issue earlier today I think.
- Iterating through Game.flags and Game.creeps while calling .createFlag or .createCreep seems like undefined behavior. I don't think it will cause issue most of the time with the for ... in loop, but it's conceptually murky to me.
- All in all, I think the old idea of having all calculations of the same tick being done on the same game state makes it easier to reason. In this new case, .createCreep and .createFlag modifies the game state. For example, does two call to .createFlag of the same name both returns OK, or will one returns an error code ?
Does Spawn.createCreep has the same slowdown as Room.createFlag?
In the docs right now, Flag.color and Flag.secondaryColor is string. But all the COLOR_* constants are number. I think the docs is wrong in this case.
It seems like RoomPosition.lookFor(LOOK_ENERGY) will also return mineral dropped on the group.