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. :)
1 Comment

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!
2 Comments

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!
4 Comments

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
0 Comments

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!
0 Comments

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

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

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

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

FlexSDK 3.3 How To Make a Flash PreLoader in AS3

EDIT: The free code-IDE FlashDevelop does a really good job of doing all these steps for you! I recommend everyone switch to it. :)

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