Another attempt...

Despite my lack of posting here, this project is not dead.  It was only "mostly dead".  It will be revived using an actual game engine rather than me coding in the draw loop and game loop myself.  So, as soon as I teach myself how to use UDK (I have reasons beyond GeoBlox for wanting to learn it), then I can get started.

When I have something to show for it, I'll post here again.

A New Direction

After several days of reviewing the code in search of our notorious memory leak, I came to a tough realization:  re-implementing the project from the ground up would be easier.  I didn't want to make this decision all on my own though.  So, I had a discussion with my brother.  We agreed to take the experience thus far as an education in the development process and are taking a much more formal approach this time through.

Now, we won't have the obstacles that we had before.  I won't be learning a new programming language, we won't be trying to figure out how to get his graphics to interact with my code, etc.  As my brother says, "It's always easier the third time."  Hopefully, we can count the initial prototype as "the first time," which puts us snugly on the third time now. :-)

Discussions

My brother and I finally were able to match up our schedules and have a meeting about the state of the game.  We talked for a fair bit about the memory leak issue we're seeing and agree that we should solve it sooner rather than later to avoid future issues that might be caused by it.  We also decided that we need some more formality in our approach to the development process.  We need design documents, feature lists, well-defined responsibilities, a well-defined production pipeline, etc.

It's been a bit thrown together up until this point, which is how I imagine most independent game developers start out.  However, if we want to actually be successful, we can't just focus on the core part of the game and expect people to like it.  So, we're going to get a bit more "business-like" by formalizing our methods, which all sounds a bit boring, but I think it will actually be a huge benefit to us now and in the future.  Once we get our production pipeline figured out, then we can start focusing more on the fun parts of game development.

So, as meeting go, this one was quite productive.

How Much Was That Worth?

Continuing from my progress last night, I worked today to integrate the moving text (TemporaryText) component into the game.  Though, I had a thought last night before bed.  I was thinking that my little brother isn't a particular fan of the TextField object and that I should generalize this component to animate other things.  As I thought about it, I realized that the thing being animated was really of no concern to the TemporaryText class.  So, I made a few modifications and renamed it to TemporaryObject (which may be a bit vague, but I'll rename it later if I need to).

