dcsimg
A Flash Developer Resource Site

Results 1 to 7 of 7

Thread: Need advice from someone used to OOP

  1. #1
    Member
    Join Date
    Sep 2009
    Posts
    88

    Unhappy Need advice from someone used to OOP

    Being still new to it, I'm currently making a game with for now the following classes: Main, LeftMenu, RightMenu, DisplayBox and Enemy.

    I was wondering what is the recommended OOP way of a few things:
    -From where should I create a new Enemy?
    -In which class should be the array that stores them (there will be hundreds)?
    -From where to use the addChild method, because it's always trouble using the stage from any other class than the document class so should the Main class do all that?

    It seems wrong to have the Main do all that, but in the same time, using the stage from another class is troublesome and feels like it's not OOP because otherwise the stage access wouldn't be so difficult to use without the use of so-so code that you don't want to see waste your view of your well organized class.

    I'm not sure if you get the feeling I have as someone new to OOP who although, understand the concept, has to deal with many limitations that become confusing only.

    Please let me know what you think is the right solution about the instanciation/array/addChild stuff.

  2. #2
    Will moderate for beer
    Join Date
    Apr 2007
    Location
    Austin, TX
    Posts
    6,801
    All of the classes you've named are primarily visual. You should start exploring classes for purposes other than putting stuff on the screen. The classic (for a good reason!) pattern is MVC, or Model, View, Controller. A Model is a class representing something that exists in your game world. Enemy, Player, Powerup, Bullet, are good candidates for being Models. A View is part of the UI. A Menu, Windows, Panes, etc are part of the View. In Flash games, Models often do double duty as Views as well. So an Enemy may define its own View.
    What you were asking about falls under the Controller heading. The Controller governs the interaction between models and drives the view. The Controller should handle keeping the game state. Creating new enemies, and keeping track of them is a job for a controller. After a new enemy is created, it will have to be represented in the view, so you'll either pass it up to some other class to put on stage, or the controller can add it to the view itself.

    MVC is not the only pattern you can use, but you should have your game logic in a place that is separate from the game appearance.

  3. #3
    Member
    Join Date
    Sep 2009
    Posts
    88
    And the controller would be the one with some kind of access to the stage or should the addChild method be called within the method of the controller but that method called from document class?

    Is it against OOP is some way to access the stage from other classes?

    Also is it usually 1 controller per view class (if there is at least some interactivity with it)?

  4. #4
    Will moderate for beer
    Join Date
    Apr 2007
    Location
    Austin, TX
    Posts
    6,801
    There's really not a lot of good reasons to manipulate the stage directly. I'll assume you meant in a colloquial sense, and really mean any DisplayObjectContainer such as the document class. Since the DisplayList is about the display, it falls under the purview of the View classes.

    The particulars will vary according to the project, but I'd guess for you that the controller should call a method in the view and pass it a new Enemy, and the view will add it to the displayList.

    There are typically far fewer classes that would be classified as Controller than there are for View. Many times a single Controller for the whole project.

    As I alluded to, you don't always need to be entirely regimented with the M/V/C distinctions. It's possible for a class to embody more than one aspect. But it is important to keep them logically distinct so that you know how everything interacts.

  5. #5
    Member
    Join Date
    Sep 2009
    Posts
    88
    Quote Originally Posted by 5TonsOfFlax View Post
    There's really not a lot of good reasons to manipulate the stage directly. I'll assume you meant in a colloquial sense, and really mean any DisplayObjectContainer such as the document class. Since the DisplayList is about the display, it falls under the purview of the View classes.

    The particulars will vary according to the project, but I'd guess for you that the controller should call a method in the view and pass it a new Enemy, and the view will add it to the displayList.

    There are typically far fewer classes that would be classified as Controller than there are for View. Many times a single Controller for the whole project.

    As I alluded to, you don't always need to be entirely regimented with the M/V/C distinctions. It's possible for a class to embody more than one aspect. But it is important to keep them logically distinct so that you know how everything interacts.
    I really do appreciate you trying to help... but your use of english vocabulary way above my skill level... The use of words I don't know like "colloquial", "purview", "call a method in the view", "alluded", "embody", *COMBINED* with the current subject being aslo something my skills aren't great (as3), at the cost of looking like an idiot, it makes me more confused than before :/

    So basically, I can't apply the stuff you said to use it in as3 as I don't get it's rightful meaning. Feels like 2 puzzles intercrossing each others for me lol o.o

  6. #6
    Will moderate for beer
    Join Date
    Apr 2007
    Location
    Austin, TX
    Posts
    6,801
    I'm sorry, I forget that a lot of people on this forum are not native English speakers. I also tend to get fancy when I write too much.

    What I was trying to say is that you almost never want to actually add something to the stage. Add your new instances to another container. That container is usually the document class, but could also be another DisplayObjectContainer you create (like a Sprite) to keep stuff organized on the DisplayList. You don't want to add things directly to the stage, because that takes it up out of the root/document class. It's better to keep your instances contained, in case you want to load your project inside something else later, like a preloader, or an ad network's loader.

    Adding things to the display should be the responsibility of your View classes. You may want to add a method to a View class like:
    Code:
    public function addEnemy(nme:Enemy):void{
      addChild(nme);
    }
    That will let you trigger adding an enemy from the Controller, but it keeps the actual implementation of how that enemy is added in the View.

    Your classes do not necessarily have to be only View, only Model, or only Controller. Sometimes, it makes a lot of sense to have a single class have responsibility for both View and Model tasks. But you should be aware of the distinction, and write your code so that your logical model information does not depend on the View, or the other way around. It can also be appropriate to make your document class the main Controller, since it is the central class of the project. But again, whether the controller is combined with the document class or not, the methods should have a well-defined set of responsibilities that cleanly interact with Views and Models.

  7. #7
    5+5=55 Schfifty Five's Avatar
    Join Date
    Jun 2006
    Posts
    698
    I don't really have anything else to add that hasn't been said by 5Tons, but you might want to check out this site / book for more in depth info:
    http://www.as3dp.com/

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

HTML5 Development Center