Aught Nine: Now Closed

I've imported all my Aught Nine blog posts and am redirecting everything over to my own site:

AndyMoore.ca

Pick up my new RSS feed over there!

Farewell, blogger!

The End of Aught Nine

Well, the year has come to a close. I started this blog knowing it would only last a year -- but don't worry! I'll be firing up a proper blog on my own website (andymoore.ca) soon. I'll make another post here to announce it, and I'll see about exporting these posts there.

Protonaut is an exercise in open development. I make a blog post just about every time I build a [working] update to the game, involve a lot of people in obtaining feedback, and have a lot of fun doing it! I haven't been updating recently because Protonaut has been on hold (dev ramps up again soon!) and I've been working on a new, top-secret project.

It's just an experiment: Switching from Open development to Secret development will allow me to get some perspective on how the two systems work with each other.

I think a retrospective is in order! When I first started this blog, I made some goals for myself. Here's how they shook out:

• I will finish moving out of my house in this next week.
  COMPLETE! I am now living with my girl, Aubrey, and have been quite happy.
• I will sell or give away most of my material goods by February 1st.
  MOSTLY COMPLETE! I have to say that living out of a backpack is quite liberating. When I only really own a backpack, clothes, and a laptop it simplifies life quite a bit. I have a few other odds and ends that I'm still trying to sell or holding on to -- a Wii and a Projector to watch the occasional movie on -- but I'm happy to ditch it all at a moment's notice.
• I will continue working on my various web contracts to pay for my bills.
  DONE! I've gained new exciting contracts over the last year.
• I will make an effort to cut expenses.
  COMPLETE! Aubrey has taught me the magic of making my own food (gasp, shock). I've actually got a handsome sum in the bank right now! I'm quite proud.
• I will finish all of my half-finished projects by April 1st.
  FAILED! I think this one wasn't destined to win through. It only makes sense to finish a project if I actually have plans or interest in them... What I ended up doing was take all my half finished projects, archive them, and promised not to look at them ever again until I'm sure I need them.
• I will continue brainstorming at least one new application or game per week.
  KINDA. I think what I was aiming for with this goal was to make sure that I was constantly thinking and working on innovation and revision, rather than focusing on and over-developing single (flawed?) applications. I think I successfully avoided this, but in a way I didn't expect: I ended up picking a single mechanic and constantly revising and innovating on it, often changing the premise of my application several times before completion.
• I will select a Flash Game from my list and create it by November 1st.
  LOL. I definitely succeeded here! When I wrote that goal, I had zero actionscript experience and had only toyed with Flash itself for a few hours. My first game was complete in 30 days (finished May 1st), and I've now made a few more.
• I will select a travel location and get there by September 1st.
  FAIL! Looks like real life got in the way of this one. Despite selling all my posessions and keeping my budget low, I don't quite have enough money squirreled away to travel somewhere with confidence in my long-term survival. :(
• I will spend New Years 09->10 in a foreign country.
  FAIL! As a successor to the above goal, it couldn't succeed.

It turns out I was quite a bit more prolific than I thought I would, with flash applications. Here's a bit of a timeline:

1. In January, I started this Blog with high hopes. I had done no industry research and had no idea what was going on, really; I was aiming for the future blind.
2. GDC March was the big turning point for me. I met up with the talented Greg Wohlwend, who I would later work with on projects, and got a massive dose of what was possible and how the industry worked in general. I was particularly inspired by Phil Hassey, Petri Purho, and other rapid-prototyping game developers.
3. Space Squid was my first game, finished May 1st, 2009. I gave myself exactly 30 days to learn Actionscript, Flash, setup a dev environment, and build a game. I ended up going through around 20 core-gameplay revisions in that time, and posted most of them to this blog.
   
   I still look back at SpaceSquid fondly. There are several really good, fun game mechanic prototypes in it's development cycle. I'm sure I could turn the basic premise into a set of a dozen fun games.
   
   Sadly, SpaceSquid wasn't picked up by any sponsors or portals (for money). The gameplay lends itself to a quick 2-minute playthrough, with little motivation to move on. I'm happy I only spent 30 days on it, and I look at it like an excellent learning experience.
4. Protonaut is still in development, but is my first mega-project. It has a lot of high hopes and future plans, but is currently in the last phases of development. Greg Wohlwend approached me to do the art on this one, and he's been an excellent source of collaboration for design philosophy and mechanic tweaking.
   
   I'm still convinced Protonaut is going to be a successful title, earning me moneys. I really want the product to be juuust perfect though; it's only going to have one day in the spotlight when I decide to start marketing it. A test-run mini-launch later in the year showed that people enjoyed the game and the mechanics, but were ultimately disappointed in the level selection. I'm going to have to get in there and whip up some premium content...
5. GDC Austin was an absolute blast. Though the venue was a bit lacking compared to the San Francisco version earlier in the year, the people were awesome. A cozy, intimate set of indie devs all hanging out and having fun... Such joy. It was there that I met DanC, who I later started working with.
   
6. Military Contracts are fun and very high paying (military flash apps? lol). I have to give huge thanks to Greg Wohlwend for passing on this job and handing it to me; it's funding my next few games. :)
7. The Wooden Fleet is a game I designed for LudumDare #16, the 48-hour-game-jam. I wanted to try my hand at writing a game in such a small timeframe, from scratch, doing all the assets myself...
   
   I ended up being pretty lazy about it. I watched a movie or two, I slept normally, and spent the weekend hanging out with my girl. In the odd hours of spare time I had, I ended up making a working game idea, but it is incredibly lacking in polish. Things like you can't move diagonally, your support ships spam out due to a bug, and your movement is way too slow.
   
   I really enjoyed working on it though and perhaps sometime in the future I'll revisit the project and make it playable.
   
8. SteamBirds is my current Pride and Joy, and this should be the first time I've mentioned it to the public. :) This is my super top secret development, being made in association with Daniel Cook (DanC of LostGarden).
   
   SteamBirds is really close to my heart because the game type, mechanics, theme, genre, content, and story are all things that I truly love. This is a game being written by me, for me -- obviously with modifications to make it more marketable. :)
   
   It's currently scheduled to launch in January sometime. The first iteration is very near completion... I'm excited :)

There are several little things I left out from the list, and a lot of new projects and collaboration requests going down in the next few months. I daresay this is becoming a full-time gig!

All I need now is some bankrolling success!

In other news: My personal website, offering up my IT services, has resulted in zero business. I want to turn it into a proper site that showcases my work and houses a more permanent blog than this one-off AughtNine gig. I'll post some details once I get something lined up.

