June « 2015 « Tidepool News

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:

             

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.

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 moo.com, 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.

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.

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.

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.