What is Fluent?

Fluent interfaces allow game designers to write more fluid and readable code.  Through the use of method chaining, English like sentences can be written to express game functionality.  Fluent interfaces can be implemented in any object oriented programming language.  Below is an example of a line in the game design document, a standard implementation example and a fluent example:

Game Design Document:

“Do 5 damage to all enemy tanks within range 2 of an entity”

Standard Example:

foreach( var unit in player.UnitsWithinRange(2) )
{
    if(!unit.IsType(Enemy) || !unit.IsType(Tank))
        continue;

    unit.Damage(5);
}

Fluent Example:

player.UnitsWithinRange(2)
  .Where(UnitIs.Enemy)
  .Where(UnitIs.Tank)
  .DoDamage(5);

This fluent example closely matches the design document and is easier to read.  It also uses less language constructs like loops and conditions.  With Intellisense, designers are given a context sensitive list of operations they can perform.  Designers simply build up the expression that describes the original line in the game design document they are implementing.

How to implement Fluent Interfaces

Fluent interfaces are actually quite easy to implement.  Objects expose methods that return a reference to the object itself allowing method chaining.  The best way to describe this is by showing the implementation required for the examples above.

First, we create the object we will be working on (I’ve called it UnitsList in my examples).  This gives us the first part of the fluent call (Get.UnitsWithinRange(2)).

public class ScriptObject
{
    UnitsList UnitsWithinRange(int range)
    {
        return new UnitsList(range);
    }
}

The UnitsList object must have a set of methods that return references to the object itself allowing method chanining:

public class UnitsList
{
    public UnitsList Where(UnitIs condition)
    {
        this.conditions.Add(condition);
        return this;
    }

The fluent expressions are terminated by returning void from a function.  This lets the designer know they have no more options and often that the actual operation will be performed.

public class UnitsList
{
    public void DoDamage(int damage)
    {
        foreach( var unit in this.mainUnit.UnitsWithinRange(range) )
        {
            if(!PassesConditions(unit))
                continue;

            unit.Damage(damage);
        }
    }