I just hate designing web pages, is all. :( Maybe I can pay someone to do it for me...

Protonaut gets Goombas

Protonaut has gotten universal praise on one thing, and one thing only: Shooting.

There isn't much to shoot in the game, and the feature is one almost stripped several times throughout development - but it's hard to scrap the one feature that makes people squeal with delight.

With some recent upgrades to the sound files, shooting is just getting more and more delicious - firing that cannon truly is an enjoyable experience. But I needed something a bit more to shoot at than the occasional Nitrogen atom.

Enter stage right: Goombas. Can you tell Greg has been busy for the last few weeks? :) My art isn't exactly befitting of the game :P

Goombas just walk left and right, and have pretty decent detection for obstacles and pits - and try to avoid them. I'm planning on make a jumper and a flyer of some sort eventually, but I'll see how this plays out in the next few builds. They kill you on touch and don't yet have any sort of projectile capacity.

Enemies might not end up in the final game. This production causes some fairly obvious problems, most obviously: the theme of the game is completely off with them. I'll see how things work out in terms of gameplay and see if I need to rework the whole thing.

It's too bad the Level Editor hasn't gotten more attention. I really feel like the level editor is a standalone work of art, and making things is incredibly easy and seamless - with tons of tools at your disposal. It's almost a direct correlary to my programming work not getting any notice, and the more artistic stuff getting the attention - nobody cares about the backend or the tools! It's like I made the best hammer in the world but I haven't found a carpenter to use it yet.

But such is the path of a programmer, I don't really have the ability to complain about that one. :)

Signposts: New feature on Probation

Protonaut seriously needs a tutorial overhaul, and I've been thinking about how to best accomplish this. I originally envisioned putting "signposts" in the game, with static text on them - then the tutorial would be one big level with a lot of help along the way.

Before I had a chance to put in the signposts, I did a few tests - some people couldn't beat my tutorial level! It was long, too difficult, and not very rewarding. An utter failure!

The signposts never made it in (instead opting for an "introduction" paragraph), and I broke the levels up into 10 easier (and more fulfilling) chunks. After launch, the complaints I get were - retrospectively - obvious: You now only get tutorial text at level launch, before it becomes relevant or obvious as to what it means. You cannot recall the tutorial text except by dying or restarting. A lot of folks took the tutorial text box as a "standard dialogue" and simply closed it.

One thing that really irks me is when players don't read, and close the box that says "PRESS Z TO JUMP - THIS IS CONFIGURABLE IN OPTIONS" then complain that they can't figure out how to jump or that Z is a stupid choice. Of course, I would do the same thing if it wasn't my game, so yes: You, Sir Kettle, are black.

So, here is my proposed solution: an in-game signpost. You can test it here, though the text isn't modifiable at this point (I need Greg to whip me up an interface to do so). I'm really interested to know what you think! Chime in with any thoughts or ideas. Here are some features:

• The intro-box will remain for two reasons: Need the Click-on-level-load to capture keyboard focus, and it gives level designers a place to put a little backstory up if they so desire it.
• The signpost text appears on touch only - thereby not "giving away" level elements or cluttering the screen.
• The signpost trigger box is sizeable any way the level designer wishes. As the text appears from the center of the box, this allows for some creative control on where text appears.
• The text fades out at a variable length, dependent on the 200WPM average that people read at.
• Linebreaks work and the resultant text box auto-resizes to fit.
• The signposts keep track of how often they have been touched, which can be recalled with the %COUNT% variable. This can eventually tie into a badge or victory condition (in the distant future) - allowing for laps counters or other more creative ventures.
• The signposts respect your keyboard control configuration with the %LEFT%, %JUMP%, %RESET%, etc. variables.
• The signpost trigger box is not yet art-ed up, art is not final :)

Again, try it out here, and let me know what you think!

Protonaut Beta Launch: A Retrospective

It's been nearly a month since launch, and it's time for a retrospective on Protonaut!

First up, I should explain away my absence for the last 30-odd days. I'd like to say I'm busy attending GDC and other business stuffs (which is partially true), but the actual reason has been crushing disappointment.

I really shouldn't be disappointed. My brain is telling me that everything is allright, and I know things will work out in the end - as I believe I do have a viable product here. The problem is, my heart doesn't handle disappointment well, and it's screwing up how my brain is responding. Just today I've managed to bundle up all the emotion and kick it out the door, and I'm finally ready to move forward.

Let's rewind a bit and explore what went wrong.

When I launched Protonaut, I knew I had a serious content problem. It's the classic chicken-and-the-egg scenario; I have a game that heavily relies on user-made-content to generate traffic, and contained very little user-made-content. All of my fancy level promotion and ranking tools are useless until I have mass traffic. I decided to launch an "open beta" of sorts, and get some traffic flowing.

Colin had a tremendous amount of luck with JayIsGames in the past, for his game Fantastic Contraption. The traffic was of the perfect demographic and seemed to fit with what I wanted my userbase to be, so I got a review up on there - then halted all media interaction immediately. I didn't want this to get out; it is still a beta, after all. The big release is yet to come!

And that's the traffic graph that pretty much overlays over the week I was at GDC. What's funny is I actually garnered more traffic than Fantastic Contraption did in it's first week, and I got more traffic from JayIsGames than FC did after the review went online. My entire problem lies in retention.

That there is a delicious pie chart of where people left my game for good, their IP address never to grace my website again. 45% of my visitors were lost completely before even loading a level. I then proceeded to lose around 20% of my traffic at each stop in the tutorial, to the point where less than 1% of total traffic finished the tutorial in it's entirety.

What's interesting, though, is that the average user spent over 10 minutes on the site, and loaded (or retried) levels on average 6 times each. A bit more digging shows me that quite a few people abandoned the tutorial partway through to get them to the user content. That's a lesson learned right there. Another lesson learned is that most of those people were restarting tutorial 1 over and over again - a sign that it's too hard, even in it's simplicity.

Sorry this one is unlabelled, but it is how many times each level was played - and essentially goes in order around the wheel - Tutorial 1, tutorial 2, tutorial 3, tutorial 4, etc...

Half the people that played #1 never got to #2. It could mean tutorial 1 is too hard, but it could also mean that the player has already decided "nope! this game isn't for me." A more engaging first-user-experience could correct this.

I'm a real slut when it comes to charts, graphs, and analytics. The average user only viewed/tried 6 levels, but sent me 15 hits to Analytics for clicking in various places on the screen. But the real blow to my pride was this graph right here - the one that everyone gets excited about, TOTAL CONVERSIONS:

Yes, that's right. I'm seeing a THREE PERCENT CONVERSION RATE! *balloons fall from ceiling, cue dance music*

Well, I did on that one day, anyway. If you average out the conversion rate since launch, it's at a still-respectable 0.4%.

Thing is, my traffic has been so low, that the numbers are heavily skewed. On top of that, I made 5 test purchases during development, and this graph is nothing but smoke and mirrors; I actually have made a grand total of ZERO sales of Protonaut after launch (except the one I paid my girlfriend to make).

Anyway, I'm putting my emotions aside now and gearing up to kick some ass. I'm going to rewrite the entire tutorial system and make the whole experience more engaging for a new user; I really want to ramp up my retention figures.

At least I'm getting "SSSL Unblocking" traffic from google!

Protonaut: LAUNCH!

That's right, after months of hard work Protonaut is finally LIVE!

We've decided to launch the game in a sort-of open-beta format so we can continue improving it and adding features as we get more and more feedback. We have a lot of big updates and features planned in the future and we fully expect Protonaut to become an even better product as time goes on.

I have to give a big heaping helping thankyou to our Alphanauts, the earliest testers of our game and invaluable sources of feedback. Also big thanks to Greg Wohlwend, without whom I probably would have cancelled the project a month in.

I'd love to go on a big rambly launch wrap-up post, but this is just the beginning! (and it's also beerfest weekend here in Victoria, BC).

Don't melt my servers while I'm away at GDC! :D

Protonaut: Launch Day?

Protonaut is on-schedule for release later today, likely sometime around midnight PST. Still waiting on some music/sound effects, and we have some shuffling of levels to do in the Trials, but otherwise the game is gold.

There will be one final build (before launch), so if you want to do us a favour and do some playtesting.. now's the time to do it!

Click here to play Protonaut.

PAX: Meh

I attended PAX (The Penny Arcade Gaming Exhibition, aka PAGE; or at least it should be) this last weekend for the first time. People seemed to get so excited about it that I had quite high hopes.

And I was pretty let down.

I caught the Nerd-Cold that was being passed around PAX so I'm a little fuzzy-headed and not feeling my best, so I'll keep this contained to a few brief bullet points:

Post edit: Rambling fail. This isn't short at all.

• You can meet and talk to the developers of the games!
  Not really, no. Sure if you are lucky, or you rush in right at the buzzer, or if you catch one at a quiet moment. But mostly, the exhibition hall is so packed full of people - and the developers are so busy with their tasks - they don't have time to talk. The few developers I did manage to snag for more than a few minutes only had time to tell me that they had a lot of fun making the game (shock!) and that they had an interesting experience and would do it again (double shock!); all the while handing out pamphlets or t-shirts to passers-by of our conversation.
  
  The typical meet-the-developer experience is to stand in line for 45 minutes and get spoken at with a megaphone. The words are usually empty; the standard press-fare you get around games. Everyone sounds like a talking press-release. Then you get a t-shirt for your patience.
  
  I attended GDC, where I could (and did!) talk to some developers for over 30 minutes. Some even went with me out to lunch for for a beer. There was never a line.
• You can play all the latest games!
  Most of the titles at PAX have already been released. A few are on the cusp of being released. But then again, I don't really put any value in playing new games first. I don't really care about that benefit. I would love to (and do) participate in pre-release testing and sharing opinions to help shape the game - but when the game is pretty much gold and just waiting for the discs to be printed... all I'm doing is getting a sneak peak.
  
  Playing games "first" simply means that the game hasn't run through all the review sites yet, and there's a much higher chance that it's a piece of crap. Kinda like how the new movie GI Joe wasn't screened to reviewers when it launched - going there on Day 1 means that yes, you are first... But odds of having a horrible experience? Pretty high, and you have no chance of being warned beforehand.
  
  I really don't know where this whole "I got it first" mentality comes in. I'm not the kind of guy (14-year-old?) who runs to his friends and says "HAHA I PLAYED xyz BEFORE YOU!" and my friends get genuinely jealous. I'm a patient fellow; I wait until TV series are cancelled before watching them, for example.
  
  Contrast this with GDC, where you get to play early builds of games that companies haven't even decided on release yet; prototypes; exploratory gameplay visions... It's quite exciting.
• You get to see all the FUTURE... TODAY!
  Again, I'm going to have to say GDC wins this one. A perfect example was the 3-D gaming concept.
  
  At PAX was the marketable (aka Cheap) version of the 3D gaming experience. Showcased by nVidia, they alternate frames on the display for your left/right eye, and using specially sync'd glasses they turn off your opposite eye from receiving said information. Being displayed on a nice 28FPS LCD display, that equated to 14FPS, with a very heavy (and very annoying) flickering effect. The technology is cheap though - a big enough video card with a special jack for the glasses, and you're set. I watched Resident Evil being played in 3D, which I admit looked cool - but ended up making me feel a little naseous and the twinges of a headache. Plus you are tethered to your gaming box to keep the glasses in sync, or you have to keep swapping in batteries for the wireless replacement. Either way is annoying.
  
  And I'm one of those guys that rolls my eyes at reviewers saying racing games makes them queasy. I'm pretty robust in that department.
  
  GDC's version was Sony's booth. They had a new TV, where they essentially doubled the pixels. Yep, you have to essentially buy two TVs to get this to work. Half the pixels on screen show left-eye information, and the other half show right-eye information. You get the full 28-FPS experience from your television set, which means no flicker, no headaches, and more information. Since the left/right channels are permanently polarized, you can use any standard cross-polarized pair of glasses - no batteries, no tether. Technically speaking you can also get 2xHD resolution in 2D as well. Obviously expensive though - new TVs for everyone!
  
• PAX Panels are awesome!
  No they aren't. I was riveted to my seat for 3 days straight at GDC; I walked out of every single talk I attempted to attend at PAX. It's obvious in retrospect; the attendees are not game developers, they are game players. They don't want the straight-up insightful answer; they want to hear the generic bulk answer.
  
  I'm also pretty upset that most of the talks I attended ended up being microphone-driven. That is to say, the panelists introduced themselves and immediately opened the mic to questions, and just answered them for an hour. This annoys me for two reasons. First, it implies that they really don't have anything to say or share on their own; the talk has no actual foundation. Secondly, the questions are soooo inaaaaaane.
  
  Someone went up to the mic and asked the PAX10 panel if Microsoft's XNA framework supported multiplayer. (!!!!)
  
  Another dude asked the PAX10 panel, "Now that you've released successful games on your own, have you been able to get good jobs at the bigger gaming studios?"... This one just blew my socks off. I suppose the average gamer dude doesn't realize that indie games are an escape from the corporate world, not an icebreaker into it. I guess I can't fault them for that, but all in all it was just a waste of my time.

