Back to basics (again)

It’s definitely different starting all over again with writing a new MUDcodebase. My first attempt was Evennia, which  has evolved significantly since I handed it over. It is/was meant to be more general-purpose, and appeal to MUX/MUSH/MOO refugees who are tired of softcode (MUX/MUSH’s internal scripting language). This time around, I’m writing something specifically crafted for my own purposes, so I get to be greedy.

I’ve got some particular ideas in mind for what I’d like to do. While I could have used Evennia (it has matured into a fine codebase), I decided to take what I learned from my first effort a few years ago, refine it, and turn something out that was the bare minimum for what I want to do (more on what that is in a future post).

I am in no way advocating this approach for most or even a few, as it’s extremely time consuming, a re-invention of the wheel, and not at all sexy. I find myself implementing command parsers/tables, object persistence, and a bunch of other stuff that I’ve already done, all in the name of being my game’s ideal environment for development. But for those that are masochistic, have tons of time on their hands, or are otherwise mentally ill, it can’t be beat!

While I am very unlikely to ever write documentation aside from what any future game moderators will need, the full source code for the new codebase can be found on GitHub. This is going to be in constant flux, backwards incompatibilities will probably arise every time I touch it, and it’s likely to be partially or completely broken at any time. That said, maybe you’ll find something useful in it.

Unable to shake the habit

Some of the first multiplayer games I played were text-based MUDs. Theiraccessibility, the imagination required, and the variety of places to spend time was great. Myself and a close friend had a few favorite places to haunt online, and had a blast exploring other people’s worlds.

We stumbled through Apocalypse, played Shades of Evil at its height, cyborged our way through Thunderdome, and finally got sucked into BattletechMUXs of various kinds. Times changed, we moved on to greater things in life, but I keep catching myself looking back at MUDs as an ideal gaming medium for me. This may sound strange to some of you, which is why I made sure to add that “for me” part at the end of that last sentence.

But why would anyone want to play these crummy, crude, text-based games when there are so many massive, beautiful titles to spend time and money on?

These crummy, crude, text-based games offer a minimalistic, focused way to game. They are typically free, they can be developed and iterated upon rapidly, and new content is exponentially easier to add than to a graphical game. The element of imagination is perhaps the single strongest appeal to me in a MUD.

I am sure by now that some are wondering where I’m going with this. To that, I answer: I am once again spending some free time hacking on a game concept I’ve been mulling over in my head for a few months. I’d like to borrow desirable elements from my favorite games, and make something that is fun for me, and hopefully others, to play.

I have no idea if I’ll get far enough to have something playable, but I have finally, after a few years of thinking, found an overall idea that I like and can make progress towards a clear goal on. More to come on this later, but I’ll be doing the development in the open on GitHub. While the more astute of you can find the project already, I’ll hold off on announcing anything until I have something interesting to show (if ever).

Amazon Simple Email Service: Not quite there

We’ve been working on transitioning a larger customer’s website from anExchange-based email server to Amazon Simple Email Service, in an effort to improve reliability and eliminate one more bit of reliance on internal infrastructure. I’ll share our experiences here for others considering the same thing.

The Good

• The setup process was simple (subscribing to the service, getting production access).
• The API calls to SES are quick and reliable.
• Sending mail is easy.

The Bad

• It makes sense to have to verify ownership of an address to use as a “reply-to” in headers, but it’s a real pain when you send from a bunch of emails under one domain. There’s no way to wildcard-verify the entire domain. Not a deal-breaker, but kind of annoying.
• There is no way to see delivery failures. Again, not a deal-breaker, but not ideal.

The Ugly

• For higher-volume sites, migrating to SES is awful. You start with a 1,000 emails per 24 hours quota, and have to increase the limit by consistently sending enough emails to put you in the neighborhood of your limit. See the Growing your quota documentation for more specifics. More on this later.
• Automated quota increasing hasn’t worked for us. We’ve been sending right near our quota for 6 days now without a bump. We’ve hit our limit a few times, and lost a handful of emails because of this, since we were planning on the quota increasing as advertised.

Quotas: Low, inflexible, and buggy

Take one look at AWS’s migration strategies for SES and consider the annoyance these represent for transitioning a large, active website. The onus is on the developer or administrator to come up with some way to only send 1,000 emails a day until SES gets around to bumping quotas up. There is no way to go through a verification process (like PayPal or some other email services) and just pay for what you use. There is no real special consideration for those who need it. There are forms to ask for an initially higher quota, but everyone ends up at the 1,000/24 hour limit initially.