    private bool PassesConditions(Unit unit)
    {
        foreach( var condition in conditions)
        {
            if(!unit.IsType(condition))
                return false;
        }
        return true;
    }
}

There are a couple of key things to notice:

1. This last code example looks a lot like the original standard example
2. A lot more “engine” code is required to setup a fluent interface than a standard interface

So, in effect, an extra layer of abstraction is being placed over the original code.  Rather than designers working on loops and conditions, they are calling (well named) methods.  This makes their life a lot easier and simplifies maintenance of their gameplay code.  It pushes the burden of maintenance down from the gameplay to the engine level and therefore on programmers, who are better suited to maintaining code.  If there is a change in the engine or game, this extra level of abstraction serves to buffer the designers and reduce the amount of code that needs to be written.

Good Interface Design

Care needs to be taken when designing the interfaces and exposing methods to the designers.  Rather than exposing all functions off a single object my recommendation is to define different objects for different situations.  The example provided starts with the player and retrieves a list of units around it.  Filters are then added before the final operation is performed on the resulting list.  By limiting the methods available to the designer to simple filters there is little risk of them making a mistake.  Also, the fact that the “DoDamage” function returns void stops them from chaining anything further.

Other Syntaxes

One small point is that designers can structure their fluent “sentences” in any way they please:

player.UnitsWithinRange(2).Where(UnitIs.Enemy).Where(UnitIs.Tank).DoDamage(5);

player.UnitsWithinRange(2)
  .Where(UnitIs.Enemy)
  .Where(UnitIs.Tank)
  .DoDamage(5);

There is no difference between the above two examples.  It’s simply a matter of coding style preferred by the writer.

Conclusion

What do you think of Fluent Interfaces?  Have you used a similar technique before?  Do you think the extra engine code and maintenance is too much hassle for the gain in clarity to designers?

As an experiment, try exposing a small set of functionality through a fluent interface and see whether your designers like working with it.

Rapid Application Development

The primary reason for using C# is because coding in it is more productive than any other language I’ve used.  Language features like interfaces, generics and delegates make it a cleaner language than C++.  Development practices such as unit testing and dependency injection are also easier to use in C#.  This clarity translates to more readable code and less bugs, particularly when working with a larger or younger team of developers.

The second productivity gain comes from having access to the .NET framework.  From its XML handling for configuration, to built-in math libraries, many of the core functions you can think of are taken care of.  This saves you writing the code yourself and lets a reliable, tested framework do the heavy lifting in areas you don’t want to spend your time.

C# lets you focus on making a game rather than writing an engine, or learning someone else’s engine.

Unified Code – Client, Server, Tools, Scripting

• Server – I’m writing the server architecture (matchmaking, leaderboard, etc) in ASP.NET and C#.  This lets me share libraries between the client and server and makes calling web services from the client a breeze.
• Tools – All our tools are also written in C#.  This means that our tools can have rendering within them, can reuse libraries and simplifies the creation of in-game tools.
• Scripting – As I’ve mentioned in a previous article, I’m using C# for the scripting language in our game.

Better Software Development

C# supports better software development practices in a number of key ways:

• Refactoring Tools – Visual Studio has great refactoring support such as renaming identifiers and extracting methods & interfaces.
• Separation of Concerns – Splitting a project into separate .dll’s is trivial in C#.  This helps with maintainability and encapsulation of code and encourages good separation of concerns.
• Unit Testing – C# has great support for unit testing through NUnit or MSTest.  As I’ve previously discussed, unit testing fits perfectly in certain areas of game development.  The easier unit testing is to achieve, the more people are likely to adopt it.

In-Game Web Browser

As part of the game engine we are developing we decided all interaction with the server for matchmaking would be through http/html.  This reduces the need for creating such a complex in-game UI system and simplifies communication with the server.  The .NET web browser control is extremely easy to use and communication between the browser and host application (the game) is a simple.

Run-time isn’t too large

I’m currently targeting the .NET 2 framework.  This put’s the footprint at around 20MB.  The latest .NET frameworks (3.5 and 4) both have a “client profile”.  This is a subset of the .NET framework that comes in at about 30MB.  My plan is to use the .NET 4 client profile once it is released as it gives me access to all the latest language features (Linq, lambda expressions, dynamic objects, etc).  MS is currently planning to make .NET 4 client profile a windows update meaning the .NET framework will finally become (almost) ubiquitous among PC’s running windows.

Negatives

There are obvious drawbacks to using C# for a commercial game engine which we took into consideration when making our decisions.

• Not Cross Platform – While engines like Unity have proven that C# can run on multiple platforms, this does not occur out of the box.  As we’re targeting PC’s exclusively for our first release this was not a problem.
• Xbox run-time not great – C# can run on the Xbox as part of XNA game studio, however the run-time performance isn’t great.  Garbage collection is a particular problem which requires refactoring code to achieve acceptable frame rates.
• Harder to use C++ libraries – Linking to straight C++ (non-COM) libraries is not trivial like it is connecting to other .NET libraries.  Extra time is required if there is a requirement to use existing libraries such as RakNet.
• Some performance concerns – C# does have some performance concerns with garbage collection and certain double math operations.  However the algorithmic gains received from working with such a great language outweigh the small performance issues in certain areas.  As with any language, bad code will run slow.

Conclusion

C# is a great language.  I thoroughly enjoy coding for it and I find it makes me more productive when creating games.  I plan to release my MVC engine in the future as an open source project.  Until then, I’m continuing to develop our engine and I’ll keep you up to date with the progress.

For reference, here are a couple of commercial games using C#:

Arena Wars - http://www.arenawars.net

AI War Fleet Command – http://www.arcengames.com/aiwar_features.php

Sacraboar – http://www.sacraboar.com

Have you used C# for game development?  Are you sick of chasing memory leaks and crashes in your C++ applications?  Do you think game developers will move on from C++ now or in the future?

What is Perfect Code?

My definition for perfect code is “Code that solves a problem, without bugs, in an optimal way”.  This has slight ambiguities, so I’ll break it down.

1.  Solves a problem

The whole idea of writing the code is to solve some non-trivial problem.  To do this perfectly, the solution must be solved for all possible cases.

2.  Without bugs

The code needs to perform the required task correctly in all situations.  This includes valid and invalid input and situations.

3. In an optimal way

I come from a game development background and therefore performance is important.  Depending on the situation, optimal will take on a different meaning.  For games, this might mean that the entire game loop must run at a minimum of 30 frames per second.  For a banking program this might mean that a transaction takes less than 10 second to complete.

Is Perfect Code Possible?

The simple answer is, yes.  Code can be written that perfectly solves a problem, without bugs and can therefore be classed as perfect.  Unlike many professions, what we create is never fully “set in stone”.  Code can change at any level, from fixing a broken statement to re-architecting an entire application.  When the three requirements below are met, developers are in the best possible position to write perfect code.

The Requirements (aka What’s Needed To Write Perfect Code)

To expect perfect code from developers, the following 3 requirements must be met:

1. Thorough Domain Knowledge
2. Enough Time
3. Great Developers

Just think about each of these for a minute before continuing.  If you’re a developer, do you meet all three requirements in your current position?  If not, which ones don’t you meet, and why?  Feel free to post a comment.

Below I’ll break down these requirements and show two graphs.  One for the amount of return gained for levels of input into each requirement.  The second graph shows the cost of achieving a set level of quality.

Each requirement also has a limiting factor.  This is the top reasons why developers often write imperfect code.

1. Thorough Domain Knowledge

Developers must have a good grasp on the subject matter they are to be working on.  If you’re making a driving game, you need to know the way cars handle, what torque is and why a blowoff valve sounds so cool.  If you’re writing an accounting program then you need to be boring, and therefore understand accounting (or is it the other way around).  You also need to know about debits and credits and the difference between cash flow and capital.

Moving from no domain knowledge to a simple understanding helps a lot when striving for perfect code.  After this point, learning more about the domain helps, however the next big leap in code quality comes from having an intimate understanding of the domain (the small mark on the x-axis in the graph below).

The following graphs show the level of quality gained by increasing domain knowledge and the cost required to achieve this.

Limiting Factor:

It’s difficult to find someone with expert domain knowledge and takes time for people to learn.  Also, many developers simply won’t want gain an intimate understanding of the domain.  This can be solved by having domain experts work closely with developers.  See Domain Driven Design by Eric Evans for an in depth discussion on this topic.

2. Enough Time

Most projects I’ve seen rarely have enough time.  Time is critical for writing perfect code as it unlocks the following factors:

1. Hacks/quick fixes won’t be written
2. There will be little to no overtime
3. Peer reviews and pair programming become possible
4. Work can be designed rather than simply hacked together
5. Work can be thoroughly tested

The mark on this graph shows where “enough time” is given for a project.  If enough time is given, the quality in code jumps substantially.  After this time though, there is a point of diminishing return as having developers continue to work on the project won’t return great gains.

One point to note is that if the amount of time given to developers changes mid project, all bets are off.

Limiting Factor:

Money is the major limiting factor with giving developers more time.  However it isn’t the only one.  Competitors can bring products out before yours or customers may have strict deadlines that you must meet.  Also, developers don’t live forever, and rarely life in the same job forever.  The longer a project runs, the more likely you are to lose developers and therefore have to retrain and rehire more, at great cost.

3. Great Developers

I agree with the concept that good developers are 10 times more efficient than average developers.  Joel Spolsky put this perfectly when he said “Five Antonio Salieris won’t produce Mozart’s Requiem.” For those that haven’t seen Amadeus, he’s saying that the order of magnitude difference between good and great developers is staggering.  Unfortunately, you just can’t get the quality you need unless you have great developers; it’s as simple as that.

The mark on this graph show’s the level of developer skills required to write perfect code.  About the top 5-10% of developers fit into this bracket.  The good news is that the difference in cost between an average developer and a great isn’t the same order of magnitude higher.

Limiting Factor:

Great developers are hard to find!  With companies like Microsoft and Google paying crazy amounts of money, the top tier will often work for them.  However the good news is that great developers can be trained and in the right environment, so long as you have smart people you can often turn them into great developers if they (and you) care enough about software development.

Do We Want Perfect Code?

That may seem like a simple question, however in reality it isn’t.  In a vacuum, for most developers that question is rhetorical.  Of course we want to write perfect code, we take pride in our work and we strive for excellence.  However, when you look at the cost involved in achieving perfect code it is not always a requirement.

This is something we must take seriously when writing software as the realities of business mean that more often than not, imperfect code is exactly what the business needs.  It’s better to ship code with issues than to not ship code at all.

Conclusion

I’m sure I’ve said at least a few controversial things, so please comment and/or email me to continue the discussion.  I continue to strive for perfect code in my life, and whether I’ll ever reach it is irrelevant.  I’ll leave you with a quote from one of my favourite movies:

“There are no perfect men in this world, only perfect intentions.”

1. Make many mistakes, but only once

I thought I’d start with the controversial one. On the surface it would seem better to say that good programmers shouldn’t make mistakes at all, however I believe this is not the case. I first heard this idea used at flight school with the Australian Air Force where my instructor told me that fighter pilots could make as many mistakes as they liked so long as they didn’t make the same one twice. He used the analogy of a large bag which holds all the mistakes you’ll make in your life. He said to make sure every time you make a mistake you take it out of the bag, sloppy people then just put it back in and wait till they make it again. Successful people take it out, analyse it, and make sure they completely understand where it came from and what they can do to stop it in the future. This is some of the best advice I’ve received over the years, and those that follow it often turn out to be better programmers. Everyone’s deleted a file from the build machine by mistake or incorrectly integrated a file before checking it in removing previous work done to it. The important thing is that we stop and realise what we’ve done wrong and make sure we understand the problem, discuss it with others if need be, and file it away to make sure we remember it in the future. This is particularly important for game programmers as we have short schedules, complex work and an unforgiving customer base. In a business app a mistake may simply mean a debit or credit isn’t bolded correctly, but for us it may mean Fatal1ty (Johnatahn Wendel) may not go quite high enough with a rocket jump and lose a match. Or more likely, 40% of your gamers will encounter the problem tell all their friends your game sucks because rocket jumps are inconsistent and you’ll lose a lot of sales. Either way we’re only human, so making mistakes is fine, so long as we learn and only make them once.

2. Actually Play games

I was both disgusted and disturbed when I finally made it into the industry and found out just how many game developers just don’t play games. They may play the game their actually making but once work’s over they’ll all shuffle off home, watch TV or do some other inane activity that doesn’t involve gaming. I often find the best game developers are those that go by the motto ‘We makes games we’d want to play’. Even if your game development house doesn’t believe in something like this, perhaps you do, and I implore you to do so. How can people that don’t even play games come close to this level of devotion? I don’t believe they can. Also fitting in with this quality is playing a wide range of games. Part of my dislike for World of Warcraft is the fact it’s stagnating the gaming-life of a lot of players. I’m all for people being passionate about a game, but I think gamers, and especially game programmers need to keep an eye on all the different games that are out to make sure they don’t get too focused on a particular game or style, homogenising the games they make.

3. Be fluent in the language they’re using

This is kind of a no-brainer, but notice I used the word ‘fluent’. I believe there are a number of levels of skill a programmer can have in a particular language and with software development practices in general. To paraphrase, being fluent means you can think about any concept that’s in general use in games today and given enough time you can create a program that will perform that task. The created program should naturally be maintainable, robust, correct and optimized. When I began game programming I wasn’t fluent in C++ and this showed. It took me a number of years of coding in my spare time and then full-time for a while before I reached that level and it has completely changed the way I work. Reaching this goal doesn’t take countless years, but it does take dedication and passion (but that’s for point 5).

4. Ready to learns from others

Being fluent in a language doesn’t mean you’re a perfect programmer, in fact I think there are quite a few levels above ‘fluent’. These levels are for another article; however the important point is that chances are you don’t know everything there is about game development, nor about software development in general. I’ll be the first to admit there’s far more I don’t know than I do, so the important thing here is that you are willing to learn from others. Even if you are the technical director of a company, or John Carmack himself, I believe that you will be able to learn something from nearly any other competent programmer out there. The great thing about being human is that we are all shaped by our own lives, so no two people are the same. Even if you’re the greatest AI programmer known to man and you could make Skynet if you just quit work and put your mind to it, a student fresh out of school will have a different experience with programming and may show you a technique that he’s just come up with for making sure your robots don’t turn on mankind and destroy the world. I said at the beginning of this article that some of these qualities apply to life in general, and this is one of them. I believe that if you go through life listening to people and learning from them, and their mistakes, you’ll come out a better person at the other end.

5. Passionate about software development

I touched on this in #3 as I think it’s the most important of the qualities. You really have to be passionate if you want to be able to become fluent in both the language your games are written in and in general game and software development practices. If you take game programming as just a job then you’re not going to be able to stick it out for the long term and make awesome games. I’ve seen people who are excellent C coders who want to make games as it’s a bit of a challenge to them. They write some awesome code, but it just seems to be missing something, that intangible ‘it’ that makes certain games awesome and others just boring. From what I’ve seen, for most people this passion is born out of a passion for playing games. As I was growing up I lived and breathed games, reading every magazine I could and visiting the hyperactive website every day to find out any news or secrets I could. As I became older I started having ideas for how to make the games I was playing better and ideas for entirely new games. I think passion is the single biggest factor that helps me to move forward and try and become the best games developer I can. This isn’t something you can learn or read books to attain, it’s just something that you either have, or you don’t. So whether you’re in the games industry or hoping to make it one day, please remember that passion for the games you play and make is your strongest quality. Make sure you nurture it by continuing to play and love games and never shut out the little part of your brain that is constantly coming up with ways to better the industry and drive it forward into the future.