Wednesday, 4 April 2012

Still Struggling

I am now seriously planning Jade, as the Android version of Bridge will be called, and here are a few of the considerations I've been working with.

Contrary to my previous assumption, I think quite a lot of Bridge code will transfer across to Jade.

It appears that most graphics Android apps consist of a kind of basic Activity, and a separate Class, a subclass of View, for the work and the display. I'm currently wondering whether I should do the same, and include all the Sprite / Scene / Data Management etc. classes within the View subclass. I'm revising scoping rules etc.

I was originally planning to put the initialise data in an xml file, but I now feel that my BridgeData class is actually more efficient, involving less iteration and parsing at startup and restart.

I found the Vector class very handy in Bridge, but I guess it's time to use these smart list classes.

I shall retain the off-screen buffer model from Bridge, do all the original artwork at full size, do vector movement etc. off-screen, then blit it into the View canvas when it's done. So at each screen size and each orientation, I'll calculate suitable View dimensions. Then I'll leave it to Java to scale the OSB to the actual screen. This is instead of doing the screen construction inside a Thread.

As for the GUI, there will be a "Jade" button (actually a Sprite) on every screen. Touching it will pause the game and allow the user to make various choices (it will actually be a virtual scene, like Inventory and Limbo). Choices include music, save, restore.

There will be differences in the cursor and carrying GUI, due to touch rather than mouse screens.

I think I can retain the cookie format of save data.

No comments: