next »

[JobLeonard]

from my years doing edtech with OLPC and Squeakland

That's quite the resumé

[teefal]

I work for myself, but I still have a boss. That which governs my days is neither human nor corporate. It exists as bits on a hard drive in northern Virginia, on a server named Vesta, in a program called JIRA. My boss is The Board...



Called a kanban board for a practice in Japan, my JIRA board (http://board.playtidepool.com) shows the state of my mind, with past accomplishments on the right, current quandaries in the middle, and future headaches on the left.

Above is a mostly green line that shows the milestone at a glance. Green is done, yellow is now, red is what's left. The red may seem bigger than the scheduled nine days might allow, but that's by design. I always add "nice to haves" in case there's time left over, which there never is.

Anyway, enough chatter, the board beckons.

[teefal]

Without question, I've spent too much time on Tidepool Adventure, my game-within-a-game tribute to the 1977 classic. Were I my own objective project manager, I'd have said long ago, "Move on."  Between parsing the original Fortran data file and adding features to get gameplay to work, Adventure's been a project all its own, one likely a distraction at best.

So why have I stuck with it?  What value does Adventure bring to Tidepool to justify this extended detour?



The best reason for Adventure is that it's a non-trivial development example for all of Tidepool. It proves what can be done, using someone else's game design, which forces me to say, "Ah I didn't think of that, I need to add this and this."  Adventure's been part of the plan from the start precisely because I knew it would guide the design of Tidepool in ways I couldn't anticipate early on.

The next reason for Adventure is that it's a great template for players to modify and extend. Colossal Cave has a long history of new versions, starting with the Don Woods one. My goal is to encourage players to make changes over time. Adventure (and MUDs) lend themselves to spontaneous extensions.

The last reason is to honor this ancestor of all story-based games. Colossal Cave Adventure was a big part of my early experience with computers. I'm sure it's influenced my software designs over the years, even my general thinking. Exploring a huge state-machine like this is a true cognitive playground.

All good reasons, but now I want out of the cave. Perhaps today will be the day.

[JobLeonard]

May you not break your neck today

[teefal]

Went to the doctor again for my foot. The limping was getting out of hand and driving was difficult.

Got more steroids, so I'm be doing cartwheels in no time

[teefal]

The two biggest parts of a software design are the architecture and the object model. The architecture governs how pieces interact and communicate. The object model details the pieces themselves, the data buckets, the nouns we use as we talk about a business.

Tidepool’s object model currently has 19 entities (only 12 detailed below), each of which has its own database table and DAO (data access object). For example, “rule” entities can be accessed through the SbRuleStore DAO, which works with the SbRule table in the MySQL database.



Many programs access the database directly, which is perfectly fine, but it limits your options. By adding a DAO abstraction layer between your code and the database, you can simplify things over time or do wacky redirection stuff like I’m doing.

The Tidepool DAO connects to two different databases: the local Derby database and the remote server database. When you save data, it first saves it locally, then queues an update to the server. When you search data, it looks only at the local database, which is much faster. The beauty of a DAO is the rest of the code doesn’t need to know this. With a flick of a switch, I can work local-only (when you’re disconnected from the Internet) or directly with the server.

Technically this DAO approach is part of the architecture. It enables the object model, which consists of the entities, their fields, and how they connect to each other, as detailed in the chart. The model is merely an abstraction, which I could implement with many different architectures.

For the curious, I’m using JPA (Java Persistence API) to do object-relational mapping both locally and on the server. All queries exist as methods in the DAO, so these details are hidden. The communication between client and server can easily switch between Remote EJB and JAX-RS. I implemented both to see which I liked better. Currently Remote EJB is winning, but when we port to tablets, we’ll have to use JAX-RS.

[oahda]

That's clever! Our educational game at work is online too but I'm afraid it simply gives up and logs the user out if the server or connection goes down, which may or may not be a problem...

[MaxTexeira]

Wow, your idea is huge! are you working alone? i like the progress a lot.

Keep the good work :D

[teefal]

Thanks Max, I am working alone, except for playtesters and advisors.

Prinsessa, one of the design goals is for Tidepool to work in occasionally connected places like Haiti.

[oahda]

Is there some kind of LAN solution as well then or is it solo mode when it goes offline?

[teefal]

Currently no local server. I've debated about whether to allow local servers or not. There's no real reason not to other than my fear of a fragmented player base.

Storymill (the server) can be run on pretty much any machine by unzipping it and running it.  It's pretty lean, especially if it uses Derby locally (not MySQL).

I might get around the fragmentation problem by requiring an occasional sync with the central server.

To enable this, I just have to write the Storymill-to-Storymill sync code, which should be pretty easy given what I've already got.

I could also add server-to-server messaging, so you could change something locally, have it propagate to your local server, and then propagate to the central server.

Or, you know, heh .. yeah. All right, I'll say it.  Peer to peer.  Servers and clients both.  Ah, wait, I'm just one person.  Nevermind.  (Testing would be a bear.)

As for client-to-client LAN, the tricky part is what happens when you finally sync.  I might try it but again, testing is key.

[JobLeonard]

Prinsessa, one of the design goals is for Tidepool to work in occasionally connected places like Haiti.

Funny, I'm investigating a much simpler version of this problem at my work, except I'm working on a web-based Single Page Application and will likely use Mozilla's localForage library to store data offline.

Also, in my case the situation is easier: the data is read-only from the server, and we're just trying to have a better cache experience so that we don't have to redownload large amounts of data every time.

[teefal]

You know, it just occurred to me that all this sync stuff may be a lot easier than I originally thought.

Since I first did the architecture, a major new piece has been implemented ... automatic version control.

Every change you make in the game goes into your private branch.  Shared changes need to be pushed to the trunk, either by the story owner or you, if you're marked as a helper.

This actually makes disconnected use a lot easier if you prevent pushing when disconnected.  I need to think more about this.

[JobLeonard]

If you manage to make distributed automatic version control kid friendly, you've accomplished something amazing 

[a-k-]

I like the recent shift towards more technical posts. Do you have any protections against malicious clients?

[teefal]

JobLeonard, this was the biggest "ah-ha" this year. Not only is distributed version control useful with kids, it's damn near essential.

The insight came when I realized that every kid wanted to do graffiti on everything. First we locked things down, requiring owner permission. Then I realized the variants could actually be really cool, that the owners might like each change better and would promote them.  This led to the "change anything" mantra.

It's still a bit hard to understand, which is why I'm making branches a big part of the upcoming improved map.  I want kids to be able to switch branches in the map and see what's different. Ideally it'll be a snap to make your own branch that cobbles together various good ideas from lots of other branches ... remixes.

a-k-, thanks. With a software developer conference coming up, I switched my focus to the nuts and bolts. It's been easier to write about, because I'm proud of much that's under the hood.  As for client security, there's currently only account validation. I'll put some kind of magic cookie handshake in there eventually. The connection isn't even encrypted yet because I've been lazy about it.  Just added it to the current milestone

[JobLeonard]

 

[teefal]

Coding in Tidepool is a mostly declarative affair, where players define rules for agents to follow. The design comes from my own Gravity environment from the early 90s, which itself was influenced by Prolog and Smalltalk. A more modern sibling might be SPARQL or Wolfram Language. Unlike these others, I've decided not to name the Tidepool language, since I want there to be many dialects that do the same things.

As of now, Tidepool rules are too syntax-laden for most kids to use. This will change in the next milestone when I make the cognitive agent's natural language interface.

For example, this current clunker:

#adv-bird.1 when "get" nearby(#adv-rod.1) or holding(#adv-rod.1), say "The bird is frightened..."

could be written in any of these ways:

• bird, when I say "get" and the rod is nearby or I'm holding the rod, say "The bird is frightened..."
• bird, instead of get say "The bird is frightened..." if I have the rod or it's nearby
• don't get the bird if I have the rod or it's in the room, say "The bird is frightened" instead.

Tidepool's current coding UI is also more complicated than I'd like. Instead of typing the rule above, you can also use the Rule Box.

The puzzle I'm currently working on is defined like this:



This basically says, "Bird, when I type "get", if I'm holding the rod or the rod is nearby, say 'The bird is frightened'.  If the rod isn't nearby and I'm not holding it but I'm not holding the cage, say 'You can catch the bird, but you cannot carry it'.  If you are holding the cage and the rod isn't near and you're not holding it, then get the bird.

There are many ways to express conditionals like these, and yes, this is too complex for kids. The structure above is merely the boiled down version of a much fuzzier future. I'm hoping you can use real language to write rules by March or April.

In Java/C/etc, this would be written:

if ( holding(aRod) || nearby(aRod) ) say( "Bird is frightened");
else if ( !holding(aCage) ) say( "Cannot carry it" );
else get(aBird)

Yes, a programmer will think this is so much easier. Good luck teaching this to a seven year old. Besides, declarative rule-based languages have deeper strengths that static procedural if-else chains can't touch.

[JobLeonard]

This is a pretty intimidating interface, I think 

bird, instead of get say

This is really confusing to me

Anyway, in programming languages we often use syntax highlighting. Have you considered coming up with some kind of "natural language highlighting" that will indicate how the computer interprets your words? Imagine something like verbs are red, nouns are blue. That might help children "debug" their code, because they can see when the computer mistakes a verb for a noun.

[oahda]

I'm wondering if a node-like system like Scratch might not work better because they make syntax errors almost impossible, while kids would be easily tripped by typos or simply not knowing the spelling of a word using a system like this, even if the syntax is relatively free. Connecting blocks with few options available, and only being able to select blocks that can logically connect to the current one.