Making an desktop+handheld game considerations

[appel]

I'm wondering what the considerations are when you're trying to put together a game that should work both on a handheld device (e.g. Android phone) and a ordinary desktop machine.

Clearly the resolutions are different, and machine power. What else? If I were to start by making it a desktop game, what should I have in mind so I can easily make it work for a handheld device? (Graphical design, and programming).

The aim is to make a game that runs on a touchscreen android, and also release as a downloadable for Windows, Mac or Linux.

[lsgames]

I once had some of the same ideas. I honestly think very few games are going to be fun on both the desktop and handheld as the platforms are so different.

/Martin

[teletubo]

Appel,
I think the biggest problem is the data input .
You might want to make it strictly using mouse, which will reflect with touch screen input .
Secondly the screen size. Not only you'll have (probably) different resolutions for Android/Desktop, you'll also have to deal with different resolutions on different Android devices. So you should always calculate you coordinates relatively .

I have made exactly what you're aiming with both of my games (check my signature) : one applet and one apk , with almost the same code . I've written an interface which imitates Java2D, and implemented both in android and Java2D .
ex:

1   2   3   4

BBufferedImage img = ImageUtils.createImage(300,300); GGraphic2D g = img.createGraphics(); g.drawRect( new RRectangle(10, 10, 60,60)); g.dispose();

This code will do the same thing on Android and Java2D. Note that I had to re-write some real simple classes (like rectangle), because they are distinctly represented on Android and Java2D (in android the rectangle is represented by top, bottom, left and right coordinates, while on Java2D it is represented by x, y , width and height).

If you are interested I might document it decently and make it available for you .

Games published by our own members! Check 'em out!

[teletubo]

I once had some of the same ideas. I honestly think very few games are going to be fun on both the desktop and handheld as the platforms are so different.

/Martin

And I quite agree with you . Android gaming can be very different from desktop, including the audience .

The reason I wrote a Java2D imitation and cross library is just because I was very used to writing Java2D and didn't want to bother learning a different API, and because of the testing (since testing and debugging on the Android is a pain) .

[appel]

And I quite agree with you . Android gaming can be very different from desktop, including the audience .

The reason I wrote a Java2D imitation and cross library is just because I was very used to writing Java2D and didn't want to bother learning a different API, and because of the testing (since testing and debugging on the Android is a pain) .

The game intended is designed to both work in a handheld and desktop. We're not just going to make a desktop game and then slap it quick and dirty over to android hoping it will play the same.

I wonder, what are the mainstream Android resolutions?

[strategy]

I wonder, what are the mainstream Android resolutions?

The direction the platform is going, there soon won't be any "mainstream" resolutions - we already have at least 4, and with the tables coming out and producers targeting the iPhone "retina" display, that spread is just going to increase.

I have to say I agree with Martin. It is very hard to make a game that is good for both the phone and the desktop. Completely different demographics - completely different play styles. This is very obvious if you see the kind of games that do well on the platform.

[tberthel]

I did it for all my games.  My games run on Android, J2SE, and J2ME.  That includes Moblin/MeeGo/Linux, Windows, Solaris, Mac, and more.  Even with full screen support.

All I can say is that I loved making my games work across 20+ devices, but it didn't make me money.

My advice is to just make the game for the desktop and then have someone like me make the port to mobile.  I will probably end up opening my Game Development Kit by the end of the year at: http://www.abappsstore.com/

[tris2k]

There currently are two projects that I'm aware of that try to facilitate desktop/android development with one game codebase for both platforms. Others android specific, but alot of droid 2d/3d/modelloader etc projects on google code:
1. LibGDX: http://code.google.com/p/libgdx/ (2D w/ GL context)
Uses jogl for the desktop impl.
blog: http://apistudios.com/hosted/marzec/badlogic/wordpress/

2. Scorpios: one of Nate's projects http://code.google.com/p/skorpios/ (2D w/ GL context)
Uses lwjgl for the desktop impl.

3. jPCT-AE - an Android port of jPCT (3D)
http://www.jpct.net/jpct-ae/

4. Ardor3D on Android (3D)
http://www.ardor3d.com/wiki/android_dev

A Couple Android Specific:
Rokon: http://code.google.com/p/rokon/ (2D)
http://rokonandroid.com/

AndEngine http://code.google.com/p/andengine/ (2D)
blog: http://www.andengine.org/blog/

Would be cool if the wonderful slick2d would be ported to android. Kev was first discouraged by floating point performance of android, but as he said targeting 2.0+ should be ok. Really seems so considering the capabilities of these new droid devices.

So let's make something. No reason why slick shouldn't be running on android.

