devlog « Tidepool News

Some code is central to everything, a kind of Grand Central Station through which all activity passes.  Nowadays such code is usually provided for you by third-party frameworks.  Since I’m essentially making a framework, I get to craft my own centerpiece, which I just named perform, which I discuss in today’s podcast.

Whenever you press a key or issue a command, it goes through perform. Each line of your scripts go through perform.  Whenever a player near you does something, it goes through perform, both yours and hers.   If there was one place in all of Tidepool’s twelve-thousand pages of code where a bug would wreak the most havoc, it would be the nine lines of perform.

Which is why I’m nervous, since yesterday I completely rewired things to allow for the new programming functionality.  Such major changes are best left for the beginning of milestones, since this gives time to let the ramifications reveal themselves.  We’re 30 days from the ISTE conference, but I’m still leary of such system-wide changes.  Time will tell.

Well, yesterday I really broke things.  Tidepool has several commands that operate on the player, such as forward, rotate, and so forth.  I wanted to generalize the system to use the same commands on any visible item in the game, so I could say “seymour.19 forward 20”, etc.

To do this, I needed to move a lot of well-tested functionality from the TpCameraGroup class (which controls what you’re looking at) to the TpItemNode class (which controls each visible item).  After an unholy slew of cut-and-pasting, I tried Tidepool and found that you can no longer move.  Even stranger, as you do try to WASD your way around, the player’s “lamp” (a light source that goes with you) does move, giving the impression of a ghostly friend walking without you.

A few attempts to fix this made things even worse.  I start today with the player looking straight up at the sky and no way to move.  Luckily, we use version control, so I can revert this mess if I really need to, though I’m hoping to find the bit I missed this morning.

Two weeks since the Alpha 2 launch and my website visits have simmered down to a handful a day.  We reached 255 new visitors, with only 9 signups to test the next version.  Feel free to signup now and reserve your username.

I’ve managed to write daily devlog posts, which seems to have helped on TIGSource, but nowhere else (ISTE, Reddit, Twitter, G+, Facebook).  I’m planning to add a few new communities, such as homeschoolers, but I’m beginning to think my posts are too abstract to generate any interest. I’ve started to use screenshots more.  Perhaps if I draw an animation of a cat playing a piano?

Today’s podcast talks about creating compelling content and improving the website. Here’s a quick scene:

Today’s podcast begins with a rundown of the four primary ways a software development schedule can slip:

  • real time – you’re not able to spend enough hours
  • poor focus – your brain just can’t latch on
  • tech troubles – third party nightmares or your own damn bugs
  • goldplating – you make something better than it needs to be

When a deadline is looming, these fears are my constant companions. Collectively they can turn a month into three pretty easily.  We try to manage this with daily status checking and course corrections, but even then the schedule’s pretty much a gamble.  Software is hard.

So how do I know that Milestone 3 will be done in the next nineteen days?   Honestly, I don’t.  It’s a reasoned estimate, one that the software gods are likely laughing about right now.   With more than thirty years of software project experience behind me, I can say with certainty that software schedules are uncertain.

Which is why we use tools like agile and timeboxing, but that’s another story.

Today I let myself dream a little, imagining what I would do if Tidepool attracted thousands of players.  Such “counting of chickens” has both practical and motivational value.  Planning for 25,000 users is daunting technical task in the short term, especially when you consider that popular Minecraft servers rarely (if ever) reach that limit.

I do have a few things in my favor. First, I’ve been designing for a large multiplayer environment from the start, unlike Minecraft.  Second, I’m using the same foundational tech that large companies like Bank of America use (the Java EE 6 stack).  Third, I’m an “application performance monitoring” (APM) consultant, having worked with companies like Marriott, Lowes, and (this week) Saks Fifth Avenue to help keep their LARGE systems running smoothly.

All things in my favor, but Tidepool is a different beast than these lean (and well funded) corporate systems.  It takes significant time and effort to test realistic load, especially for a system with graphics-intensive clients.  Firing up LoadRunner to simulate web users is one thing.  Imagining what’ll happen when 500 players decide to meet in-game for some community event is another.

