The slides from Branden's presentation at FITC Hollywood 2007, Flash on the Beach 2007, and FITC Winnipeg 2007 - "The Nooks and Crannies of ActionScript 3" are now available for download. Enjoy - and if you have any questions or comments drop us a line.
First off if you want to follow along, it would be a good idea to download the current Abalone source code and read the first article in the series..
I ended the first entry of this series talking about nodes - how each space on the board of Abalone is a node. After deciding on the concept of nodes my next step was to think about what kind of data each node needed to contain. Each node need to know about it's immediate neighbors and what it's current state is (empty, has a black marble or has a white marble). By the looks of it both of these types of data were well suited for something known as an enumerated type. Unfortunately ActionScript 3 doesn't explicitly support enumerated types, but they can be sufficiently faked.
Thus, we have the AbaloneDirection class and the AbaloneState class. Both of these classes should never be instatiated - instead they just hold our special sets of data. So what's the benefit of storing our states in the special strings? Why not just use strings in the first place? Well, that comes down to working smarter and having your tools work for you. If you use this faked-up enumerated type and always refer to AbaloneState.EMPTY then you don't have to worry about funny misspellings and other nasty errors that the compiler won't catch for you. Sure, it's a little more work up front, but your code ends up being much more clean and easier to debug - which is a pretty fair trade off in my book.
The only funny thing in those two classes is that the AbaloneDirection class also has a static method named getInverse - this method helps in making connections between two nodes go both ways. That is NodeA connects to NodeB through it's AbaloneDirection.RIGHT edge. That means that NodeB needs to connect back to NodeA using it's AbaloneDirection.LEFT edge.
Now that our data is sorted out, let's get back to the nodes themselves. After thinking about it a bit I realized that there were in actuality two types of nodes - the regular nodes that we've already discussed and the gutter that surrounds the playing board. These two different types of nodes are similar in that marbles can be pushed into them, but what they actually do when marbles are pushed into them is different. It would be nice if they were essentially interchangable - something that can be pulled off through the use of an interface. I defined a simple interface called IAbaloneNode that enforces two methods, setNeighbor and push. Then I defined two classes, AbaloneNode and AbaloneGutter that implemented that interface.
AbaloneNode defines it's setNeighbor method so that it both makes references to the neighbor and makes sure the neighbor has a reference back to it. The push method of AbaloneNode "pushes" the state of the node onto the appropriate neighbor and handles the logic of dealing with empty nodes along the way. It turns out that AbaloneGutter can't push marbles back into the playing board, so it's setNeighbor method can be blank (it has to have a setNeighbor method though, to conform to the interface). The push method of AbaloneGutter accepts whatever state was pushed into it and then broadcasts out an event of the type AbaloneEvent.EJECT that contains the state (type of marble) that was ejected.
Notice that with all of this that there is no enforcement of the rules of Abalone - and for good reason. By keeping the classes as simple as possible and having them handle one concept (how nodes connect) we end up with more flexible and easier to understand code. In the next part of this series we'll be looking at the code that defines and enforces the rules of Abalone.
Continuing on the "money for nothin' and code for free" train - here's our second code drop of the week! (Don't expect this kind of service in the future!)
I'm finally getting around to learning regular expressions. Yeah, you can commence pointing and laughing now.
Now I'm the kind of person who learns things by futzing with them. So, I wanted to make a quick way to futz with regular expressions - but it turns out a pretty cool one already exists - Kodos. Plus, it's written in one of my favorite languages - python!
However, I also want to learn Flex (again, finally) so I decided for forge ahead and just copy Kodos in Flex. The result is Ninox. The silly name is shared by a type of owl (which if you are a true geek, you will know graces the venerated O'Reilly RegEx book).
Now this is my first Flex app. I'm sure I screwed somethings up - but it does work, and Keenan vetted at least the basic design (so blame him!).
As promised in my last post, though a little late, I just finished up a quick-n-dirty version of the game Asteroids in ActionScript 3. The actual zip file is a Flex project - so you can import it directly into Flex if you so desire (File -> Import, General -> Existing Projects into Workspace, Select Archive).
It's all nice and object-oriented and should be fairly easy to understand. However, if you have any questions please feel free to post them in the comments.
