Introducing RoboDojo

April 11th, 2009
  1. Inherit from an abstract base class
  2. Build in your own navigation and targeting algorithms
  3. Join the arena
  4. Battle to the death

That’s the idea behind this little project, RoboDojo. No, it isn’t a new idea. No, it isn’t terribly unique (Java’s RoboCode), but it sure is fun. And the domain turns out to be very useful to learning .NET development on many levels.

About RoboDojo

Built your own Robot in .NET. Your bot is loaded into BattleField host application where it is initialized and set on its way. The game proceeds in turns, during which each bot getting a turn. Each turn allows a single physical move, and single shot of a weapon.

Bots get current data about the environment in each turn, and use it to make decisions about what to do next (movement and targeting).

The battle runs, the bots take damage, the last bot standing wins (unless the timer runs out first).

Why I Started This

When building courseware or coding examples to work with new technologies, there is always challenge in looking for a domain to work in. Frankly, the customer address book example, although real, makes me want to scream. I am betting this is why Hanselman started BabySmash in the first place.

It is important to note that I started this little pile of code as a playground and a general application with which to learn and grow.

The State of The Project

The first drop I made on CodePlex is very raw.

The current code base seems to work, does not have complete test coverage, only has a little functionality, but is promising. It is a WinForm (for goodness sake) application wherein a user can basically just build a square bot that travels around the screen. No weapon features yet.

I admit, the code is stalled out a bit at the moment. I am neck deep in some real work for a little while, but I pledge to not let this project atrophy.

Next Big Features

Here are the high level features I want to get in next. Before this, though, I want to ensure better coverage on the code that is already there so refactoring gets safer.

  1. Weapon support
  2. Game persistence for storing battles and results
  3. Implement the UI in WPF (vector graphics just kill bitmaps)

If You are Interested

Please let me know. I am happy to work with anyone who might actually care about this project. I freely admit that I am not, nor have I ever been:

  • A game programmer
  • A UI expert
  • A successful administrator of an opensource project

David Starr

  • Marcus

    Hey David,

    This is an awesome idea and i will follow this project.

  • chris

    Would be cool if someone would donate a server or money for an EC2 instance to host a global WCF service. We could have a realtime Silverlight UI on the web.

  • http://elegantcode.com Tony Rasa

    Massively Multiplayer RoboDojo.

  • http://elegantcode.com David Starr

    In all seriousness, I considered that architecture, but I think the lag time would be prohibitive. Now, obviously there are people who know how to do this better than I do. Quake exists, after all.

    Game interaction is an EXTREMELY chatty service problem.

  • http://elegantcode.com Tony Rasa

    All players upload their chosen warriors to The Arena (hosted up on the server). When everybody is ready, a match is begun (think Halo, or Gears of War – xbox live matches). All the “fighting” occurs on the server, which is broadcasting updates to the clients watching (so lag isn’t a factor). Store results of each match so you can display ‘ladders’ or whatever. If I’m understanding this right, the ‘bots are autononmous so we don’t need to worry about users submitting bot actions and responding to input and all that.

    waaaay easier to state the problem then do it of course – first major issue, need to use some of that famous .NET Code Access Security so that somebody doesn’t upload a ‘bot that sends spam or crashes the server or whatever.

    But hey, the basic idea should be straightforward enough..

blog comments powered by Disqus