Archive for April 2012

Why the Easter bunny will not be visiting this year.

April 23, 2012



How to map a NHibernate <MAP> tag in FluentNhibernate?

April 21, 2012


One of the common problems experienced when using Fluent NHibernate is how to convert a particular mapping, previously in HBM file format, to a Fluent NHibernate syntax.

In this tutorial example I will model an Entity to Entity-Settings structure. Typically used to stored additional information on the entity when you don’t want to designate a particular column to do the job. So we provide an open structure in the form of a key-value pair table.

In classic NHibernate HBM files you would use a <MAP> element to represent this relationship. However in Fluent NHibernate it’s mapped slightly differently.


  • NHibernate 3.2.400
  • FluentNHibernate


This is the database structure we will deal with:

I’m intentionally keeping it simple. We have a Customer table that holds basic customer information and a CustomerSettings table which hold key-value pair string information – in other words it holds whatever we want that fits the structure of a key-value pair. I also want any changes to the Customer settings to be saved when I persist the Customer object.

My classes look as follows:

    public class Customer
        public Customer()
            Settings = new Dictionary();

        public virtual int Id { get; set; }
        public virtual string Name { get; set; }
        public virtual string Surname { get; set; }
        public virtual IDictionary Settings { get; set; }

The mapping is actually really simple but it took forever to figure out how to do it properly. So the classmap looks like so:

    public class CustomerMap : ClassMap
        public CustomerMap()
            Id(x => x.Id).Not.Nullable().GeneratedBy.Identity();
            Map(x => x.Name).Not.Nullable().Length(50);
            Map(x => x.Surname).Not.Nullable().Length(50);

            HasMany(x => x.Settings)
                index => index.Column("`Key`").Type(),
                element => element.Column("Value").Type()

And that’s it! Now all you need to do is a basic NHibernate save, with your customer information and settings and the settings will also save in your cascade:


            var customer = new Customer
                            Name    = "Joe",
                            Surname = "Blogs"
            customer.Settings.Add("Age", "30");
            customer.Settings.Add("Country", "ZA");

            using (var session = DatabaseContext.SessionFactory.OpenSession())
                using (var tx = session.BeginTransaction())

What if Star Wars was a FPS?

April 3, 2012

star wars fps

How to hire a software developer?

April 2, 2012

Hiring a developer is a like hiring a specialist – you need the knowledge and you need to take the time.

Most of the people interviewing these days are unqualified to interview and form a fair assessment of a developer. The last time I heard doctors chatting I had no idea what they were talking about. (Do I have something like that in my body?) As with any profession, I.T. people have their own lingo. We have our own words, terms, definitions and we have the infamous three-letter-acronym (TLA). All this combined with the tendency to alter or enhance the meaning of a word to communicate a particular concept makes “geek-speak” tremendously difficult to understand. Speaking “geek-speak” is therefore a prerequisite to effectively understanding a developer and their skill set.

 Interviewing a developer takes time. Approximately an hour should be enough. An interviewer needs to gain an understanding of the projects the developer’s done and the skills they have built. The only way to do this is to communicate. Many developers don’t like communication. Many feel that it’s an inefficient waste of their time. My suggestion: get over it. That person, should you hire them, will save you more time and hassle that the one hour interview would take. Not everything can be automated and besides, the only way you can get a feel for a person’s ability to express them self is to chat to them.

 The process at my company starts with a five question test, given to a recruiter, to weed out the unwanted. Recruiters can use these questions to evaluate candidates. The test shouldn’t take more than 5-10 minutes. As technical lead, I then review the answers to see HOW the questions were answered. This step is a time saver. Call it a first line of defence. The emphasis here is that the test should be brief. No sense in wasting anyone’s time.

 If I still like the look of a candidate I ask them to come in for an interview. It’s an informal, one-on-one, technical interview. Within 30-60 minutes a senior developer should be able to assess the candidate’s level. There is no quick fix. There are no theory exams that will assess a person’s effectiveness. Those only test the ability to retain knowledge and not how to implement it. Furthermore, tests do not reveal or take into account a person’s other skills – like the ability to string words together to form a sentence (mentioned earlier).

 One last vital ingredient I look for is passion. Is the developer passionate about their chosen profession? Do they know about any of the new technologies being released? Software development is a field in flux. It changes frequently and sometimes quite rapidly. Is the person being interviewed aware of their environment? Are they reading up on these new technologies?

 What development books are they reading? Nothing is more disheartening than a software developer who has no interest in enhancing his skill in his field. All decent developers are inherently curious. They find the I.T. field challenging and exciting. This is the type of passion I look for. Someone who is going to go the extra mile. Someone who is abreast of the latest developments. Someone to bring new ideas and concepts to the table. Ultimately someone who will enhance the development team.

 It all comes back to “taking the time”. There’s no easy way round this one. To truly gain an understanding of a developer you need to sit with them. Speak with them. Find out what makes them tick and how they communicate their thoughts. The last thing you want is to hire a brilliant antagonist, that regularly puts your team’s back up and has zero ability to convey their ideas. Despite their brilliance the team will be worse off for it. Meet. Chat. And more often than not the truth promptly reveals itself.

