Global Triumph

One more thing I would love- anyone heard of Schemaverse.com?  I haven't started playing there yet at all, but I love the concept of it.  I would be yet even more enthralled with combining the idea of that with this game.

The idea of Schemaverse if you haven't heard of it is to give all players SQL access to the game's database so that they can write their own queries against the game board.  They also have update permission only on specific views that give them access to their own game pieces.

I can't see why you can't have a game that has both a nice graphical front end interface as well as a more powerful command-line type of interface- even an interface to do your own SQL type of queries.

Opens the possibility of abuse. Some will want to update after every couple of placements. Will make it impossible to play with ipad or android unless using remote desktop. Basically, it opens a can of worms; too much risk, not enough reward.

I don't understand what you mean about the possibility of abuse.  The current browser-based game already sends an update to the server after every single move.  You can't get much worse than that for server load.  Or did you mean something else by updating after a couple of placements?

If you meant refreshing the full game board snapshot, there should be no need for the application to do that...  oh wait, I guess maybe there would be if the later players still insist on having their unfair advantage of seeing the earlier players' newly placed units.  I don't see any justification for allowing that, but I guess that controversy is what might throw a monkey wrench into the works on the issue of network traffic.  What I was thinking was that no one would be able to see anything that any other player has done until after the daily cycle runs.  It's really the only fair way to play it.

Even allowing the newly placed units to be seen, it's possible the network traffic still could be less, depending how it's implemented.

I also don't really know what you mean by too must risk and not enough reward... are you talking about the players or about the game developer / owner?

Having a client/server based system involves a lot more work on johnny's part, it is more vulnerable to security breaches, or modifying the client in an attempt to gain unfair advantage, the client would have compatibility issues unlike it's current incarnation, johnny would have to update both the client and server each time he wants to add or revise functionality, the server would use infinitely more bandwidth just downloading and updating clients, i could go on...

For this type of game, bad idea. The underlying principle of GT is a simple game that anyone can play with minimal effort from anywhere. A client is not conducive to that.

I don't agree that this opens up the game to any more abuse than what could already occur.  If you wanted to sniff the network traffic, you could easily figure out Johnny's server API and create your own routines, browser-based or using your language of choice, to do things that the current, web-based client can't do.  Unless he's somehow protecting against that on the server side, I would venture to say that it would be easier to hack GT as a web-based game (where you can freely see all of the client-side code) than it would be if he had written a proprietary client.

That being said, the idea of supporting multiple OSes and OS versions would not be something that I would want to take on as an individual and I completely see the merit of this being a browser-based game.  I, too, would be against the desktop client idea.  On the other hand, if George is volunteering to reverse-engineer Johnny's game based on the network traffic he sees and putting this into some kind of client app, go for it.  If you don't mind targeting Android first, that would be great, because I can't really play the game on my phone and I would love to be able to do that.

I will say this, however, in response to some of the benefits listed in the original post:
- Downloading the entire map and all pieces once at the beginning of the day would be insufficient for showing moves made by your alliance members during the day.
- Downloading the entire map once at the beginning of the day could possibly produce a greater server load and bandwidth than the way that it is currently done since most people do not look at every single sector of the map during the day.
- Caching moves on the client and sending them every ten minutes or at shutdown wouldn't be good enough if the client crashed or you lost power after 9 minutes and 59 seconds; you could mitigate this by saving the moves to a file, locally, but if the user didn't restart the app right away, those moves would be "lost" or could get applied the next day after the cycle.

All of the improvements that you suggested could actually be implemented in a browser-based game and would only have to be written once in a standards-compliant manner to work across all browsers (well, maybe not IE if you're talking standards, but all decent browsers).  Even the ability to view the map at both zoom levels simultaneously.  You could even add additional zoom levels or tiling like Google Maps so that you would never have to click on the edge of the screen to scroll.  These are all choices that Johnny made when creating the game and I'm sure he had his reasons for them, though I'm fairly certain it would never have crossed his mind to make a client that users would have to download and install on their PC's.

I'm not sure how open Johnny is to having help since I've never really talked to the guy, but I'm sure if you wrote a new browser-based client that had superior functionality to the original and submitted it to him that he would at least consider putting it out there for general use.  The real meat of the game, itself, is on the server.  The client side is just bells and whistles.  True functionality is limited only by how he designed the server-side API and the entire game could probably be played with nothing but http requests and completely text based if you could read and interpret the server's responses.