Snrrrub

Ah, that makes more sense. No, it's not one giant surface -- that would be insane. You basically have your drawing surface which is the current resolution (say 1024x768). Every frame, you clear the surface and draw tiles onto the surface. So every frame, you look at where you are and what the resolution is. Based on that, you can find out which tiles you need to draw by looking it up in the map. -Snrrrub

I'm not sure what you're trying to say with your "ratio-ing" of black and white images onto 16:1 maps. And the other question is pretty ambiguous too. What do you mean "how are maps handled"? Are you looking for the data structure used? Or do you want to know what information is stored "in the map"? What I can tell you is that the tile map is neither logically nor physically sub-divided into sub-regions on the client while performing collision detection. Hope that helps. -Snrrrub

It uses bounding boxes for ships and all weapons are treated as point objects (which is why you can see decoys going halfway through the wall before bouncing). Yes, collisions are checked every frame. Without giving specific numbers, I'll say that objects near the viewport are checked more than objects further away from the viewport. Data structure: flat array. Cheers, Snrrrub

Well, you can write C++ code on most "decent" phones nowadays since they're based on Symbian OS. Mind you, I don't think anyone would want to play on the stupidly low resolutions. Of course, there's always Nokia Series 90 (the recently-announced Nokia 7700) or the Sony Ericsson P800/P900 if you happen to have around $1000 to blow on a cell phone. The 7700 has a 640x320 screen at 16bpp so it's actually pretty sweet as far as resolution goes. Too bad it's like 6-8 months away. Anyway, you can't necessarily take Java code written for a PC and put it on a cell phone. The phones use J2ME and MIDP 1.0 or, more recently with the introduction of Nokia 6600, MIDP 2.0. Among other things, floating point support is missing so simple trigonometric functions cannot be used unless you're into the fixed point arithmetic and have fixed point lookup tables or manage to write a fixed point approximation routine for those trig functions. Good times, good times... Now, will someone tell me why I bothered posting this? -Snrrrub

The server sends a seed periodically to clients. The clients generate greens based on the seed. The green type is generated when it is placed on the map. Clients are sycned only if they enter an arena at the same time. If client A enters 10 seconds before client B, then client B will still generate the same greens at the same locations as client A but it will do so 10 seconds later. The server has little to do with greening except 1) generating the green seed and 2) notifying teammates which green has been taken for prize sharing. Although it is possible for the server to check if a green is valid by performing the same calculations a client would, I doubt it has been implemented for performance reasons. That would explain *watchgreen: a way for moderators to see if someone's green distribution is biased from the expected distribution. So what does this mean? Yeah, you could do sounds/images per green type without making any protocol or server changes. The client does most of the work anyway. -Snrrrub