Could someone please check this out for me?

Tom2012

In my games I'll be creating simple classes to add sprites to screen.

An example would be a class to add mario-style coins to the screen. Could someone please let me know if this is the way to do it:

1) Coin.lua

Coin = Core.class(Sprite);

-- Event function

function onEnterFrame(self,event)
-- do hit test here
--print(self:getX())
self:setX(self:getX() + self.speed)

-- Went off screen

if(self:getX()>100) then
self:removeEventListener(Event.ENTER_FRAME, onEnterFrame, self)
-- kill sprite
self.myScene:removeChild(self)
end
end


-- Add coin function

function Coin:addCoin(scene,x,y,speed)

local newCoin = Bitmap.new(Texture.new("coin.png"))

scene:addChild(newCoin)
newCoin:setAnchorPoint(0.5,0.5)
newCoin:setPosition(x,y)
newCoin.speed = speed;
newCoin.myScene = scene;

newCoin:addEventListener(Event.ENTER_FRAME, onEnterFrame, newCoin)

end




2) Method on the scene

level1 = Core.class(Sprite)

function level1:init()

Coin:addCoin(self,50,100,2)
Coin:addCoin(self,50,200,1)

end


Thanks and apologies for all the questions. I'll pipe down for a bit after this I promise. ;-)

Ozkar619

It seems you're missing the init() function. It work as a constructor of the class. In this case, as I would do it (I'm no expert btw but i think it would work) would be like this:

---Coin Class---

Coin = Core.class(Sprite)

function Coin:init(parent, x, y, speed)
self.parent = parent
self.speed = speed
--(There are two ways to handle location; by moving the entire sprite cointaing the coin or by moving the bitmap. I'm going to ilustrate both but you only have to use one)--

-(moving the sprite)--
self:setX(x)
self:setY(y)
-------------------

local coinBitmap = Bitmap.new(Texture.new("coinimage.png"))

--(moving the bitmap)--
coinBitmap:setX(x)
coinBitmap:setY(y)
--------------------

self:addChild(coinBitmap)
self:addEventListener(Event.ENTER_FRAME, Coin.onEnterFrame, self)


end

function Coin:onEnterFrame(event)

--(moving the sprite)--
self:setX(self:getX() + self.speed)

if(self:getX() > //whathever the screen size or limit is) then

self:removeChildAt(1)
self.parent:removeChild(self)

end
---------------------------

--(moving the bitmap)--
self:getChildAt(1):setX(self:getChildAt(1):getX() + speed)

if(self:getChildAt(1):getX() > //whathever the screen size or limit is) then

self:removeChildAt(1)
self.parent:removeChild(self)

end
--------------------

end


now on the scene or parent you want to contain this coin:

--(if you want to hold a function used to create coins in the scene)
function scene:addCoin(x, y, speed)
local coin = Coin.new(self, x, y, speed)
self:addChild(coin)
end

--(calling the function)
self:addCoin(50,100,2)
self:addCoin(50,200,1)

techdojo

Also as an aside - I wouldn't be creating a single enter frame listener for each object.
It would be a LOT more efficient to create a list of all "coins" in the world (stored as x,y positions) and then have a "coin manager" object and a pool of "visible coin objects".

It would be the job of the "coin manager" to (re)use entries from the "visible coin objects" pool as and when new coins became visible and current coins were collected.

It would also be the managers job to run through the list of visible coins and then do the appropriate hit checks (on a much reduced data set), animations etc.

From experience I've found the best option is to (where possible) only have one EnterFrame listener and then have an "update" function associated with each class / object, you then call the various "update" functions as and when you need to.

Ozkar619

Also as an aside - I wouldn't be creating a single enter frame listener for each object.
It would be a LOT more efficient to create a list of all "coins" in the world (stored as x,y positions) and then have a "coin manager" object and a pool of "visible coin objects".

It would be the job of the "coin manager" to (re)use entries from the "visible coin objects" pool as and when new coins became visible and current coins were collected.

It would also be the managers job to run through the list of visible coins and then do the appropriate hit checks (on a much reduced data set), animations etc.

From experience I've found the best option is to (where possible) only have one EnterFrame listener and then have an "update" function associated with each class / object, you then call the various "update" functions as and when you need to.

Hmmm Interesting.
How about when you have a list of objects/classes/sprites that are sensible to touch? Do you also use only one touchEvent (touchbegin, touchend, touchmove, touchcancel) and use the list of objects to manage it?

What makes it work slower? Isn't the "for" or "foreach" loop you're gonna have to use to run the entire list going to consume the same resources?

I'm asumming that the enterFrame must have something in the background.

I'm asking you this because I had that architecture (the one with the update method) before on a game I'm programming, but I stopped doing it that way and started to put single enterframe and touch events into each sprite because the first method seemed a little more complex (at least for me) to understand. But if it's a lot more efficient, the hell with simplicity, I'm gonna re-structure the code to work in that way.

Tom2012

Also as an aside - I wouldn't be creating a single enter frame listener for each object.
It would be a LOT more efficient to create a list of all "coins" in the world (stored as x,y positions) and then have a "coin manager" object and a pool of "visible coin objects".

It would be the job of the "coin manager" to (re)use entries from the "visible coin objects" pool as and when new coins became visible and current coins were collected.

It would also be the managers job to run through the list of visible coins and then do the appropriate hit checks (on a much reduced data set), animations etc.

From experience I've found the best option is to (where possible) only have one EnterFrame listener and then have an "update" function associated with each class / object, you then call the various "update" functions as and when you need to.

Thanks for the advice. Going to overhaul my game today with this in mind.