The Problem

Indie developers have trouble finding other like-minded indie developers to work with.

I talk with a lot of indie developers and they tend to fall into three main categories:  programmers, designers and artist.  Each of these groups has a hard time finding quality people from the other two groups.  This is a major problem for indie game development as fewer games are being produced and talent is going to waste.

The Cause

The main cause of this problem is a lack of communication between the groups.  There is no reliable way for Programmer Pete to find Artist Andy or Designer Dave.  Pete was in the games industry for 10 years before “going indie” but he knows few people.  He kept to himself and while he is friends with a lot of other programmers he hasn’t kept in contact with many artists or designers.  Andy has a lot of trouble finding programmers and designers he can work with.  They are always so restrictive in what they let Andy achieve.  Dave is full of great ideas but can’t find a good programmer who’s happy to implement his idea.

There are hundreds of Pete’s, Andy’s and Dave’s in the world, but few of them know or have a reliable way of finding each other.

Key Contention Points

In the rare occasions when developers from these individual groups do meet up, often they are incompatible.  From my experience, the key points of contention fall into these main categories:

• Compensation – Working for free, profit share, an hour rate or a fixed amount.  Where a developer is in their life will often drive their monetary needs.  While Dave has 3 years of savings he’s happy to burn through, Pete needs a large paycheque to buy all his programming books and pizza.
• Game Type – Each developer has their favourite game type and many developers don’t like to stray too far from their comfort zone.  Andy just wants to work on an FPS but Pete is an RTS fanatic while Dave has an idea for the greatest MMO of all time.
• Game Size – Projects range from days to years to develop.  The level of investment needs to match each individual’s situation.  While Pete might be happy to spend the next 3 years slowly plugging away at a game, Andy wants it down within the next month so he can get back to working on his comic book.
• Availability – The bills still need to be paid and the time dedicated to a “real job” directly affects how much time each developer can spend on the game.  Pete is a contract programmer who has half his week spare to work on the game while Dave works at McDonald’s 50 hours a week to make ends meet.

The Solution

One solution I’ve seen for this problem comes in the form of “help wanted” sections in popular websites such as gamedev.net and indiegamer.net.  These sites allow teams to post their project and the skills they are after.  Another solution is networking.  Taking every opportunity to meet like minded game developers and talking to as many people as possible until like-minded people are found.  Whether visiting an IGDA meeting, the GDC or the local game development educational institute.

I’ve often thought that a site dedicated to connecting indie developers would be beneficial.  Teams or individual developers could post their projects with exactly what they are looking for.  Developers can also post their skills so others can find them.  A match making system could connect these two groups and reduce the uncertainty when looking for other developers.  Do you think there’s a need for such a site, or does this site already exist and it’s not well known?  Would this site be beneficial to your current situation or are you happy with the current solutions?

Conclusion

Is this a problem you face as an indie developer?  Of all the indie developers I know, over half of them are facing this problem right now.  Have you managed to solve this problem, and if so, how?  How are you currently finding other developers to work with and how do you determine if you are compatible?

.mischief.mayhem.soap.
http://msinilo.pl/blog/?feed=rss2

Atom
http://farrarfocus.blogspot.com/feeds/posts/default

Beautiful Pixels
http://feeds.feedburner.com/BeautifulPixels

Dead Voxels
http://deadvoxels.blogspot.com/feeds/posts/default

Diary of a Graphics Programmer
http://diaryofagraphicsprogrammer.blogspot.com/feeds/posts/default

direct to video
http://directtovideo.wordpress.com/feed/

Gamasutra
http://feeds.feedburner.com/GamasutraNews

Game Angst
http://gameangst.com/?feed=rss2

Game Rendering
http://www.gamerendering.com/feed/

GameArchitect
http://gamearchitect.net/feed/

GameDev.Net
http://www.gamedev.net/xml/

Geeks3D Forums – 3D-Tech News Around The Web
http://feeds2.feedburner.com/Geeks3DTechNewsForum

GPGPU» :: GPGPU.org
http://www.gpgpu.org/cgi-bin/blosxom.cgi/index.rss

Graphic Rants
http://graphicrants.blogspot.com/feeds/posts/default

Graphics Size Coding
http://sizecoding.blogspot.com/feeds/posts/default

Humus
http://www.humus.name/rss.xml

Ignacio Castaño
http://castano.ludicon.com/blog/feed/

John Ratcliff’s Code Suppository
http://codesuppository.blogspot.com/feeds/posts/default

level of detail
http://www.jshopf.com/blog/?feed=rss2

Level of Detail
http://levelofdetail.wordpress.com/feed/

Lost in the Triangles
http://feeds.feedburner.com/LostInTheTriangles

Make It Big In Games
http://makeitbigingames.com/feed/

