Need to store OOP objects in a table or not?

Games
#1

Regarding my other post about OOP game programming (and bullets :slight_smile: I have a second question:

Typically one would try to keep score of objects created in a table, like " bullets[#bullets+1] = bulletlib.newBullet ". This allows you to go over each element in this table and perform sweet logic with these elements. This is what I typically do (for destroying sprites when a level is over, for instance).

Now, if I would go down another path and go strict OOP, I wonder if this is necessary. I get the feeling that it would be nice to create ‘anonymous’ objects, without names or handlers, and just give them all their own game logic, including logic to destroy and remove themselvers. I could use a variable like “leveldone” and set it to true, and have all my bullets check this variable each frame to see if they should disappear or not.

So what do you think? Sweetness because you don’t have to keep track of things and every objects takes care of itself without the need to be addressed with a handler, or nightmarish because you have no control or management of your objects?

I know this is a very open question but feel free to chip in :slight_smile:

Cheers,
Thomas

p.s. I do all my stuff without physics, just using my own tile engine. [import]uid: 70134 topic_id: 27922 reply_id: 327922[/import]

#2

I am not a fan of OOP personally and haven’t done hardly anything with it with Corona but I daresay this would be nightmarish in my opinion.

I don’t think that’s helpful at all but as you’re soliciting opinions I just figured I’d chime in with mine :wink:

Hope you get a variety of (more experienced) responses!

Peach :slight_smile: [import]uid: 52491 topic_id: 27922 reply_id: 113033[/import]

#3

Hi Peach,

Thanks! One vote for nightmare it is then :wink:

For the record: when I say OOP I do mean the pseudo-OOP as described in Jon Beebe’s “Spawning Objects the right way” tutorial - which in practice boils down to instantiating a sort of class, but without the concepts of inheritance and polymorphism that are beyond my grasp, to be honest!

I do get your sentiment but I am hoping to sort of “lighten up” my main game logic loop - which tends to run into thousands of lines of code easily when I run my own flavor of tile based movement and collision. Making each bullet and boss run their own logic in their own enterframe listener could make my game logic more manageable I would think - but I am definitely still debating very much.

Cheers and thanks,
Thomas [import]uid: 70134 topic_id: 27922 reply_id: 113036[/import]

#4

I’m an old school procedural guy, but I think going OOP where each bullet it its own object had has it’s own logic to determine when it should be removed makes perfect sense. It means not having to track it and I don’t think you’re going to run into the “nightmarish since you don’t have control” because the object has control and it should provide cleaner logic that a single “gameLoop” that has to do a lot of work.

[import]uid: 19626 topic_id: 27922 reply_id: 113044[/import]

#5

Hi Rob,

Thanks for your input. Do you happen to have any experience with or idea of wether Corona takes a big performance hit if you have about 20 bullets on screen, each with its own enterFrame listener?

Thanks,
Thomas [import]uid: 70134 topic_id: 27922 reply_id: 113046[/import]

#6

I don’t think you’ll see a performance hit at all. All you’re really doing is moving where the code lives.

Either you have a list of bullets to loop through and run code on in a single enterFrame event handler, or you have a list of enterFrame event handlers (one for each bullet) to execute. They sound the same performance-wise to me. But the advantages of OOP and allowing yourself to “forget” parts of your game when they’re complete is essential to not driving yourself crazy when you’re making a medium - large size game. Given the time, the more you leverage OOP and event-driven programming the better in my mind.

This is the lua class implementation I’m using: http://lua-users.org/wiki/SimpleLuaClasses
[import]uid: 135733 topic_id: 27922 reply_id: 113049[/import]

#7

– dup post – [import]uid: 135733 topic_id: 27922 reply_id: 113050[/import]

#8

Rob and Adam,

You have convinced me to give it a shot! :slight_smile:

Since you guys seem to know what you’re talking about I have a follow-up question: since I’ll be having a lot of separate modules and objects that will at some point need to be able to “see” where other objects are, is there a good way to work this way without needing to create globals?

More specifically: if I spawn local bullets (shot from the hero’s gun) and have local enemies, how can I detect where these enemies (or bullets) are without having to use lots of globals?

thx,
Thomas [import]uid: 70134 topic_id: 27922 reply_id: 113051[/import]

#9

If any of the Ansca team are reading - I think expanding upon Jonathan’s guides so far with a proper game example in pseudo-Corona OOP would be a good idea.

It seems as though there’s a lot of different ways to starting up with an OOP approach (SimpleLuaClasses, Beebe’s OWL, David McCuskey’s DMC library, etc…); so many in fact that I get scared off before I’ve even begun.

As Adam says above, it’s really essential for any projects of a medium-big structure that it’s got to be worthwhile pushing developers along that path and avoiding epic length game-logic loops. [import]uid: 33275 topic_id: 27922 reply_id: 113052[/import]

#10

Agreed!

So… Jon B or anyone from Ansca: +1 for a tutorial of a game where every item has it’s own behaviour (sort of covered in the spawning tutorial) and the proper structure for making sure all items have access to eachother’s position and other properties without needing to make everything global would be excellent.

I’ve had tons of fun with Corona so far exactly because I could avoid OOP and “hardcode” everything (as I call it) but I’m running into the limitations mentioned above when I’m trying to make more deep or complex games.

Thomas [import]uid: 70134 topic_id: 27922 reply_id: 113053[/import]

#11

20 bullets on the screen at once shouldn’t be an issue.
[import]uid: 19626 topic_id: 27922 reply_id: 113056[/import]

#12

Just curious, what’s the end goal of the bullets? Is it to track them so you can remove them when they are off-screen or hit an object? [import]uid: 14218 topic_id: 27922 reply_id: 113058[/import]

#13

Depending on how far you take the OOP approach there’s also the issue of display objects not working with setmetatable(). I seem to remember Jon talking about using a proxy to get around this and I think that’s what he does with OWL, but I recall somebody commenting in one of his blog posts on the subject about how it wasn’t really a suitable workaround.

But I’m guessing you’re not taking things that far thomas6? [import]uid: 33275 topic_id: 27922 reply_id: 113059[/import]

#14

On your globals question thomas:

It really depends on why. Since you’re talking about bullets, I assume its for the purpose of killing an enemy.

You should avoid having your bullets look for enemy positions on enterFrame if you can. Lookups like that work, but can get out of control quickly. If you shoot off twenty bullets and each bullet is looping through an array of enemies looking for positions, you’re probably doing more work than you have to.

Are you using the physics engine? You could have a collision event listener on your enemies (or bullets either way will work) that check if a colliding object is a bullet or not and if it is, take damage, etc. Doing it this way, you don’t need any globals at all.

Also, may be of use in the effort to be aware of what’s happening in your game without checking manually each frame is the dispatchEvent function of corona display objects. If you needed to count enemy deaths for example you could have enemies dispatch a custom event say “enemyDeath” that you listen for in your main.lua or GameManager.

[import]uid: 135733 topic_id: 27922 reply_id: 113067[/import]

#15

“p.s. I do all my stuff without physics, just using my own tile engine.”

Hah, well then maybe you have no choice. [import]uid: 135733 topic_id: 27922 reply_id: 113068[/import]