5 Replies Latest reply on Jul 27, 2007 1:31 PM by Newsgroup_User

    A bit of advice for a flash dev wanting to code a game

    archont Level 1
      Hello.

      I've been using flash for quite some time now - though I would hardly call myself a highly skilled coder, especially now that AS3 came out and I have a hard time adapting to some of it's aspects, the switch from an apparent scripting language to a full-fledged, strict, precise and FAST language. But to the point.

      I want to make a game in flash. The (quite lengthy now) design bible is finished, the graphic artist is hired and working, now all that remains is to have a skilled coder, and I, as can be witnessed, have been chosen to fulfill this role.

      To give a brief overview of the game we're making it will be a simple 2d arcade style platform game where your avatar is a small worm trying to fill his belly and get to the end of the level without becoming the lunch of any number of opponents littering the playfield.

      Having quite some background experience in C I decided to use a familiar game structure, a drastically dumbed down version of Richard Fine's Enginuity engine. The tutorial is available on gamedev.net and although the engine never reached the final stage of development it did teach me a certain philosophy.

      To summarize the structure, the engine operates on updating, that is calling the update function of each node in the top level node list, with each of the nodes calling an update method on their children, should they be present, giving us a tree-like structure looping in updates over and over with the ability to pause, kill or move any node of the tree. The nodes, or tasks are for things such as an NPC, a particle effect of his muzzle flash and a list of projectiles he fired, the later two being the child nodes of the NPC node.

      Is this kind of structure needlessly overcomplicated for the requirements of a small flash game? Did anybody already implement this kind of structure in flash? How does it work? In C I would instantly think about pointers as a variable to hold the addresses of all the relevant nodes, however in flash I'm not sure. At this point I'm assuming that should I create a node class and inherit future nodes from it the variables to other nodes would be references?

      Example code is pasted below

      And what about garbage collection? Suppose I have two objects, a global AI manager and the AI of a particular enemy. The AI manager containing a reference to the AI of the particular enemy, the particular AI having nothing but some data . If the first object, the manager, is destroyed, the second would traditionally become memory garbage, unaccessible by any other object. (Note that neither of those objects would inherit from the existing flash classbase). Does flash have garbage collection that would clean up this object? If so, is there a way to invoke and control it manually or is it done on a frame per frame basis?

      As for physics I'm using the same Separating Axis Theorem-based approach as metanet did in N Ninja, though I'm not certain if I need that kind of complexity given the game was supposed to be simple. While I'm at it, does there exist a flash collision detection/response library? Third party naturally as I'm talking about functionality beyond hittest.

      And finally, if anyone has any tips, links, advice, books, titles to share with a fledgling AS3 coder I would be very obliged.

      Thanks,
      -archont
        • 1. Re: A bit of advice for a flash dev wanting to code a game
          Level 7
          Hi Archont,

          Man, I'm going to sound like I'm selling something but please believe
          me...it's open source! My API has a big chunk that allows it to process
          this type of decentralized tree structure with the extra ability to add
          and decouple parts of the tree dynamically (whenever you want). It's
          sort of like the Flash event broadcaster except that it has more
          options. So, yes, you can do that and making scalable applications is
          never a bad thing (as long as you're not killing your processor).

          Class inheritance is very much supported in Flash and ActionScript 3.0
          does a fantastic job of allowing you to manage inheritance. The only
          thing that may possibly get messy is having to call children and run
          down through the tree but, like I said, events can do that for you.
          Rather than:

          for (instance in this.children) {
          call some function;
          }

          ...and having to write the child management routines, you simply do:

          this.createchild;
          broadcast(some message);

          ...and the children do:

          this.listenfor(some message) -> call this function

          Pseudo code but you get the idea. I'd recommend starting with a tree
          structure. Implementing it, once you've written a couple of classes,
          should be pretty straightforward.

          Hope this helps to get you started,
          Patrick

          archont wrote:
          > Hello.
          >
          > I've been using flash for quite some time now - though I would hardly call
          > myself a highly skilled coder, especially now that AS3 came out and I have a
          > hard time adapting to some of it's aspects, the switch from an apparent
          > scripting language to a full-fledged, strict, precise and FAST language. But to
          > the point.
          >
          > I want to make a game in flash. The (quite lengthy now) design bible is
          > finished, the graphic artist is hired and working, now all that remains is to
          > have a skilled coder, and I, as can be witnessed, have been chosen to fulfill
          > this role.
          >
          > To give a brief overview of the game we're making it will be a simple 2d
          > arcade style platform game where your avatar is a small worm trying to fill his
          > belly and get to the end of the level without becoming the lunch of any number
          > of opponents littering the playfield.
          >
          > Having quite some background experience in C I decided to use a familiar game
          > structure, a drastically dumbed down version of Richard Fine's Enginuity
          > engine. The tutorial is available on gamedev.net and although the engine never
          > reached the final stage of development it did teach me a certain philosophy.
          >
          > To summarize the structure, the engine operates on updating, that is calling
          > the update function of each node in the top level node list, with each of the
          > nodes calling an update method on their children, should they be present,
          > giving us a tree-like structure looping in updates over and over with the
          > ability to pause, kill or move any node of the tree. The nodes, or tasks are
          > for things such as an NPC, a particle effect of his muzzle flash and a list of
          > projectiles he fired, the later two being the child nodes of the NPC node.
          >
          > Is this kind of structure needlessly overcomplicated for the requirements of a
          > small flash game? Did anybody already implement this kind of structure in
          > flash? How does it work? In C I would instantly think about pointers as a
          > variable to hold the addresses of all the relevant nodes, however in flash I'm
          > not sure. At this point I'm assuming that should I create a node class and
          > inherit future nodes from it the variables to other nodes would be references?
          >
          > Example code is pasted below
          >
          > And what about garbage collection? Suppose I have two objects, a global AI
          > manager and the AI of a particular enemy. The AI manager containing a reference
          > to the AI of the particular enemy, the particular AI having nothing but some
          > data . If the first object, the manager, is destroyed, the second would
          > traditionally become memory garbage, unaccessible by any other object. (Note
          > that neither of those objects would inherit from the existing flash classbase).
          > Does flash have garbage collection that would clean up this object? If so, is
          > there a way to invoke and control it manually or is it done on a frame per
          > frame basis?
          >
          > As for physics I'm using the same Separating Axis Theorem-based approach as
          > metanet did in N Ninja, though I'm not certain if I need that kind of
          > complexity given the game was supposed to be simple. While I'm at it, does
          > there exist a flash collision detection/response library? Third party naturally
          > as I'm talking about functionality beyond hittest.
          >
          > And finally, if anyone has any tips, links, advice, books, titles to share
          > with a fledgling AS3 coder I would be very obliged.
          >
          > Thanks,
          > -archont
          >
          > package engine
          > {
          > class Node
          > {
          > public var parent:Node; // now is this a garbage-safe reference or would
          > assigning
          > public var lastSibling:Node; // the same value elsewhere trigger a copy
          > constructor?
          > public var nextSibling:Node;
          > public var firstChild:Node;
          >
          > public function Update(){} // pure virtual function to be inherited and
          > overwritten by actual tasks
          > }
          > }
          >

          --
          http://www.baynewmedia.com
          Faster, easier, better...ActionScript development taken to new heights.
          Download the BNMAPI today. You'll wonder how you ever did without it!
          Available for ActionScript 2.0/3.0.
          • 2. Re: A bit of advice for a flash dev wanting to code a game
            archont Level 1
            Wow.

            I've browsed through your library and I must say I am quite impressed. Another hidden gem I would have used before if I knew about it. And while it's got a bookmark already, it's a AS2 version and I'm using AS3. While rewriting the major portions shouldn't be that hard given I have a working example right there, I did read a post about an AS3 version, is it coming up anytime soon?
            • 3. Re: A bit of advice for a flash dev wanting to code a game
              archont Level 1
              Another two quick questions while I'm here. Sorry for cluttering the boards by the way.

              1) Suppose each frame I need a different shape. Is clearing and drawing using the graphics API fast enough to be used for a dozen or so objects for a game?

              2) Although this may seem quite a simple question I have tried several approaches and failed.

              Suppose we have a class with a private variable being a reference to a Sprite. At some point we want to delete the sprite and put another one in it's place. delete doesn't work as one cannot delete a member in a non-dynamic class, while assigning it to null as per the documentation doesn't destroy the object. Unlinking it from the parent does work in making it invisible of course but the object is still in memory. Does both unlinking the displayobject from it's parent and setting it's reference to null delete it? If not, how can it be done?
              • 4. Re: A bit of advice for a flash dev wanting to code a   game
                Level 7
                It's written, just a few pieces missing. If you're not planning to
                broadcast events outside of the SWF (you can do this with the AS2
                version), everything else is there. The methods have been slightly
                changes but the concepts are the same. I'll package up a beta and upload
                it to my site.

                Patrick

                archont wrote:
                > Wow.
                >
                > I've browsed through your library and I must say I am quite impressed. Another
                > hidden gem I would have used before if I knew about it. And while it's got a
                > bookmark already, it's a AS2 version and I'm using AS3. While rewriting the
                > major portions shouldn't be that hard given I have a working example right
                > there, I did read a post about an AS3 version, is it coming up anytime soon?
                >

                --
                http://www.baynewmedia.com
                Faster, easier, better...ActionScript development taken to new heights.
                Download the BNMAPI today. You'll wonder how you ever did without it!
                Available for ActionScript 2.0/3.0.
                • 5. Re: A bit of advice for a flash dev wanting to code a   game
                  Level 7
                  1. The drawing API may be fast enough for shapes that aren't too
                  complex. However, once you exceed about 500 vertices, you start to
                  notice a slowdown. Raster graphics would be better or, if the graphics
                  don't change much between frames (except maybe scaling/rotation), then
                  you can use the drawing API and cache the shapes as bitmaps.

                  2.Generally, all descendants of the DisplayObjectContainer such as
                  MovieClip and Sprite should be declared as dynamic for the very reason
                  that stuff is intended to be added at runtime. Removing objects from the
                  display list, however, is done easily simply by setting the value to
                  null (as you mentioned). A non-dynamic class can only set/unset the
                  items that are specifically declared at compile time, as I think you're
                  aware, so display objects that will change quite a bit really should be
                  dynamic.

                  One note on deleting objects...you don't actually ever delete objects in
                  Flash memory (this was true in previous versions of Flash as well). When
                  you set the reference to null, the Flash garbage collector scans the
                  application memory to see if there are any other references set for the
                  object. If there are none, the object is wiped form memory. You don't
                  actually have any control over this process except to control where
                  references for objects are stored so that you can wipe them. There was a
                  "delete" command in ActionScript 2.0 but this did roughly the same
                  thing...deleted the particular reference. If another class had a
                  reference to the object, it remained in memory.

                  Hope that clears it up.

                  archont wrote:
                  > Another two quick questions while I'm here. Sorry for cluttering the boards by
                  > the way.
                  >
                  > 1) Suppose each frame I need a different shape. Is clearing and drawing using
                  > the graphics API fast enough to be used for a dozen or so objects for a game?
                  >
                  > 2) Although this may seem quite a simple question I have tried several
                  > approaches and failed.
                  >
                  > Suppose we have a class with a private variable being a reference to a Sprite.
                  > At some point we want to delete the sprite and put another one in it's place.
                  > delete doesn't work as one cannot delete a member in a non-dynamic class, while
                  > assigning it to null as per the documentation doesn't destroy the object.
                  > Unlinking it from the parent does work in making it invisible of course but the
                  > object is still in memory. Does both unlinking the displayobject from it's
                  > parent and setting it's reference to null delete it? If not, how can it be done?
                  >

                  --
                  http://www.baynewmedia.com
                  Faster, easier, better...ActionScript development taken to new heights.
                  Download the BNMAPI today. You'll wonder how you ever did without it!
                  Available for ActionScript 2.0/3.0.