Platform Shooter OOP Game Logic

Games
#1

Hi there my fellow Coronites,

I just started work on a platform shooter (think Sonic or Mario but where the main character can shoot guns and the enemies and bosses can also do this), and I’m wondering about how to tackle my game logic.

I’m using a pseudo-OOP approach, where I spawn a boss-object, and the boss-object spawns bullets every second, and I’m faced with several approaches to bullet collision detection etc. Some of the options are:

  1. Every bullet that is spawned gets its own Runtime-Enterframe eventListener that detects collisions and if needed kills the player or triggers an explosion. This is neat and clean and very OOP-minded, but would mean creating and destroying loads of eventlisteners on the fly all the time.
  2. I use one big enterframe eventlistener in my main game loop that iterates over all bullets in existance in that frame. This is probably more efficient but breaks the OOP paradigm that every object contains its own logic - and makes it harder to just adjust the behaviour of one class.

What do you guys do or use? And does anyone know if having massive amounts of enterframe eventlisteners will slow down Corona a lot?

Thanks,
Thomas

p.s. This is my first game adhering to a pseudo OOP standard, modulizing my code, and I have to say the appeal is obvious regarding structure in the code. [import]uid: 70134 topic_id: 27921 reply_id: 327921[/import]

#2

I would think 1 would be better - a massive amount of Runtime listeners is always better avoided if you have an option to do so. [import]uid: 52491 topic_id: 27921 reply_id: 113037[/import]

#3

Peach said…
I would think 1 would be better - a massive amount of Runtime listeners is always better avoided if you have an option to do so.

Surely you mean number 2 would be best then, or have I read it wrong? [import]uid: 7841 topic_id: 27921 reply_id: 113181[/import]

#4

This was discussed recently in a different thread (oh, your other thread: https://developer.anscamobile.com/forum/2012/06/25/need-store-oop-objects-table-or-not) but I personally think that you can go full OOP/OOD and still keep to a single thread…

Consider the event model we all know: Lots of objects all wanting to have something done per tap, per timer tick, per frame render etc. All of our code is, whether we realise it or not, in its own memory space - our whole application is a single blob of memory being executed separately from others.

When we want an enterFrame event to be fired we ‘register’ our function to be called on that event with the system and it gets called - undoubtedly along with lots of others.

In your situation, I would do this:

Create a lua file with global functions to be called per given event type (timer, enterFrame, etc.)
In the same file have a function which creates OO-style objects (most devs do this with display objects)
Those OO objects register themselves with the global function for their lua file to get certain events called
When the timer or event function in the file’s global code gets called by the API it loops through the registered functions calling them in turn

Peach is right (of course!) in that keeping event timers like enterFrame functions reduced will improve performance, but (if I remember my compiler lessons properly, so there is some doubt here) this is because of issues like CPU mode switching, similar to the performance bottlenecks caused by error handling - it is better (ie: “more performant”) to predict a situation and handle it logically, even if that is a lot of code, than to simply catch an exception. I could be wrong in this case because I don’t know anything about Apple’s CPU architectures (though being made by ARM they might still have something in common with the Archimedes architectures I learnt on.) [import]uid: 8271 topic_id: 27921 reply_id: 113186[/import]

#5

Don’t have much to add to this - except Acorn Archimedes, RISC OS, FTW.

Sorry I’ll go now… [import]uid: 33275 topic_id: 27921 reply_id: 113188[/import]