My Code Kata–A Solution Kata

There are many developers and coders out there who like to do code Kata’s to keep their coding ability up to scratch and to practice their skills. I think it is a good idea.

While I like the concept, I find them dead boring and of minimal purpose. Yes, they serve to hone your skills but that’s about it. They are often quite abstract, in that they usually focus on a small problem set requiring specific solutions. It is fair enough as that is how they are designed but again, I find them quite boring.

What I personally like to do is go for something a little larger and a little more fun. It takes a little more time and is not as easily executed as a kata though, but it services the same purposes from a practice perspective and allows me to continue to solve some problems that are not directly part of the initial goal. This means I can cover a broader learning range and have a bit more fun. If I am lucky, sometimes they even end up being useful tools.

With that in mind, I thought I’d share my current ‘kata’. It is not really a code kata as it is too big. I prefer to think of it as a ‘solution kata’.

The code is on bitbucket here.

What I wanted to do was create a kind of simplistic virtual world where I can create a player, or a class, stuff it into the world, and see if it survives, and can navigate its way to the exit.

Requirements were pretty simple:

1. Must be able to define a map to describe the world using simple X,Y co-ordinates. Z co-ordinates as well if you feel like getting clever.
2. Should have the concept of entrances, exists, solid blocks, and potentially other materials (again if you want to get clever).
3. A coder should be able to easily write a class which will act as an inhabitant of the world.
4. An inhabitant will receive stimulus from the world in the form of surrounding environment and be able to make a decision on action which it passes back to the ‘world’ for processing.
5. At a minimum, an inhabitant will have sight and speed characteristics which determine how far they can ‘see’ in the world, and how fast they can move.
6. Coders who write a really bad ‘inhabitant’ should not adversely affect the rest of world.
7. Should allow multiple inhabitants in the world.

So that was the solution I set out to act as a practice solution and a little bit of fun. It had some interesting problems to solve and I figured, if it turned out ok, I could potentially use this as a ‘developer test’ for interviews. Ask a potential coder to write a class for an inhabitant. Show the coder the map they will navigate, but also mention that we will use their code to navigate a map they have not yet seen and a little more complex.

I have been playing with solution for a short time now and have it working in basic concepts. Below is a screen shot using a very basic console visualiser that shows the map, boundaries, blocks, entrance, exit and players/inhabitants.

The yellow asterisks ‘*’ are the players, green ‘O’ the entrance, purple ‘^’ the exit, maroon/browny ‘#’ are solid blocks.

The players can move around at different speeds, knock into each others, and make directional movement decisions based on what they see and who is around them. It has been quite fun to write and it is also quite fun to develop different players to inject into the world.

The code below shows a really simple implementation of an inhabitant that can work out what to do based on stimulus from the world. It is pretty simple and just tries to move in some direction if there is nothing blocking the path.

public class TestPlayer:LivingEntity
{
    public TestPlayer()
    {
        Name = "Beta Boy";
        LifeKey = Guid.NewGuid();
    }
    public override ActionResult DecideActionToPerform(EcoDev.Core.Common.Actions.ActionContext actionContext)
    {
        try
        {
            var action = new MovementAction();

            // move forward if we can
            if (actionContext.Position.ForwardFacingPositions.Length > 0)
            {
                if (CheckAccessibilityOfMapBlock(actionContext.Position.ForwardFacingPositions[0]))
                {
                    action.DirectionToMove = MovementDirection.Forward;
                    return action;
                }
            }
            if (actionContext.Position.LeftFacingPositions.Length > 0)
            {
                if (CheckAccessibilityOfMapBlock(actionContext.Position.LeftFacingPositions[0]))
                {
                    action.DirectionToMove = MovementDirection.Left;
                    return action;
                }
            }
            if (actionContext.Position.RearFacingPositions.Length > 0)
            {
                if (CheckAccessibilityOfMapBlock(actionContext.Position.RearFacingPositions[0]))
                {
                    action.DirectionToMove = MovementDirection.Back;
                    return action;
                }
            }
            if (actionContext.Position.RightFacingPositions.Length > 0)
            {
                if (CheckAccessibilityOfMapBlock(actionContext.Position.RightFacingPositions[0]))
                {
                    action.DirectionToMove = MovementDirection.Right;
                    return action;
                }
            }

            return action;
        }
        catch (Exception ex)
        {
            World.WriteDebugInformation("Player: "+ Name, string.Format("Player Generated exception: {0}",ex.Message));
            throw ex;
        }
    }

    private bool CheckAccessibilityOfMapBlock(MapBlock block)
    {
        if (block == null || block.Accessibility == MapBlockAccessibility.AllowEntry || block.Accessibility == MapBlockAccessibility.AllowExit || block.Accessibility == MapBlockAccessibility.AllowPotentialEntry)
        {
            return true;
        }
        return false;
    }

}

It is simple and it seems to work well. The world implementation itself decides the stimulus context that is passed to he inhabitant to make an action decision. All movement is carried out on separate threads and timed appropriately to be as fair as possible and to cater for additional skills such as speed, and eventually maybe stamina, strength, with actions like fighting. It is pretty fun to make up random maps and see how your inhabitant does.

You can download the code from here.

Along the way I have played with parallel extensions to make the compute intensive stuff spread across all cores, had to heavily factor in visibility of methods and properties so design of classes was paramount, work out movement algorithms that play fairly in the world and properly favour the players with higher abilities, as well as a host of other issues.

So that is my ‘solution kata’.

If I keep going with it, I may develop a web interface for it where people can upload assemblies and watch their player within a web browser visualiser and maybe even a map designer.

What do you do to keep the fires burning?