Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Creating classes question — Gideros Forum

Creating classes question

NinjadoodleNinjadoodle Member
edited October 2017 in General questions
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!

Comments

  • hgy29hgy29 Maintainer
    Accepted Answer
    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.

    Likes: Ninjadoodle

    +1 -1 (+1 / -0 )Share on Facebook
  • NinjadoodleNinjadoodle Member
    edited 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!
  • hgy29hgy29 Maintainer
    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

    Likes: Ninjadoodle, antix

    +1 -1 (+2 / -0 )Share on Facebook
  • Awesome, thanks again!
  • antixantix Member
    edited 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.

    Likes: pie, Ninjadoodle

    +1 -1 (+2 / -0 )Share on Facebook
  • 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?
  • 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 :)

    Likes: Ninjadoodle

    +1 -1 (+1 / -0 )Share on Facebook
  • HolonistHolonist Member
    edited 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.
  • @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 :)
  • NinjadoodleNinjadoodle Member
    edited 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 :)
  • antixantix Member
    edited 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.
  • 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 :)
  • totebototebo Member
    Accepted Answer
    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
    My Gideros games: www.totebo.com
    +1 -1 (+3 / -0 )Share on Facebook
  • @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.
  • totebototebo Member
    Accepted Answer
    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.

    Likes: Ninjadoodle

    My Gideros games: www.totebo.com
    +1 -1 (+1 / -0 )Share on Facebook
  • antixantix Member
    edited 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 :D
  • @totebo - Thanks heaps for the info, I didn't know that could be done either :)

    Likes: totebo

    +1 -1 (+1 / -0 )Share on Facebook
Sign In or Register to comment.