FOSS gamedev and creative worlds

I've begun work on a new Minetest bot, implementing the network stack from scratch in PHP. Progress is going slowly, but smoothly, and I expect to have the software operational by September.

A bot is simply a computer-controlled player in this case, where it is limited by privileges, dig times, and movement speed. However, the bot can perform tiring or repetitive work efficiently, patiently, and precisely, 24/7.

With these facts, a number of design decisions loom, especially those related to security or abuse.

I'd like to solicit everyone's opinion on a few questions:

• Should the code be closed-source, or open-source?
  Remember that it's implemented in PHP, so source=finished product. I feared letting the source code into the hands of vandals, but Foobar brought up a good point saying that the average griefer won't understand how to use it.
• Should bots be limited by time?
  A bot can work incessantly, giving an operator an advantage. Should this be limited?
• Should servers be opt-in, or opt-out?
• Can bots be leased/rented/sold to other players with in-game currency/materials?
  Again, this can lead to an unfair advantage.
• Should I provide the actual program to prospective users? How much scrutiny should I hold in regards to making sure a user isn't a vandal?

I'm trying to hear from all different kinds of people(even vandals, feel free to give me your thoughts), so nobody is too insignificant to comment.
Please explain your reasoning in your responses.

Answers: I believe open source. If it isn't then how would we get it. Also others could help improve it so there is another reason. Finally monetest open source so not clieny-open source. I think that you should have people set a time limit. Servers should be able to also. If someone doesn't have a 24/7 computer running then time would not be a problem. Bots should be able to be rented if there is a server setting for bots.

Questions: what do you mean by opt-in/opt-out. Also please explain prospective users.

Note:I would love to teat the early stages of this on my private worlds but someone would have to make a build for me.

jojoa1997 wrote:Answers: I believe open source. If it isn't then how would we get it. Also others could help improve it so there is another reason. Finally monetest open source so not clieny-open source. I think that you should have people set a time limit. Servers should be able to also. If someone doesn't have a 24/7 computer running then time would not be a problem. Bots should be able to be rented if there is a server setting for bots.

Questions: what do you mean by opt-in/opt-out. Also please explain prospective users.

Note:I would love to teat the early stages of this on my private worlds but someone would have to make a build for me.

Since source==what you run(since it is PHP), the question is to whether restrict availability. Prospective users are people who want to run bots on their own computers.

Please also provide reasoning for your answers so I know what leads you to a certain idea.

rarkenin wrote:Should the code be closed-source, or open-source?

Today's griefers are rarely smart, so there's no problem in open sourcing it.

rarkenin wrote:Should servers be opt-in, or opt-out?

Opt-in would be better.

How would you implement an opt-in/out system? If you're essentially just asking the client 'Are you a bot?' don't waste your time because anybody can make a client give any answer to that. The verification needs to be entirely on the server end because the client can just lie to you. The only option that might be remotely possible is to implement some sort of CAPTCHA, but for that to work you would have to have all clients solve a CAPTCHA for it to be effective, and nobody wants to do that to log into their game. Plus with a bot, a human could handle the login captcha then walk away and the bot is online to do whatever it wants.

Make all players do a small "parkour" jump practice to get out of the spawn.

Calinou wrote:Make all players do a small "parkour" jump practice to get out of the spawn.

What is that? How would that help? The bots can simply do it much more precisely.

Of course it should be random (per-server, or even randomly generated for every new player), but it's actually pretty hard for bots to do it.

Calinou wrote:Of course it should be random (per-server, or even randomly generated for every new player), but it's actually pretty hard for bots to do it.

Unfortunately, with the architecture of the bots(limited physics support), they can actually do it with relative ease.

Calinou wrote:Of course it should be random (per-server, or even randomly generated for every new player), but it's actually pretty hard for bots to do it.

that wouldnt work because some people dont want to / can't do parkour. if i had to do that on every server i went on i would just play singleplayer. I say give bots a unique code to be able to tell them from others (for rollback purposes)

jojoa1997 wrote:

Calinou wrote:Of course it should be random (per-server, or even randomly generated for every new player), but it's actually pretty hard for bots to do it.

that wouldnt work because some people dont want to / can't do parkour. if i had to do that on every server i went on i would just play singleplayer. I say give bots a unique code to be able to tell them from others (for rollback purposes)

I don't think I've explained the bot architecture sufficiently. It runs a limited physics internally, then sends position to the server. It is very finicky with collisions, and seems to sometimes fly or overjump for a few seconds. It would probably fail through the parkour.

maybe just have us open an automaticly closing door and not let bots open doors

jojoa1997 wrote:maybe just have us open an automaticly closing door and not let bots open doors

jojoa1997 wrote:I say give bots a unique code to be able to tell them from others (for rollback purposes)

How will you know it's a bot? A bot could be programmed to send any client version, it doesn't have to tell the server it's a bot. So if we're going to open the door to bots we're just going to have to accept that there will be grief bots and all we can do is ban them individually like we do human griefers.

BrandonReese wrote:How will you know it's a bot? A bot could be programmed to send any client version, it doesn't have to tell the server it's a bot. So if we're going to open the door to bots we're just going to have to accept that there will be grief bots and all we can do is ban them individually like we do human griefers.

