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.

Leverage existing technology

Game developers have a bad habit of re-inventing the wheel.  The easiest way to run a game into the ground is to spend all our time creating new technology that already exists in the world.  We need to swallow our pride and use technology someone else has spent time and money creating.  Our core focus is making games, not game technology.  Let the experts handle the technology for us.

For programmers, there are countless engines we can take advantage of from Unity3D to Torque to UDK.  Project managers have access to countless tools to streamline the management process and keep them focussed on running a good team.

Learn to spend money where it’s needed.  Development time costs money.  If a problem has an off-the-shelf solution, we compare the cost of buying this to developing the solution in-house.  Nine times out of ten, it will be far cheaper to go with the former.

Aim Small

Projects always grow over time, sometimes uncontrollably.  We aim to start small, and keep a keen eye out for features that can be cut, checking the cost-to-benefit ratio of everything we do.  Ordering features by this ratio and cutting features from the bottom of the list when time runs out.

Feature creep is a killer on projects of all sizes.  By keeping milestones short we minimize the opportunities for us to diverge too far from our main goal.  If a feature grows in complexity beyond the scope of the initial design we take a step back and re-evaluate whether that feature is necessary given the new estimate on how long it will take to complete.

Build what you need, not what you think you need

Too many developers spend months working on the technology for their next game before starting the game itself.  Sometimes, they never make it to developing the game!  The most pragmatic solution to this is using someone else’s engine.  However, if we must create our own technology then we only create what we need right now.

A trap many developers fall into is thinking “we’ll be using this feature in the next five games, so it’s worth putting a lot of time into it now”.  If we do this for all our features, we won’t create our first game, let alone the next five.  My rule is that I don’t have enough information to make a generalised solution until I’ve implemented it at least a couple of times.

A great way of achieving these goals is adopting an agile development practice.  We are using Scrum for our current game which helps to keep us focussed on creating just enough to reach each sprint/milestone.

It’s done when people are happy to pay for it

A game is never going to be perfect.  I’m not advocating the release of buggy, broken games, but we do need to be practical when deciding whether our game is ready for release.  Creating constant playable builds is the best way to make sure the game is always fun and always meets a pre-determined quality bar set by the team.

It’s easy to fall into the trap of not wanting to release the game until it’s perfect.  After working on a game for months or years, it feels like your baby and you don’t want it out in the real world before it’s ready.  Being pragmatic means making the tough decision of deciding when the time is right to release the game even if you’re not 100% happy with it.

It is often better to cut a feature to give time to polish the existing gameplay which leads me to my next point…

“We’ll do that in version 2″

Release early and release often.  The best way to break the hit-driven nature of the games industry is to break the usual tradition of a big release with minimal updates after.  Plan to give away free (or cheap) “expansions” of core gameplay pushing the development of these features back until after initial release.  This has a number of key benefits:

• Begin to earn revenue sooner
• Drive the initial cost of the game down by releasing additional content in a paid or subscription format (e.g. DLC, in-game assets)
• Valuable feedback on the direction to take the game
• Focus on the bare minimum set of features to sell the game, minimizing feature creep
• Form a closer relationship with gamers by giving them constant updates

Use the highest level of abstraction possible

The higher the level of abstraction, the more time can be spent working on the game, rather than working on technology.  We are happy to give up some of the control over run-time performance for an increase in development speed.  Programmers can use a programming language like C# allowing them to spend time making a fun game, rather than managing memory and resources.  Artists can use a tool like ZBrush to create good looking models more easily and quickly.

Automate

Any repetitive day-to-day tasks should be automated by technology.  From build creation to the art pipeline.  We keep our time focussed on making a better game, not performing menial, repetitive tasks.  Programmers need to get in the mindset of spending a few hours per week working on tools to make everyone’s life better.  A programmer spending a few hours adding a new tool or updating an existing one can save weeks of work for the rest of the team.  Artists can learn batch operations in 3DSMax and Photoshop to help this process

Conclusion

This gives an insight into the ways we are being pragmatic in the development of our game.  By constantly focussing on the final product we make sure our time is spent on the most important tasks at all time.

How pragmatic are you in game development?  Do you have any other tips for minimizing cost and time?

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?

Advantages

There are a number of key advantages to using C# as a scripting language in your game engine.  I’ll list these first then describe how I achieve them.

• Designers use Visual Studio. Most designers are stuck using notepad (or similar) when writing their scripts.  With my technique, designers can use Visual Studio, gaining the full power of the IDE.  Including:
  • Intellisense. Letting them know what functions exist on all of the objects you’ve exposed, as well as documentation you’ve provided in code.
  • Compilation. Designers can compile their scripts while making changes to catch any compile-time problems.
  • Full Debugging Support. Another area lacking in most scripting languages is the debugging support.  Designers have access to all of Visual Studios debugging functionality to help them find and fix issues with their code.
