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... >_<

Back In Action

After getting everything moved over to my new apartment and setting up my work area, I was able to get a bit more coding done.  I added a few more buttons to the menu screen (Records and Quit).  Now that the screen manager is doing its thing, adding screens has become easy.  I did notice, however, that there's another memory leak.  I think it's from the title MovieClip object.  I'll have to wait for my next collaboration with my brother before we can know for sure though.  I'm going to try to get the Records (i.e. High Scores) screen working tomorrow.  I'll also add a pause screen, rather than just freezing the game like I'm doing now.

Default Function Parameters For Objects

I haven't really been able to spend a lot of time on the game since I'm in the middle of moving.  I was able to get a little bit done tonight though.

I changed from a list of function parameters in the screen manager's changeScene() function to an object that holds all of the desired properties.  The first issue, of course, was one of defaults.  With parameters, giving a default value is easy, but the downside to them is that if you want to define the last one on the list, then you need to provide some sort of value for all of them, even if you don't want to change the default values.  What I ended up doing was creating a "defaults" object and added a mergeObject() function to my Utility class.  Then I took the parameter (which may be null altogether) and merged the defaults in.  The parameter's properties take precedence.  So, I'm good to go.  After a little bit of testing, I think I can go to bed now.  I'm just glad to be making any sort of forward progress on a regular basis, even if it's tiny.

A Productive Day

After posting to this blog last night, I got an idea for a little riff to go into the second theme song.  Surprisingly, I actually remembered it in the morning and throughout the day until I got home.  I loaded up MixCraft and put the notes in.  I'm still not sure exactly how I'm going to fit it in, but I got it to match up with the drum and bass tracks.

I wanted to get some coding done before bed.  So, I made an attempt at adding some "slide left" and "slide right" transitions (in and out) to my screen manager.  I was pleasantly surprised to see it work the first time.  Even after over a decade of programming, getting something non-trivial to work the first time is still a rare event.  In any case, I can sleep soundly knowing that I made significant progress today.  I even learned the difference between stage.width and stage.stageWidth.

I Guess I Should Start Writing Things Down

So, I'm in the process of creating a video game with my brother.  I'm told that if I want people to actually care about it that I should write a development blog...and here we are!  We're a ways into the process.  So, a little back story is in order.

[By the way, this first entry covers the first 2 months of development because I didn't know to start this blog until then.  So, don't feel the need to read it all in one sitting.  I think I'm mildly entertain, but I'm not *that* entertaining.]

I have been writing software professionally for roughly nine years, non-professionally (unprofessionally?) for the last 17 or so years.  I've always liked video games, and one of my fantasies as a young programmer was to, one day, write a game.  Eager to learn, I went to the book store to see what they had on game programming.  I found several very large books and opened them up.  I was a bit disheartened because they were full of Assembly language code.  Now, I have since learned assembly language, but I knew that I was not interested in putting in THAT much effort to game development, lest I ruin my appetite for games.  So, I abandoned that particular dream in favor of others.  (Though that desire never really went away.)

Not too long ago, my little brother graduated from the SMU Guildhall with a master's degree in interactive media (read: "video game design").  Throughout his  academic career there, and particularly after graduating, he wanted me to make a game with him.  He needed a programmer, but I kept passing it off as "too difficult" and "not my area of expertise."  However, I eventually decided that I was willing to take on a very minor project if it could help him get his career in game design moving.  I thought, "what could be simpler than a puzzle game?"  There aren't a lot of game mechanics to program., the art could be super-easy, and...well...I like puzzle games (who DOESN'T love Tetris?).

So, we began having serious discussions about game development.  We both agreed that the scope we were talking about only warranted distribution on a mobile platform.  I happened to have some Android devices.  So we opted to go with an Android app.  We did a bunch of research and learned about their XML format and program structure.  I also realized that Android apps are written in Java (not my favorite programming language), but I was willing to suck it up to get this game out the door.  Thankfully, however, my brother discovered a way to get Flash games onto mobile devices.  It also had an easy way to develop to iPhones without having to change the code, which essentially doubled our potential market.  That on to of the fact that I could stop refreshing my Java skills was enough reason for me to switch over.  I was excited!  Then he told me that I'd have to write in Action Script 3 (AS3), which I'd never even seen before.  I was suddenly less excited.  I started reading the online documentation for AS3 and realized that it was *very* similar to Javascript, a language I use for work.  I was excited again!  I also found a cool development environment called FlashDevelop that was completely free and actually very good quality.  We were off to a good start.  I was able to reuse my skills from languages like Javascript and C++, and my brother was able to utilize all of his skills in Adobe products.

We knew that we wanted to make something new and different but not so obscure that people wouldn't get it (or worse, not enjoy it).  So we settled on a single, fundamental concept and a few related mechanics.  We had rather long discussions about features (most of which were thrown out or left for "version 2") and were mindful of things like play balance and intuitiveness of the interface (I must confess, most of the "deep" game stuff came from my brother...he *is* the one with the master's degree).  We made a quick outline of our process, knowing it was likely to change, and made clear distinctions in our respective responsibilities.  Then we got to work.  He worked on the art and the menu system.  I got right to designing the underlying model of the game.  Not knowing any better, I went straight to a model-view-controller (MVC) design paradigm, which turned out to be a decent approach for this kind of game.  We hadn't quite figured out how to get his artwork into my development environment (or my code into *his* development environment).  So, the first few iterations had "programmer art" (otherwise known as "colored squares").

