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