meshula.net
http://meshula.net/wordpress/?feed=rss2

OpenGL News
http://www.opengl.org/news/rss_2.0/

NVIDIA Developer News
http://news.developer.nvidia.com/rss.xml

Outside Hollywood
http://www.outside-hollywood.com/feed/

Real-Time Rendering
http://www.realtimerendering.com/blog/feed/

realtimecollisiondetection.net – the blog
http://realtimecollisiondetection.net/blog/?feed=rss2

Sanders’ blog
http://sandervanrossen.blogspot.com/feeds/posts/default

Scattered Pixels
http://feeds.feedburner.com/ScatteredPixels

Solid Angle
http://solid-angle.blogspot.com/feeds/posts/default

The Hacks of Life
http://hacksoflife.blogspot.com/feeds/posts/default

w00t
http://bpeers.com/blog/xml-rss2.php

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.

What are virgin play testers?

A virgin is anyone who has never played nor seen someone play your game before.  That second part is important.  If Bob is watching Jim play your game then both Bob and Jim are no longer virgins.

They are equivalent to someone downloading the demo of your game and firing it up for the first time.  They should come from your target audience and preferably be scattered throughout this demographic.

Why do you need virgin play testers?

People have a short attention span these days.  You only have minutes to convince someone your game is worth buying.  Watching a virgin play your game lets you watch the experiences every player will go through when they first play it.  This is absolutely vital if you want to make your game playable and get a conversion.

Gladwell in Outliers has the 10,000 hour rule: the time it takes to become proficient in an activity.  I have the 1,000 hour rule.  After 1,000 hours working on (and playing) your game you can’t objectively determine its quality. The only caveat to this rule is that after a year of not having anything to do with the game your virgin status is reset.  This doesn’t really help in the world of game development as you can rarely take a year off.  It’s much easier to just go out and find virgins. The bottom line is that the only way you can experience what your game is like for a virgin is watching them play.

What’s the best process?

Here are some simple rules to help you:

• Video tape everything – If possible, try and get the game and their hands in the shot at the same time.  This lets you see what buttons/sticks they are pressing at different stages, particularly if they get stuck
• Don’t help – If you have to help them your game needs some major changes.  Imagine that same person sitting at home without you there; they will most likely give up on the game.
• Get them to say what they are thinking – The best way to find out when they are stuck, bored, excited, surprised or confused is to get them to tell you what they are thinking as they play through the game
• Don’t dismiss anything – No matter how trivial a comment is you need to take it on board.  Even if the person dismisses their comment later you should take notice of it.  On a number of occasions people would say a particular part of the game wasn’t a problem after having it explained and it’s easy to then ignore that issue.
• Fix the problems – This is vital.  There’s no point getting virgins in to play the game if you don’t fix problems they find.  This might seem like a simple idea, but it’s important you keep a record of every issue and resolve them.

Where can you find virgin play testers?

There are 4 main places you can find virgins to play test your game:

1. Within your company – If you work for a large company, start internally.  This reduces NDA and other issues, helps build community within the company and encourages other teams to start virgin play testing if they don’t already
2. Friends and family – The next best step is people you know and trust.  You’ll still want them to sign an NDA, but there’s less chance they’ll break it.  This is also a great way to catch up with your partner who you haven’t seen since before crunch started.
3. Local game development education institutions – Go to your local game education centre and put up a sign on the notice board reading “Get your name in the credits of a game, right now!”  I guarantee* at least 90% of them will jump at the opportunity.  This also has the secondary benefits of letting you scope out talent and you might even get some good suggestions for your game.
4. Everyone else – This is the most important and largest group.  Grab random people off the street or from your local video game shop.  You want to be taking a large cross reference of people here.  It’s also a good idea to find some people outside your target audience.  You may find the game appeals to a larger audience, or that making some small tweaks will broaden your audience substantially.  Free beer and/or pizza is usually payment enough for people to sit and play games for a few hours.

*Not a guarantee

Conclusion

I’d like to say a big thanks to Matt Ford for a lot of the ideas from this post.

I was blown away by how important it was to watch virgins playing our game each and every week.  It does take time and resources, but it’s well worth the effort.  It helps keep you on track and focussing on the initial user experience, the most important part for making the sale.

Go out right now, find someone that hasn’t played your game before, sit them down and watch them play.  I guarantee* you’ll learn something about your game that will make it better.

*This one is a guarantee (unless you’re a lawyer)

Introduction

I first used virtual reality in 1995 while visiting SegaWorld in London.  They had a ride you sat in, donned a virtual reality headset and furiously pressed buttons to win or lose a battle (along with 20 or so other people).  I was so excited to finally get to use virtual reality that I took a wrong turn getting on the ride and fell off into the hydraulics.  I’m not sure if it was the amazing 3D, head tracking or loss of blood from my injuries but I had an awakening experience.  I knew that in the future, we’d all be playing games using virtual reality, and the world would be a better place.  Unfortunately, this never happened, but is it too late?

