Here’s the code I originally produced, which scans through a list of NLP-tagged words and retrieves the first verb. If the list is empty then we need to return an empty string and if the list has no verbs then we assume that the first (or only) word in the list is a verb. For example, if I type “who” or “uptime” into the game then these should be considered verbs for command dispatching, even though NLP says they’re not verbs per se.

Ugly as Sin Code:

def firstVerb = {
if (words.size == 1)
words.head.value
else {
val outWords = words.filter( word => word.pos == Verb)
if (outWords == Set.empty)
words.head.value
else
outWords.head.value
}
}

And thanks to the geniuses over at Stack Overflow, they were able to guide me to this incredibly simple, elegant refactoring:

Refactored Code:

words find(_.pos == Verb) orElse words.headOption map(_.value) getOrElse ""

My hope is that someday I will think in terms of the second, more clean and refactored version and not instinctively reach for my imperative crutches.

In this blog post, I’ve come one step closer to that goal by enabling the dispatching of commands. As players enter input, that input is sent off to a Commander actor which tags up the input with parts of speech. Once the Comander is finished with it, it wraps the tagged words in an EnrichedCommand message and sends that to the player, which now has the trait Commandable, allowing the player to respond to enriched commands. This has an added benefit of allowing NPCs to be scripted in the future by allowing them to pretend to ‘type’ things like “kill player”, etc.

Eventually rooms will add commands to players when they enter the room to allow them to type the name of the exit (e.g. north, south, up, window) as a verb. Mortals and Wizards alike each have a unique set of commands they need to be able to type and these commands are grouped into “command libraries” (my old alma mater MUD, Genesis, an LPMUD, called them command souls). For example, here’s the first version of the Mortal command lib:

package com.kotancode.scalamud.core.cmd

import com.kotancode.scalamud.core.ServerStats
import com.kotancode.scalamud.core.TextMessage
import com.kotancode.scalamud.Game
import com.kotancode.scalamud.core.Implicits._
import akka.actor._
import akka.routing._

abstract class CommandLibMessage
case class AttachCommandLib extends CommandLibMessage

class MortalCommandLib extends Actor {
	def receive = handleMortalCommands

	def handleMortalCommands: Receive = {
		case cmd:EnrichedCommand if cmd.firstVerb == "who" => {
			handleWho(cmd.issuer)
		}
		case AttachCommandLib => {
			attachToSender(sender)
		}
	}

	def handleWho(issuer: ActorRef) = {
		println("player "+ issuer.name + " typed who.")
		var stringOut = "Players logged in:\n"
		for (p: ActorRef <- Game.server.inventory) {
			stringOut += p.name + "\n"
		}
		issuer ! TextMessage(stringOut)
	}

	def attachToSender(sender:ActorRef) = {
		sender ! AddCommand(Set("who"), self)
	}

}

Those of you who program in iOS or Cocoa might recognize some of the “Delegate Pattern” here… when the command lib attaches itself to something capable of issuing commands (anything that carries the Commandable trait, like a player or NPC), it just passes the implicit sender ActorRef so that actor can now dispatch commands to that lib.

Here’s the code in the Commander object that sends enriched commands to the actor that “typed” (virtually or for real) the command:

package com.kotancode.scalamud.core.cmd

import akka.actor._
import akka.routing._

import com.kotancode.scalamud.core.lang.EnrichedWord
import java.util.ArrayList
import edu.stanford.nlp.ling.Sentence
import edu.stanford.nlp.ling.TaggedWord
import edu.stanford.nlp.ling.HasWord
import edu.stanford.nlp.tagger.maxent.MaxentTagger
import scala.collection.JavaConverters._
import scala.collection.mutable.ListBuffer
import com.kotancode.scalamud.core.cmd._

class Commander extends Actor {
	def receive = {
		case s:String => {
			val words = s.split(" ");
			val wordList = new java.util.ArrayList[String]();
			for (elem <- words) wordList.add(elem)
		    val sentence = Sentence.toWordList(wordList);
		    val taggedSentence = Commander.tagger.tagSentence(sentence).asScala.toList

			var enrichedWords = new ListBuffer[EnrichedWord]
		    for (tw : TaggedWord <- taggedSentence) {
				val ew = EnrichedWord(tw)
				println(ew)
				enrichedWords += ew
			}

			sender ! HandleCommand(EnrichedCommand(enrichedWords, sender))
	}
}
}