[From July 11, 2013]

I had learned about the drawRect() function and wasn't afraid to use it.  We were proud of our working model.  It handled keyboard input and demonstrated all the basic mechanics of the game, and that was within a week of the first line of code!  We showed this early version to our nephew, who I would consider to be an avid mobile game player.  His response was, let's say, less than stellar.

Now, a bit of explanation of the game lest you think, from the above picture, that this is some wacky version of Connect Four (which is an awesome game, but it's not *our* awesome game).  This game is, by all rights, a falling block game.  The twist is that blocks don't always fall down, they have a direction associated with them.  The little black lines (yay moveTo(), lineTo()!) point in the direction that the block will fall when nothing is in the way.  The block with the small red square is the "gun" that fires the blocks.  Groups of three or more blocks of the same color will cancel out, and those blocks off to the right are the upcoming blocks that will be loaded into the gun.

The above version is actually the second version that I made.  The first involved trace() statements and the clever use of numbers and the ^,<,>, v characters ... it was ugly.

At this point, what I had was basically a state machine with inputs.  Nothing was actually animated.  I was redrawing the entire screen after every button press, and we didn't have necessary features like a clock (we want the game to have an element of time pressure).  But what we really wanted to figure out was how to get the artwork into the game.  We devoted a fair amount of effort to this task and, in a weekend of learning about SWCs and libraries and whatnot, figured it out and got some of the preliminary artwork integrated.  I also figured out how to move the gun around with the mouse because detecting keyboard input wasn't going to be terribly useful for a mobile device.

[From July 16, 2013]

Much cooler looking, right?

We turned our attention to the next biggest aspect of the game, and that was the special blocks.  We decided on making special blocks for cancellation groups of 4 or more.  We had to talk about not only what the special blocks would do but at what size cancellation group would they be earned.  That whole discussion lead us to determine that we really needed to figure out a scoring system.  So, we came up with a formula that we felt was balanced enough while still encouraging smart game play.  I added a score tracking feature (with programmer art).  We also decided that the "deck" on the side should fill up the entire height of the screen since we have the space.  The result was this.

[From July 17, 2013]

Now, I was drawing the special blocks where they needed to be, but they didn't do anything special other than behave as "any" colored blocks.  Also, as you can see from the picture, there's a clock block...and no clock.  I decided that I would get to that later.  The other special blocks were going to be more fun since they resulted in extra blocks cancelling.  I wanted to work on things like the bomb block, like the one below.

[From July 19, 2013]

(Plus it meant that I didn't have to figure out how to make a clock for a little while longer.)

The next feature to add was one that I had been putting off and semi-dreading: animation.  I've worked on various graphic projects in the past, and knowing what I know about how computers work I am still amazed that computers can animate things on the screen and not grind to a halt.  My brother assured me that it wouldn't be difficult to animate the block if I just used Tweens.  Having played around with CSS3 animations, I felt like I had a decent understanding of how to go about this.  I read some tutorials and got to coding.  There was only one problem.  I didn't have Flash Pro, which meant that I didn't have the "fl" library, which mean I didn't have the Tween class.  This frustrated me, but I was on a roll and wasn't going to be deterred.  I looked online for alternatives to the Tween class.  I saw some good ones, but they came with licenses, which normally wouldn't bother me, but I was planning on selling this game.  That meant that I needed to pay particular attention to the licenses.  None of them seemed entirely agreeable to me.  So, I did what you're not supposed to do.  I made my own tween class.  This turned out to be easier than I thought.  I had a decent understanding of easing functions, and built my tween class to use my easing class (another replacement for something from the "fl" library).  My first attempt used a linear easing, because it took me five seconds to write it.  The feel just wasn't right though.  That was partly due to the fact that the animation took the same amount of time whether I was firing a block one space or eight spaces.  I gave the blocks a constant speed and figured out the time the animation should take from the good ol' formula d = vt.  I wanted the blocks to seem more like they were falling.  So, I made a quadratic easing function to match the effects of gravity.  I liked the look of that.  I got into an easing function frenzy and decided that the blocks absolutely needed to bounce when they hit.  So, I programmed that in.  As a side note, I had to use the standard form of several quadratic functions that satisfied a certain criteria to make the bounce look realistic.  So, that's high school algebra in action for you right there, if you were wondering where one might use it.

[From July 22, 2013]

Notice the blue X moving up the screen while the gun is already pointing to the right.

What you can't see in the picture is that I also added a shot clock, which will automatically fire the gun if you wait too long, but I had nothing on the interface indicating what it was.  So, that was the next step.  Also, making a second clock is easy once you already have one.  So, I put in a game clock as well.  This was all fine and dandy, but anybody halfway decent at the game could play forever at the speed of the shot clock.  So, we figured out a way to progress the levels to make the shot clock shorter and shorter as the game went on, again considering game design issues like play balance and steady progression.

[From July 23, 2013]

After all those were done and a little debugging happened, I started working on some auxiliary features, namely particle effects and the "ghost" block.  The ghost block, as we called it, in our original design was to indicate to the player where a fired block would land.  On a mobile device, the ghost block would be what the player would press to get the gun to fire (having them move the gun with their finger and fire by tapping the gun would likely result in unintentional firing and frustrated players).  I didn't have any artwork for the ghost block just yet.  So, I went back to ol' faithful (drawRect()).  I also made a first attempt at a particle system.  I remembered my brother talking about different particle systems a lot, but I never really understood them.  He had to explain to me how they typically worked.  So, I made a quick and dirty version.  The results are shown below:

[From July 31, 2013]

At this point, we basically have a working game that doesn't look too shabby.  There was actually an in-between version that had even better art, but something about the way my brother wrote the scripting for it caused a memory leak so we had to pull it out until we could isolate the problem.  This is why he does the drawing and I do the programming :-).  We were on quite a roll for a while, but we had a family reunion to attend, new jobs were had, and life generally barged in.  Our development cycle slowed down considerably.  

Not having many new features to program in, I decided to turn to the music and sound effects for the game until we could get back into a routine.  Unlike my solution with the tweens and easing functions, I wasn't going to be able to write my own music creation software.  So, I had to shell out some money for a copy of MixCraft 6.  I have to say, that software is really impressive.  I spent the better part of a week just figuring out what that software is capable of.  I also realized that, despite having played guitar for many years, I know next to nothing about sound engineering and mixing.  I also don't write music and don't consider myself musically inclined (I can mimic other people's music, I just don't compose).  Given that my brother was busy, I was going to have to be the guy.  So, I starting listening to Pandora.com for some inspiration.  After several weeks of tinkering with different riffs, beat, melodies, and instrumentation I finally got something that might be long enough to be considered a loop-able song for a game.  I was feeling quite proud of myself and gave the song to my brother for review.  He liked it and then told me that, to avoid repetitiveness, I should have at least one other song.  Doh!  I had used up most of my creative juices on the first one.  I gave myself a few days and have about half of a song (if the first song is considered a "full" song).

I needed a bit of a break from the music and am still searching for inspiration.  In the meantime, I decided to write some reusable components that we're likely to need in future games.  I did some research and decided that a screen manager would be a handy thing to have.  I had to figure out how to make a singleton in AS3 to get this done.  Then I tested a proof of concept version (which is too ugly to show here.  "Uglier than that first screen shot above?" you ask.  Yes).  In any case, it works, but I still need to add transitions to the screen changes (enter, once again, my tween class).

Aside from all of this technical stuff, my brother and I have made a marketing strategy for the game, part of which is this blog (if you made it this far, thanks for reading)!

Life is still particularly busy for the both of us at the moment, but we are anxious to get back into full swing.

My intent (and hopefully follow through) is to keep this blog updated with the happenings of our development efforts as they happen.  Here, I will detail our struggles and celebrate our successes.  If you are looking to write your first game, I hope you find this blog informative.  If you've written tons of games, we are more than willing to listen to advice!

Till next time...