Posts made by TodPunk
RE: On the topic of open source code bases
@trepidimous http://www.leagueofautomatednations.com/map/shard2/bots is helpful, if not 100% accurate.
RE: A way to set subscription to inactive without despawning
Kind of a vacation mode, where it holds your remaining for later?
RE: Introduce boosts one teir at a time rather than all at rcl6.
Personally I think this is a step backwards. Balance really should be about not giving too much power to one set or the other. In Screeps, your power is your ability to utilize mechanics in your code, not what mechanics you necessarily have access to. What we're saying with this change is that nobody will be able to establish a room in an area with RCL8s because they won't be able to defend against those rooms, regardless of their code, because they don't have access to those.
I want screeps to be code-centric, even more so than it is today, and this just makes it more room-centric. As @SteveTrov is pointing out, it's impossible to defend an RCL5 room against an RCL6. This a distinction in respawn areas, but quickly goes away. The majority of cases are RCL8s over there you need to defend against. If your code is good, you might be able to do so at RCL6 if you have the credits/friends to get the boosts to enable yourself.
We're already going the route of more disparity with power creeps. I don't think adding more to a mechanic already in game is going to help that inequality, especially when your power spawn is only RCL8
RE: WebGL doesn't seem to delete ramparts when destroyed
Maybe you need to destroy it before u abandon your room controller?
They /are/ destroyed. Like, they are actually gone. The display is just not updating to reflect that.
WebGL doesn't seem to delete ramparts when destroyed
I've been destroying my rooms today. Every time I run the following:
_.forEach(Game.rooms.<roomname>.find(FIND_STRUCTURES), (s) => s.destroy())
It destroys everything, but the display doesn't remove any ramparts. They're gone, but they're still drawn.
RE: Explicitly allow multi-accounting (with narrower restrictions)
Oh and if you don't have time for multiple accounts, why do you care?
More importantly, why doesn't everyone care? Taboos break communities (of games or otherwise), and frankly breed distrust. From the limited number of people I know that multi-account, it limits their participation in the community about what they can share and frankly I think that's sad because I think there's significant overlap between those that would multi-account and those that are passionate about various code approaches. That's purely anecdotal, though, so I can't claim it as anything but my hunch.
I want this to be another botting style opinion war forever, where it doesn't have to be this threat of "I'll tell Dad!" and instead becomes "you're botting, I don't like that, so I'm killing you." Great! That's how sandbox communities should be. You're multi-accounting, I don't like that, so I'm killing you. Can we verify it? About as much as we can verify bots, and maybe we develop better strategies for doing so, like LOAN is trying.
Explicitly allow multi-accounting (with narrower restrictions)
It's just time. The idea that alliances are allowed because of some perceived layer of separation ("you have to get them to agree") is ignoring the fact that the same criticisms of multi-accounting should be criticisms of alliances. In fact, several have quit in the past stating some of those criticisms about alliances in the first place.
I don't care about people's principles, that's their decision and I support them in quitting or having their opinions or whatever. What I do care about is interesting problems and not shaming something some people are clearly doing anyway. (To head off the conspiracy theorists, no, I'm not multi-accounting. I don't have the time to run, and if anyone thinks Jacoboco isn't really my son's account, they could just watch how inefficient he is at getting things done that I want him to, like taking over space so I can respawn right now.)
It probably needs some caveats, like only one Steam purchase should be allowed per person so an army of 10 CPU-ers doesn't just blanket take up space, but adding another account to the mix should be allowed outside novice areas. What are the concerns? Let's deal with the concrete ones, as opposed to the fluffy "it's not fair" things that don't have a place in a sandbox game anyway.
Reasons to do this:
- Increased revenue. If someone wants to go as far as taking over a shard with their subs, great, that's a lot of revenue, just create another shard instead.
- Less shame. Shaming culture is anathema to a community. Discourse is healthy. Shaming someone out of the community just means it's not a community worth having, and we've seen that happen here before, so let's just explicitly state "this is ok, so leave people alone about it." This also means we'd know more about who is multi-accounting and you can target them if you don't like it, just like we do with bots.
- More interesting problems. Right now my office mates and I are trying to do a cooperating AI, where it acts as a sort of hive mind. We're not close to finished, but it's showing some promise. What more can people do with this kind of thing? What ways can such an interesting scenario be used?
- Mechanical balances. These just always follow when you open up explicit behaviors. The game can't be abused to a certain point or the devs have to step in and make changes so everyone feels they can get a chance to do what they set out to do. Lots of examples of this exist in every sandbox game ever. This would be balanced just the same.
- Allowing things is easier than disallowing things you can't control. There's no way to tell if someone is multi-accounting definitively unless they admit it. Right now, a lot of multi accounters I've heard of just don't admit it. I'd personally die on that mountain because I don't like secrets, but I understand why they keep it to themselves. Even those that admit it, how would you enforce it? "Well, you said it to this guy and we trust him, so..." It's so much more scalable and customer friendly to just allow it.
- The problems with it that I've seen can be dealt with. It's also easier to deal with problems that might be rather than limit something that might cause the maybe problems.
Tell me how I'm wrong. Not that you disagree with it on principle. Tell me what concrete things you think will break if allowed. My feelings don't matter, your feelings don't either. Engage the mechanical problems. If you can't come up with a reason beyond how you feel about it, then there's really no reason not to do it. Well, beyond inaction taking less effort than action, of course. =cP