10 Things Learnt Running Prehysteria – Part 2

April 1, 2012

6. Marketing is a bitch
The Internet has opened up an incredible channel to market your game, but there is so much “interference” out there getting knowledge of your game’s existence to your target market is an art form in itself. Take part in forums. Find game sites that will publish your link. Advertise where you can. If you have a marketing budget, use it wisely. There are many shifty sites that offer marketing services that mean squat. Ultimately word of mouth is your best method of advertising. This relies largely on the hype of your game and the enthusiasm of your community.

7. Technology versus Story/Theme
What’s more important, technology or story/theme? The short answer is “yes”. Technology enables or imposes limits on your game, but story/theme defines it. Such is the nature of game design. You can spend all your time perfecting the technology. Creating a supersonic graphics engine and a mind-blowing user interface, but at the end of the day all you have is the “plumbing” of the game. It’s the equivalent of installing Windows XP on a computer but failing to install any applications. It may look great and have all the potential, but without any software applications no work can ultimately get done. Technology is vital for game design. It is your foundation. It enables your game, controls the mechanics and defines your limitations. However, that’s all it is. You still need to create the actual game. A game engine is just that. You still need to build the world, make it interesting and give it flavour.

8. Innovate
Keep the game fresh and exciting. Listen to player feedback as to whether you’re on track or not. An enthusiastic player is your best ally. In fact, some of our best ideas have come from players. An enthusiastic player wants to see your game succeed as much as you do. That being said, examine all suggestions carefully. Weigh up the pros and cons, development time and priorities. Not all advice is good advice. For Prehysteria we had a Priorities Document. Each meeting we’d take all the feedback we’d received that week, make a decision if the suggestion should live or die. And then prioritise.

9. You are your target market
Never forget this. You are your target market. There is a reason you went into game design – because you love games. Similarly there is a reason you chose to design a particular genre of game. When it comes to decisions or new features, try and put yourself in the shoes of a player. Imagine what you would enjoy in a game like the one you’re designing. What features would you require? What characteristics would enthuse you and what would cause you to turn away? Remember that you’re creating this game because this is the type of game you love. And if a new idea inspires you, there’s a good chance your players will get excited too.

10. Stop farting in the wind
You’ve got a game idea, so just do it (sorry Nike). Too many game designers talk their games into oblivion. Until you have a product that people can play, you have squat. Nada. Nothing. Okay, reckon I’ve made my point. You can’t get everything right first time around. There will be bug fixes. There will be tweaks. There will be decisions made and routes taken that you end up having to backtrack on. It’s all a part of the process. You won’t get it all right first time, but if your players are enthusiastic and having fun, then you’ve achieved success. After all, a game is made to be played. Hope to see you all online… biting and nipping… so come visit us at: Prehysteria – the coolest game since the ice age thawed.

