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:
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.
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.
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.
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.
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!
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.
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.
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.
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.