At TPAC in 2017, someone asked me, what would I do if I could work on what I was really interested in and cared about? I sheepishly admitted that, well, I'd like to work on social networks as a distributed virtual world / game.

I thought I'd be laughed out of the room. Instead, it turned out that almost everyone I was working with had background in that space. Even the ocap stuff I'd been studying came largely from Electric Communities Habitat.

That gave me the courage to pursue .


In he connects Electric Community with E for capabilities. Do those have a direct connection? I'm wading thru the articles, haven't seen it yet, but I might have missed it or not gotten there yet. It's all interesting anyway, just curious about that angle...figure some direct connection probly exists....

No need to respond to that. If I find it, I'll post it here. I was just thinking out loud, sorry...

@bhaugen E is the programming language that Electric Communities Habitat was written in. After EC(H) shut down, the E language survived and lived on as so you're absolutely right :)

@bhaugen This is one reason that I say that even if Spritely fails to deliver a game that people play, it will probably result in interesting and useful things, because historically that has been the case


That's even better! Every time I think we are doing something new, I find out somebody did it before!

But that's better. Gives us maps for how to do it. We are not flying blind.

@bhaugen There is a direct connection. @cwebber talks about it on… and there are some links (like the one you quoted!) in the shownotes.
@bhaugen Short story, in an online game you have objects interacting and that means you need access control.

@cwebber Just got my first awareness of Spritely.

Looked fun until I saw you're using Racket. Then it looked *really* fun!

@ptvirgo I'm glad you're excited! The first independently runnable demo is available, and I think it's also very readable Racket code:

@cwebber Nice, I'm checking it out.

Do you have a favorite tutorial on the actor model? My background is pretty non-traditional, though I've been fleshing things out.

@ptvirgo I don't have one, I'd like to write one though. It's pretty simple: think of each actor as an entity with some address you can send messages to, which can also potentially spawn actors itself, which can send messages to the other actors it knows about, and which can change its state or behavior in response to messages.

Here's a hint: actors are objects, but asynchronous. Handling messages tends to be like method dispatch. :)

@cwebber Thanks for the hint .. ! Sounds like a simple idea that gets really powerful when applied well. I'll poke around a bit and see if I catch a light-bulb.

I had a potentially similar event just last week over coffee with @Danielle .

Sign in to participate in the conversation

Octodon is a nice general purpose instance. more