5 Comments

  1. Saad
    Saad March 25, 2011 at 6:55 pm . Reply

    maybe i’m wrong about this, but is it worth learning papervision or away3d when molehill is coming out?

    1. Trent Sterling
      Trent Sterling March 25, 2011 at 8:06 pm . Reply

      Papervision won’t be updated to use molehill because it’s pretty much an abandoned project, but Away3D already has a molehill build you can play around with.

      Molehill is just a very low level API, and you still need a library like Away3D, Alternativa, or something of your own to do things like importing meshes, set up textures/UVs, and all that other fun stuff.

  2. joel
    joel May 23, 2011 at 10:08 am . Reply

    So I just got finished implementing components to replace my inheritance based entity system. Getting used to factories and pooling has been a bit of a battle, but I feel as though Iā€™m ready to start actual game production.

    im interested, but it seems i cant find the perfect reference of what you are saying.. inheritance system vs the factories and pooling. is there an article that explains about the factory system?

    1. Trent Sterling
      Trent Sterling May 23, 2011 at 1:55 pm . Reply

      You might take a look at PushButtonEngine or another components library. Essentially you rid yourself of inheritance (except in situations where it is obvious to use it), and use components to build your game objects. The components are written to be ‘plug and play’, as if you’re hooking up new USB devices, or ‘code chunks’.

      There are several different ways you can do components. Some people like to get rid of the GameObject class entirely, and use a component manager with an ID set up. That was is the quickest, with a lower amount of function calls to update components.

      Personally I prefer having a GameObject class, as a component container. I think many implementations would do it this way. To break it down further, you’ll have a GameObject class, which simply holds a list of components, a BaseComponent, which you can extend into the new components, and a TickedComponent – or UpdateableComponent, or a BehaviourComponent, whatever you wish to call it, that is updated either each frame, or on a timer/regular basis.

      So maybe you’d have a SpriteComponent, and a RigidBodyComponent, and a FlyingBombBehaviourComponent to create a physics enabled bomb that flys around using user input. But I’m rambling, here’s some links to the FGL discussions where I got into components.

      EDIT: Oh, and the best video I’ve ever seen describing components!

      Components in 5 minutes or less

      Component based Entities with Properties
      http://www.flashgamelicense.com/view_thread.php?search=1&offset=0&thread_id=20587

      Organizing Classes and Objects in a Game
      http://www.flashgamelicense.com/view_thread.php?search=1&offset=0&thread_id=26962

      Good luck, and remember not to get too stuck on design patterns. You can end up dumping a lot of time into them, and the players don’t care how the game was coded… Oh, and make sure your game could actually use components! In many cases, inheritance is fine.

      1. joel
        joel June 3, 2011 at 4:18 am . Reply

        wow, thank you very much for the reply, you even hook up a video of it..
        perhaps since my background is art and not programming, i still have a hard time in understanding the component implementation, from the video. I’m now going to read the stuff in the fgl thread. THank you again šŸ™‚

Leave a Reply to Trent Sterling Cancel reply