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?

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.

The Mini-Game

As part of a mini-game for CIC I wanted players to be able to play a chess-like game allowing one of the 4 or 5 players per ship to conduct ‘Electronic Warfare’ against other ships they were battling with. I needed to do a lot of prototyping of the game rules testing different types of units, different board sizes etc. For the greatest flexibility in prototyping I decided to implement the entire game logic in script files allowing rule changes on the fly. After investigating the different options for scripting languages, I chose to go with GM Script. It also gave me the added benefit of trying out GM Script on a small sized project to help decide if I should use it for the high-level AI in the rest of CIC.

During the creation of the board game engine I first created chess and checkers, using script files only, to make sure I had enough features for a full chess-like game. I then created a separate script file with the rules and unit types for my ‘Electronic Warfare’ game. It shows just how flexible scripting languages can be, with a simple change in script file completely changing the game.

Game Monkey Script

GM Script is “a simple, small, game / application extension language for C++ coders”. It’s similar to Lua, but designed with C/C++ game programmers in mind. Using a C style language it allows script (.gm) files to be loaded and executed at run-time. The script files allow many useful features from configurable variables to complex functions. I found it easy to use, simple to integrate with my own code, and generally a great benefit to the project. I highly recommend anyone to check out GM script for any scripting solutions they need in the future, and feel free to contact me for any more detailed info or questions.

MiniMax (with alpha-beta pruning)

Thinking back to my AI subjects at university I remembered that minimax tree traversal was one of the best forms of AI for chess-like games. After some investigation I decided I’d implement minimax for my chess game, and after a few hours of coding had simplistic tree generation and traversal implemented. The basic concept of minimax tree traversal requires you to generate a tree of possible moves from the current board layout (and all moves from each of those moves etc). Each set of moves is a new level in the tree, and the children for each node are all the possible moves from that board configuration. The number of nodes in the tree quickly blows out with only looking ahead a small number of moves (currently I look forward 3 or 4 moves). To allow looking forward this far I needed the game to run a lot faster. I added my own memory pool, I compressed my board and unit class sizes as far as I could and ran AMD’s optimizer (CodeAnalyst) over my game to find any bottlenecks. After squeezing as much performance as I could out of the code I ended up running into a brick wall, I couldn’t have both the flexibility of a scripting language and still have the speed to run the minimax algorithm properly.

Script vs. AI

As a lot of the core gameplay was implemented as functions within GM script, every time I called them I had a major run-time hit which wasn’t a problem during regular play, but when generating thousands of possible moves it soon grinds to a halt. Don’t get me wrong, I’m not saying you shouldn’t use scripting in your games; it’s just that you have to choose where you use it wisely. One area of the GM script that allows your app to still have excellent run-time performance is configuration variables. By loading all of the definitions in at once (at load time) and storing them in regular C++ structs/class you can then access them at full speed while still having the flexibility of originally loading them in from script. There is no native support for binding GM config files to C++ struct/classes however it’s a simple task to create this yourself. Using configuration variables I’ve managed to get around the problem for now, however it means I can’t have any of the extra features (like special moves such as castling in chess) working with the AI.

The main performance problem will occur if you use script in a time critical part of the game loop. Scripting languages when compiled to non-native byte code will be 10-100 times slower than native code.

Conclusion

So in summary, GM script could be a great addition to your game, in moderation, and minimax is an excellent algorithm to use in any chess-like game. Minimax has fairly limited uses outside of that scope, however it was fun to implement and only took a few hours to get up and running, with a few extra hours optimizing it. I now have the fun task of making the AI smarter through the ‘score’ it gives to a particular board configuration, the better the algorithm, the smarter the AI will be. Once I’m happy with the AI I’ll look to start integrating it within CIC and see how it plays with the rest of the game. Then it’s on to implementing all of the fancy features I’ve come up with over the past few months of design. I’d like to thank Shauno for working on the art for my ‘Electronic Warfare’ game, it goes to show again just how much better a game looks when a real artist has spent even a few hours on it.