next »

[IBwWG]

A quick intro (see also my obligatory intro), but go into more depth about the game.

This will be my debut commercial game.  It is based on an already published kids' book, but meant to have enough substance and difficulty variation to be challenging/fun for adults.

The game intentionally followed the book pretty closely, which was limiting, but in a handy way (seemed to fit an article I read that talked about creativity being easier to come by, when one has limits.)  What this meant was, I created a minigame for pretty much anything that the two main characters did in the original story--also some friends they make along the way, but mainly these two.

The structure was made so that, at each point in the book, you get to choose between two minigames: one as Mathilda, or one as Willy.  Then, since the book has a return journey, you're made to play your second choice on the way home.  I made a wonky exception to this at one point, where there are four characters/minigames to choose from, but two of the games are actually the same with different graphics, so it's like 3 minigames and you have to beat two of them to finish the overall game.  Then at the end of the game there's a stickerbook activity.

For replay value, each minigame either has:

a) pre-set difficulties: easy peasy, normal, tricky, or super tricky

or

b) Play What You Can: you simply play until you don't want to anymore

With either type, you earn 0-4 "books" (the in-game level-ups currency) depending on how you fared.  With pre-set difficulties there's a goal to meet, then you earn the number of books corresponding to the difficulty.  With PWYC, a score is kept, and there's a map of score ranges to books earned.

Then, with these books, you can level up various stats for Willy and Mathilda and also two other characters, although those only apply to a single minigame each.

I managed to get it so that there are about as many stat-ups as there are books to earn, but most of them still need implementing: half of them are unique and even the non-unique ones have a bit of a touchy game balancing aspect to their implementation, naturally.

So, what are the games?

   public static var games:Array<String> = [
      "Painting Your Dreams", // stickerbook
      "Under the Spell of Shiny Shimmering Sunbeam Sparkles", // arithmetic/pathfinding
      "Dolphin Patterns", // x,y-location-based pattern recognition
      "Collect Fairy Dust", // side-scroller where you are trying to hit every obstacle
      "Catch Up", // similar side-scroller, but where you are trying to avoid every obstacle
      "Aikido as Mathilda", // essentially a very-fast-reaction-time multiple choice quiz covered in gobs of eye candy
      "Aikido as Willy", // same as above, but different eye candy
      "Acrobatics as Princess Balapoo", // trampoline simulator, where you also must throw rings up in the air and catch them
      "Acrobatics as the Catfish Fairy", // trampoline simulator, where you also are trying to jump through hoops, and somersault
      "The Lost Piece of Atlantis", // slider puzzle, with planned rotations
      "Treasure Hunting", // hidden object genre
   ];

What needs doing?  A little of everything!  What am I doing next?  Depends on my mood.  

Tools:

The GIMP
Audacity
CoaTools
Blender
HaxeFlixel
HaxeDevelop/FlashDevelop
Haxe

Questions welcome.    Screenshots will be coming soon.

[IBwWG]

To give you an idea of how things have evolved, some prototype and test screenshots from earlier in the development.  Screenshots of how it is now will come...a bit later

The game is HD from the start, BTW.  Although, I may do a lower-res version so that it fits easier / plays better on phones and netbooks, later.  Each of these links to a full image.

Here was Catch Up, when the mechanic was "press any key for a forward/upward boost"...flixel particle emitters in action:



Here was Dolphin Patterns, when I was still figuring out what I could do with the waves:



This is the initial mockup for the main map, which is mostly what I went with in the end.  The sidebar changed style a bunch, though.



Lastly, these are some of my early experiments with Spriter, before I switched to CoaTools, and before Michael redrew the body parts separately for me so I could animate them properly:

First:



Then a week later, with the redrawn parts, still in Spriter:

[IBwWG]

I forgot I had a few more screenshots hanging around.  These are how the Painting Your Dreams activity looks currently.

The first one shows what the Masher Robot (mentioned in my haxe development blog) produced:



And these two are ones made by my daughter:




