Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Design woes: Inheritance or Interfaces?  (Read 2333 times)
0 Members and 1 Guest are viewing this topic.
Offline RageMatrix

Senior Newbie

Java games rock!

« Posted 2005-03-11 09:40:14 »

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: -


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.

Offline Fraggle

Senior Newbie

Java is Great!

« Reply #1 - Posted 2005-03-13 16:06:28 »

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,


Build multiplayers mobile java game for a living.
Offline RageMatrix

Senior Newbie

Java games rock!

« Reply #2 - Posted 2005-03-13 16:45:30 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Ninja

Medals: 57

falling into the abyss of reality

« Reply #3 - Posted 2005-03-13 19:04:50 »

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

Senior Newbie

Java games rock!

« Reply #4 - Posted 2005-03-13 19:09:44 »

Okey-dokey. Guess I'll have to have a mess around and see whats works best. So no hard and fast rules then? real need to answer that, I guess. Wink
Offline wooD

Senior Newbie

J2ME Developer

« Reply #5 - Posted 2005-03-15 19:53:48 »

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.


Offline Abuse

JGO Ninja

Medals: 57

falling into the abyss of reality

« Reply #6 - Posted 2005-03-15 22:13:51 »

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!
Offline Fraggle

Senior Newbie

Java is Great!

« Reply #7 - Posted 2005-03-16 04:35:28 »

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 Smiley

I have to grab my bicycle and go to work Smiley


Build multiplayers mobile java game for a living.
Offline Abuse

JGO Ninja

Medals: 57

falling into the abyss of reality

« Reply #8 - Posted 2005-03-16 08:55:10 »

A good place to start is jasmin, and BCEL.
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Archive (92 views)
2017-02-27 19:41:49

Riven (83 views)
2017-02-27 17:26:59

numerical (450 views)
2017-02-21 07:32:16

numerical (455 views)
2017-02-21 07:31:46

theagentd (563 views)
2017-02-18 13:42:33

theagentd (559 views)
2017-02-18 13:35:16

h.pernpeintner (1735 views)
2017-01-24 22:39:11

h.pernpeintner (1689 views)
2017-01-24 22:38:32

Galdo (2271 views)
2017-01-12 13:44:09

Archive (2183 views)
2017-01-02 05:31:41
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!