Quick Links

Education Edu

Simulations Sims

Math Tools Math

Games Games

Generative ArtArt

Actinoscript Prog

Farmville Farm





Click the above-left picture of the FizxBlox! applet to start the game full screen.


Blox Game Engine

The Concept

Following close on the heels of the financial windfall from my very first ever all star super game of cats and mice, I decided to attempt another home-run with a brand new game. Hoping to cash in on the vogue of abbreviating words like text-crazed 12 year old girls, I've shortened my game's name from Physics Blocks to Fizx Blox. It's also cool because it has two X s in it. (u n m bff) I actually got to this with a convoluted path of other names: Brian Ball, Brain Ball, Physics Ball, Physics Blox, and finally, perfection in, Fizx Blox. I figured, getting the name right was 90% of the battle.

The concept of this game is copied verbatim from Keith Peters' (bit-101) iphone game Vector Blocks. Except, that I've never personally played his game. I don't own an iphone, know anyone who does who will let me play with it, and Keith Peters doesn't return my emails. So I can't really say that it operates anything like KP's VB. Mostly, I watched a youtube video of Keith playing a couple of levels of his game. My greatest envy was over his iphone, but I thought the game had merit, too.

I sought to improve upon his design by making the game board larger, making it more accessible with a web version, adding many more types of blox that control the ball's movement, and making it relatively easy for a player to submit his/her own souped up game level for others to enjoy. Except, somehow, his games is popular while mine langours in relative obscurity.


Having been released for almost a whole week now, I cleared my calendar, naturally expecting the deluge of praise and adulation to keep me busy for a while. Much to my chagrin, my stellar blog which typically receives as many as 10 whole visitors in a day has resulted in a barely discernable trickle of attention for the game. Posting a youtube video demonstrating game play, with pop-up bubbles explaining all, also has had little effect, perhaps because it's only been viewed 3 times, and that by myself.

Fizx Blox

Fizx Blox is effectively a physics simulation in which the player drags various types of Blox around a gameboard so that they interact with balls. Standard physics concepts such as Newtonian forces, friction, electromagnetic fields & charge, gravity, and perfectly elastic collisions are applied. The slightly non-standard physics of wormhole portals and magnetic monopoles was also used, but mostly due to my own ignorance of physics and for my own ease of programming. My motto for this project: If real world physics is too tricky, re-label it as Fizx and then do it however you like.

For example, collisions

I remember doing this stuff in physics classes, understanding it, and even programming it. Which is why it is such an embarrassing turn of events that I had so much trouble getting this to work the little bit that I did. But, rather than hash out all the horrible details of this again, you can read about it in my very painful blog entry on the topic, etc.

Magnetic Monopoles

Back when studying EE, I distinctly remember having the idea of "there are no magnetic monopoles" drummed into my head. In fact, Maxwell's equations were usually used to justify this, though I can no longer remember how. Naturally, being the rebel that I am, I programmed magnetic monopoles into Fizx Blox. This wasn't because I had any deep seated feeling on the subject, or even much of a memory of it, but rather because it seemed easier. For what it's worth, wikipedia seems to suggest that monopoles are all the rage again, so go figure.

Something's Not Right

Earlier working versions had all the code in a single frame's actionscript using a library of graphic symbols as necessary, but, that little sinking feeling that I was coding it wrong reared it's ugly head. Somehow, I've been brainwashed into believing that my code needed to be object oriented, based in independent classes, and never rely on predrawn graphics or symbols. Poor poor pitiful me. So, abandoning my previous efforts, I rewrote. Version1, Version2, Version3, etc. But can you imagine drawing a lightswitch, lightbulb, or Tyrannosaurus Rex via actionscript? Yes, that was me. Absolutely nothing in the library, for all the good it did me.

Unfortunately, this sort of thing had to happen a few times. As much as I tried to actually plan my game, my coding often was just off-the-cuff reaction to having coded myself into another corner with an early design mistake such as the one in which I arbitrarily decided to change the primary class in my game, Cells to Blox. Having literally been inherited 47 times, this was going to be a nuisance. Lucky for me, I discovered Heatsoft's free Handy File Tool (HFT) which let me make these changes in one fell swoop. BTW, if there's some easy way to do this already built into windows XP, please let me know (with as little condescension as possible).

Meanwhile I discovered that having functionality broken out into infinitesimally small pieces may make sense for preventing code from ever being duplicated, it surely makes it a nightmare to debug when you can't determine in which of the 5 inherited steps along the way some arbitrary function exists or is overridden. I think real programmers have some sort of cool tool for determining such, but as a professional integrated development environment (IDE), Flash has quite a ways to go before it catches up to the big boys.

If there is some means to determine when to break functionality out into yet another class versus shove it into an already overcrowded class, I've yet to learn it. Fizx Blox errs on the side of complete division of labor and zero overcrowding. I can't say that it made my life much easier.

All those Freakin' Levels