BTW, all three of them show FlxScrollableArea, a tiny part of the game that I open-sourced, in action...a real reinventing the wheel, because I guess that's what you sometimes do when it comes to common UI widgets and video games, if you want to go with something folks are familiar with.

[IBwWG]

For some comparison, here is the current Catch Up game:



It features what may be an innovative input mechanic (see instructions at the top of the screenshot).  At least, I came up with it and I hadn't seen it anywhere else.  What it translates to is, you can more easily button-mash by drumming your fingers across any keys you like, e.g. ASDFASDFASDF -- the faster you drum, the more he swims up.  To swim down you just hold any key.  For me, this made an interesting way of controlling the character, which I thought might be easier to translate directly to phones, but that remains to be seen.

The next shot features (in the same minigame) a general overlay I created, which pauses the game to allow you to edit Talkers (by putting their head in the right spot, for the tail of the speech bubble to point to) and their speeches.  Some of the game's cutscenes are integrated this way, using the already-on-screen characters.

I was thinking of releasing it as a separate library, but there might be a more generic scene editor coming to HaxeFlixel soon which would sort of make this unnecessary.



Finally, here's the current level-up screen, showing one tooltip.  I'm about to rework it a bit, because currently the entire tooltip is read aloud by the announcer voice (me...this was a lot of fun to record except when I had a cold and it was almost the deadline!) and it gets a bit annoying.



Instead, I'm going to make it so you click a particular character + attribute combination in the grid, and a separate UI pops up, with the read-aloud of each part being optional, and which minigames it affects being more visual with icons and such instead of just text.

[IBwWG]

And, although this one has a bit of a problem since their wrists don't line up at the beginning of the animation as they should, it gives you an idea of why maybe it's a little bit crazy of me to be doing 2d cut-out animation for Aikido moves. 

[IBwWG]

