Fun Stuff · Games · The Legend of Zelda: Black Crown · XNA Framework

The Legend of Zelda: Black Crown featured!

My little fan game project The Legend of Zelda: Black Crown is the Featured Project over at Zelda Fan Game Central! \o/ You can discuss it on the Forum Thread or take a look at the Wiki Entry.

For any of you that have missed the game, here are some screenshots and the download link. It requires Windows, Microsoft .NET Framework 4.6.1 ( and a GPU that supports Shader Model 2.0. Please poke me if you have any feedback or ideas on how to improve the game!

Don’t forget to use the Zelda Updater after installing the game to get the latest patch.



Games · The Legend of Zelda: Black Crown · XNA Framework

Zelda video’n shots

TLoZ: BC is a free offline hack and slash RPG, best compared to Diablo.
In BC you hunt for the best items, steadily improving your stats and talents!

Here are some new screenshots and a simple gameplay video.

Game Download

Don’t forget to get latest patch by using the Zelda Updater! Requires  Microsoft .NET Framework 4.6.1

Programming · Source Code

C# <3 Ruby

IronRuby allows you to get some of the freedom and expressiveness of Ruby in the .NET biz. world. Recently I’ve been using it as a simple game scripting language.

Warning: This post is a beginner tutorial on how to get started with hosting IronRuby inside your C# application.
C# loves Ruby
Step 1
Download the IronRuby binaries from Codeplex: Warning: As of writing this the IronRuby 1.1.3 installer won’t install the binaries.

Step 2
Add references to IronRuby.dll, Microsoft.Csharp.dll and Microsoft.Scripting.dll to your project.
Step 3
ScriptEngine and ScriptScope are the key classes of the Dynamic Language Runtime that allow us to run Ruby code: (Download Tutorial Source Code – Rename to Zip)

// Tutorial 1:

// Initiate the main object that drives IronRuby:
var engine = IronRuby.Ruby.CreateEngine();

// And here goes the magic:
engine.Execute( "puts 'Meow, from Ruby!'" );
// Tutorial 2:
var engine = IronRuby.Ruby.CreateEngine();

// ScriptScopes allow you to capture variables and methods
// within a specific non-global scope.
ScriptScope scope = engine.CreateScope();

// The ScriptScope API allows us to easily set variables
// from .NET:
scope.SetVariable( "score", 10 );

// You can also use Ruby to set variables:
engine.Execute( "max_score = 10", scope );

// Let us access the variables now. Note the usage of "%Q/ /"
// as a replacement of " " in our Ruby code.
engine.Execute( "puts %Q/Your score is #{score} of #{max_score}!/", scope );

Step 4 – Domain Specific Languages
We can ‘teach’ our scripts a set of specialized methods that make it easy to interact with the problem domain. With the help of Ruby’s expressiveness our scripts will look more like a custom language that is focused on the target domain. See Teta on github for a text adventure that is build around a Ruby DSL.

# Here's a silly example from my Zelda fangame:
on_time_changed do |time|
  if time == 'DayBegan' then
    if roll_1_in 100 then
      spawn_item 'Ruby1'

      after_seconds 2 do
         fairy_says "Oh, what's that? Lucky!"
// Tutorial 3 - how to get started with a Ruby DSL from C#:
var engine = IronRuby.Ruby.CreateEngine();
var scope = engine.CreateScope();

string domain =
        class Universe
            attr_accessor :underlying_theory
            attr_accessor :groups

            def initialize()
                @groups = []

            def to_s
                %Q/Universe based on #{underlying_theory} is filled with: #{groups}./

        class Group
            attr_accessor :name
            attr_accessor :galaxies

            def initialize()
                @galaxies = []

        class Galaxy
            attr_accessor :name

// Now teach it about our domain. You could use normal C# classes too.
// But those might be at times be more awkward to access from within Ruby.
engine.Execute( domain, scope );

string dsl =
        # DSL:
        def universe(hash)
            u = @@current_u =
            u.underlying_theory = hash[:based_on]

            yield if block_given?

        def group(named)
            g = @@currrent_g =
   = named

            yield if block_given?
            @@current_u.groups << g

        def galaxy(named)
            g =
   = named

            @@currrent_g.galaxies << g

// 'Enable' our tiny DSL:
engine.Execute( dsl, scope );

// And lets use it to create some universes:
string ruby =
        mt = universe based_on: 'M-Theory' do
            group 'Local group' do
                galaxy 'Milky Way'
                galaxy 'Andromeda Galaxy'
                galaxy 'Triangulum Galaxy'

            group 'Virgo Cluster'
            group 'Centaurus Supercluster'

        hlt = universe based_on: 'HL-Theory' do
            group 'Black Mesa' do
                galaxy 'On a Rail '
                galaxy 'Questionable Ethics'
                galaxy 'Lambda Core'
                galaxy 'Nihilanth'

        et = universe based_on: 'Empty-World Theory'
        [mt, hlt, et]

// ScriptEngine.Execute returns our list of universes as the result of the ruby code:
dynamic universes = engine.Execute( ruby, scope );

foreach( dynamic universe in universes )
    Console.WriteLine( universe );

Step 5 – Miscellaneous Notes
I encourage you to use a Test/Specification Driven Development style when working with your Ruby scripts (It is imho a must with dynamic languages). Personally I can’t yet rate how easy/hard it is to get something like RSpec running with IronRuby and loose scripts.

The outside image of IronRuby looks a bit shady at the moment. The official website doesn’t link to the newest version, and all in all the project is fragmentted over too many different domains. It doesn’t help that the installer and Visual Studio integration (v 1.1.3) is somewhat bugged. From the inside we’ve got a very solid product that can get you some of the Ruby love inside the .NET world. Thanks to the open source community on continuing work on IronRuby and IronPython! <3

::Edit Step 6 – Tip: Compile from Source ::Edit (30.06.2012)
To get the best experience, until the IronRuby team decides to release a new version, you should compile IronRuby from source for your target framework. This has shown to give me a great performance increase. Great work!

Step 7 – Additional Resources
IronRuby Tutorial Source Code – Rename to Zip

IronRuby on Codeplex
IronRuby Mailing List
IronRuby Source Code
IronRuby Issue Tracker

Design Patterns & Best Practices · Programming

Code: Abstract Unit of Work

Today I’ve been tinkering about how to best implement the
Unit of Work/Repository patterns at the client (service)-side.

Warning! This blog post contains experimental source code!

What I want:
1. Simple to use. Usage is easy to explain.
2. Doesn’t leak the underlying data access framework.
3. Supports transactions.
4. Supports multiple parallel units of work when required.
5. Manages the session/context scope for me.
Not quite sure whether I need nested UoWs.

Here is what I have come up so far. I’ll update this post once I figure out something new about all of this.

// Scoped unit of work:
// 1. Quite simple
// 2. Repositories use the currently active UoW
// 3. Doesn't support multiple UoWs to be active
// 4. Using block scopes the current session/object context
// 5. Repositories are injected using the constructor
using( UnitOfWork.Start() )
   var user = this.userRepository.GetUserByName( "Paul" );
   var skill = this.skillRepository.GetSkillByName( "Ruby" );
   user.Award( skill );

// Scoped UoW, that also starts a new transaction:
// When the UoW is disposed it will be rolled-back
// unless it has been committed.
using( var uow = UnitOfWork.Start( transaction: true ) )
   var user = this.userRepository.GetUserByName( "Paul" );
   var skill = this.skillRepository.GetSkillByName( "Ruby" );
   user.Award( skill );

If the current Unit of Work is marked to be unique for each thread (ThreadStaticAttribute) it can safely handle multiple ‘requests’ at the same time. No need for any >special case< handling.

Thanks to @pragmatrix for pointing this out on Twitter. :)

Fun Stuff · Games · The Legend of Zelda: Black Crown

New Release of Zelda – Black Crown: Updater!

And another update to my Zelda fan-game. Besides many new items, a new boss and more – the greatest new addition is an Updater / Patcher which allows you to get the very latest version without re-downloading the full game. Enjoy!
Zelda Updater / Patcher
For the people that are interested how I’ve implemented the Updater / Patcher:
When I decide to release a new version I run custom “Release Packager Tool”.

This tool creates, amongst other things, a manifest file that stores the date and time every file of the game has been modified. This manifest, including, all other files is then uploaded to my webspace. Now when you start the Updater / Patcher it downloads that manifest file and checks what other files need be updated by downloading them too.

To make the patcher itself update-able I am using a stub executable that runs the actual patcher executable in a separate AppDomain. That AppDomain has Shadow Copying of Files enabled. ShadowCopyFiles = “true” has the effect that the assembly and its dependencies are copied into a temporary folder upon execution -> as such the original patcher files are not locked and can be replaced.

var domainSetup = new AppDomainSetup() {
    ShadowCopyFiles = &quot;true&quot;

var domain = AppDomain.CreateDomain(
    &quot;Update Domain&quot;,

domain.ExecuteAssembly( updaterAssembly );