That is correct; identifying bots is a problem since the source is what is run in a default installation(as I had, for some reason, decided to use PHP).

rarkenin wrote:

BrandonReese wrote:How will you know it's a bot? A bot could be programmed to send any client version, it doesn't have to tell the server it's a bot. So if we're going to open the door to bots we're just going to have to accept that there will be grief bots and all we can do is ban them individually like we do human griefers.

That is correct; identifying bots is a problem since the source is what is run in a default installation(as I had, for some reason, decided to use PHP).

There are free PHP Obfuscators and encoders that would limit who could edit it, but then it becomes closed source. I've used PHTML Encoder a little and it seems to work well.

http://www.rssoftlab.com/phpenc.php

BrandonReese wrote:There are free PHP Obfuscators and encoders that would limit who could edit it, but then it becomes closed source. I've used PHTML Encoder a little and it seems to work well.

I don't think obfuscation is the way to go. It will be broken one way or another, and developing policies will also help when bots become more prevalent.

I'm making a large move, and putting the code up on GitHub. I'll take pull requests, but I won't have time to actually work on it until the summer.

It is now up!

could you make a windows build

Jojoa, PHP programs do not require building.

rarkenin wrote:Jojoa, PHP programs do not require building.

how would I run one

jojoa1997 wrote:

rarkenin wrote:Jojoa, PHP programs do not require building.

how would I run one

Install PHP, then it's as simple as php.exe <file you would like to run> to run something from the command line.

Calinou wrote:Today's griefers are rarely smart, so there's no problem in open sourcing it.

"Ignoring the enemy first step to failure."

BrandonReese wrote:Install PHP, then it's as simple as php.exe <file you would like to run> to run something from the command line.

Would you not use a web server?

I also recommend Xampp, MinetestRemote will also run perfectly on it!

rubenwardy wrote:

BrandonReese wrote:Install PHP, then it's as simple as php.exe <file you would like to run> to run something from the command line.

Would you not use a web server?

It will be required to run something like this from the command line. This PHP is not like the scripts for a website that do their job quickly and exit. This will use loops and run continuously until the user requests that the script terminate.

You would not run this through a webserver because:

1) It's unnecessary
2) The main loop could freeze Apache or any web server you use, at the very least tie up a child process
3) Most shared/free hosts use max_execution_time in their PHP configuration which will terminate the script after it runs for X seconds. I believe the default for PHP is 30 seconds
4) The bot would potentially stop running if you close the browser window
5) If there is no output the browser will eventually close the connection, thus terminating the script.

So it's really just not designed to be ran through a web server. It's a PHP-CLI script.

BrandonReese wrote:
So it's really just not designed to be ran through a web server. It's a PHP-CLI script.

That was the original design, and that is the way it is remaining. It even has a check built in so it can't be run as a web server.

rarkenin wrote:

• Should the code be closed-source, or open-source?
  Remember that it's implemented in PHP, so source=finished product. I feared letting the source code into the hands of vandals, but Foobar brought up a good point saying that the average griefer won't understand how to use it.
• Should bots be limited by time?
  A bot can work incessantly, giving an operator an advantage. Should this be limited?
• Should servers be opt-in, or opt-out?
• Can bots be leased/rented/sold to other players with in-game currency/materials?
  Again, this can lead to an unfair advantage.
• Should I provide the actual program to prospective users? How much scrutiny should I hold in regards to making sure a user isn't a vandal?

* Open / closed: That's up to you, but the nature of Minetest and PHP both is open source. I really depends on whether you want others to benifit from the code, or just you.
* Opt in / out: I'm not sure what to say here. Both maybe? If the server opts in, bots are allowed, if they opt out, bots are not. If they choose neither, it is a grey area, and up to the bot runner. There are those of us that stand neutral about bots, and out lack of opting in or out should not be assumed to mean the opposite choice is chosen. There are also those that don't know about bots.
* Bots are a service. Renting and selling seems fair. But it also seems pointless. You'd get more materials by using them to gather materials than you would get by charging for them.
* How would you implement any kind of anti-vandal security?

0gb.us wrote:* How would you implement any kind of anti-vandal security?

Probably use of RSA keys and web-of-trust things, but the problem is that if it is open-source anyone can bypass it.

Edit: I want to reiterate that I encourage, and kind of want, help with development if anyone is interested.

rarkenin wrote:

0gb.us wrote:* How would you implement any kind of anti-vandal security?

Probably use of RSA keys and web-of-trust things, but the problem is that if it is open-source anyone can bypass it.

Edit: I want to reiterate that I encourage, and kind of want, help with development if anyone is interested.

Yeah ....

As I always say, security needs to be server-side, not client side. You can never trust the client.

As the bot is a client, and can potentially mirror a human client, we would need a tool that works to protect us against malicious humans as well. But that's already a problem people are trying to solve.

EDIT: That is to say, if you don't cause mayhem with your bots and you never release them, someone else will build bots and cause mayhem. Someone who won't try to be polite. So whatever you choose to do, server side precautions will need to be developed.