I guess what I'm saying is, most of the things people attend PAX for can be seen a hundredfold better at GDC - minus the lines, the headaches, and the hassles. Of course, GDC tickets cost 10 to 20 times more.

I had a pretty good experience in another genre at PAX though. It wasn't all bad news.

I ended up spending most of my time at PAX playing boardgames. A crapload of them. And I had a ton of fun doing it - it was really interesting and exciting, playing a bunch of things I had never heard of before. I picked out one or two that I'd even like to purchase, and I had some long talks (and played games with) the staff of the creating companies.

Then the realization hit me: This must be what people are getting out of the video-game side of things. I'm fairly entrenched in gaming media - I subscribe to every gaming site I know of in my RSS reader; I read most interviews and watch a lot of gameplay videos. Everything at PAX I knew before I attended. However, I subscribe to zero board game blogs. I don't even know of any that exist (I'm sure there are though), and as such I was taken completely off guard by the scope and selection of awesome board games at PAX.

I therefore conclude one of two things:

a) PAX is for gamers that do not have the internet (and are not aware of upcoming or released titles),

b) PAX is for gamers wanting to expand their horizons beyond their favorite medium, or

c) Both A and B.

I fall into category C, I suppose. Video games were a complete bomb for me; but Board Games was an awesome experience.

I don't have any plans to attend a future PAX (I don't see there being another 40 new board games for me to play if I do go), but if I did attend I'd probably spend all my time exploring RPGs or figurine-games like Warhammer and the like (since I didn't get a chance to myself).

Seattle itself was kinda fun though. I was so exhausted and spent most of my time at PAX itself that I didn't give a good go of the city, but the few places I went to were great. Tried some decent beers and had a really good curry or two.

One Week to Go

Though technically launch date is somewhere around September 10th, I've got so much going on there's only around 6 days of actual work left for me to finish Protonaut. That means I don't have a lot of time to post here :)

Just launched Build 44 on the site which contains a very new introduction made by Greg. It's pretty wicked.

Other than that - polish, polish, polish! Now that gameplay is finalized it's just bug fixing and pretty-making. I'm about 95% finalized on the set of tutorial levels (now numbering ten), and I'm.. well, maybe only 10% done the actual game levels. I'll get there soon enough. I'd better.

Decimal or Integer to Binary / AS3 Code

I had a need for this routine in Protonaut, and Ryan Madsen was gracious enough to pseudo-code this up for me. I then converted it to proper AS3 and to suit protonaut's needs.

It's modifiable easily enough, but here's the basic premise:

Input a decimal (say, the number 1) and request an array length in return (default 6 bits).

It will convert the decimal to binary, and store each bit into an array in reverse order for easy flag operation. Our example of 1 would then return [1,0,0,0,0,0].

  private function dec2bin(dec:uint, digits:Number=6):Array {
   var result:Array = new Array();
   for (var i:Number = 0; i <= digits-1; i++) result[i] = 0;    for (var i:Number=digits-1; i >= 0; i--) {
    if ((dec - Math.pow(2,i)) >= 0) {
      result[i] = 1;
      dec -= Math.pow(2,i);
    }
   }
   return result; // results are in reverse order... 1 == 1,0,0,0,0,0
  }

I used this code for retrieving a single ascii charcode to store the combinations of the various 6 keys you can press in the game. I googled around and couldn't find anything, so hopefully this will help someone else.

This is easily converted to outputing the Binary to String format, or reversing the Array, if you so need.

Working out Replays

My current project, Protonaut, somewhat recently got a "Replay" feature. You can save your victories and share them with your friends! But how to execute the replay feature is really tricky, especially when you only have finite space and bandwidth to dish them out with.

Protonaut uses a level editor and a collection of Box2D parts - somewhat similar to Fantastic Contraption. Replays in FC are called designs, and all it is is a snapshot of the starting conditions. Since there is now way to interact with FC mid-design, you can safely let the simulation "play out" on your computer, and it will turn out the same. It's as if the fate of your contraption has been pre-determined.

I'm not able to do this obviously. You control the player character throughout, and you can change your mind halfway through playing a level - what with having a brain and free will and all.

After looking at a few options (taking a snapshot of all the objects in the level and tweening them for example), I decided to go with recording keypresses. While a replay is running, it's as if one of those automatic-piano-playing-rollers is over your keyboard. The game otherwise thinks it's you controlling it yourself!

Building the data structure was simple at first. I just wanted to get it done, and I wasn't thinking about storage requirements. Here's an example clip of the replay file:

[...] ,,1,1,0,0,0,0,0,0,,2,2,0,0,0,-1,10,0,,3,3,0,0,0,23,0,0 [...]

I used comma deliminators and the data is broken down as:

,,Array Index, Tick#, jumpstate, firestate, (other keys)...

Keystates could be At Rest (0), Just Released (-1), or Held Down (length).

There was several problems with this setup, mostly structural, but all my fault. It was possible to hold down, say, the fire button for millions of ticks - throwing huge numbers into the mix and making it a very big and clunky bit of code. To help smooth things over, I did ZIP the file - which shrunk things down nicely.

Yesterday I decided to clean things up. I realized that "just released" and "held length" could be programatically determined; If the last frame was > 0 and this frame == 0, then it means the key was down last tick.. but not this tick. -1 for release. So it was no longer necessary to store the actual keystate, but just an up/down 0/1 representation.

That means that the keystate could be summarized in a single 6-bit number, that has 64 possible combinations. From there it was easy to find a spot on the ASCII Character table that had 64 human-readable characters in a row, and just mapped the key value to that.

