Alrighty Let's Talk Damage Scaling

[Jacob Sokora]

I've started working on the damage scaling plugin, and the way I'm writing it to work is essentially listen to every event and whenever a player does something they get points. The more times they do a single action, the less points they get for that action (ie getting 10 points for the first diamond ore you mine, and then 9 for the next and so on) so that it's more work to focus on one thing, and less work, but more diverse work, to do lots of things. There will also be general categories that can be weighted. For instance certain blocks could be added to a list in the config so mining those blocks gives you more points. That way mining ores will get you more points than mining cobble. I intend to listen for just about anything relevant that players can do but I probably wont think of them all so I decided to bring it up here. I'm hoping we can get a good list of just about everything someone might do on Civcraft and add it to the list. Then of course the admins will be able to configure it however they want secretly so nobody knows exactly what they need to do to win. So I guess I'll start off with a list of things I've already thought of:

• Block break
• Block place
• Farming
• Factory use
• Chat
• Breeding
• Killing
• Enchanting
• Taming animals
• Changing worlds
• Fishing
• Repairing enchanted items
• Moving (it would track unique blocks you stand on the more points, so people who travel a lot would get points eventually but people who make a script to just walk back and forth wouldnt)
• Statistic changes (basically catches anything that shows up in the statistics page)
• Spawning mobs from eggs
• Reinforcing
• Breaking reinforcements

So that's what I have so far. Any additions would be welcome (or subtractions with reasoning) and I'm hoping we can get this online soon so people actually have to play the server to win at pvp!

Also wanted to mention that it would check your last login on startup and if you haven't played in x days your pvp level will start to decrease to prevent people farming up points, logging out for a while, and then coming back months later. I really want this to exist so people have to invest time and effort into the server consistently, not necessarily to avoid pvp or "le hcf invasion" but more to prevent new people from immediately fighting, and to prevent people who log on every couple weeks just to pvp from pvping. People need to start playing civcraft in ways other than pvp, let's see to it that happens.

[Gavin Jenkins]

This is a public google group, and this plugin concept doesn't work at all if it is made public, because once you make any list like this known, botting is trivial.

In this case, in maybe an hour I could be ready with scripts to bot reinforcing, break, place, chat, changing worlds, fishing and stat changes quite easily, and shortly thereafter farm and factories, which would already have to be good enough here, since you can't force players to be much more diverse than that from this list, without requiring them to raid or raise livestock, etc. So as it is now, publicly known, anybody bringing on people to raid who is more likely to bot would probably be at full strength BEFORE an actual human would.

I really think that to be successful, this needs to be taken to admin only or some sort of trusted subcommittee and kept completely secret on no public forums. Also it needs generally more esoteric stuff than most of this list. Or at the least, significantly different or expanded from this list once private.

[Jacob Sokora]

Well here's the thing, if admins make it so only one thing levels you up then this doesn't work, so it has to be all things that level you up. How much they level you is up to the admins and they'll be able to configure that later. It's up to us to figure out what everything means, so it's actually good to make it public because then it's less likely we'll miss something

[justin kilpatrick]

some bot detection will probably be used, but in general Gavin is right, however this plugin is coded its important which events to listen to are in the configuration file so that we can add them ourselves and change them on the fly without having to close source the plugin

[Rourke750]

We can just do a randomly changing thing everyday.  Like some days these events are listened others these are.

[Arieh Kovler]

Does this encourage specialisation, which can be botted? Or does it encourage variety of activities and therefore discourage specialisation? 

[Gavin Jenkins]

A thought, not about the algorithms, but... What if the same stuff (or similar) used to gain points for full damage, whatever that is, also over a much longer period of time, increases the coal cost of keeping that player pearled (obviously actions in the end don't count)?

A major player on every day actually playing for months suffers much more from being pearled than some dude who hopped on three days ago. One of the major asymmetries and unreasonable advantages of the latter is therefore the relative lack of caring AFTER being pearled, compared to the former. Being able to exact more suffering should be associated with a higher coal cost. Likely up to some cap, or logarithmically curved, blah blah.

Like somebody who has been playing very consistently and earning points for months might get up to a cap near 32 coal a day, somebody almost brand new may already be at 1.0 damage, but still be only be 2 coal a day.

[Nick]

After it's all said and done, if it works for combat other uses for the activity score could be used. Let's not expand the scope and potentially gain multiple unusable features instead of just one.  ;)