Armed with this incredibly flexible component, I integrated it into the game.  I had to modify the model to return, not only the current score, but the number of points the last action earned and the position at which the last fired block landed.  I used that position to specify where the point text should start.  I had to mess around a bit with font sizes and text color (all which will likely change when my brother's more artistic eye has anything to do with it).

All in all, the addition was easier than I expected.  Here are some screen shots to get an idea of how this works.  The points fade in at the last fired position and then move to the score position in the top left and fade out.  The picture below are before, during, and after the points are generated (an animated gif would have done better, but I'm not particularly interested in figuring out how to make one of those at 1am).

Anyway, with this new feature, players will know how much that combo was actually worth. :-)

Just Make It Right The First Time...Piece Of Cake

I write that title mostly in jest, but I did make a component that actually worked right the first time.  Instances like this aren't all that common in software development.  So, I'm actually quite happy about my latest success.

I was trying to think of what other programming I could do for the game and thought of a component that I could use to show the points that a combo earned.  I wanted something general enough to be reused in other contexts.  So, I gave the component, which I called TemporaryText, all sorts of parameters.  I was even feeling particularly inspired by jQuery and made some of the parameters able to be either numbers or objects with multiple numbers, which was a moderate pain but it provides a great deal of flexibility and ease of use.

I drew from the screen manager component in setting the transitions and defaults of the parameters.  My proof of concept code fades in a message that says "Click!" wherever the user clicks.  Then it animates the text up into the top left corner of the screen and then fades out.  I was mostly expecting some sort of crash to happen because of the complicated transitions, but apparently I was thinking clearly.

I separated the animation into three stages.  In the start() function, which is the only public function of the class, the object adds itself to a DisplayObjectContainer and does the "in" transition based on the type that the user set.  When that transition is done, the object calls the move() function, which moves the text to the ending position.  When that transition is done, the object calls the finish() function, which does the "out" transition, also set by the user, and removes itself from the DisplayObjectContainer.

I didn't have time tonight to integrate this into the game, but I expect that it'll go fairly easily.  Anyway...yay for quick success!

It Works...But I'm Not Happy About It

I've been researching AS3 event handling for days and have not come up with a solution for the pause screen.  I noticed a comment on stackoverflow.com (which, by the way, is a programmer's best friend, I've found) that said to add a mouse click event handler to the stage and output the target and currentTarget of the event to see what is eating the events.  Well, that turned out to put me on the track of a workable solution, despite its hackish nature.

The stage was grabbing all of the click events on the pause screen.  So, I decided to change the addEventListener() call from being attached to the MovieClip that held the button on the pause screen, to the pause screen itself and then finally to the DisplayObjectContainer that the pause screen is getting added to (the stage).  The effect of which is that clicking absolutely anywhere on the pause screen will unpause the game.  Maybe that'll turn out to be a good thing...I still don't like the solution.  If I ever need to add an event listener to a button on a layered screen, I'll have to revisit this problem.  At some point, I should probably read a book or something on AS3 to get some "formal" training.

In any case, progress was made.

Adventures With Stacks And Boolean Expressions

So, the good news is, I was able to get done the things I was hoping to get done today.  Unfortunately, it took me longer than expected.  I'm still feeling like a newbie when it comes to Flash programming, and it definitely showed today.

For the high scores screen, I was able to provide a main menu option to get to it, and also went directly to it after the game over screen.  I had, what I thought was, a clever boolean expression [...it's about to get technical].  I have a utility function to insert an item into an array based on the value of a named field it the item.  The high scores have both a score field and a time field (so you can see how long it took you to get the score), but the items are still sorted by the score only.  I provided a way to plug in an alternate function for determining whether or not two values are "in order," which led to the (not-so-clever) boolean expression inside an if statement:

if ((fn && fn(item[field], list[i][field]) < 0) ||  item[field] < list[i][field]))

The "intent" of this was to only call the user-supplied fn() function if it was present.  Otherwise, just use a standard less-than operator.  The problem is, if the fn() function is defined but returns something greater than or equal to zero, then the second part of that expression triggers, which is not what I want.  In testing, I was seeing some strange orders for the scores (e.g. 0, 0, 90, 0, 0, 0).  The highest number *should* be on top.  Once I figured out that it was my utility function, it was an easy fix.  I just changed the above line to this:

if ((fn && fn(item[field], list[i][field]) < 0) || (!fn && item[field] < list[i][field]))

The only change is the !fn &&  part.  What that does is say, "don't use the less than operator unless the fn() function is specifically NOT defined."  That took care of the ordering.


The next big challenge was for the pause menu.  For all the screens up until this point, I was able to just destroy the old screen and replace it with the new one.  Well, that would be rather irritating if pausing the game destroyed your progress.  I recognized that there had to be a way to layer screens on top of each other so I could return the player to the old screen.  I went through several variations on this.  My initial thought was to change my curr_scene member into curr_scenes (instead of an object, it was now an array).  After a bit of debugging, I realized this was unnecessary since Flash DisplayObjectContainer objects work like a stack already.  So, I undid my previous changes and opted to just split my changeScene() function into two functions: pushScene() and popScene().  Those functions were now available in addition to changeScene(), which now just called popScene() and pushScene() in succession.  A few minor changes were necessary to split the functions, but I essentially had exactly what I wanted.

I didn't really want the pause screen to just appear in place.  So, I decided to add a "fade" transition to the screen manager.  It turned out to be very simple.  Rather than transitioning the x property of the screen, I transitioned the alpha property (0 --> 1 does a fade in, 1--> 0 does a fade out).  So, I guess I got done even more than I expected today. :-)

I'm still having an issue with the resume button on the pause screen.  It doesn't seem to want to handle clicks from the mouse, even though I set it up to do so just like the menu buttons.  I'll probably figure it out tomorrow.  It's past my bedtime... >_<