object Commander {
	val tagger = new MaxentTagger("models/english-bidirectional-distsim.tagger")
}

The important bit is that the player gets the HandleCommand message, which then goes through a dispatch process in the Commandable trait, and eventually registered verb handlers (like those registered via attached command libraries) get invoked via messages. Here’s the Commandable trait:

package com.kotancode.scalamud.core.cmd

import akka.actor._
import akka.routing._
import scala.collection.mutable.HashMap
import scala.collection.mutable.HashSet

sealed abstract class CommandMessage
case class AddCommand(verbs:Set[String], handlerTarget:ActorRef) extends CommandMessage
case class Removecommand(verb:String) extends CommandMessage
case class HandleCommand(command:EnrichedCommand) extends CommandMessage

trait Commandable {

	private val verbHandlers: HashMap[Set[String], ActorRef] = new HashMap[Set[String], ActorRef]

	def handleCommandMessages:akka.actor.Actor.Receive = {
		case AddCommand(verbs, handlerTarget) => {
			verbHandlers.put(verbs, handlerTarget)
		}

		case HandleCommand(cmd) => {
			dispatch(cmd)
		}
	}

	def dispatch(cmd:EnrichedCommand) = {
		println("handled a command "+ cmd +".")
		println("command's first verb: " + cmd.firstVerb)
		val targetHandlers = verbHandlers.filterKeys(key => key.contains(cmd.firstVerb))
		targetHandlers foreach {case (key, value) => value ! cmd}
	}
}

The dispatching actually happens in the targetHandlers foreach … line where the command is sent to every command handler that declared interest in that verb. In our case, we have a mortal command verb who that displays the list of connected users and the wizard command verb uptime that displays the length of time the server app has been running.

The following is sample session output from telnetting to the game:

Welcome to ScalaMUD 1.0

Login: Kevin
Welcome to ScalaMUD, Kevin
who
Kevin: who
Players logged in:
Bob
Kevin
Kevin
uptime
Kevin: uptime
Server has been up for 6 mins 39 secs.

Now that I can log in with multiple players, see who is online, and dispatch commands to handlers as well as differentiate between mortal and wizard abilities, this game is finally starting to feel like the beginnings of a real MUD.

So what is Apple planning to do with Mac OS X Mountain Lion? According to the information I can find publicly, here are some of the highlights:

• Game Center – Apple’s game service that provides everything from matchmaking to leader boards, achievements, and even in-game multiplayer voice chat is coming to the Mac. This also means that developers writing games for the Mac will be able to participate in all that amazing goodness that iOS developers have been enjoying since iOS 4.1.
• iCloud – I don’t really know all the details here only that iCloud is even more integrated into the OS now and I’m assuming the developer experience around iCloud is getting better. I’m actually hoping that experience gets better because writing iCloud code on Lion is a pain in the ass.
• Sharing – More iOS goodness comes to the Mac with sharing “sheets”. Every application on Mountain Lion now gets a little sharing icon that uses sharing services, allowing you to share whatever you’re looking at in the application with your buddies via e-mail or whatever other services are registered on the Mac, including Twitter. I would imagine that it wouldn’t take much work, assuming the sharing APIs are good, to add other sharing targets like Facebook, Dropbox, LinkedIn, etc to your Mac – turning it into just as much of a social hub as your phone.
• Twitter - Twitter is a first-class citizen on the Mac just like it became first-class on iOS 5. This means that Mountain Lion users can tweet from pretty much anywhere and using the “sharing” services, they can share pretty much whatever they’re working on in any application (that supports it) via Twitter. Not only is twitter a first-class citizen, but applications can send Tweets on behalf of their users without any extra work. Twitter appears to be accessible in API form to developers without them having to figure out which of the 10 open-source Objective-C twitter libraries they want to shoehorn into their app. This is fantastic news for developers and I hope we get similar integration possibilities with Facebook, Dropbox, etc via Sharing “sheet” APIs.
• Notifications - In what looks to be very similar to the notification center on iOS 5, Apple now has a unified display of messages that are pertinent to the user, including IMs, iMessages (also now a fully integrated part of Mountain Lion), and application-level notifications. In classic Apple style, they are aiming to push popular 3rd parties out of this market with their 1st party offering. Applications like Growl may find it hard to compete with the unified interface, but time will tell how the 1st-vs-3rd party battles are settled.
• Gatekeeper - Again I don’t know all the details, but this feature aims to make your application more secure and, more importantly, provides developers with a secure way of distributing verified, signed applications outside the app store. For most developers, the App Store is absolutely the best way to go. But for some applications, it makes no sense to put in the app store and many people don’t need Apple’s distribution channel and so aren’t comfortable sharing 30% of their profit with the company. Gatekeeper and Developer IDs and signing give developers a way of distributing applications that users can feel comfortable downloading, installing, and using.
• 64-Bit – You simply cannot run Mountain Lion on a 32-bit machine. The kernel is 64-bit and an entire host of 32-bit “wrappers” are missing in Mountain Lion, further drawing a line in the sand against 32-bit apps. If only some other software giant whose name starts with M that makes an operating system would also draw a similar line. In words from one of my favorite movies of all time (Zombieland), “It’s time to nut up or shut up.”
• SSO – In order to support seamless sharing and such, there appears to be some kind of single sign-on facility in OS X much like Windows has been allowing you to link your “LiveID” to your user account for quite some time … only with the Twitter integration I would imagine Apple’s SSO allows for more than just Apple ID storage.