I think today I finally have my todo list a bit organized.  The thing is, it keeps growing (especially when Mathilda plays, because she's a great beta tester, hopping from game to game and trying on all difficulties just to see the differences!)  From this I think I can deduce that I am entering the "20" part of the 80/20 window soon.

[IBwWG]

So this week I need to focus on some other things, and actually this month there will not be much development while I work on another, non-game project.  But I did manage to fix a few things, like the announcer sometimes not announcing things and the game then getting stuck because it was waiting for a callback that never happened.  June we should be back in full swing again.    Meanwhile I threw a few screenshots on twitter if you're interested, under the hashtag #mathildagame.

[IBwWG]

This week, I made a mistake: I forgot to heed the advice that the only way to make sure you are making a difference when trying to optimize something, is to measure.

I knew that one minigame (a side scroller) had at least two memory leaks.  One, the Mash Robot had found for me, where memory would slowly leak, and when I found it it was when my camera's X value was over 10 million pixels.

The other showed itself within a minute and a half of mash robot testing, taking up 1.6 GB and crashing the game.

I thought, well, maybe a better design in the first place would have been to not let the X value grow indefinitely, but jump everything back every couple screens.

Somehow (surprise!) this introduced some new bugs.  And also didn't necessarily solve the memory issue.  But it's hard to tell...because I didn't measure (at least in an isolated test case.)

[IBwWG]

Some screenshots of the current state of some of the minigames:

UtSSSSS, the initial shimmer-in showing a combination of art from the book, a bit of custom stuff I did in Inkscape, and a bit of stuff rendered by the game engine for extra shimmery glory:



The Lost Piece, a slider puzzle whose algorithm I need to touch up a bit to make the difficulty more consistent:



Treasure Hunting, which looks a bit hilarious IMO but is still fun to play:



And finally for Screenshot Saturday, Princess Balapoo juggling some rings...after 14 screenshots this was the best one I could get...it's already a bit of a juggle just playing the game, naturally

[IBwWG]

And that will be it for the next few weeks, I think.  Get ready for a flurry of devlog-age in June, hopefully

[IBwWG]

OK, I'm back!

I am *SO* glad our narrator, Michael, got his audio cable fixed.  I could not figure out how, with a better mic than mine, there was so much noise in the recording.

Listen to this!  http://ibwwg.com/early/fixed-cable.wav

[IBwWG]

In this phase of the game's development, I'll be switching gears a bit, away from my normal intellectual curiosity and perfectionism, towards more creative and improvised solutions.  Sometimes.

Just before I left, I noticed a memory leak on the side-scroller games, if I left them running long enough with my masher robot.  Instead of the Right Thing To Do, measuring before the change, I guessed that maybe having X coordinates in the millions was too much for the outer engine or video card or something, and rewrote the side-scroller engine to Not Do That.  Instead every 4 screens or so it would take the X values of all sprites and backgrounds and everything, and dial them back 4 screens.

It looks fine as it's scrolling--no background seams or jumps or anything.  Did it solve the memory leak?  Not sure, have to still test.  Did it introduce new quirky bugs?  Yes, and this is the trouble.  Now whenever the dial-back occurs, a few random sprites--sometimes, but not always--leave and new ones take their place in a different random vertical location.

But I don't want to revert the change, because I fixed a bunch of other things while I was at it.  I guess I'm ahead, overall, then.

I'd post some screenshots, but this is another bug I'm seeing just now: when I take a screenshot, it momentarily lags the game, but for whatever unintuitive reason, the screenshot is of the moment after the lag.  When my random keypress to take the screenshot has affected what I wanted to screenshot (because in this game any button is usable...bit of a quirky UI but it allows for some fun things.)  Maybe I'll just exclude the function keys or something.

[IBwWG]

Today's log, I was gearing up for the next beta when I could today, in between babysitting and whatnot.  I got the rest of Michael's new recordings in there, and normalized all the audio (thanks, Normalize, you rock!)  Then I looked for any showstoppers, and found a couple (missing graphics that used to be there...hmm...this is why it would have made more sense to finish all the game's shared infrastructure first, but oh well.  Didn't know what the requirements would be until I made the games.  Chicken and egg...)

One roadblock I had managed to put in front of players since the last beta was the infrastructure for help screens, because some games needed a bit more explanation than others--this is a bit of a challenge given that the minigames are of quite a range of natures and UI mechanics.  Currently each minigame has instructions announced in my annoying announcer voice at the beginning.  The next idea was to have a pause/help screen with either screenshots or animations on how to play, and I wasn't sure how those would look, exactly.  (The pause/help screen also served as a natural "are you sure?" buffer for exiting the minigame--the back button takes an extra click to get to this way, and the extra click is in the opposite corner.)

I think I have a good idea now, but still have to implement it: Each minigame can have a series of help blocks.  A help block is made up of a piece of a screenshot, a control (key, mouse, tap), and a description.  If the blocks overflow the screen I can use FlxScrollableArea to have scrollbars.  The screenshots can be swapped out / updated easier this way; the controls can have remappability at some point; the descriptions can be read aloud by the announcer on mouseover rather than in a giant overwhelming speech.  It's a bit more infrastructure than a static screenshot, but I think the flexibility is worth it.

[IBwWG]

Lots of internal management today, will share about that later.  For now one item: I moved the more developer-oriented blog from blogger.com over to the HaxeFlixel forums, so if you're interested in more technical aspects, you can find it at http://forum.haxeflixel.com/topic/60/willy-and-mathilda-s-houseboat-adventure-game going forward.

I managed to get the help system more or less how I had imagined, and now I'm just taking myriad screenshots, to then use for the help.  They're not done yet, and I'm off to bed, but I'm sure there will be plenty of fuel for Screenshot Saturday tomorrow. 

[IBwWG]

As part of finishing the basic help, I'm done the first round of screenshots for that.  Here's a montage (thank you, ImageMagick--so much quicker and easier than online photo montage offerings for what I wanted to do!) showing the current state of each of the minigames (some have more than others, depending on what I wanted to put in the help):

[IBwWG]

I have the help how I want it, now, and the bugs are worked out, and the visual content is in.

Time for the announcer voice!  To properly collect all the texts that need to be read, I should do a full playthrough, and mouse over every piece of help text while I'm at it.  (It's not quite a matter of just reading from the help XML file.  That would cover most of it, but there are several parts where I re-use text by breaking it up--for example, where a number is said out loud, and that could be in a variable.)

