Quick Links: Gideros Home | Download Gideros | Developer Guide
Creating classes question
  • 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!
  • hgy29hgy29 +1 -1 (+1 / -0 )
    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

  • 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 +1 -1 (+2 / -0 )
    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

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

    Check out my DevBlog, my GitHub, and my games Falling Animals | Breaky Wall | Exetor
  • 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?
  • antixantix +1 -1 (+1 / -0 )
    Member
    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

    Check out my DevBlog, my GitHub, and my games Falling Animals | Breaky Wall | Exetor
  • @antix - cool thanks :)
  • @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.
  • antixantix +1 -1
    Member
    @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 :)
    Check out my DevBlog, my GitHub, and my games Falling Animals | Breaky Wall | Exetor
  • 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 +1 -1
    Member
    @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.
    Check out my DevBlog, my GitHub, and my games Falling Animals | Breaky Wall | Exetor
  • 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 +1 -1 (+2 / -0 )
    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

    Likes: antix, Ninjadoodle

    My Gideros games: www.totebo.com
  • antixantix +1 -1
    Member
    @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.
    Check out my DevBlog, my GitHub, and my games Falling Animals | Breaky Wall | Exetor
  • totebototebo +1 -1 (+1 / -0 )
    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
  • antixantix +1 -1
    Member
    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
    Check out my DevBlog, my GitHub, and my games Falling Animals | Breaky Wall | Exetor
  • @totebo - Thanks heaps for the info, I didn't know that could be done either :)

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with OpenID

In this Discussion

Top Posters