WARNING: If you’re not interested in RPG games, or Ruby programming, ignore this blog post.

A few years ago, when I was learning Ruby, I had an idea for a game.

Here are my initial notes for the game that I jotted down before writing code:

• You start out with a small team of heros.
• Foes start streaming in.
• You fight the foes.
• Results: deaths/stats upgrade/skill acquirement.
• Payment: you get paid for your hard work and effort by the town for your kills.
• Shopping to upgrade equipment.
• Cash in experience for stats upgrades.
• Heros can permanently die.

The inspiration was the “Tower Defense” games that were hugely popular.

I considered basing the game engine on D&D, but instead chose Fudge game system.

I implemented a number of features, including:

• Name generator
• Creature library
• Foe generator
• Hero generator
• Combat system
• Items system
• Skill system
• Open ID

Why did I do all this? To amuse my son, Emerson. We played the game on my computer.

I have tossed it out onto the Internet (http://towndefensegame.com), so you can play the game too :) Source code (rough & unrefactored) has been posted to http://github.com/ryw/town-defense-game for your amusement. I decided to not try and quickly clean up the source code before posting, except what I had to to get it deployed.

The UI is ugly and layouts need fixed in certain browsers, sometimes a hero dies during battle then gets hit again and is somehow brought back to life (bug), there are no tests, there is no instruction on how to play the game.

But it’s out there now so Emerson can play whenever he wants, and now I’m motivated to clean it up.

Feel free to play it and see if you can get hero’s on the top 20 list. I’m warning you now, however, that Emerson is competitive.

Make sure you have autotest-rails gem installed.

So I was talking with Michael Guterl, about the lack of a true Ruby user group in town. Rather than complain about it, I whipped out http://cincinnatirb.org/.

There are some well-known Ruby people in town; I’m not one of them. Despite my lack of credentials, I do love Ruby and don’t totally suck, but more importantly, the time has come for a Cincinnati.rb.

Come one, come all, it’s open hacking night every night—we’re going to let the meeting drive itself to wherever it wants to go.

P.S. We’re flexible about meeting space, but we’ll kick it off at the RecruitMilitary HQ in Loveland on Nov. 17th for meeting #1 at least.

Drop us a note if you want to show up :)

So ASP.NET MVC Preview 4 is about to hit the streets. I have been watching, waiting, hoping that the ASP.NET effort at copying Rails would be so compelling that I could stomach investing in .NET programming again.

The new preview 4 features:

• filter interceptors (before + after hooks for controllers)
• outputcache filters (action caching)
• handle error filters (custom error page)
• authorize filter (role-based authorization)
• accountcontroller class (wrapper to ASP.NET membership API)
• minor improvement to testing
• some ajax stuff

They are incorporating community-driven features, which is good. But I don’t think the project has anywhere near the velocity it needs. It’s taken them 2 months to get this new functionality out the door… I’m not very excited, because it’s hard not to compare what’s going on to present-day Rails, which is years ahead.

The big concerns I have about ASP.NET MVC are:

• still not opinionated enough. Rather than simplifying .NET web development, they are giving more choices
• the names they are giving features… ugh! Give me the silly Rails “plugin_fu” and “sexy_plugin” names any day vs. filter, filter, filter
• documentation not at your fingertips—maybe it’ll get there, but I bet there will never be a docs site for ASP.NET MVC as simple + easy to use as RailsBrain
• no plugin system that I’ve heard about
• not Restful… /:controller/:action/:id is so 2005. And I suppose for webservices, they still want developers to use SOAP?

I actually want the project to succeed, because it’s tough for organizations who have invested in .NET system to consider switch. And I want my .NET friends to be happier. They truly don’t know what they’re missing in the amazing Ruby community—Rails, Github, Merb, nginx/thin, Sinatra, Radiant, Shoulda, RSpec, and literally dozens of other interconnecting projects.

If a beginner was starting his ‘Rails journey’ should we advise traditional test::unit testing vs. new rspec testing… I think rspec is the future, and it’s now relatively stable, but it’s also more complicated + tricky than test::unit.

Would you advise newbies learn test::unit before rspec in order to more fully appreciate rspec?

I just gave advice not to test at all on first project, as learning Ruby + Rails is tough enough without trying to figure out testing… Did I goof?

The progress David Chelimsky is making on rspec is impressive, in particular his ability to take a diverse set of input and drive the project forward. Of course, big props go to Pat Maddox for driving the plain text file idea forward.

See David’s full post.