All in all Mountain Lion is looking pretty promising. Again, there’s absolutely nothing groundbreaking in here, but starting with Lion and continuing with Mountain Lion, it appears that Mac developers are finally getting access to the same amount of lovin’ that the iOS developers have been enjoying since iOS 4.

While I had the MUD code open I decided to start working on the problem of accepting player input. Sure, I have a socket reader that accepts text from players but what does one do with this text?

In the old days, I would’ve tokenized the string. By tokenized here I mean just splitting it blindly on spaces. Then I would have considered the first word in the array to be the verb and then dispatched the remaining parameters to some function in the MUD code that knows how to respond to that verb. For example, if I typed kill dragon then I would’ve tagged kill as the verb and dragon as the “rest”. This would have eventually found its way to some kill() method on a player that takes an array of strings as parameters.

Thankfully this isn’t the old days.

Instead what I did was declare a Maven dependency on the Stanford NLP (Natural Language Processing) project. To be specific, I wanted to use the Stanford non-linear Parts of Speech tagger. Why should I deal with parsing strings in a dumb way when someone else has spent years creating a powerful, well-trained NLP engine that can tag every sentence my player types with parts of speech?

This way, instead of relying on forcing players to type in pidgin dialects (e.g. kill dragon or cast spell or move north) I can let them type complete English sentences (if they want). I will then tag those sentences with the appropriate parts of speech and infer what they wanted to do from that.

I want this parsing to take place in the background. Once the player’s sentence has been enriched with parts of speech, I want to send the enriched sentence back to whatever typed it so that the command can be dispatched. To do this, I created a new Actor called Commander:

package com.kotancode.scalamud.core

import akka.actor._
import akka.routing._

import com.kotancode.scalamud.core.lang.EnrichedWord
import java.util.ArrayList
import edu.stanford.nlp.ling.Sentence
import edu.stanford.nlp.ling.TaggedWord
import edu.stanford.nlp.ling.HasWord
import edu.stanford.nlp.tagger.maxent.MaxentTagger
import scala.collection.JavaConverters._

class Commander extends Actor {
	def receive = {
		case s:String => {
			val words = s.split(" ");
			val wordList = new java.util.ArrayList[String]();
			for (elem <- words) wordList.add(elem)
		    val sentence = Sentence.toWordList(wordList);
		    val taggedSentence = Commander.tagger.tagSentence(sentence).asScala.toList

			var enrichedWords = new ArrayList[EnrichedWord]
		    for (tw : TaggedWord <- taggedSentence) {
		//		println(tw.value + "/" + tw.tag)
				val ew = EnrichedWord(tw)
				println(ew)
				enrichedWords.add(ew)
			}
	}
  }
}

