Results 1 to 5 of 5

Thread: [RESOLVED] Understanding the correlation of static methods/events compared to non-static

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2008
    Location
    PA
    Posts
    365

    Resolved [RESOLVED] Understanding the correlation of static methods/events compared to non-static

    I currently have a thread going in the Games and Game Programming subforum about a brick breaker game I've been coding. I've come across a scenario where I'm unsure on the preferred method of updating variables. This area of discussion is about the current classes and how they interact, thus a new thread rather than tacking it onto the current one.

    My main loop has a boolean it checks in case it needs to generate a new level. If it does, it calls a method inside a static class (LevelGenerator) called "GenerateLevel", passing through a GameLevel integer variable and a couple of other items. The static class's method then instantiates as many "Bricks" as it needs to display and adds them to the panel (panel is passed to the static class). Each brick has it's own Destroy method. Upon calling the Brick's destroy method, I'd like to raise an event so that I can update the score (integer variable) on the very main portion of the program. But, what's the best method?

    First: Should I forgo any events inside of the Brick class, and upon its Destroy method, just update a public static integer variable on the main form? From previous reading/discussions, I've been led to mostly disregard public statics variables and use events to do cross-class talking.

    Second: If I leave the Brick's Destroy method with an event, the static LevelGenerator class is now hooking the events for all the Bricks it creates. Is it worthwhile to make a static event inside the LevelGenerator class, that gets executed from any Bricks raised Destroy event (since each destroy event is hooked independently in LevelGenerator) and hook the static event in my main form?

    Third: Should I pass a List(of Bricks) back to the main form, and loop them and attach the events to the main form? I already have the List(of Bricks) but it doesn't get passed to the main form currently.

    Are any of these better or faster or more efficient than than the others. In my mind, updating a public static variable is the easiest and least amount of code and just works, but is it "standard"?

  2. #2
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: Understanding the correlation of static methods/events compared to non-static

    If you're updating the score where you destroy the brick then I'd say that it's pointless having an event but if you destroy in one place and update the score somewhere else then an event is probably a good idea. The code that creates the bricks can have a delegate that refers to the method that updates the score and register that with the brick's event when it's created.

  3. #3

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2008
    Location
    PA
    Posts
    365

    Re: Understanding the correlation of static methods/events compared to non-static

    If you're updating the score where you destroy the brick then I'd say that it's pointless having an event
    I'm unsure whether if in the future I'll be updating the score from anywhere else... I think you've opened my thought process though. Maybe it's best to make a public static method on the main form and just call that when destroying the brick passing the bricks value. That might be easier than attaching events and it's more dynamic than just updating a static variable itself. Thanks JMC!

  4. #4
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Understanding the correlation of static methods/events compared to non-static

    I haven't done a lot of gaming programming, but I do think there are various scope issues as to what area of the code knows what information.
    There has to be some level of the game that understands where objects are going to be placed (the bricks may know where they are, but not necessarily how they got there), and movement of the various object etc.

    In my case, I did do most of a game as a programming example some time back, but never completed it.
    The main game logic would know, for instance, that a bullet was in flight and call a method on the bullet object to move the bullet. The game logic would have the list of objects in the game, so would loop and call a HitTest method on all the active objects and the object would return True if it was hit. The score was a variable accessible to the game logic (not to the object hit), so the game logic would update the score variable (part of the game object), but the game object would get the amount to add to the score from the player object hit (the object knew what it was worth, not the game logic code).
    The game logic level did also set a flag indicating that the score variable had been changed.
    That way, later when it came time to redraw the field, the drawing logic would know whether it had to update the score area of the display.
    In my case, the objects did not signal or update the score. They just knew that they had been hit, and reported the hit back to the higher level calling logic.
    They also set an internal flag, i.e. "I'm dying" so that next few frames when they are called to draw themselves, they could animate an explosion sequence before they deactivated themselves.
    Last edited by passel; Apr 8th, 2014 at 07:00 PM.

  5. #5

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2008
    Location
    PA
    Posts
    365

    Re: Understanding the correlation of static methods/events compared to non-static

    I think it's beginning to migrate into some game discussion now, which I didn't intend. But good points brought up.

    In the main game logic:
    - Loop balls 'this is to handle if more than 1 ball is being displayed
    - Move ball(*) 'inside of here I loop the bricks for ball collisions

    ---------------
    Inside of moving each ball, since I'm testing the bricks for collisions to make a valid ball movement, wouldn't it be more efficient to do brick logic at this point. If I just note the bricks and loop them in the game logic next, it's basically a redundant loop of all the bricks. So, at the moment, my game logic is unaware of anything that the bricks do. In my mind it makes sense.

    So, currently, inside of moving the balls with all the collision detection, I call the appropriate bricks destroy method. This sets certain flags for the next call of moving the balls. Thus, inside the bricks destroy method, is when I'd "think" would be appropriate to add the bricks value (score) to the main score of the game.
    --------------

    I'm leaving the previous couple of paragraphs in for completeness. However, as I'm typing it out, I realize I can do it differently. I can always pass back the bricks combined values from the ball movements, which would be passed back into the game logic. Sometimes just typing things out and seeing others thoughts help!

    Marking resolved as I'm now no longer needing the statics or events for cross communication...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width