Well folks, hell did indeed freeze over last weekend. After six months of financial limbo, I was finally able to fix Tidepool’s remaining bugs and ship Alpha 2 to my 100 alpha testers.
You can see my quick tutorials here.
To hear me ramble about it for 20 minutes, listen to today’s podcast episode.
My current schedule has me finishing this current milestone by early June. As for Colossal Cave, I decided to hold off on the core logic so that I can use Tidepool’s rule system to implement Crowther&Wood’s action mapping.
Yesterday was all about luring people on my alpha list to actually respond. Turns out my mailing list announcement on Saturday ended up in most people’s spam (or worse), so I took the time to individually address all 100 people, asking them to click a link to let me know they’re out there. Yes, sounds desperate, I know. And I kinda was.
I made a landing page that summarized how to download and play the new Tidepool release once I realized that most people didn’t get the first email. The good news is that my response rate greatly increased … almost half have at least clicked through the link and seen the landing page. Still very few downloads and NO players except me, my wife, and daughter. Yes, I know, it’s been less than a day for most of them. I’m impatient, okay?
In other news, today’s podcast discusses thorny addressability issues in-game, such as what does it mean when you type “seymour forward 100” when you’ve got two agents named seymour by different players AND a player named seymour.
In today’s podcast, I broke down the eight core concepts in programming and came up with examples for how to implement them in Tidepool.
Specifically: variables, expressions, statements, blocks, conditionals, loops, events, rules.
Tidepool has a few constraints that make designing this new language more difficult than the norm. For one, it has to be easily understandable by young children (ages 7 and up), which means it cannot rely on strict syntax and a lot of punctuation.
Another constraint is that it has to be easily typed as a chat message … line by line … so, no colored blocks and tiles and no text editor formatting. Related to this is that it must be able to be SPOKEN easily. We want voice input to remain an option, particular when people use Tidepool on small devices.
Anyway, I came up with a small test bed of statements that I’ll start implementing today:
* seymour, forward 10
* seymour, when anyone is near, forward 10
* seymour, begin, forward 10, turn 90, forward 10, turn 90, forward 10, turn 90, end
* seymour, repeat forward 10
Syntax will very likely change many times before things settle, but this is a good enough start for now.
From interrupt lookup tables to event processing queues, code is often kicked off in more ways than RUN. Today’s podcast talks about Tidepool events and rules, which allow you to specify all manner of custom actions whenever certain conditions occur.
A few examples: “when someone says meep, jump in the air and say meep too”; “When someone comes near, run away”; “When someone clicks on you, change your animation to “Frightened Fox”.
Tidepool has a message dispatcher that routes all changes between players through the Storymill server. Whenever a change arrives, agents in the same story need to check their rules to see if one them needs to be fired. For example, when player @teefal presses the W key to move forward, agent #happyFox needs to check how far it is from @teefal. If @teefal is “near” (perhaps 2 meters away), then #happyFox fires off the “run away” rule.
One of the reasons I built my own game engine is so I could customize this nitty-gritty stuff, allowing me to make the programming language intrinsic to the game environment. I’ve got very specific ideas on how I want to teach programming to children. Having my own engine lets me get creative and do non-standard things.
Programming in Tidepool has three key differences with other systems. First, the overall model is one of conversational language acquisition. You chat with your agents to learn what they know and to teach them new tricks. Second, all coding is “talkable,” meaning you can dictate it through a voice recognition interface. Last, coding is very flexible as there are often many different ways to say the same thing. Tidepool will use Storybot, our cognitive agent, to help determine what players are trying to say using “do you mean?” clarifications based upon the evolving context.
I discuss all this in today’s podcast, along with my first testbed of sentence types:
* seymour forward 10
* seymour turn 90
* seymour sound meep
* seymour begin, forward 15, turn 120, forward 15, turn 120, forward 15, end
* seymour when square, begin, forward 10, turn 90, forward 10, turn 90, forward 10, turn 90, forward 10, end
* seymour when anyone is near, forward 10
* seymour when mosey, forward 25
* seymour square
* seymour mosey
As you can see with the “square” example, I’m using the “when” clause to define what would be a method or function in another system. “When” statements define rules, which are the quintessential code block in Tidepool. Anything more than a simple command or block is a rule.
Regular expressions are likely the most powerful, most underrated, tool in all of programming, or so I preach in today’s podcast. I also touch on Tidepool’s parser, which allows players to type commands in a variety of formats, allowing something closer to natural language than your typical syntax-laden command line.
Of particular interest today is messaging scopes. When you type a line into Tidepool’s message bar, where does it go? Does a player or agent on the other side of the Tidepool world see it? How about those outside your current story? At this point, Tidepool will have the following scopes:
- world – every player/agent will see your message
- neighborhood – only parcels where the sender is a “helper” will see it
- parcel – only the sender’s parcel will see it (and all the stories in that parcel)
- story – only the sender’s current story will see it (and all its scenes)
- scene – only the sender’s current scene will see it
By default, only players and agents in the sender’s current scene will see messages. Keep in mind, when I say ‘message’, I don’t just mean chat messages. Every action and change in Tidepool is done by sending messages, so “seymour forward 10” will be seen by other agents and players in seymour’s current scene.
I haven’t figured out the syntax for specifying other scopes yet. More examples are needed.
Once you’ve taught a Tidepool agent some new rules, how do you change them? The answer is the director, a new user interface element that I discuss in today’s podcast. The director is much like a programming IDE (integrated development environment) in that it lets you review and edit your code, then step through it like a debugger. It’s your window inside your agents, letting you browse and extend their capabilities.
Another UI element is the timeline, which lets you hang rules on timed events, so you can say things like “angry bear, when player time is 20 seconds, do a scary dance.” This lets you schedule events relative to a player’s entry into your story or scene. The timeline gives you an overview of what’s about to happen in a story as well as what has already happened, so you can use it to investigate past activity.
The third programming tool is the roster, which will soon be extended to let you control agents directly, playing and stopping them, setting properties, and so forth. Think of the roster as a kind of buddy list for the agents and players in your story. Add in the message bar and lexicon and you’ve got the full programming interface for Tidepool, along with the goals for the current milestone, and June.
A big part of developing & marketing a software product is management, or talk-talk-talking through your goals, plans, and pesky side issues. Given a choice, I’d gladly ignore such things and happily wallow in the code all day, but given my background and skills, I’m usually the one brainstorming schedule and marketing plans, as I do in today’s podcast.
The plan is to release the next version, Alpha 3, the programming version, on June 20th. On that day, we also launch our Kickstarter campaign to raise funds for our courseware authors. I’m planning to pay eight people to create 24 courseware units. Each will get paid $1000 a unit for 40 hours work (two weeks).
Kickstarter donors who give $50 or more get to use Tidepool right away. All other donors wait till we finish our Kickstarter and release Alpha 4, the courseware version, on July 19th. By then, we should have eight units.
A month later, we launch the Tidepool beta on August 13th. On that day, we open up the floodgates and let everyone play. We focus our publicity efforts in August on teachers and schools, who are just beginning their fall prep.
* $50 gets you in during Alpha 3 (June 20)
* $25 gets you in during Alpha 4 (Jul 19)
* everyone gets in during the beta (Aug 13).
Sounds like a plan, and a lot of work!
After a year plus working on my own, it’s both wonderful and horrible to have new people playing Tidepool. As hard as I try to find and fix my own bugs, I’m necessarily, categorically, awful at the task. Like racehorses trained to go straight around a circle, developers have well-established blinders with their own code. We create our own ruts, repeating the same sequence of steps sometimes hundreds of times until we can no longer see another way around.
One funny, and inexplicable, example happened last night. I was playing Tidepool with my friend Jon, typing to him, making jokes. “Wait, what just happened?” A little later, “There it is again.” Turns out whenever you type the closed parenthesis, it sends you “home”, just as if you clicked the home button. How on earth did I go so long without finding this bug? Well, it turns out I didn’t make smiley faces with myself when typing “this is a test” and “right back at ya” over and over.
Also in today’s podcast, I brainstorm the new director box, a fresh and full-of-possibility UI design … my favorite thing to make. Instead of talking about it, here’s a scan from my design book. Nothing makes me happier than solving puzzles like this.
I am of course imperfect and emotional. While academia and business pretend they’re immune, working solo on a two year project, I have no such luxury. From the start, I’ve maintained that the biggest risk, the most likely reason for failure, is not being emotionally strong enough to finish. While I left this risk off the business plan for obvious reasons, it’s been foremost in my mind all along. I guess I should give myself credit for putting in a full year so far.
Today’s podcast is a good example of the periodic “talking to” I give myself when I’m feeling down. While most would think it a mopefest, I suspect others can relate. Much is made in our culture of the struggling writer or painter, working alone in frustration. Programming is no different. Whether part of a team or alone, we each wrestle with our doubts. Being the sole designer, programmer, marketer, and tester is its own kind of gauntlet.
The struggle isn’t technical. It’s human.