Given this, I’ve been rethinking my “open the floodgates” date a bit.  Perhaps better to have a closed beta for a while.

In today’s podcast, I talk through a current bug involving 3D coordinate transformations.  After some recent refactoring, the player no longer moves in the direction they are facing.  The WASD keys move along the X and Z axes only, even though you can look around correctly.

Talking about it with you, the imagined audience, is an example of something called rubber duck debugging, where you try to explain a problem in simple terms to a non-technical stand-in.  The act of explaining it often clarifies the problem, allowing you to fix the bug.  In truth, the rubber duck is often more helpful than most managers.

Last night I was at dinner with my consulting client until 10pm.  Between the time this bug has taken, and the hours I’ve lost down here in Jackson, I’m beginning to worry that I won’t be able to make up the lost time.  I’m not at the “change the plan” stage yet, but I’m fast approaching it.

In 24 days, I’ll be attending the largest annual gathering of education tech enthusiasts, the ISTE Conference in Philadelphia.  While I won’t be presenting, I do hope to speak with as many teachers as I can.  This morning I debated what printed materials to hand out.

I’m a fan of, primarily for their ability to print a different image, front and back, on every business card or postcard you print.  I’ve been around the advertising world for literally my entire life.  Such flexibility (and pricing) is pretty much unheard of until recently.

I plan to print a variety of in-game sketches on the front and signup details (including unique codenames) on the back. Right now I’m debating between their square cards (left), mini cards (center), and postcards (right). The postcards would be best to leave on a table for people to take, while the others would be great to handout.  At these prices, I might even do both.

Now to convince my alpha team to spend the next few weeks drawing sketches.

Last time my wife used the Tidepool website, she was overwhelmed.  “Where do I click?  There are two many choices.”   Over time, the site has grown in complexity.  With fourteen choices on the side navs, it was overdue for some serious pruning.

This morning I split the site in two, with half pertaining to the actual game and the other half to project nuts and bolts.  Now you have to click “Project” to see things like “Roadmap”, “Biz Plan”, and “Tracker”.

While this helps, I’m still feeling fairly “meh” overall.  I designed this to be an internal project site, so didn’t spend much wow time on it.  I’d love to add more images and color, with some nifty scrolling sections as is so common these days, but I just don’t have the time to do it justice.

Besides, I don’t want it to be too slick.  Tidepool is a hand-drawn world.  The website should showcase this aesthetic.

The hardest thing to do is write tiny bits of texts.  Today I debated the new Tidepool talking points which, when written, will go on the back of the postcard and will replace the “About” page. I’ve talked about each point a hundred different ways over the years.  I’ve written a full business plan and made a project trailer.

So once more, in rough form, here goes … what makes Tidepool different?

  • world – explore and create a shared hand-drawn 3D world
  • stories – make interactive stories and games for others to play
  • coding – program your creations to watch for conditions and respond to events
  • courseware – build supplemental educational materials that teach concepts deeply
  • fundraising – players can purchase crystals from vetted schools and NGOs
  • agents – chat with cognitive agents, allowing a conversational approach to coding

A good start, but more is needed before it’s brochure quality.  I’ve also got to match my icons to the concepts:


Today I fly to Phoenix and I woke up too damned early.  Stressing over all of it, today’s talk is a jumbled mess of pre-conference prep and daunted expectations.

My reach has always exceeded my grasp, so why should now be any different?   The blessing of such ambition is consistently exceeding the norm.  The curse is stress and broken promises.  “In the long run men only hit what they aim at. Therefore, though they should fail immediately, they had better aim at something high.”

So what’s to do?  Fifteen features, 9 improvements, 22 bugs, conference handouts, finish the trailer, make the Kickstarter page, publicize to new audiences, and keep these daily devlog posts going.  All the while spending working hours consulting for the State of Arizona and all my “free time” doing billable hours on my other project.

Twenty-one days. Criminy.  Will I finish all of it?  Of course not.

Will I try?   That’s the plan.