Games for Android are a little different than writing for PC or console, really seems to be less of the dull grundge as well. But at the price, for more advanced efforts there are less resources sitting right there on Fresh Meat or Source Forge for the hunting up. Me being me, of course, I aways have an interest in cross platform portability (as well as a general disdain for Oracle Java).
One thought that occured to me, is why not do it the same as I would on a PC?
What is the activity to a game? What the user sees. All it really needs to know is processing input, rendering output, and talking to the big cheese. That's it. Hell, before we talk communication methods, step back and think there: an Android activiy and a Windows executable could both function as clients, talk to the same server, and have a cross platform multiplayer game. Or even a screen like detach/reattach feature where you could begin playing on your mobile phone, then switch to a PC with way better graphics. Threating the user side of the app as a "Client", it would be possible to have a low-end client for basic phones and a high definition client for sexy tablets.
To make it work, we need a service program to communicate with. On a PC, I would probably use shared memory for offline play and sockets for network play. In favour of shared memory, would be the ease at which C++ code would likely be tweakable to use a shared memory allocator to store command objects, rather than having to do as much extra leg work to serialize the information within across a process boundry. Android land makes most issues a moot point. Network wise, I'd probably just use JSON.
Something that interests me, is how much of the core game design be implemented in such a way, that it could be used off Android by reusing the same library. C code, whatever C++ code the NDK can compile, or Java code should all work, as long as long as one watchs what non-portable bits are stuffed in there.
Putting this much thought into it, can probably be blamed on poking around the FreeBSD and Q3A source trees over the years, and finding the possibilities fascinating lol.
One thought that occured to me, is why not do it the same as I would on a PC?
What is the activity to a game? What the user sees. All it really needs to know is processing input, rendering output, and talking to the big cheese. That's it. Hell, before we talk communication methods, step back and think there: an Android activiy and a Windows executable could both function as clients, talk to the same server, and have a cross platform multiplayer game. Or even a screen like detach/reattach feature where you could begin playing on your mobile phone, then switch to a PC with way better graphics. Threating the user side of the app as a "Client", it would be possible to have a low-end client for basic phones and a high definition client for sexy tablets.
To make it work, we need a service program to communicate with. On a PC, I would probably use shared memory for offline play and sockets for network play. In favour of shared memory, would be the ease at which C++ code would likely be tweakable to use a shared memory allocator to store command objects, rather than having to do as much extra leg work to serialize the information within across a process boundry. Android land makes most issues a moot point. Network wise, I'd probably just use JSON.
Something that interests me, is how much of the core game design be implemented in such a way, that it could be used off Android by reusing the same library. C code, whatever C++ code the NDK can compile, or Java code should all work, as long as long as one watchs what non-portable bits are stuffed in there.
Putting this much thought into it, can probably be blamed on poking around the FreeBSD and Q3A source trees over the years, and finding the possibilities fascinating lol.
No comments:
Post a Comment