Then I stripped out the commas and dropped recording of null frames (where you aren't pressing any keys). Then I dropped the array indexes, because they were completely unused. Now the replay data looks like this:

...191J192Q200p201'202'203'204'205W300L...

Quite a bit shorter! All it is is "Tick#" followed by a character that represents the keypresses.

After running this through the ZIP algorythm, total space on the database was reduced to 1/20th of it's original size (using a speedrun on Tutorial #1 as a basepoint)!! I'm so very happy with this... I'm sure my database will agree with me. And my bandwidth bill.

Special thanks go out to Aubrey for helping me out with BitShifting and Ryan for writing me out a psuedocode Binary-to-String function.

FlexSDK 3.3 How To Make a Flash PreLoader in AS3

One of the things that has been vexing me lately is trying to get a Flash PreLoader working for my games. I've tried Googling it, but there are too many like-terms: Flex Builder, FlashBuilder, Flex, CS3, CS4... The all have different methods, and my method is the least googleable: Flex 3.3 SDK, AS3 only.

I don't want others to run into the same problem, so here's a tutorial on how to make a flash preloader for AS3 with nothing more than notepad.

STEP 1: Why a preloader?

The first thing you have to do is arm yourself with knowledge. Why do you need a preloader?

As you may or may not know, every single SWF file is a movie. Even if it's a simple Hello World application, it is a movie with a single frame. It's hard to remember this sometimes, because working in the AS3 environment we don't have easy access to the stage's timeline, and everything we do happens on the first frame. Here's the key to remember, though: The entire current frame must be loaded before the frame starts to play. Most AS3 applications are built on a single frame (#1), which means your entire SWF must be downloaded, and loaded to memory, to display anything.

"But SWFs aren't all that big," you say. "Why would I need a preloader for that?"

The average connection speed in the United States is probably way lower than you think, or what you currently have. The fact that you are reading this blog at all probably means you have a 5mbps+ broadband connection. But that's how us geeks roll, and we only ever talk to other geeks. I'm on a 10mbps line with access to 50mbps if I wanted to pay extra for it.

The US has made several headlines recently beacuse the average broadband speed in the US is 1mbps. That is 128 kilobytes per second. But did you note the italicised term there? Over 60% of the United States does not have access to Broadband, so dialup is the connection type for many people. But what does that mean in real terms?

Here at Build 35 of Protonaut, the game is sitting at just under 600Kb - not counting audio assets. On the average broadband connection, it will take around 5 seconds to load and display the game to your screen. On a standard dialup connection, it will take over a minute. Many users will leave your page if they see a blank window for more than a second or two. 5 seconds of load time is absolutely painful, and is faster than the average connection!

STEP 2: Setting Up an AS3 Preloader

Allright, now that I've convinced you to use a preloader for your FlexSDK application, let's take a look at what is required.

First, you will need a whole new class file that will be your entire preloader. Here's some sample code for what I've used, and placed inside "Preloader.as" in the root directory of my project:

package {

import flash.display.DisplayObject;
import flash.display.MovieClip;
import flash.events.Event;
import flash.utils.getDefinitionByName;

[SWF(width='800', height='450', backgroundColor='#E5E5E3', frameRate='30')]

public class Preloader extends MovieClip {

   public function Preloader() {
       stop();
       addEventListener(Event.ENTER_FRAME, onEnterFrame);
   }

   public function onEnterFrame(event:Event):void {
       if(framesLoaded == totalFrames) {
           removeEventListener(Event.ENTER_FRAME, onEnterFrame);
           nextFrame();
           init();
       } else {
           // Show your preloading graphic or animation here
       }
   }

   private function init():void {
       var mainClass:Class = Class(getDefinitionByName("Main"));
       if (mainClass) {
           var app:Object = new mainClass();
           addChild(app as DisplayObject);
       }
   }
}
}

It's a very simple application. It simply adds an event listener that waits until ALL frames have loaded, and once that happens it will launch your "Main" class. At this point in the game, we still only have a single frame, so it won't do much. In this case, "Main.as" is my main class for Protonaut and also exists in the root folder of my project. You will have to edit this to match the main class name for your project - use "BobJones" if "BobJones.as" is the primary class in your project.

I've placed a comment where your preloading graphic, animation, advertisment - or heck - minigame, should reside.

If you compile and run this code alone, without following the extra steps below - the preloader will "blip by" in an instant and not show up until the whole SWF has loaded. So we aren't quite there yet, but we're prepared!

STEP 3: Reconfigure Your Compiler

Now that we have "Preloader.as" in place, we want to move the rest of your application off of Frame 1 and onto Frame 2. This will allow the preloader to show itself first, and wait on the loading of the second frame.

Here's a slice of my compiling instructions:

    "mxmlc.exe" -frame two Main -file-specs="Preloader.as"

They key statement here is "-frame two Main". This tells the compiler to move the class "Main" onto the second frame of the movie, and thus preventing it from loading before displaying the preloader.

For advanced users, note that you can specify any number of frames this way - possibly breaking up your application into several loading chunks, which can silently load in the background while people navigate your menus!

THAT'S IT!

STEP 4: Correcting for Errors

That's it, Unless of course you were referencing the Stage a whole lot in your code. Now that the concept of the "stage" resides in frame 1, the stage is outside of the scope for your "Main" class on Frame 2. Any references in your code to "stage" will now return Null, and probably cause you some headaches.

There's nothing stopping you from passing the stage to Frame 2 as a variable, though!

I dove back into Preloader.as and changed:

    var app:Object = new mainClass();

To:

    var app:Object = new mainClass(this);

Then, in Main.as's constsructor, I had it accept this as a variable and stored it for later reference. Couldn't be simpler!

STEP 5: Basking in your Glory

Now it's about time to crack open that beer because you're done. If you had any questions, or if this helped you at all, please leave a comment! I'll try to update this with any answers to questions people have.

The Pressure to Release on-Time

I am starting to wonder if I can get Protonaut out the door on time.

Greg and I set a goal to have the game in releasable form by September 14th - the date I'll be flying down to GDC Austin. I figured this was a good a date as any - might as well have your game done before going to a game conference. As of this posting, there is just about 3 weeks left. It seemed far enough away, at the time - and our progress on the game appears to be maintaining a steady pace. But then real life steps in.

I could start with the small complaints - tonight's programming timeslot was instead wasted fighting the first-ever porn-spammer on the Fantastic Contraption forums. I am still very proud of how the community held together and stayed sane for over a year before this happened, and I'm pretty sure this will blow over as well - but due to some technical difficulties my entire night was consumed.

I have bigger fish to fry than a single night, though. Some old chums I used to work with have roped me into covering some shifts at their new office next week. Sure, it's part time; I can work most (if not all) of it from home; and the workload is likely light. But it'll harm my train of thought fairly hardcore, and code will progress at a halting pace at best.

Then there is the last-minute ticket purchase for PAX. I've never been to the Penny Arcade Expo, but I hear it is a blast - and that's going to consume a hearty 4-day weekend, plus some recovery time.

Then there is the Great Canadian Beer Festival, for which I am not only attending both days - but am also volunteering for, doing the volunteer orientation, and doing the afterparty. The recovery time for this is going to be even longer.

Let's not forget that Colin Northway, old chum of mine and writer of Fantastic Contraption, is in town and we will likely hang out at least a tiny bit.

That isn't to mention my regular routines (Aikido, getting exercise on my bike, chores, harvest season in the garden, etc.) that pretty much slims my remaining working time down to just about 7 days worth of solid effort. It's suddenly gotten dark in here, what with all the foreboding-ness. I'm officially daunted.

It's not all doom-and-gloom, though. We've hit Build 35 in Protonaut now, which sports the first incarnation of music and sound effects, not to mention a few key tweaks and the usual barrage of new menu interfaces - which has really got me excited. For the first time, Protonaut feels like an unfinished game instead of a collection of parts that might amount to something someday. Roger Levy is now on board with Greg and I to do our music, and he produced a great 8-bit Russian folk-tune to fit the Red-theme of the game today. It reminds me of Monkey Island music, it's really sweet.

For more external influences, Greg posted to his blog about the success of his latest game, Fig. 8, and how the bidding war went down. It's a very interesting timeline and I think it does a good job at representing the value behind proper marketing, and putting your game in the correct (bidding) spotlight. Congrats to Greg & the others at Intuition. It's very motivating reading about other's success.

I suppose I just have to keep my chin high and my nose down to the grindstone. I guess I'll be coding inverted.

Thanks for listening. :)

