Vote on 2.0

[reedlaw]

I'd like to know whether a sandboxed-version that still runs in the console, or a remote API calling version would be more fun?

Because of the ease of cheating in its current state there needs to be some separation between the players and the engine. It could be done in separate process, using a gem like shikashi, or just put it on a server and let players communicate by sending and receiving json objects.

[vitaly-pushkar]

I would prefer variant with a server and API. But there should be also some easy way to test application in console before communicate with the server.

I like the console version. Piping the output to less makes it easy to see what's going on. I'm not sure how the server version would work out in this regard.

[reedlaw]

Been thinking about a version that communicates via json or REST API and my conclusion is that it would be much slower and not support as many concurrent players. Also, there is a problem of hosting each Player. I wouldn't want people over-burdening Heroku or some such free service with game players. So my idea version would be a hosted service that would allow web submission of ruby code, plus continuing to maintain the github hosted code with the same players so that developers could run the simulation locally. The challenge with this is to come up with a way to safely run potentially hostile ruby code. As it stands, I've been reviewing all submitted code to make sure there's nothing like this. But I'm not sure how to go about automating that process for a web service.

[hellopatrick]

Been thinking about a version that communicates via json or REST API and my conclusion is that it would be much slower and not support as many concurrent players. Also, there is a problem of hosting each Player. I wouldn't want people over-burdening Heroku or some such free service with game players.

You could limit the number of moves a player can make in a given day to not burden Heroku or free Amazon EC2 micro instance.

You could also just have the game server periodically query the players for their move or reactions to certain events, instead of the players sending their moves to the client when they want. So more of a turn-based MMO.

Sounds like fun, but could just be me :).

[reedlaw]

What happens when Player servers go down? Isn't this akin to creating a kind of botnet? Maybe each player service could visualize the game from its own perspective using BrowserQuest. Popular players could attract viewers. But it still seems kind of wasteful. Really all the players need are a way to run a single ruby process with some network connectivity.

[hellopatrick]

What happens when Player servers go down?

They forfeit their current turn. If they forfeit too many turns in a row, just remove them from active players.

Isn't this akin to creating a kind of botnet?

I don't think so? The servers are playing a game with each other, not conspiring for nefarious means. You'd just want to make sure that clients may only interact with the central game server. They'd really not need to know the location/address of other players. I don't think such a setup would violate Heroku's acceptable usage policy.

Maybe each player service could visualize the game from its own perspective using BrowserQuest. Popular players could attract viewers. But it still seems kind of wasteful.

If the game world was built up enough that this was possible, that'd be amazing, in my opinion. If someone wanted to produce a visualization, let them have at it.

Really all the players need are a way to run a single ruby process with some network connectivity.

Well, the simplest/starter kit could just be a sinatra web app hosted on heroku with the free web dyno:

# myapp.rb
require 'sinatra'

post '/move' do
    # process json rep. of world, perhaps some ruby-mmo provided code to reproduce Game.world
    # figure out next move, just like normal
    next_move.to_json
end

Just an idea, after all.

[reedlaw]

I never thought it would be in violation of Heroku's usage policy, it's just kind of taking advantage of their free tier in a way that would be costly for them in the event there were a large number of such players.

Maybe if we host the engine service we can provide a certain amount of resources for running players that have been contributed to the github repo. If someone wanted to make a private player they would be responsible for hosting it.

[benmanns]

I think a client/server architecture would solve the issue of cheating, but it also privatizes all of the competitors code. The best part of this game for me is looking through other players' code to find out why I keep losing, even though my AI is superior (it's because they all attack the leader!).

Without being able to see the how other players work and testing it locally, there would be no way for me to compensate. I would rather try to openly outsmart people than try to keep AI secrets hidden.