I started a little android/desktop  project. It borrows the GL abstraction layer from libgdx (i removed most of the ES specific methods)
It uses lwjgl for the desktop impl. Api similar to slick2d w/ xna stuff.
 
Troid:  http://code.google.com/p/troid/
My Tube    http://www.youtube.com/user/droidgamers
Typical game looks something like:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41

public class Game1 extends Game {         .....    public Game1 (String title){       super(title);    }    public void init(GameContainer c) {       // Texture2D       tex = Content.getTexture("res/example.png");         flip = tex.flippedCopy(true, true);             scaled = tex.scaledCopy(0.5f);             sub = tex.getSubTexture(0, 0, tex.width/2, tex.height/2);             // Animation       anim = Content.getAnimation("res/homingmissile.png",64,64);         anim.setPingPong(true);             // XML SpriteSheet       sheet = Content.getXMLSpriteSheet("game1/game1_pack.png", "game1/game1_pack.png.xml");       cannon = sheet.getSprite("cannon.png");       c.showDebug(true);    }      public void update(GameContainer c, float delta) {                 ....    }    public void draw(GameContainer c, Graphics g) {         g.drawTexture(tex, 0,0);       g.drawTexture(flip, 0,0);       g.drawTexture(sub, 0,0);       g.drawAnimation(anim, 100,100);       g.drawString("Line 2\tLine 2\tLine 2\tLine 2", 100,500);          }      public static void main(String[] args) {         DesktopGameContainer gc = new DesktopGameContainer();       gc.setGame(new Game1("Game1 Test - Desktop"));       gc.start();    } }

The same code runs on both android and the desktop. Only difference being the 6 line launcer for android:

1   2   3   4   5   6

public class TestsLauncher extends GameActivity {    public void onCreate(AndroidGameContainer gc) {                         gc.setGame(new Game1("Game1 Test - Android"));       gc.start();    } }

As for screen size considerations, scaling the gl context should do the trick. Think that's how iphone games work on the ipad


Those other projects are alot more advanced than mine , but im trying to incorporate as much of slick's functionality as I can manage. If anyone with a phone can test out the demos that would be great. i don't have one.
Checkout the code. let me know how much it sucks. Did i mention i'm a gl n00b? 

[tberthel]

Well mine doesn't, "try to facilitate".  It actually already has 10 real games on J2ME, Android, and J2SE.  That includes Moblin/MeeGo.

Why just support Android and J2SE when you can get J2ME as well.

[Nate]

Thanks for the plug tris2k. I wish I had more time to spend on Skorpios. I just got a puppy and it is a huge time sink! Cutest thing in the world tho. She's sleeping on my lap right now.

Games published by our own members! Check 'em out!

[jfelrod1960]

Maybe you should give Ardor3d a look.  I see you are a member of the community.
http://www.ardor3d.com/forums/viewforum.php?f=17

The developers are trying to upgrade the engine to facilitate desktop/android development.

[tris2k]

Thanks for the plug tris2k. I wish I had more time to spend on Skorpios. I just got a puppy and it is a huge time sink! Cutest thing in the world tho. She's sleeping on my lap right now.

Baby is a full time responsibility 

Why just support Android and J2SE when you can get J2ME as well.

Is JME worth the effort? 

[gouessej]

Well mine doesn't, "try to facilitate".  It actually already has 10 real games on J2ME, Android, and J2SE.  That includes Moblin/MeeGo.

How do you support MeeGo? I thought J2ME was not supported on this platform.

Why just support Android and J2SE when you can get J2ME as well.

J2ME is very fragmented as far as I know, you have to know the bugs of each particular VM... M3G and OpenGL-ES are not supported by all J2ME-compatible mobile phones.

[tberthel]

MeeGo/Moblin does support J2SE though.  While my games do support J2ME they don't require that the device support it.

Yep not all J2ME implementations are good, but most phones that support it now do fine.  I'm not concerned with J2ME or Android fragmentation, but you are right about 3D support.  My current games are not limited to OpenGL.   That is they will run without OpenGL, but may have performance improvements based on hardware when it is enabled.

[gouessej]

MeeGo/Moblin does support J2SE though.  While my games do support J2ME they don't require that the device support it.

It is a nice piece of news as I had read somewhere Java would not be officially supported on MeeGo.

Yep not all J2ME implementations are good, but most phones that support it now do fine.  I'm not concerned with J2ME or Android fragmentation, but you are right about 3D support.  My current games are not limited to OpenGL.   That is they will run without OpenGL, but may have performance improvements based on hardware when it is enabled.

I see what you mean but I don't imagine writing a 3D FPS without proper OpenGL(-ES) support.

[gouessej]

J2SE for Embedded 6 is not shipped with Meego by default, some manufacturers use it with Meego, that is what I feared...