• Run-Time Changes. Designers still have complete control to change their scripts at run-time.  Scripts can be reloaded automatically when files are changed, or (more likely) a “reset” button can be exposed in the game engine that allows them to reset the level and reload all scripts.
• Compile scripts into the executable for release. You have the option to use the scripts compiled into the executable if you prefer, protecting your files.
• Complete Access to game objects, or whatever you want designers to access. Designers are working in the same language you are developing in.  They have full access to the game objects or to a subset you decide on.  I use an interface and expose what I want them to use.
• FAST Run-time performance. The C# code is compiled not interpreted meaning the run-time performance is as good as the rest of the engine.  The slight performance bottleneck of reflecting the function can be removed by compiling scripts into executable if required.
• No Binding Required. Binding is automatic between the game engine and the script.  You don’t need to write any plumbing and exposing a new function is as easy as adding it to the engine.

How It Works

The setup is surprisingly easy, designers follow these steps and their up and running:

1. Add the script file to the Visual Studio project (preferably in its own directory)
2. Create an Init() function in the script class which will automatically be called by the engine
3. Create callbacks for events and implement the game logic
4. Run the game and make changes to scripts in real-time as needed

I use the run-time compilation functionality of the .NET framework to compile and run the code on- the-fly.  This has a small performance hit during compilation however the run-time performance is excellent.

Some Examples

Below are a few examples I put together today to show the power of the system.

The first script below creates an entity at the beginning of the game and then sets up a callback that will fire every 5 seconds.  The TestScript object’s lifetime is until the scripting system is reset allowing stateful object creation.

public class TestScript : BaseScript
{
    int team = 1;
    int xPos = 15;
    int yPos = 2;

    public void Init()
    {
        script.CreateEntity("Healer", team, xPos, yPos);
        script.CallEveryXSeconds(MyCallback, 5);
    }

    public void MyCallback()
    {
        script.CreateEntity("Tank", team, xPos, yPos++);
    }
}

The next script shows how simple customizing a game entity can be.  Whenever an effect is added or removed from a game entity, the following two functions are called allowing designers complete control over gameplay.  Notice the designer is given access only to what they need while still having complete control to change any settings or values of the entity.  An interface could be used to restrict what operations can be performed on entities as required.

class SpeedUpEffect
{
    public void AddEffect(GameEntity entity)
    {
        entity.Speed += 1;
    }

    public void RemoveEffect(GameEntity entity)
    {
        entity.Speed -= 1;
    }
}

Conclusion

As I said, I was amazed both at how simple all of this was to set up (only a few hours) and how powerful the system is.  If anyone is interested I’d be happy to share the source code for how I achieved this.  As I continue development of my engine I will be experimenting more with this scripting system and will release more information as I develop it.

Problem

When you chose an engine or platform to develop for, you’re locking yourself into its scripting language.  This has the following core problems:

• Difficult cross platform development.  Cross platform development is hard enough without the worry of porting gameplay code.  Gameplay code should not be platform specific, and therefore there is no reason to have a different language per platform/engine.
• Immature languages.  With each company re-inventing the wheel when they implement a new language designers are left with immature languages.
• Too many languages.  Designers must learn a new language whenever they develop for a new engine/platform.  This increases development time and reduces fluency in a language.  A designer cannot be free to fully express themselves until they are fluent in the language they describe their gameplay in.

Solution

The solution to these problems is to have a unified scripting language shared by all engines/platforms.  Written specifically for game development it would take the best of current scripting languages.  The games industry as a whole would “own” the language allowing it to evolve with the needs of the industry as each new generation of hardware is released.

Advantages

There are a number of key advantages for moving towards a unified scripting language.

• Single gameplay codebase.  Gameplay doesn’t change dramatically between similar platforms (e.g. 360 and PS3 or flash and iPhone).  A unified language would allow a single codebase to kept across multiple platforms helping with porting and maintenance.
• Specific to game development needs.  A language created specifically for game development could cater to the needs of the industry.
• Single language for designers to use. Small nuances in existing languages can create major issues for non-programmer designers.  A single unified language reduces these problems and makes the learning path for students clearer.
• Less Wheel Re-Invention.  An open-source unified scripting language would allow anyone to submit changes to the language to improve it, rather than re-inventing a whole new language.
• Unified Toolset.  A unified set of tools could sit on top of a unified scripting language.

Genre Specific

The core language will hold the basic building blocks for all games.  In the future, small libraries can be built by studios or the community for each specific genre.  For example a library of functions common to most FPS or RTS games could be created and shared between developers.   A unified scripting language makes this sharing possible and encourages people to develop well thought out, robust libraries they can reuse from engine to engine.  It also serves to soften the blow for designers when changing engines as their common set of functions will move across with them.

How

There are two main options for the creation of a new unified scripting language:

• Large studio forks their current language.  For example Epic could open up Unreal Script and give out the source code for its implementation (let’s call it OpenUnrealScript).
• Community Driven.  A simple codeplex/google code project with a couple of leaders and a team of developers would allow for rapid development, while meeting the needs of multiple teams.  Early adopters would drive the initial feature-set and help to drive its development.

Conclusion

My dream is to see the next generation of consoles and other platforms (PC, iPhone, Flash) all supporting a unified language.  I’m interested in people’s thoughts on this idea and candidates for which language to use.  It’s less about language features and just agreeing on a core language everyone can use to develop games and bring all developers onto the same page.