[Jake Jungbluth]

Here is an idea I had 

Could it be dynamic enough to just list the full name events in the config that will be captured? 

Basically a script could write the code for te listener class then?

Imports would have to be added but it could just generate all the methods for eAch event 

That way only the live config could tell what works and it would be able to change day to day or week to week and be flexible to do whatever so admins could play around with it 

Could not even be possible I just think that would be pretty neat, this could also be a Terrible idea for some reason I don't know 

[Jacob Sokora]

So are we in agreement that we should be tracking everything people do with diminishing returns for doing just one thing?

[Nick]

Sure, it should start there. We won't know how well that will work unless we get something in place.

If you want to track all events, you can rip apart https://github.com/erocs/Gadget/blob/master/generate_handlers.py if you want.

N

[Arieh Kovler]

I don't think we necessarily want to punish specialisation, but perhaps we need to think about what we mean by specialisation.

[Jacob Sokora]

Well no, I think if someone wants to mine thousands of diamonds or something like that then sure they should have full scaling, but it has to be harder or take longer doing just one thing to encourage people not to bot

[Greg Boiczyk]

Something like ore mining which cant be botted easily shouldn't necessarily scale down the more you do it.  Well as long as there is some protection coded in to prevent ore that was placed by a player from counting as a normal mined ore (since then I'd just write a bot that places and removes ores).  

[Jacob Sokora]

yeah and the admins would be able to set how different events are scaled

[Greg Boiczyk]

Vein mining is the least bottable thing i can think of (short of PvP), so if the point of scaling is to prevent botting then the scaling should be minimal assuming it can be set up to only accept ores that are mined from a vein or naturally occurring vanilla distribution.  Of course then I guess I could write a script that just mines 2 blocks in front of me and walks forward one block while holding shift and I can probably bot this 

[Jacob Sokora]

Yeah the scaling would probably be minimal for that but you would want scaling for other activites. You can't just have ore mining to get damage because some people don't mine

[Greg Boiczyk]

Definitely need to scale stuff like traveling, changing dimensions, farming, etc that are stupidly bottable pretty hard so that a wheat bot doesn't get fully damage scaled quickly 

[Gavin Jenkins]

Ore mining:
1) Get a silk touch pick
2) Mine an ore
3) Place the ore where it was
4) Go to step 2.

Yes you can make it so that doesn't work, but would you have without me saying that? (Even so, a 2x1 tunnel digger that uses a repetitive system like always dousing with water then attempting to place gravel repeatedly then digging again with a shovel could do pretty well overnight...)

I don't think it's wise to make any exceptions to safeguards at all. Only if and when you come up with a method of distinguishing humans that is so robust you could publicly announce it with no problem, everything should have sanity limits.

[Gavin Jenkins]

Anyway, again, can we please form a private subcommittee or something? Or even more than one if lots of people care, and admins could choose what they like best and find coders to work closed source on the best ideas.

I have tons of concepts I think would solve a lot of these problems but am not going to post them here, because they wouldn't work if I did.

On Tuesday, February 10, 2015 at 12:50:40 AM UTC-6, Jacob Sokora wrote:

[Jacob Sokora]

Anyway again you clearly don't get the point of this thread. The point of this plugin is for active players to get benefits so we want to track all activity. The other specifics of the plugin will be more private but the plugin has no reason to be closed source only the config like with humbug

[Gavin Jenkins]

First of all, even if all of that is correct, that doesn't mean we shouldn't discuss in private. Even if tracking all actions, the details of caps vs. taperings vs. whatever other schemes etc. shouldn't be public if not necessary. Or the exact details of how you track each action (such as for vein mining, whether it has to be a native vein or just any ore and how you might go about keeping track of that, etc.)

Secondly, the fact that we want all actual active human players to get benefits does NOT logically imply that we must track all actions. If there is even one single thing that humans do across the board no matter what their profession or playstyle that bots do not do, then that is sufficient, without having to track anything else. Two or three such things are better. OR things that bots do that humans do not. There's actually several possible strategies that don't involve tracking the vast majority of actions, which might be simpler, harder to get around, and less laggy and memory intensive.

I do not want to discuss or commit to/point out further exact or detailed examples of such things in public, although I can think of many of them.