Early on, I knew that I was going to need a systematic approach to my level design. I opted for an array of levels, each element of which, was a "level array". Each "level array" was made up of items, usually, individual blox. [NOTE: In Brian land, Blox is both singular and plural. Yes, it's a little confusing.] Obviously, I'd need the coordinates and type of each. But, to save time & space, there was a quantity. I figured that if (qty>1) then they all appeared together on the sidepanel at the right.

Of course, sometimes, blox can be modified, e.g., normally, the variable push blox can be rotated, have it's strength increased/decreased. But, what if I wanted a non-standard angle blox that I didn't want varied? OK. So then each item entry in the level needed to have flags to indicate whether it would be locked in position, strength, or direction, and initially appearance on the gameboard. Competent programmers with functioning brains may have a hard time visualizing this next part, but I wasted a ridiculous amount of time confusing myself with whether the flags meant that they were locked or free to move. I attribute at least a portion of such responsibility on this to having my code dispersed over multiple classes. Oh, and then there were the initial values, such as strength and direction for blox. Finally, there were the special case level items that included instructions and title and such.

The evolution of the shape of the levels, level, and level items occurred throughout the programming process. Somewhere toward its completion, I programmed something that would display a properly formatted level based on the current setup of the gameboard. Besides making my job in creating levels much easier, I hoped that eventually players would create their own levels and send them to me to include in the game. {If only I could just get some actual players.}


My real goal was to not have the levels array included in the code but read via XML. This way, I could have a finished working SWF and then just update a text file -- the dream of XML programmers everywhere. But, wouldn't you know it, this problem cropped up.

Early in my Blox programming, I realized I was starting to form long lists of variables that I effectively used as constants. Rather than the near mortal sin of "magic numbers," that is numbers that appear without explanation in the middle of the code, I needed to have all the numbers encoded as constants or variables and then referred to strictly by name. This was deeply imprinted at a very early age. So, when it came to the various colors to be used, I hard coded constants, BLACK, WHITE, RED, etc. at the top of every class that needed them. Naturally, this sort of redundancy necessitated the creation of a ColorObject class which had the official list of all the game's colors in a single location. Similarly, I ended up with a handful of "index" classes that had the several indices used. And a handful of classes seemed to need to know about the couple dozen types of Blox that were possible, in particular, the level reading and level generating classes.

The real problem, as yet unsolved {if you know the answer, please tell me}, involved the use of such indices in conjunction with XML. I certinaly didn't want to have hard coded magic numbers littering my XML. God forbid I change the number or order of blox types in my index and all my XML coded levels become broken. So, I want to have a representation of the actual number, a token, a variable read from XML to tell me what the blox will be, but that information is kept in an index. Using such indices in the XML seemed to make sense at first, such as bit.DeGauss, for the deGausser type of blox, or bit.Bumper, for the pinball bumper blox. But that thing that I read in from XML is either text or value, I have no idea how to read in and make use of a preexisting variable name. I think I would do some sort of eval if I were still living in AS2.

In short, I got hung up on one of the most important part of my design, the XML levels. When I finally figure it out, I refactor and redeploy. But frankly, it's going to be a rhymes-with-witch to get all that hand tweaked code that generates levels that look like arrays to instead look like XML. I can hardly wait. Maybe if I'm lucky, I won't figure this out real soon.


I've always found it to be the case that those silly little details, unimportant to actual gameplay, such as intro screen, credits screen, scoring system, points, help, etc. are such nuisances to code. At least, they're not nearly as much fun as the game itself. Fortunately for me, I pretty much perfected the game here to not have scoring or points and to not give credit to anyone, even myself. However, I found that I did need to create something of a help system.

But, for crying out loud, how difficult could it be, seeing as I'd already programmed all the elements of the game and had specialized classes for everything under the sun. Apparently, plenty.

I ended up creating this ridiculously elaborate help system with help board, help page, equation helplet, and text helplet classes to get the job done. All of that, in addition to all my object visible classes needed in the game. And yes, I really did need Blox equations in the help system. Check it out for yourself.

Of course, this necessitated an elaborate helppages array reminiscent of my overwrought game levels array. But, when it was completed, it worked so beautifully, I can hardly wait to re-use it in another game. It actually became fun to create the help pages. In fact, I had so much fun, I ended up creating an easter-egg help page. Pure silliness.

Naturally, I feel completely confident in revealing all my personal and painful programming experiences here because, based on my website's statistics, apparently no one but my mom is actually reading my blog.


Ever see one of those really cool, smart actionscript programers, with really popular blogs, like Lee Brimelow or Gary Rosenzweig, in their video tutorials with coding, voice, and sometimes even a picture-in-picture of themselves as they teach/program some really cool stuff and then wonder how the heck did they create that? I'd always just assumed that they had some really cool computer like a mac that did all that stuff about a billion times better than my pc.

And that, probably still is the case, however, in playing catchup to the youtube generation, creating a Fizx Blox video of my own, I discovered that this was even doable on the pc, for basically free. Jing, camtasia, and a few others have a few free solutions, if you don't mind a little hassle converting between formats to one that finally fits. And if you are really hard core about it, you can easily figure out out to overlay various streams (such as your webcam) on top of your game demo video with tools like premiere or after effects, but talk about overkill. My video is silent simply because I don't have a microphone on my desktop anymore. This was related to temporarily having a yappy little dog in the house that liked to chew on things on my desk.

I probably won't be trying to compete with the youtube professionals.

Back to Blox

So, now that I have this "blox" system, I realize I can apply this to other games. Blox tower defense, Rainbow builder blox, and a few others. Rainbow blox is currently in the works.