Should it be the “Next Big Thing”?

VR has a number of key features that make it the obvious path for game development in the future:

• Full 3D Immersion – rather than looking at the game world sitting on a monitor that’s sitting in your room you are actually in the world.  Even 2D games take up your entire peripheral vision making them immersive.
• True 3D (for free) – Having two images allows a true stereoscopic display of the 3D world
• Head tracking – Most VR headsets have built in head tracking which adds to the immersion.  Now you can look at the pre-pubescent kid in counter strike before he headshots you.
• Look cool – Why wear nerdy 3D glasses when you can look like this:

It’s best suited to the following games:

• Flight Sims
• First-Person Shooters
• Racing Games
• Sport Games

VR also opens up the possibility of relaxation and full emersion games that aren’t possible with regular monitors.  This might sound a little hippie like, but I can see some great opportunities in games for children in hospitals and rehabilitation from injuries.

In my eyes, these benefits make it the ideal candidate for game development in the future.  The current bout of depression leading from the immersion experienced in the “Avatar” movie is proof that even 3D movies are enough to have a greater impact on people (and that some people are fairly weak).

3D movies bring up an interesting stepping stone towards VR.  Monitors are now available with high enough refresh rates that 3D glasses can be used to present a 3D image on the screen at 50Hz.  This might be an easier sell now that 3D movies are becoming more mainstream.  I find it interesting that some people are happy to accept 3D movies as the “next big thing” while dismissing virtual reality as a thing of the past, despite the fact it has much greater qualities.

So why hasn’t Virtual Reality taken off?

There are a few main reasons why Virtual Reality is still not in the mainstream of gaming:

• Price – With the average headset coming in at $1,500USD, this is a lot for an 800×600 display by anyone’s standards.  While it is comparable to some larger end monitors it’s still too high for the average gamer.  If the price of headsets can come down below $750USD and resolutions can be at least 1024×768 I expect a much larger uptake.  That’s certainly the sweet spot for price and resolution for me.
• Vertigo/Eye Strain – Some people have issues focussing on the screens in the virtual reality headset and others suffer from eye strain.  Most people should get used to this over time however it might simply mean some people never adopt the technology
• Lack of interest – People just got bored with the idea.  For so long we kept hearing about how VR was going to change the world and it never did.  A great example of this is the fact that searches for “Virtual Reality” are down 80% since 2004!

Any other crazy thoughts?

What would a blog post from me be without a reference to Microsoft?  The ultimate way for virtual reality to take off is for Microsoft to develop the headsets.  They make awesome peripherals, have the money to back it and have the console to go along with it.  Having both Xbox and PC support virtual reality would be better for gamers, game developers and give Microsoft more of an edge over the competition.

What do you think?

Have you used Virtual Reality before?  Did you like it?  How much would you be willing to pay and what resolution do you think should be the minimum supported?  Many people I’ve spoken to about Virtual Reality think it’s dead, what do you think?

Roles

Game development involves a number of common roles as well as some overlooked ones.  Individual team members can handle multiple roles on smaller teams and some roles can be shared by more than one person.

Programming

Programming on an independent team is about more than just game development.  The programming department will be responsible for tools and website development.  They will also have to handle the creation of the installer.

Design

Design is one of the great areas it pays to share ownership.  The designer has the final say on decisions and is the go to if people are unsure.  They also maintain the game design document to unify the team.  A wiki is a great way to collaborate on the design document.

Art

The art department is responsible for not just game art but also creation of marketing material and web design.  Artists need to work closely with the programmers to make sure technical requirements are met and to drive the requirements for tools.  They also need to collaborate with design to make sure the look and feel of the game is met.

Sound

Often overlooked, sound is vitally important to give atmosphere to the game.  Sound should not be left to the last minute as it will feel disconnected and won’t add as much to the game.  The programmers should build the infrastructure for the sound early to allow experimentation.

Project Management

Project managers are responsible for the velocity of the team (how much they are achieving each milestone).  They need to be aware of when team members are falling behind and make sure everyone is performing their duties.  Visibility is the key to making sure everyone on the team is aware of their current goals and deadlines.

QA

Without QA the game will be unplayable.  QA is another area that is good to share across the whole team.  The team should be playing the game constantly and fixing bugs as they go.  It is preferable to have non-programmers doing QA as it is easy for them to overlook issues in their own code.  Sharing the games with friends and having a beta-testing period is a great way to share the load.

Business

