Google's Race and Other Epic Failures

Google's not racing to the bottom, they're free falling in Apple's main market segment. They're selling Nexus 7 with a loss, and they don't care. It's not Google's main market, and from what I've heard the Nexus 7 is profoundly good (according to many I spoke to better than iPad), but with hardly any cash flow into developer's pockets. Developers sell most apps for free, users use mostly free apps. Google don't care about a profit, but cares enough about the market segment and has enough brilliant people to, at least eventually, equal and surpass the design and performance of the iPad.

iPhone 5 followed the traditional electronics recipe: faster+smaller hardware, faster+better software. But as there's nothing "new" people start looking at other things, the disappointment is obvious as we all expect something a hundred times better than the last one, as the iPhone 1 was a hundred times better than it's predecessors.

Google is the underdog here, and Apple's not playing their cards right, and even so no company currently have a deck that could match people's expectations of Apple. It's five years since the iPhone arrived and it's a darn shame that it couldn't last longer. I definitely don't love Apple, but I loved the door they opened to me as a developer. In a year or two Google's going to slam that door shut on us indie developers. There'll be other doors, but those will require ever increasing struggles from indie developers as we abandon the ship like rats. In hordes.

There will be time to finish my first good game though. I tried out various concepts in refactoring and decided I'd stick with using a singleton physics engine for the client, which will be a good enough trade-off between performance and generic code.

The game will feature single player and multiplayer modes, and the server can only be hosted on a regular computer I think. Which means that the single player mode will have to also run rules and AI, but when running multiplayer the rules and AI will be executed on the server. It will be a challenge, but the alternatives are worse, either in performance or in resulting code.

Short on why the major refactoring failed

Most refactoring is straight-forward and almost mechanical. These were not. The game engine is designed something like this:

     resource loader
          /
         /       
   1 TICKER      /-- "logic manager", has game objects which play sounds, update
       |        /    3D model positions according to physical dittos, "what happens when"
       |       /
 N game managers --- physics manager, steps physics simulation
       ^      \  \__
       |       \    \-- network
       |        \
       |         \-- resource loader
       |
client game manager

Simplistically the TICKER is the current singleton, keeps track of game time, and ticks progression. Both the TICKER and the game managers are inherited into server and client classes; the client game managers each have a rectangular view on the screen to fill. These scenarios are the tricky ones:

• Playing a moving sound with two different speeds and Doppler effect on two different client logic managers (this is a feature I love).
• Supporting several players on one connection would require a little refactoring on the network code and the "who owns what object" code too, which would be very boooooring. I want to make a game, not an engine now.
• Rendering of "mass objects", i.e. undergrowth, is done close to the camera, would require rewrite for cameras.
• Generally, each single to multiple, and vice versa, use of each of these would require substantial refactorings/rewrites: game manager, "avatar", 2D GUI, camera, microphone, control settings, console, worker threading, single logic handling for multiple/parallel game worlds.
• And the devil's in the details.

With the designated path using a single physics manager, I'll be able to have very little overhead in performance (I'd say no more than a percent or two) but with totally acceptable code. The game objects will no longer have a one-to-one connection to the physical objects, instead the physical objects will have the game object ID and the game objects will have some type of "resource proxies" between them and the physical objects and the two "on force feedback" and "on trigger" callbacks (physics -> logic) will be delegated to each of the N game objects.

I'm halfway done already, soon ready to start game coding instead of engine coding, peuh!