Build 33: Protonaut Gameplay Finalized

We hit a milestone this weekend, and it feels really nice. The gameplay is finalized.

That's not to say that the entire game is finalized - oh no. Still lots of work to do. But in terms of actual gameplay elements - how the character moves, how elements work, how levels are designed - that's all finalized. If you were to make a level in the game today, it would still work upon release.

This is very good news, as it means I can now start building levels for this beast.

We're up to Build 33 - check it out at www.protonaut.net .

Build 30: Epic Changes

It's finally here!

I'm sorry it took so long to get Build 30 out, but I really had no choice. Exactly two weeks ago I put out Build 29, and things started changing so much that the game was relatively unplayable until just recently. I put in a final few touches tonight and I am left with a product I am happy to release.

I also wanted to make it a big one, since I'm turning 30 this year, and 30 is a big round number, and I'm hoping to have the game in a releasable state 30 days from now... It's just a nice convergence of numbers.

Here's the gist of things:

- Complete UI do-over. All the major graphics and art have been updated and replaced. This was the biggest speedbump - I couldn't release a game if you couldn't sign in!
- Replays. Yep, you can now record and playback your victories!
- A lot of gameplay changes - nothing incredibly major, but important nonetheless.
- New website uploaded.
- New forum software installed and re-built. Also hacked to accept user registrations right from the game.

I thought the old graphics were hot, but this new hotness is just... on fire. I love it, I love it to bits. I especially like how it looks sitting pretty in the new website. The notification boxes and level save boxes are all in place now too, and I've implemented handy new features like URL-copying-to-clipboard and other fun stuff. The entire graphical user experience is simply doublegood now.

It's getting pretty late here so I'm going to sign off for now. Updates and new builds should come more frequently now, and the changes will become smaller and smaller in scope as we start ramping up for launch day. Thank you, Alphanauts, for helping us get this far.

Check out the brand new website at www.protonaut.net.