In our case, we worked around the migration annoyances. We send about 1,500-3,000 a day, so we just manually switched back and forth between our old SMTP/Exchange setup and the new SES backend. We’ve been doing this for 6 days now, whereas our quota should have bumped after day 3. Low quotas are one thing. Not raising the limits after the documented period is even worse.

The Recommendation

For very small sites, or those that are starting with SES, it can be a great fit. It’s cheaper than the comparable services, it’s simple to get set up with, and it’s fast and reliable. For sites that already have a higher email volume, I’d suggest avoiding SES until it matures. It’s still not documented clearly in some places, and the quota buggyness and inflexibility mentioned earlier in this post are show-stoppers.

This one needs another six months in the cooker. I’m sure later iterations will improve the service, as has been the case with the other products offered in AWS.

New IMC and IRC extensions for Evennia MUD server

Evennia, the Twisted+Django MUD server, has just finished bringing inshiny new support for IRC and IMC (Inter-mud communication) as of revision 1456. This allows users to bind a local game channel to a remote IRC or IMC room. Evennia transparently sends/receives messages between the game server and the remote IRC/IMC server, while the players are able to talk over said channel just like they would a normal one.

It is even possible to bridge an IRC room to an IMC channel, with the Evennia server acting as a hub for messages. The next step for any eager takers may be to create a Jabber extension (any takers?).

If you’re curious, feel free to drop by #evennia on FreeNode to pester the developers.

django-ses + celery = Sea Cucumber

Maintaining, monitoring, and keeping a mail server in good standing canbe pretty time-consuming. Having to worry about things like PTR records and being blacklisted from a false-positive stinks pretty bad. We also didn’t want to have to run and manage yet another machine. Fortunately, the recently released Amazon Simple Email Service takes care of this for us, with no fuss and at very cheap rates.

We (DUO Interactive) started using django-ses in production a few weeks ago, and things have hummed along without a hitch. We were able to drop django-ses into our deployment with maybe three lines altered. It’s just an email backend, so this is to be expected.

Our initial deployment was for a project running on Amazon EC2, so the latency between it and SES was tiny, and reliability has been great. However, we wanted to be able to make use of SES on our Django projects that were outside of Amazon’s network. Also, even projects internal to AWS should have delivery re-tries and non-blocking sending (more on that later).

Slow-downs and hiccups and errors, oh my!

The big problem we saw with using django-ses on a deployment external to Amazon Web Services was that any kind of momentary slow-down or API error (they happen, but very rarely) resulted in a lost email. The django-ses email backend uses boto’s new SES API, which is blocking, so we also saw email-sending views slow down when there were bumps in network performance. This was obviously just bad design on our part, as views should not block waiting for email to be handed off to an external service.

django-ses is meant to be as simple as possible. We wanted to take django-ses’s simplicity and add the following:

• Non-blocking calls for email sending from views. The user shouldn’t see a visible slow-down.
• Automatic re-try for API calls to SES that fail. Ensures messages get delivered.
• The ability to send emails through SES quickly, reliably, and efficiently from deployments external to Amazon Web Services.

The solution: Sea Cucumber

We ended up taking Harry Marr’s excellent django-ses and adapting it to use the (also awesome) django-celery. Celery has all of the things we needed built in (auto retry, async hand-off of background tasks), and we already have it in use for a number of other purposes. The end result is the now open-sourced Sea Cucumber Django app. It was more appropriate to fork the project, rather than tack something on to django-ses, as what we wanted to do did not mesh well with what was already there.

An additional perk is that combining Sea Cucumber with django-celery’s handy admin views for monitoring tasks lets us have peace of mind that everything is working as it should.

Requirements

• boto 2.04b+
• Django 1.2 and up, but we won’t turn down patches for restoring compatibility with earlier versions.
• Python 2.5+
• celery 2.x and django-celery 2.x

Using Sea Cucumber

• You may install Sea Cucumber via pip: pip install seacucumber
• You’ll also probably want to make sure you have the latest boto: pip install —upgrade boto
• Register for SES.
• Look at the Sea Cucumber README.
• Profit.

Getting help

If you run into any issues, have questions, or would like to offer suggestions or ideas, you are encouraged to drop issues on our issue tracker. We also haunt the #duo room on FreeNode on week days.

Credit where it’s due

Harry Marr put a ton of work into boto’s new SES backend, within a day of Amazon releasing this service. He then went on to write django-ses. We are extremely thankful for all of his hard work, and thank him for cranking out a good chunk of code that Sea Cucumber still uses.