object Commander {
	val tagger = new MaxentTagger("models/english-bidirectional-distsim.tagger")
}

At this point I’m just building the array of enriched words and I’m not actually sending the command back to the player (I’ll do that tonight or tomorrow, time permitting .. as always, you can check out the GitHub repo for the latest changes to the MUD). One of the interesting bits here is how I’m using a Java library from Scala. This is usually a pretty painless task but sometimes there are issues. In this case, the Stanford NLP library class Sentence has a bunch of overloads for the toWordList method. Java knows how to pick which overload but Scala doesn’t if I just use type inference and default Scala types. To get it to pick the right toWordList method I had to manually construct an ArrayList[String] because passing an Array[String] doesn’t let Scala know which overload to pick. It’s a little annoying but if I can keep the Scala->Java bridge points like this minimal then it’s not bad.

The flip side of this is that I’m getting back a regular Java array list in response to toWordList, which doesn’t support pretty Scala-native iteration because it doesn’t contain a foreach method, which is the underpinning that supports all the syntactic sugar around iteration. To deal with that, I imported the Java converters package implicits so that I could get the asScala function, which lets me call toList, which gives me a nice Scala list that I can use for easy iteration.

Here’s some sample output when I connect to the MUD and enter a sample sentence, which is then tokenized and tagged with parts of speech:

[EnrichedWord: word=attack, tag=VB, pos=Verb]
[EnrichedWord: word=the, tag=DT, pos=DontCare]
[EnrichedWord: word=green, tag=JJ, pos=Adjective]
[EnrichedWord: word=dragon, tag=NN, pos=Noun]
[EnrichedWord: word=with, tag=IN, pos=DontCare]
[EnrichedWord: word=the, tag=DT, pos=DontCare]
[EnrichedWord: word=yellow, tag=JJ, pos=Adjective]
[EnrichedWord: word=sword, tag=NN, pos=Noun]

The real goal here is that I will be taking the tagged nouns in the sentence and scanning through the player’s inventory and the environment in which the player stands for objects which have names that match the nouns and then using adjectives to disambiguate them if collisions occur. That way, when I type “kick blue bottle” I will be able to scan the surroundings for objects called “bottle” and if I find more than one, I’ll only gather up the ones that are blue.

In case you’re wondering what the EnrichedWord class looks like, which has some helper code that identifies only the parts of speech I care about, here it is:

package com.kotancode.scalamud.core.lang

import edu.stanford.nlp.ling.TaggedWord

case class PartOfSpeech
case object Noun extends PartOfSpeech
case object Verb extends PartOfSpeech
case object Adjective extends PartOfSpeech
case object DontCare extends PartOfSpeech

class EnrichedWord(value:String, tag:String, val pos:PartOfSpeech) extends TaggedWord(value, tag) {

	override def toString = "[EnrichedWord: word=" + value +", tag=" + tag + ", pos=" + pos + "]"
}

object EnrichedWord {
	def apply(hw: TaggedWord) = {
		val ew = new EnrichedWord(hw.value, hw.tag, rootTypeOf(hw.tag))
		ew
	}

	def rootTypeOf(s:String) = {
		s match {
			case "VB" | "VBD" | "VBG" | "VBN" | "VBP" | "VBZ" => Verb
			case  "NN" | "NNS" | "NNP" | "NNPS" => Noun
			case "JJ" | "JJR" | "JJS" => Adjective
			case _ => DontCare
		}
	}
}

Note that the EnrichedWord Scala class inherits from the Stanford TaggedWord Java class.

I really, really, love the syntax of the string pattern matcher I use to obtain the POS root (adjective, verb, noun, don’t care) from the Penn Treebank Tags that are used by the Stanford NLP POS tagger.

The takeaway I got from this exercise is further reinforcement of my rule to never re-invent the wheel because there are wheel experts out there who have dedicated their lives and careers to building wheels more awesome than I could ever hope to build. Hence I declare a Maven dependency on the NLP library and in a single night, I’ve got a MUD that can intelligently POS-tag player sentences which I can then use to identify potential targets of player commands. In addition, I don’t have to create a pidgin dialect for interacting with the MUD. English works and the MUD should be able to deal with “I kill the dragon with the blue sword because I am the shizzle” with the same ease as “kill dragon with sword”.