Check out the complete changelog for Build 30 at this forum post. (It's a big one!)

The Indie's Lament

I just hopped out of a steaming hot shower (where I do most of my thinking) and listening to The Decemberists when I started having conflicting thoughts on how big an Independant Games team should be.

The fella doing art for Protonaut, and my primary partner in this venture, is Greg Wohlwend (who has a wicked website). He's great. He works tremendously fast and is wonderfully talented. He has a good head on his shoulders about how the industry operates and has a good handle on games themselves, and gives very valuable feedback on how things are going on the code end of things. If I could buy stock in G.W. futures, I would.

I think one of the best things about having a single partner like Greg is the mutual motivation. Like a climbing plant seeking sunshine, I'm just a dude in search of a relaxed, lazy lifestyle on the beach. When I code alone, I can often lose multiple weeks of development time to a newly released game. I can get distracted with watching Firefly again. If the sun shines a bit more brightly today I might just go down to said beach. Having Greg around keeps me motivated - not just out of guilt for letting him down, but also by genuinely keeping me excited about the project. When he produces a new piece of art, I can't wait to implement it!

There is, however, a fleck of dust within that diamond. When I am motivated; when I am actually getting things done, I have a very one track mind. I get an idea, I iterate the code towards the utlimate goal, and I end up having an agreeable chunk of software - something to be proud of. During this process I'm often observed to decline food (gasp!) and push away beer (the horror!), and hardly move from my chair for upwards of 12 hours. I'm not complaining here, I'm just saying - this is how I do my best work.

Sometimes those coding sessions can go on for weeks.

By having a partner, it's pretty much guaranteeing an interruption. Sure, sometimes the interruption is good - feedback on the current project, maybe some hints or shortcuts to make me finish faster - but sometimes it can be a bit more trying. While I'm excited to accept new game assets (be it code, art, sound), and I know the game will be better for it; I think many programmers will agree: Dropping a project halfway through to switch to a new task is like trying to change gears without a clutch.

As each additional project member is added to the mix, this can occur more and more frequently. I believe this is observed even at the highest levels of corporate culture, where daily status meetings can end up being your primary export. More people to pay attention to, with a deteriorating level of productivity.

It's at around this time I start remember the recent Cogs Postmortem I read. They pretty much say the same thing, but quantify it with a graph.

As much as the businessman in me wants to run my own studio; as much as I want to have a team and command them to fetch me my surfboard; I don't think I can be what I want to be... a Programmer... In a team with much more than 2 to 3 people.

And with a team of 1, I'd never get anything done.

I guess that makes me Indie!

Protonaut Build 29: Finally, a Challenge

I've found that in programming Protonaut, I haven't been particularly challenged. That's not to say that it isn't super interesting or fun, but it feels that I've been largely coasting instead of actually thinking.

I'm not talking about Math problems - I'm absolutely pants when it comes Math in the first place, so anything calculated is a smaller hurdle for me. Rather, I'm thinking more of the mental excercises -I haven't had to do any serious figuring on how to do something or even constructed simple algorithms.

Until today, that is.

I started off the day right today by not getting to bed until around 5AM. Then I had a series of ludicrous dreams, then I was woken up at 6AM by the lady next door asking "Is this yours?" and pointing to a dead cat in a box she had brought over (it wasn't mine, thank goodness).

After a robust effort at continuing-to-sleep-till-noon, I thought perhaps today was a day to do something different.

Forgetting to eat, I scanned my to-do list and tackled the most interesting sounding task: Copying all items connected to whatever you clicked on. For example, if you created a complex molecule in Protonaut's editor, duplicating the whole shibang, maintaining proportions, and moving them around the screen all at once.

This one is a bit more complex than it sounds, as I did a really good job of keeping my level objects... well, more of a theory than actual hard definitions. My level objects suggest that an item might be in one place, and if you did some hefty math and lookups you'd see that it was correct. Bonds are an excellent example; they have no X,Y coordinates or size definitions - they are merely the idea that a bridge may exist between two already existing elements. All the hard definitions I allow the physics engine to handle for me. It's this exact architecture that's made it really quite easy to write up this whole deal.

I ended up making my first Linked List in years (through lack of requirement, not choice), and designed some tree-traversal algorithms to find out exactly what was connected to each other, taking care not to duplicate entries.

Then doing up the math to keep the X,Y coordinates offset correctly as I move them all around the screen... Well, let's just say it was a fun several hours worth of code. I feel like I've just had a fresh code shower. Ho ho!

Conclusion: Very satisfying.

So here it is, Build 29. Coming up on the big three-oh! Recent noteable changes:

• Several sets of tutorial level revisions
• Lots of minor glitch fixes
• A dozen updates to player movement rates, gravity values, friction values, and scenario behaviours (eg: fixed the I'm-pressing-on-a-wall-and-can't-jump-high hard-to-reproduce glitch)
• A dozen updates to the level editor (see them all here), including molecule copying and whole-molecule moving.

How to make a Platformer Feel Right

One of the big draws to a platformer-style-game is the feel. A good, responsive control scheme with some nice animations can make the difference between sluggish boredom and excitement.

I've never really looked into the mechanics behind character movement before, and when confronted with the problem of making Protonaut feel nice, I had to do some research. As it happens, William and Sly was released that very day, and I took it a whirl.

William and Sly is an excellent game where you hop around in a tile-based world as a Fox named Sly. I highly recommend you give it a try! Sly controls very nicely. He is immediately responsive in his left/right motions, and jumping is a quick, rapid motion. On top of some fluid controls, Sly animates a sitting position while at rest, has a very nice run animation, and bounds in an animated arc when jumping.

One game that stood out for me as an excellent platformer was N Game (later remade as N+ for consoles). It was critically acclaimed for having excellent controls, so I revisited it to take a deeper analysis. You can play it here.

N Game was interesting to me. You play the role of a Ninja that simply has to collect some items and avoid the badguys. The left/right motion is a big sluggish - the player accelerates as he moves, but it feels OK. The jumping seems a bit unpredictable to me and I had a hard time navigating even the first level - but I'm sure it's just me not being used to it. It seems a lot of other people liked the game, and again - it was hailed for it's amazing controls.

What really stood out for me, though, were the animations. The player character had an animation for pretty much any situation he got himself into - sliding down a wall, various states of jumping, and even death. It really seemed to make up for it.

I had to take a look at a really crappy Flash game too, just to see what else was out there. Being a large fan of the Indiana Jones franchise, my eye was caught by an unlicensed ripoff named - well, indiana jones. I'm not sure if the loss of capitalization was intentional.

This game is definitely bottom-rung in terms of control. Just give it a quick run-through and jump off of a ledge and you'll see what I mean. It's almost as if you controls are mapped directly to the keyboard in a hideous 1:1 ratio - it's obvious there was not much thought put into this at all.

But the artistic team put a lot of polish onto this game, and there it is making money being front and center on the #1 platformer-oriented portion of the gaming portal. This kind of crap really gets on my nerves, because I believe the gameplay can (and should) stand on it's own two feet first, and have graphics applied later to taste. I said so just a few days ago. This game is the polar opposite - polish, lots and lots of polish, complete with unlicensed rips and cashing in on a brand I love - with no thought given to gameplay.

To help clear the taste out of my mouth I did a quick mental revisit to Super Mario Brothers (for a quick refresher, there's a badly done flash version - again, without licensing).

Mario had some fairly descent, polished graphics for it's time. The controls were crisp and responsive, and things flowed rather quickly. I'm sure I don't have to preach to the choir about this one.

I took all I had learned and compared it to Protonaut and where it was currently at (around Build 25 at the time). Protonaut was largely based on real physics. The player is average human density, average human height, and other game objects (like floors and platforms) were the density of concrete. Gravity was fixed to a steady 9.81 m/s^2, Earth norm. Each object interacted with one another with as-accurate-as-I-could-find coefficients of friction. Movement was handled by applying a steady force in a particular direction, capping off at a maximum speed. About the only unrealistic thing was how high you could jump, which seems to be a standard in any platformer ever made. An earlier form of the game wouldn't even let you change direction unless your feet were on the ground!

I figured real-life objects interacting in a real physics engine in a real-life environment would be a pretty good, fun experience, and would save me a lot of effort!

Nope.

Turns out people's natural rates of acceleration are... Well, boring. People can't stop running fast enough. People can't run fast enough. In short, people are sluggish, unresponsive creatures, and have no place in a fun platformer.

I ended up going through all my movement code. I increased the player's rate of acceleration, I made the at-rest-friction levels to be impossibly high to make him stop faster, I made his movement in the air more responsive, and made a whole bunch of number tweaks and if statements. (As an aside: The next time I make a platformer, I am not going to use a physics engine if I can avoid it! The amount of work that went into these tweaks was much higher than I wished, and I ended up breaking a few rules (resetting player velocity manually instead of applying a force, for example).)

I found the gameplay immediately improved and was a lot more fun. Playing a dorky, slow marshmallow of a man isn't as fun as a nimble ninja jumping from wall-to-wall. But something was still missing. It still felt like everything was moving in slow motion; nothing quite felt right.

I did another tour of the previously mentioned games and found out that none of them had the same problem. All 4 of the previously mentioned games felt "right" in a way Protonaut wasn't achieving. After some searching and feeling it out, I think I put my finger on it: Gravity.

9.81 m/s^2 is fine and dandy in our lives, but it feels a bit too slow and sluggish when you're talking about a world of superheros that can easily jump twice their height. With our incredibly poor acceleration rates and reaction times, a box could easily fall on our head and crush it. But the box doesn't fall particularly fast.

Cranking the gravity up to 13.5 m/s^2 made the game feel much more response and smooth feeling. I guess the whole idea behind platformers is to exaggerate everything; all forces should be somewhere around double of what they would be in real life. I'm still churning out new builds with new tweaks, but I'm finally homing in on what can be called "fun, invigorating" gameplay.

And for those that are wondering - yes, Protonaut's level editor allows you to define the gravity vector. I just altered the default setting and re-applied the gravity settings to the tutorial levels, and tuned the player controls for that environment... If you reset gravity back to 9.81, the player will jump higher than he did before.

Protonaut Build 27: Gameplay Tweaks

After showcasing build 25 I got a lot of good responses. People are getting excited about the game, and I got some important feedback on the tutorial.

Changes in build 26/27:

- The tutorial is now split into 8 distinct parts. This allows people to get the "rush of victory" pretty frequently early on, while splitting new ideas into easy-to-process chunks.

- The tutorials now have descriptive text that tell people how to play each stage.

- The Atomic Detonator now has a bit more control. Hold down shift to increase power, release to launch. It's sensitive - maximum power is reached in only half a second. But it feels nice, and allows you to easily get things nearby with a quick tap. The A.D. will auto-launch when maximum strength is hit.

- Atomic Detonator's maximum power is now 25% greater (can fling it quite far now if you want to).

- Increased player friction while at rest to a much higher amount. It's now harder to slide down things (if they are shallow enough of an angle to get your feet on the surface) and when you let go of the movement keys you stop nearly instantly. This helps make the controls feel more responsive.

- Decreased player friction while moving, again making the controls feel more responsive.

- Replaced most of the tutorial text again in Build 27

- Fixed a bug where Nitrogen wouldn't explode when it killed you.

- Swapped default controls to the arrow keys (you can switch it back to WASD from the options menu)

- Fixed the immediate wall-jump bug when standing next to a wall and jumping straight up, making you appear to jump 2x the height of normal.

- Also, wall-jumping now requires that you are travelling away from the wall you are currently touching (should have been like that from the start...).

- If you have a downward velocity while wall-jumping, the jump will now "stall you" in place thus giving you a chance to recover. This fixes the dreadful "I'm walljumping like a madman but still falling down into this chasm" situation.

- Made tutorial text disappear upon victory/failure.

I'm getting pretty excited. I'm feeling like I've hit the end of my prototyping and I'm moving into full-scale production.

But since my prototyping was polishing itself along the way, it's more like I'm late beta and about to go gold. Great feeling!

Mechanics more than Gimmicks

I've often thought that the point, or the core concepts, of Protonaut have been lost because there is no good demonstration level - and all the levels submitted are by Fantastic-Contraptioners. It keeps the game looking like something it's not, so I decided to rectify that today.

But first, maybe I should talk about game mechanics vs. gimmicks.

Game Mechanics are the fundamental cores of gameplay. Mario is a platformer, and he squishes enemies by stomping on them. His various suits (fire flower, raccoon, etc.) offer up different mechanics you can play with, and they fundamentally change the game.

Gimmicks are the things that sound cool on paper, that look awesome, or are "neat" - but don't actually contribute to the gameplay in any meaningful sense. I like broadly lumping "realistic graphics" into this category. Sure it might look cool, and it might even sell a few extra copies based on game-footage and screenshots. But does it actually affect gameplay? No.

The thing is, it's really very easy to think up good gimmicky things. Camera tricks, dazzling explosions, distorting the image based on explosion shockwaves.. The list can go on and on. These are the low-hanging fruits of the feature tree.

I sat back today and thought about all the ideas I've been having. They're all largely gimmicky. I wanted the game to have a bit more meat to it - a bit more fun. Let the game stand on it's own two feet before I start swiveling cameras around. I think maybe I was overthinking the problem before, and I think I've hit upon a simple solution that fundamentally changes the game.

Previous to Build 24, all the round elements (Hydrogen, Oxygen, and Nitrogen) were identical except for the graphics. Now, Hydrogen is lighter-than-air and has the capacity to lift things; Nitrogen is dangerously unstable and can kill the player. Oxygen remains inert and simply rolls around.

The catch is - you still have to "collect" (destroy?) all three of them. If you let the Hydrogen float away from you, the level can become impossible. Nitrogen is tricky, as you can only set it off with your little flingalbe sticks (rods of ice? TNT? atomic detonators?).

Carbon and Aluminum still remain, of course - Aluminum being very heavy and capable of killing the player by falling upon him (and remains indestructable in and of itself), and Carbon provides a more utilitarian role as a "wheel" (that can be destroyed).

Before now, the game was largely about grabbing items in the correct order to prevent the collapsing structure from burying you (or the target elements). Though this might have a neat puzzly aspect to it, it is much better executed with a simple clicking interface. Running around on the structure was largely a chore and not exactly fun.

Now the levels can have all sorts of dynamics - a Hydrogen isotope floating a chain of explosive Nitrogen towards the player, for example. Puzzles triggered by lifts and dangerous rolling elements to dodge. Stacks of Aluminum to anchor and weigh things down. Levers, pullies, platforming fun!

Now, this is a lot to add to the game. Even though the amount of work behind it was marginal, the impact it has is grand. Now, more than ever, I needed a level that was easy - quick to play through - had a low risk of death/restart - and demonstrated all the core concepts of the game. And thus was birthed the first incarnation of the tutorial.

In the level I demonstrate how each of the elements work. What needs collecting and what isn't collectible. I introduce movement, jumping, and walljumping. There is a few places where you need to use the throwing stick to grab Nitrogen. I slowly introduce the concepts of bonds, and give a small sampling of different effects and puzzles that bonds can produce. I even demonstrate some unique properties (ie: structural bonds go through terrain), and top it all off with a "boss fight" of sorts.

I think I was successful in demonstrating that this game can stand on it's own two feet on the basis of elements alone. Using bonds is completely optional and you can actually have a fun, puzzle-y time without using them, and just focusing on the platforming aspect of the game. Level designers should be focusing more on the "wall" item, and get used to what you can accomplish from that level. Use bonds as a method of enhancement, not a focus of design.

A few other folks have stumbled upon some unique designs that speak to the essence of the game - Ryan Madsen for example, and a few others. I can't link to them now, as these changes have essentially ruined their designs. I never claimed to be an expert level designer, though, and I hope my level can inspire others to create even better ones.

I am a very happy guy right now.