10 Things Learnt Running Prehysteria – Part 1

April 1, 2012

Prehysteria was a web-based game where you play dinosaurs fighting and trying to out-evolve each other to be the top of the bone pile. A friend and I developed it and ran it successfully for about 2 years. It even made some money!

1. Have a plan
When my partner and I first sat down to write Prehysteria, we wrote out an action plan. Basically we covered high-concept topics like:

  • What should the game be like?
  • What are our goals and outcomes?
  • What challenges lie ahead and how can we overcome them?
  • How do we plan on attracting players?
  • What is the central theme and how do we reinforce this in the game?
  • How does the game run?
  • Is it turn-based or real time and how does this affect play?

It was a brainstorming session and our thoughts, in bullet form, formed this document. In the initial design sessions, we would actually bring this plan to the meetings and sit with it in front of us. Each major decision would either be required to fit into our plan or the plan would have to accommodate the change in direction. Nevertheless, having a written record kept us firmly focussed on our theme and goals.

2. Meet early and often
Meet at least once a week, at least until you’re over the initial development hump. This is a non-negotiable. The entire team must be there. Momentum is paramount in getting a game going, and organising regular meetings makes it more concrete and forces the involved parties to act. Physically meeting is putting aside dedicated time to analyze and explore the game concept. It reinforces the evolution of the game, ideas are generated, progress is monitored and perhaps most importantly, firm decisions are made. It’s easy to put down the phone after a telephonic meeting and continue playing your Xbox 360. But when you have a physical meeting it’s a different story. Even if only slightly, it can make all the difference.

3. Theme is everything
Your theme is essentially what makes your game special. In a world of 1001 medieval, space colonization and pirate clones, Prehysteria was to be something out of the ordinary. There was nothing similar to Prehysteria on the market. And playing prehistoric dinosaurs with attitude is cool. Certainly there were other browser-based games on the Internet, but that is merely a technology platform. The theme is what made Prehysteria unique. My partner and I discussed our theme and how to develop it. Thereafter, every decision had to fit into theme. Fortunately Prehysteria is a quirky game so we had loose boundaries. (I.e. Who says dinosaurs can’t build walks and tree houses?) I cannot stress theme more. If you break your theme and become something generic, then you’ve lost the magic.

4. You can’t please everyone
No matter what you do and no matter how hard you try, someone will always get upset with you for some reason. Sometimes this is due to a misunderstanding. To alleviate this we established a forum, in addition to online help, and Frequently Asked Questions (FAQ). Involve your player base and local development community in helping to build the game. These people are gamers or game designers and are a rich (and often educated) source of feedback. Have an “open door” policy. Listen to feedback. Reply promptly and patiently answer questions. However, some people are just moaners and there’s no pleasing them. For example, Prehysteria offers the four basic races for free. The four advanced races are on a par, but additionally have a special ability. We took care not to allow this special ability to give the advanced races an overwhelming advantage. Despite this a player complained that $2 a month was an unacceptable fee to play an advanced race. I explained that there is no material advantage and even pointed out that the top ranked players were playing basic races. This player was still not happy. Bottom line, he wanted the game, the entire game, for free. Which brings me to my next point…

5. It is not a popularity contest
You can’t please everyone all the time and you will piss some people off. Running a game is not a popularity contest. You will need to make some difficult decisions. Make your decisions based on the improvement of the game as a whole. If you make your decisions to keep a player happy, but the logic of your decision is flawed, your game will be worse off for it. Never forget, you are a wizard. And therefore you must act like one. Enforce where necessary, like cracking down harshly on cheating. At the end of the day be reasonable. Players want to have fun and they will as long as the rules are enforced equitably.

Continued in Part 2