Processing 1.0 - Processing Discourse - Asteroids base classes

We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.

Index › Discussion › Exhibition › Asteroids base classes

‹ Previous Topic | Next Topic ›

Pages: 1

Asteroids base classes (Read 1601 times)

blindfish

Asteroids base classes
Nov 29^th, 2009, 4:11am

I've just posted the base classes I used to create my asteroids game on Open Processing:

http://www.openprocessing.org/visuals/?visualID=6263

I did a little bit of work to tidy up the code and added some explanatory comments though I'm very much aware that lots of improvements could still be made... Anyway - if anyone feels the urge to do something with this and post the results here (or just give me some feedback) that would be cool

Where is the what if the what is in why?

Quark

Re: Asteroids base classes
Reply #1 - Nov 29^th, 2009, 9:39am

Hi blindfish I can see you are really getting into OO, this is really useful when developing larger scale software.

I noticed you seemed concerned about efficiency using the registerDraw() method instead of looping through the arraylist. I wouldn't worry about that, getting each class to be responsible for itself can simplify the code in the main sketch (as you discovered with an empty draw method) which makes it much more useful to someone else to use in their own game.

One area you might consider is replacing the arraylist, because removing elements from within an arraylist is quite slow especially if there are a lot of elements. A good solution is probably a HashSet since it is very fast at inserting and removing objects.

blindfish

Re: Asteroids base classes
Reply #2 - Nov 29^th, 2009, 11:51am

I feel I'm getting there with OOP concepts and I've been spending some time reading up on it; but it seems the best way to get your head round it is to dive in and try and put it into practice and I figured a game would at least have a fun outcome

My motivation for posting this code was partly so I could get some feedback on where things could be improved; what had been implemented in a sensible way etc. so your response is much appreciated; and if it's helpful to anyone else then so much the better...

I definitely see the benefit of registerDraw(), but have also noticed some interesting gotchas (e.g. it seems it's possible to register something more than once, which can have interesting effects). One question I still have with it is whether there's any easy way to switch the order of registered objects - i.e. to move the 'layers' up or down. I can see how it might be possible to use some kind of 'controller class' to store objects and unregister/re-register them in the order you need, but wondered if there was a simpler approach?

Thanks again!

Where is the what if the what is in why?

Quark

Re: Asteroids base classes
Reply #3 - Nov 29^th, 2009, 12:14pm

I have had a look at the Processing source code and it uses a simple array to hold the objects that have implemented registeredDraw() and it does not prevent duplicates, well spotted..

Looking at the code the draw methods are called in the order they were registered. That being the case it would not be easy to implement layers. Probably have to do your own thing and abandon registerDraw() at least in part mmm needs some thought...

blindfish

Re: Asteroids base classes
Reply #4 - Dec 5^th, 2009, 4:30am

Quark wrote on Nov 29^th, 2009, 9:39am:

<snip>
One area you might consider is replacing the arraylist, because removing elements from within an arraylist is quite slow especially if there are a lot of elements. A good solution is probably a HashSet since it is very fast at inserting and removing objects.

Well... I've spent a little time converting my ArrayLists to Hashsets. In some cases this proved really straightforward; in others I had to do some work to get things running and I'm still encountering problems. I suspect my lack of experience - with Hashsets in particular - is a key factor here.

I'm now thinking that in some cases the ArrayList is a better (well OK - easier!) option, regardless of performance issues. For instance I'm thinking that it would be interesting to make asteroids bounce off each other. That means asteroid to asteroid collision detection, which means nested iteration over the same container. But an iterator returns the elements "in no particular order". So how do I implement basic collision optimisation (i.e. only iterating over untested collisions in the nested iterator) Do I need to delve into the murky world of even more arcane container types Shocked

Where is the what if the what is in why?

koogy

Re: Asteroids base classes
Reply #5 - Dec 5^th, 2009, 10:41am

there are other classes the implement List and which will therefore let you iterate through them in order - LinkedList or TreeList for instance (neither has to shuffle up the remaining elements of the list like arraylist does)

linked list is a bit slow at removing a given node, but great if the node in question is the first or last node. treelist is good at removing nodes, less good at adding them (but not terrible). depends on how big your lists are really.

(oh treelist isn't a standard java thing but an apache commons library thing - http://commons.apache.org/collections/api-3.1/org/apache/commons/collections/list/TreeList.html and i'm not sure i've seen anyone incorporate apache libraries in processing before, but it should be possible.)

Pages: 1

‹ Previous Topic | Next Topic ›