A quick playthrough is a good idea anyway, just to make sure nothing's completely broken before it goes out for wider testing.

But I need a break at this point.  Perhaps Beta 6 will not come out today after all.  We'll see.

[IBwWG]

A playthrough is always a good idea!  Found a few new bugs that probably shouldn't go out.  It's too bad, because weekends I imagine are easier for testers to find time to test.  Hmm...ever a question of trade-offs...

[IBwWG]

I forgot to log about something before that may be of interest.  You can see in the very early shot of Catch Up in this thread that Willy was always level there.  In a later shot, you can see him tilting--a mechanic that in some ways resembles the old SOPWITH.EXE (remember that?  no?  I'm not sure how I do, either), except that a) you can't loop-dee-loop, and b) if you hit the ground in SOPWITH, you're dead.

These two differences made for something I had to figure out, if I wanted to keep the tilting: what happens when you hit the top or bottom edge?  Before the tilting, I had the character flip upside-down, which was kinda fun, but I found it harder to vary the difficulty with the mechanic that I was using then.

Unfortunately, I also found that figuring out an intersection with a rotated non-square graphic isn't as efficient as I had hoped.  It's quite strange, because I use pixel perfect collision checking already to check for the character colliding with obstacles.  As soon as I tried to make it with a top/bottom edge barrier (even a tiny line that followed the character around, 1px tall and less than the width of the screen), colliding with it would grind things to a halt, and I couldn't figure out why.  It's possible I could if I visited it again now, but since then I've taken it in a different direction.

Anyway, recently we went from a crude-looking mechanic of "if you get near the edge, you level off" except that "near" when you're on an angle and when you're level are about 50px different, so it looked and felt pretty mediocre.  With an only slightly more sophisticated mechanic, it now looks and feels much more intuitive: when you get to the edge, your dolphin noses along it at an angle, sort of sticking you vertically there until you actively swim in the opposite direction.  All I needed to do was tilt the graphics a bit, measure the difference, and add a "sticky" Bool.  Not too kludgy for how it turned out!

[IBwWG]

[IBwWG]

So I've been working on a bit of prioritization, and came across a few interesting todo items.

Currently, the two Aikido and the two acrobatics games are "Play What You Can", without a difficulty level or specific goal.  You play as long as you want, and then the amount of books you earned for the meta-game depends on how many points you got in-game.

Although the "difficulty level" model used on the rest of the minigames has some advantages, I was wondering if PWYC has a nicer feel to it for the player and should maybe be used for more of the games...pretty much wherever it could fit.

The Lost Piece of Atlantis is a great example of one where it doesn't fit.  You have a puzzle of a set size, and that size depends on the difficulty.  Pretty straightforward dynamic.

But, many of the games are not like that.  Treasure Hunting, for example, you could play indefinitely.

The two swimming games, Collect Fairy Dust and Catch Up, have a "good stress" feel to them currently, but maybe PWYC would be even better.  Currently  you have a certain number of obstacles (based on the difficulty level) to either high five (in Collect Fairy Dust) or avoid (in Catch Up).  As you high five or avoid each one, a counter is counting down, and after 10, every number is verbalized, so you really get the New Year's / rocket ship / etc. countdown feel to it.  In Catch Up, there's a big animation cutscene built into the ending of the minigame.  Also, the top speed and obstacle spacing depend on the difficulty.

But all that could still fit with PWYC.  In fact, the top speed and obstacle spacing could gradually increase with each obstacle, which adds the "good stress" exactly until the player's limit, rather than potentially past it if they picked too high a difficulty; meanwhile higher difficulties than the current highest become possible for very skilled players.  The cutscene in CU can still work--as soon as the player hits Pause and then Quit Minigame, the cutscene would play before quitting (unless they quit right at the beginning without getting any points, or perhaps without reaching a certain minimum.)

What do you think?