[justin kilpatrick]

this is clearly going to be much higher effort than I had originally envisioned, while I am still interested in such a plugin I would like to prioritize working on the sharding preparations for the time being. 

As Gavin is saying discussing the plugin will probably reduce its potency, which is unfortunate as it can make it difficult to develop. 

[programmerdan]

As a counterpoint to some of Gavin's, perhaps the best approach would be a data collection task. Write the intercept plugin, but for a month simply harvest data on players. Use that to construct a few "ideal" or "average" models that encapsulate what real players actually do.

The AI guy in me says to use these models and train a decision machine / "deep neural network" or SVM to discern player vs. bot or newbie. 

The practical guy in me says we could use those models to make pretty good decisions concerning how to weigh player actions in determining if a player is legit or not without resorting to fancy AI.

Basically, if the only way to get full damage is to approximate a real player's actions based on several legit models discerned from actual players, and you go to all the trouble of actually approximating that behavior over time, aren't you effectively just a legit player?

We could tie ourselves in circles on this, or just get some hard data to see if its feasible. If after collecting data for a month you've got activity soup and no clear stochastic or average models emerge, call this idea dead and move on.

[Gavin]

"deep neural network" That's a great idea... I do cognitive neural models for a living =P could probably give it a very decent shot. You would need to harvest first, as mentioned. And then I would only need a decent amount of volunteer data to tune it, not all the real data which you shouldn't trust anybody with obviously (instead as many volunteers as possible willing to let me/other devs see all the info for a few different bots, and willing to volunteer a full record of their actions as a player)

If you were to do that, the best type of data to harvest would be a combination of persistent records of more "interesting" events like crop gathering, etc. But then also short bursts of recording EVERYTHING, like every single event that bukkit records, for 2 minute intervals every so often. With all their locations and timings and everything.

The awesome thing about the neural network idea is that the programmer doesn't even know what it finds important usually. They're almost impossible to interpret meaningfully if they have a hidden layer or two.

[Bob Pendragon]

Track what everybody does and provide diminishing returns on everything but their maximum. That's what specialization would be.

[justin kilpatrick]

not sure how feasible 100% tracking would be unless we async it, but if we can it could be interesting.

[Daniel Boston]

Yeah, that'd be my approach. Kind of a syslogd for player actions. Fire off the event into a queue, if some get dropped it's no big deal. Perfect tracking is overkill; looking to get the overall model.

[justin kilpatrick]

It would have to work like this, full logging on creates a queue, every event logged is added to the queue, when the queue is full full logging stops, the learning algorithm gets a message to start processing the queue in its own thread, then it updates its database with the results. That would be pretty much zero lag. 

Do we really want to try somthing neural here? If we do should we just go ahead and add alts list functionality?  I wonder what it would learn about alts, also whats the probability of skynet? 

[Daniel Boston]

(even though I suggested it)

The biggest issue, and why I suggest collection only before anybody spends time crafting either NN or any other AI or advanced probabilistic or stochastic or ANY model expectations, is that my firm expectation is tracking will lead to event soup. Most players, in my granted limited experience, are extremely varied in their *patterns of actions* and unless we can find a sufficiently normative collection or discernment methodology, we'll just be facing data soup. 

It's possible a well designed NN or deep learning structure could find a pattern we could not, and it might be worth the attempt a-priori, but I have my doubts. Do any of the other list devs have any input on this? I realize I've resurrected a quiet topic.

[justin kilpatrick]

we would of course need to teach the system, have it gather a bunch of data and have us tell it which ones are bots, but even then that's not enough, lots of accounts switch between botting and normal use at which point even a system where we go and specify it would just end up with data soup. 

[Gavin]

They don't switch every 3 seconds... All you have to do is test like 5-10 minute chunks of data and look for a bi-modal or multimodal distribution treating each chunk as a separate datapoint (not each player).

Then manual inspection should be able to pretty easily identify what "classes" of playstyle each mode of the distribution relates to.

[Daniel Boston]

Thanks for bringing that up, was where my thoughts were going. If the differences in pattern are significant enough, we should also be able to discern the edges between modes quite readily.

If you do start coding something along those lines, I'd love to get in on contributing early.

[justin kilpatrick]

this sounds like it needs to have a processing module pretty much 100% disconnected from bukkit and then someone writes a good bridge to feed it data.