No, my experience with regular expression support and parsing in other languages like C# and Java has left a terrible taste in my mouth. I hate it. When I want to parse stuff, I want to use pattern matching and rich syntax like I can get from languages like F# or Scala.

This made me wonder if Scala didn’t make regex parsing easier. Turns out, it makes it brain-dead simple with the clever use of the concept of an unapply. The same capability that makes Scala so good at constructing, zipping, and traversing list structures also makes it just as good at cracking apart structures into their component parts.

As a sample, I created a simple string in Scala and then put the “.r” postfix on it, turning it into a regular expression:

scala> val zombieLog = """(d\+) zombies spotted in (\w+).""".r

This created a regular expression with two groups. If you’re used to doing this kind of thing in Java or C# then you’re probably thinking that you now need to write 10 lines of code to set up the regex compiler, call some method to feed the string into the regex compiler, then access groups by numeric, 0-based indexes.

Fortunately, this is Scala and more often than not, things suck less in Scalaville.

First, I’ll create an input string that I want to crack apart with my regex:

scala> val inputText = "200 zombies spotted in Mexico."

Now I’ll use unapply and syntactic sugar and Scala goodness to pull out the right values:

scala> val zombieLog(zombieCount, location) = inputText // UNAPPLY magic
zombieCount: String = 200
location: String = Mexico

And that’s it, Bob’s your uncle. With the plethora of online regular expression builders available, it should only take you a few minutes to create the regex you need and slap it into your Scala code.

At first, the power and utility of these companion objects wasn’t really all that clear to me but then I started finding myself using them more and more to the point where I am pretty sure I couldn’t write a Scala app of any decent size without using them.

Let’s take a look at one of the most common uses of a companion object as a place to put factory methods using the apply method:

class BucketOSlime private (val slimeColor:String) {
    // Stuff goes here...
}
object BucketOSlime {
    def apply(color:String):BucketOSlime = new BucketOSlime(color)
}

With this code in place you can now create colorful buckets of slime with a constructor shortcut syntax that lets you leave off the word “new” entirely:

val blueSlime = BucketOSlime("blue")
val whiteSlime = BucketOSlime("white")

The fun (and power) doesn’t stop here. You can use multiple apply methods or a single apply method with pattern matching to return different instances of the same abstract object:

object BucketOSlime {
    def apply(color:String):BucketOSlime = {
        if (color == "blue")
              new BlueBucketOSlime
        else
              new RegularBucketOSlime(color)
    }
}

There are a ton of other ways you can use companion objects. Another common one is to wrap implicits to upgrade or enrich a class (like I’ve done with my MUD recently) so that the implicit doesn’t need to be imported directly.

The more I use Scala, the more I thoroughly enjoy it. I still utterly despise when I see people overloading symbols everywhere so that Scala’s complexity approaches “write once confuse everywhere” status… but with discipline I still think developers can keep Scala syntax clean, concise, and eminently readable.

Cover Art - SAMS Teach Yourself Mac OS X Lion Programming in 24 Hours

I am posting this blog post here to let people know that all of the revisions are done, all of the proofs have been approved and accepted, and the only thing left to do for this book is to print it.

So now there is no excuse – go out and buy yourself a copy. Then buy one for your friends and your parents and your friends’ parents.

I hope you enjoy reading the book and learning from it as much as I enjoyed writing it.

That said, I am building a MUD here and I’m going to need state. My rooms need names, descriptions, and exits. My NPCs are going to need combat stats and inventories, my players are going to need names, descriptions, races, genders, etc. This is all basic stuff but – if I can’t get to a game object reference from an ActorRef, how am I going to get at their internal state?

Easy! Don’t use internal state.

Remembering back to my first post where I upgraded my old Scala MUD to use Akka actors, I noted that every actor in a system has a unique path string that denotes its position within a hierarchy of supervisory actors much like the way supervisors and processes exist in an Erlang system. That gave me the idea to store the state for my actors in a big in-memory hash (which I could then upgrade to some kind of distributed or CouchDB-type store later).

