I'm thinking of experimenting with Ruby and building a Computer player, but I wanted to know if there are any plans to require signing or keying of any read/write capable clients. I think it would be a good idea to do this, and that we should put some rules on types of clients and abilities.
- Vanilla client (class 1) is simply the current client ported to a new platform, with no tools or automated gizmos. This would have no restrictions.
- Enhanced client (class 2) has tools/calculators, but does not automatically manage your tax rates, for example. This would likely have no restrictions.
- Automated clients (class 3) will do some activities for you, such as freighter routes, changing friendly codes on events (gaining a new planet, after HYPing, etc) and tax rates or long-term starbase queues. These would likely have restrictions.
- Computer AI clients (class 4) will play a whole race for you, exploring, fighting etc. These would definitely have restrictions.
My thoughts on restrictions:
- A game would require a valid key for all clients.
- Game creators could restrict the class of clients allowed. (Only class 1-2 clients allowed for this game, no "change every friendly code every turn", etc.)
- Class 4 (and maybe 3) clients would have a requirement to transmit a diplomatic message to all players the first turn they are used and every X turns.
However, it would be trivial to get around any key-based system, as far as I can tell. We'll need to discuss if we think griefers would be tempted to use clients to destroy games, and how to prevent that. The only way I can see to prevent it would be to allow read/write clients that only originate from VGAP.nu with a public key encryption scheme to prevent copying/modification of the client. So one could develop a computer AI, but to play it outside of custom games it would require submitting it to VGAP.nu so the code could be inspected and signed, and released on the website as a potential client.
As the API is open probably wouldn't matter a great deal if you are using an external tool - anyone who wants to can create a front-end and the front-end would not be able to do anything you couldn't do in game. If I write a computer algorithm that plays the game well, it's an algorithm I would be able to apply manually.
However, I wouldn't object to the possibility that a person would want to create a game that forces you to play through the built-in interfaces. Frankly, I don't see the issue, but that's something that should be up to the participants in a specific battle. I would probably only participate in games that let me use external tools, which would be my privilege as well. To each his own.
That having been said, I'd rather see the devs of Planets Nu build the full turn submission API out than implement these specific restriction features... :P
joeman, I agree, these clients would NOT be able to "cheat" per se, but take advantage of things most humans wouldn't do because of the time or whatever involved, mostly related to friendly codes, and would also eliminate those silly mistakes a typical human player could make, and another player could take advantage of. (Sorry cb1 :) )
Last time I looked, one of the virtues of VGAP was that you win by strategy, not by software, and that you can choose the client that most suits you. People are totally different. There are people who memorize the complete ship list. Who can play 10 games in parallel and still remember each ship's order. And then there are people like me who suck at remembering numbers and want their client to remember everything and present nice calculations. Or, there are mouse users, and there are keyboard users.
Currently, planets.nu trusts clients. It trusts the Javascript to never cheat, and since read/write clients use the Javascript interface, it must implicitly trust them. It happened more than once that my client (PCC2 + adapter) cheated by accident in my test game beause I had a mistake in the code.
Thus, if there are restrictions to be implemented, they should be doing what VGAP hosts have restricted for 20 years now: rule checks. Not feature checks. But given the format of the interface as it is now, that'll be very hard.
That aside, nothing would stop you from using your "forbidden" client to prepare the turn and copy over the changes by hand. Guess what I'm doing just right now as I don't yet trust my client for a real game....
I would absolutely like to see rule checking. Do the resources at each point add up correctly? Have the ships traveled too far?
Another method would be to send instructions, not results. Rather than saying the planet now has 3 D and the SDSF 200, say that the planet will transfer 200. They could either record all the instructions issued (including the ones that are undone and corrected), or back-calculate from the state submitted (the player finally decided to send 150 colonists and 50 supplies).
I'd also like to see games where AIs are allowed, even encouraged. They're fun to develop. They play at my erratic schedule -- fast when I have hours, slow when I'm busy. AIs haven't hurt the popularity of chess.
Stefan: I totally agree about the strategy vs. software point, although as Richard's post points out not everyone feels that way, and one could argue that precision is another factor by which you can be measured...
CB1: Sending instructions instead of results and having the possibility of setting up a multi-turn strategy that runs by itself (e.g. optimized auto-shipping routes in safe space using a fleet of assigned freighters) is exactly what I want to do - I want to be able to skip the micromanagement and focus on strategy, it's one of the reasons why when my friends were playing this game in the 90s I never stuck with it.
It's been a long time since I played VGA Planets and I'd totally forgotten about the massive cheating ability that can be imparted by manipulating system data - I think I now understand why the turn upload hasn't been implemented via the new JSON API yet... I can't speak for others but my intention is to implement a non-cheating front-end...