Creating classes question

Ninjadoodle · October 2017

Hi guys

Just wondering if there is a way to make a class belong to a scene

Currently I do ...

Player = Core.class(Sprite)
function Player:init(x, y)
	self.sprite = Bitmap.new(atlas:getTextureRegion("player.png"))
	self.sprite:setAnchorPoint(0.5, 0.5)
	self.sprite:setPosition(x, y)
	self:addChild(self.sprite)
	stage:addChild(self)
end

What I'm wondering if there is something like ...

Scene1:Player = Core.class(Sprite)

... and what the correct syntax would be.

Thanks heaps in advance!

hgy29 · October 2017

That should work, although the syntax would be

 Scene1.Player=Core.class(Sprite)

Remark that it doesn't mean that the class belongs to Scene1, rather that its definition is now stored in Scene1 instead of global scope.

Ninjadoodle · October 2017

Thanks heaps for the answer ... I think that's what I was looking for

Does this mean that I can create ...

Scene1.Player=Core.class(Sprite)

Scene2.Player=Core.class(Sprite)

without conflicting?

Thanks again!

hgy29 · October 2017

Sure you can. Classes are just tables in the end, you can store them wherever you want, even pass them to functions, return them, etc

Ninjadoodle · October 2017

Awesome, thanks again!

antix · October 2017

Hey @NinjaDoodle, ever considered using a Bitmap instead of a Sprite for your player class? Sprites are great for groups but a single Bitmap doesn't require it to be hanging off a parent

Player = Core.class(Bitmap)
 
function Player:init(texture, x, y)
  self.texture = texture
  self:setAnchorPoint(0.5, 0.5)
  self:setPosition(x, y)
  stage:addChild(self)
end
 
local t = atlas:getTextureRegion("player.png")
local player = Player.new(t, x, y)

As long as you add the required args (in this case a TextureRegion for the Bitmap class) before your own it's all good.

Ninjadoodle · October 2017

Hi @antix

Thank you for the tip

Is there any benefit / performance increase by doing this - or any disadvantage in using sprites for single bitmaps?

antix · October 2017

There is very little overhead when you have a Bitmap hanging off a Sprite. Once you start getting into hundreds of them it might cause some performance hit. Better to start off lean and mean.. and stay that way

Ninjadoodle · October 2017

@antix - cool thanks

Holonist · October 2017

@antix I think you're mixing up things a bit.

In your example one could still say Scene1.player = Core.class(Bitmap)
That doesn't mean player is a child of Scene1.

You would still have to call Scene1:addChild(Scene1.player) in order for the Bitmap/Sprite/whatever to show up.

Storing the player-object in the Scene vs. in global scope is purely a matter of how you want to call it and if you want to have one player for each scene, and possibly multiple scenes/players active at the same time.

@Ninjadoodle could you supply some more information on what you're trying to do? Because your request may or may not make sense. Usually you would only create one player object and add it to different scenes once they show up.

antix · October 2017

@Holonist, I wasn't talking at all about scenes. I was talking about two different methods to create a new game entity...

1. Create a Sprite, then attach a Bitmap to that Sprite, and finally add the Sprite to your scene.

2. Create a Bitmap and add that to your scene.

So my whole point was that just creating a Bitmap is more efficient than first creating a Sprite and then a Bitmap to represent a game entity. I hope that's clearer

Ninjadoodle · October 2017

Hi @Holonist

Thank for the reply

What you described is exactly what I was looking at doing. Many scenes (mini games) which might all have a Player object.

I was wondering what the best practice is.

I could simply do ...

PlayerScene1 = Core.class(Sprite)
PlayerScene2 = Core.class(Sprite)

and so on ...

I however wasn't sure if there is another way that's commonly used to deal with this case.

Thanks again

antix · October 2017

@NinjaDoodle, will the player use the same data structure for each case? If so then just make it global so then you only need to make one and reuse it over multiple scenes. So in main.lua create your player..

PLAYER = Player.new()

Then in your scene you can cache the player and then add it to the scene

SomeScene = Core.class(Sprite)
 
function SomeScene(init)
  local player = PLAYER -- get the global player
  self.player = player
  player:reset()
  self:addChild(player)
end
 
function SomeScene:SomeFunction()
  local player = self.player
  player:doSomeStuff()
end

Personally I make all global variables in CAPS which makes it easy to spot them.

Ninjadoodle · October 2017

Hi @antix

Thank you for the tip! I will just go with the global setup it seems like its the simplest, and to be honest I think I'm overcomplicating things

totebo · October 2017

Also, a local var would be a lot faster than self;

SomeScene = Core.class(Sprite)
 
local player
 
function SomeScene(init)
  player = PLAYER -- get the global player
  player:reset()
  self:addChild(player)
end
 
function SomeScene:SomeFunction()
  player:doSomeStuff()
end

antix · October 2017

@totebo, nice, I didn't think locals could be used like that. It is logical though since I guess player is local to that entire lua file.

totebo · October 2017

Yeah, exactly. And boy, are they fast. I use them for everything apart from in classes that have more than one instance, where it doesn't work because the local var then becomes shared by all instances. But for things like math.random and other generic methods it makes things run a lot smoother.

antix · October 2017

Hmm okay I will keep that in mind. I suppose it saves typing and code size since I would usually be doing stuff like this...

function Game:generateItem()
  local random = math.random
end
function Game:dispenseCurrency()
  local random = math.random
end
function Game:calculateDamage()
  local random = math.random
end

Would need to watch for things like you said with different instances getting the short end of the stick though

Ninjadoodle · October 2017

@totebo - Thanks heaps for the info, I didn't know that could be done either

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Creating classes question

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Creating classes question

Comments