With that problem solved, the only real problem now was that my ActorRef instances didn’t have concrete properties. One of my favorite features of Scala, which is also used in building DSLs, is the pimp my class or pimp my library pattern. This works very much like class extensions in C#. I can create a class that encapsulates or enriches an underlying class type by providing methods that operate on or with that class. In my case, I wanted strongly typed accessors like name and description that actually deferred the backing store to this singleton, in-memory hash.

Here’s my scala file that contains an Implicits object that enriches the ActorRef type with the wrapper class and the wrapper class provides a getter and setter for name.

package com.kotancode.scalamud.core

import akka.actor.ActorRef
import scala.collection.mutable.{Map,
    SynchronizedMap, HashMap}

object Implicits {
	implicit def enrichActorRef(value: ActorRef) = new WrappedActorRef(value)
}

/*
 * Singleton containing a hash map keyed on the Actor Ref path
 * which contains additional hash maps.
 * There is one hash map for every actorref that needs state
 */
object StateMap {

   // Creates a thread-safe hash map
   def makeMap: Map[String, HashMap[String,String]] = {
       new HashMap[String, HashMap[String,String]] with
           SynchronizedMap[String, HashMap[String,String]]
   }

   private var stateMap = makeMap

   def getState(key:String):HashMap[String,String] = {
   	 if (!stateMap.contains(key))
	     stateMap.put(key, new HashMap[String,String])
	 stateMap(key)
   }

   def setState(key:String, propertyName:String, value:String) = {
		var state: HashMap[String,String] = null
		val result = stateMap.get(key)
		result match {
			case Some(x) => state = x
			case None => state = new HashMap[String,String]
		}
		state.put(propertyName, value)
		stateMap.put(key, state)
   }
}

class WrappedActorRef(val actorRef: ActorRef) {

	def name:String = StateMap.getState(actorRef.path.toString)("name")
	def name_=(value:String) { StateMap.setState(actorRef.path.toString, "name", value) }
}

An obvious refactoring opportunity here would be to move the StateMap class out to its own separate Scala file but I’ve always been a huge fan of the agile process of getting something working first and refactoring afterward.

Now, to use my newly enhanced ActorRef (with state) class all I have to do is add the following import

import com.kotancode.scalamud.core.Implicits._