Without someone managing the business side of game development, you may as well be making the game just for fun.  One team member needs to be responsible for making sure the game will be profitable.  The entire team needs to be mindful of the fact they are making a game for profit, not just fun.  Business includes marketing, sales, business plan writing and possibly seeking funding.  The team needs a business plan covering:

• Marketing Strategy – How will people find out about your game?  How will you sell the game and how much will it cost?
• Cash flow Summary – What are the expenses of the team and how will you afford to keep the business running?
• Economic Assessment – How much do you expect to make from the game, based on similar games

Co-Location

If possible, the entire team should work together in the one building.  This lets the team quickly test ideas, keep each other motivated, play-test the game together and watch each other play.  Renting an office is expensive and it’s important to keep costs as low as possible.  Get creative, work together on laptops in a coffee shop, move in together, or work in each other garages or basements.

Workloads

Depending on the situation each team member may have differing hours they can devote to the project.  Each team member’s level of commitment should be discussed and decided up front.  The closer these levels can be the better.  Having a large imbalance in working hours can lead to resentment and hostility between team members.  Some ways of evening out imbalances include:

• Larger share/profit ownership
• More creative control over project

Personalities

Personality trumps ability on indie teams.  As with most high-intelligence professions, game developers often have strong personalities.  While these personalities might be annoying at a large game studio, it can be the death of a small indie team.  Each developer needs to put the game and the team ahead of their own agenda.  When possible a team should be formed with people that have worked together previously.

Conflict

Every team has conflict.  Conflict can be minimized having a unified goal.  The best option is to have someone in a position of power to settle disputes.  This person must be trusted by everyone not to push their own agenda.  Some solutions to solving conflict in your team:

• Talk it through – Open, continuous conversation is the best way to solve problems
• Compromise – The larger the team, the harder it is to keep everyone happy.  Compromise is a necessity.  Ultimately the team is in it together and need to compromise to solve disputes.
• Give everyone a voice – Voting is a great way to solve disputes.  The team must agree that a voting mechanism will be used and respected up front.

Outsourcing vs In-house

Many Indie companies have little money, necessitating all work is done in-house.  Outsourcing gives a reliable quality for a fixed price.  Some areas worth outsourcing include:

• Game Engines – shared by the whole team, they can save a lot of development time
• Sound Libraries – can be used as building blocks to create sounds for the game
• Art – Art is often the critical path in development.  Outsourcing may save time and money

Conclusion

This should set you up on the path to creating a solid team for your next indie game project.  What are your experiences with building a team?  Where have you succeeded and failed? Do you have any recommendations for others who are building their team?

The Pragmatic Programmer: From Journeyman to Master

Code Complete

Rapid Development: Taming Wild Software Schedules

Agile Software Development, Principles, Patterns, and Practices

Refactoring: Improving the Design of Existing Code

Peopleware: Productive Projects and Teams

The Mythical Man-Month: Essays on Software Engineering

Design Patterns: Elements of Reusable Object-Oriented Software

Software Estimation: Demystifying the Black Art

Patterns of Enterprise Application Architecture

Software

1. Download Visual Studio 2008 Express – http://bit.ly/VCSExp

2. Download XNA Game Studio 3.1 – http://bit.ly/XNAGS31

Learning C#

3. Read these C# tutorials

a. C# Station Tutorial – http://bit.ly/CSTut1

b. C# WikiBooks – http://bit.ly/CSWiki

Learning XNA

4. Read these XNA tutorials

a. Introduction – http://bit.ly/XNATut1

b. 2D Introduction – http://bit.ly/XNATut2D

c. 3D Introduction – http://bit.ly/XNATut3D

5. Look at these starter kits – http://bit.ly/XNAKit

Other Links

6. Visit the following for more information on game development

a. Gamedev.net – http://www.gamedev.net/

b. Gamasutra – http://gamasutra.com/

c. Indie Gamer Forums – http://forums.indiegamer.com/

What should you create?

I’ve found the best way to learn game development is by creating a full game.  Exactly what game you create depends on what you want to get out of game development.  There are a number of paths I commonly see people taking:

• Becoming a game programmer – The best route here is to take an existing game like Pong, Space Invaders or Mario and recreating it.  The game design done is already complete, allowing you to focus on learning the skills required to code the game
• Becoming a game designer – Rather than recreating an existing game, come up with a new, simpler design.
• Getting a job at a particular game company - Before you begin your new game, you should find out what technology the company is using.  You are much more likely to be hired by them if you are experienced in their technology suite.  If you’re unsure of what they use, ask them.  Game companies are always looking for good talent and they’ll be happy to share the technologies they use with you.

Want more?

I’d like this list to become a comprehensive, step-by-step introduction to game development that takes developers from zero experience to creating their own 3D (or 2D) games.  If you get to a point where you’re stuck and don’t know what to do next, please email me and I’ll help you fill in the blanks.

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?