Design woes: Inheritance or Interfaces?

Java on Mobile Devices J2ME
#1

Okay, I’m now at the stage where I need to keep track of my game entities for each level. In terms of space-saving and efficiency, whats the best method: -

  1. First off, I need to pool some object instances and create them all at the beginning to keep the speed up. How fast is the J2ME implementation of the Vector class? Worth using this, or creating my own doubly-linked list?

  2. Should I use seperate data structures for each type of entity or lump everything all together? If the latter, I need a common way of accessing all my entities. Inheritance or Interfaces?

I need things like: -

projectiles
enemies
collectables
player
platforms

So, should all these have say the same base class or implement several interfaces? This wouldn’t really be something I’d ask if I was using J2SE, but since this is mobile development, I think design needs to be really well-thought out.

Advice?

#2

My advice, if you’re into keeping the jar size small:

  • create on class “entity”, use state machine to determine behavior for each entities.

Creating classes or interfaces will force them to be included into the jar, and creates lot’s of bytecode just to set them up.

Something else: we usally creates interfaces with only final static vars, for code clarity (network states, strings etc…).
They are inlined by the obfuscator and then scrapped, thus not creating files into the jar.

Hope this helps,

Fraggle

#3

Interesting idea with the state machine. Wouldn’t some of sort if/switch construct slow things down the more “types” of entities you have or is it negligable?
Anyhow, I’ll be sure to try it.

#4

polymorphic behaviour through interfaces or inheritance has its own performance costs - which is likely comparable to a lookupSwitch.

#5

Okey-dokey. Guess I’ll have to have a mess around and see whats works best. So no hard and fast rules then?

…no real need to answer that, I guess. :wink:

#6

I’ll probably get beat up for this, but my games have three or four classes.

A main class which contains all the data, typically static.
A canvas class.
A menu class (because List sucks).

I keep all of my data in arrays and allocate it up front. On lower power phones memory is very limited and you don’t want to be creating and droping objects all over the place.

I always have a tick thread attached to the canvas class. This is for animation.

On games with a networking componenet, I put another thread on the main class which handles the networking.

On a game that had to share data between two different midlets, I did create a data class so I could share the data code between the two midlets.

Those are my simple rules for keeping size down.

Wood

#7

My only objection to over use of static’s, is that it encourages inefficient coding.

Many many Java programmers fail to realise that accessing a local variable cost either 1 or 2 bytes, where as accessing a member or static will cost atleast 3bytes, possibly more.

Do this repeatedly, and you end up with code 30-50% bigger, and potencially slower.

Without a full understanding of Java to bytecode conversion, restructuring code to ‘improve’ the performance will often give little to no gain.

Another popular ‘optimisation’ is reducing the number of methods.
While, this in itself is no bad thing - it is not the complete truth.
What efficient code should realy strive to do, is scope reduction.

Avoiding the overhead of methods can give large gains - however - if during the process of merging all your code into monolithic methods, you increase the scope of your local variables, you will infact incur a significant (possibly even counter productive) increase in code size.

Idealy, you never want more than 4 local variables in scope at once. (there are 1byte instructions for accessing the 1st 4 locals)

So, beyond the mananagement considerations of portability & maintainabilty, there is also a very good technical reason why well structured, modular code is not only more readable, but can infact be more efficient!

#8

I agree with Abuse on that. But my final static in interface mentionned earlier are inlined by the obfuscator, so it’s just clarity there…

Btw, switch is costier than if… if… if…

Abuse, do you know a good website or book so I can learn more about the fascinating world of the java-bytecode conversion? (especially generated bytecode cost).
I have severals hypothesis on certains fines points…

Anyway, just to help, here are some classic tips straight out of my head at this early time:

  • Make use of default value in properties initialization as much as possible (int = 0, boolean = false, object = null etc…). It will reduce by a few bytes for each properties.

  • If you really need to have a propertie instead of a local var, making them static will save a few bytes too.

  • Private/public doesn’t make a difference in bytecode generated.

  • Try… Catch() is expensive, use a “global” Try… Catch() instead of severals small ones.

There are many more, but now I have trouble remembering them all :slight_smile:

I have to grab my bicycle and go to work :slight_smile:

Seb

#9

A good place to start is jasmin, and BCEL.