To the top of my Scala file and below anywhere the type ActorRef is known, I can read and write the name property, as shown here:

	private def handlePlayerLogin(player:ActorRef) = {
		println("Player logged in: " + player)
		allPlayers ::= player
		for (p: ActorRef <- allPlayers) {
			p ! TextMessage(player.name + " logged in.")
	    }

Because ActorRef has been pimped to use the external state provider, I can use player.name in my code and it works!

So far I’ve been focused mostly on syntax and learning what idiomatic Scala looks like, how to create and use Akka actors, and so on. It wasn’t until the other night that I started thinking about design and philosophy. This mini-revelation came about when I spent hours trying to find a way to get the actual type from underneath an ActorRef.

I was using context.actorOf() to create actors, as one should with Akka 2.0. So I might be creating and starting actors for rooms, monsters, or living room tables – anything that I thought might be instructive to mess around with. This is when I noticed that once you create an ActorRef by adding your actor to the actor system (either via system.actorOf or context.actorOf) you can’t get at the actual class underneath. All you can do is interact with it like an actor-shaped black box by sending and receiving messages.

In other words, let’s say I’ve got a class called Zombie that is an actor that I’ve added to the actor system. The Zombie has properties like name, eatingSpeed, and percentLivingTissueRemaining. With regular Scala actors, I would’ve been able to mix and match classic OOP-style programming with actor-style programming:

println(tehZombie.name)
tehZombie.percentLivingTissueRemaining = 12
tehZombie ! FeedUpon(randomVictim)

At first this might look nice and appealing, but there’s something insidious happening here. First, our code has access to the internal state of tehZombie for both reading and writing. Secondly, we can send actor-style messages to tehZombie. Back during my first attempt at a MUD using regular Scala actors, I regularly abused this capacity – reading public fields from instances of actors all the while sending them messages.

One main purpose of an actor system is to take the complexity away of multi-threaded access to shared state and business logic. If we have one actor able to access another actor using standard OOP-style member-access patterns, we’ve basically ruined all of the advantages we’re getting from the actor system to begin with because access to public state on an object is not inherently thread-safe.

If we change internal state on an Akka actor in response to a message, we are guaranteed that such a state change is thread-safe. Not only is it thread-safe, it’s single-threaded because the actor’s inbox is being processed by that actor’s thread (or thread pool) and no one else.

So what does this mean? It means that, within the context of an actor system, public state and OOP-style member access is BAD.

Unfortunately, what this means for my MUD is that I’ve got some refactoring to do because I noticed that I’ve been cheating and I passed around a reference to this to another actor – which gave that actor “unsafe” access to public members of my class. What I really should be doing is making sure that nothing on my actors is exposed publicly and I should be aiming for a message pure environment where everything works as though actors are black boxes that just receive messages, do what they need to do, and send back out messages to other actors within the system.

Akka 2.0 enforces an awful lot of this by suppressing access to this from other actors (I cheated… bad, bad, Kevin). Hopefully within a few days (after the Giants win the Super Bowl) I will have some refactoring checked into the Github repo that hopefully has a fully functioning system that is clean, message pure, and exposes no unsafe members.

Wish me luck

There is actually quite a bit of difference in complexity and power between Akka 1.3 and Akka 2.0. There’s a detailed blog post here that covers some details on the breaking changes between 1.2/1.3 and 2.0.

The biggest thing that concerns me is that Akka 2.0 has this concept of an actor system, which is really a tree-like hierarchy of actors. Some actors act in a supervisory capacity over other child actors and this tree is query able at runtime. If this sounds like Erlang’s supervisor process system to you that’s no accident… the philosophy guiding the development of Akka 2.0′s actor system is very Erlang-ish.

So when I create my top-level Game singleton object, I now need to create an instance of an Actor System and fire up a top level actor (I can have multiple top-level actors):

package com.kotancode.scalamud

import akka.actor._
import akka.routing._

/*
 * Root-level Game singleton
 * Creates the Akka Actor System for all subsequent game objects
 */
object Game extends App {
	val system = ActorSystem("ScalaMUD")
	val server = system.actorOf(Props(new GameServer()), "server")
	println("System Starting")
	server ! ServerStart()
}

Note here the use of system.actorOf. If I want to create a subordinate (child) actor within the context of the parent actor doing the creation, then I would use context.actorOf. I can give each of my actors a unique name so that they have descriptive path names when they appear in the actor system tree.

So far I was happy with the upgrade and I didn’t have too much trouble. Then I got to the point where I was creating anonymous actors in order to execute my while loops for accepting sockets and reading input from a socket in the background… Akka 2.0 has removed the spawn { } syntax and replaced it with some severe limitations, namely you can no longer create anonymous actors that do not implement a receive method. This means the old spawn { // do something } construct is impossible, replaced with this snippet from my GameServer class:

case s:ServerStart => {
	context.actorOf(Props(new Actor {
		def receive = {
			case ss:ServerStart => {
				startSocketListener
			}
		}
	})) ! s

If you’re thinking OMGWTFBBQ at this point, you’re not alone. Basically what I’m doing is creating an anonymous actor, defining a receive method that receives a specific message and does something in response to that message and then sending a message to my anonymous actor. This is actually the way the documentation tells you to spawn off asynchronous background tasks without using named actors.

Before you start the flame war here – it is worth taking a minute to think hard about the fact that everything that occurs asynchronously within Akka is supposed to be an asynchronous event-driven, message-passing construct. In short, if I was really anal about this, I would have spawned off an actor that reads from the input socket stream in its own private loop and I would have spawned off another actor that encapsulates the output writer. When the input reader has read a line, it should send a message indicating that a line has been read and when something needs to send text to a player, it should do so through its output writer actor.

At this point I’m not that anal and I don’t need that level of complexity, so I’m leaving it out. I only mention this alternative to ease the pain of the new way of doing anonymous actors.

In short, I did get the MUD running on Akka 2.0-M3 and, while a little put off by the anonymous actor syntax, I understand its need and I applaud the type safe people for forcing actors to receive messages.

If you want to follow the code for the MUD as I continue working on it, check out my GitHub repo.