What fanatical pragmatism is

Fanatical pragmatism involves pursuing the optimal product as cost effectively as possible, without cutting corners.  For anything non-trivial, see if there is an existing solution that can solve the problem.  For games, this involves using a 3^rd party engine, particle system, etc wherever possible.  It’s about solving the problems that need to be solved, in the cheapest way possible.

It’s good for developers as focuses them on completing as much as possible, as quickly as possible.  It’s also good for the business as it means the problems the business exists to solve are solved as cost effectively as possible.

What fanatical pragmatism isn’t

It is not about cutting corners to get to a solution faster.  Nor is it about ignoring long-term goals to reach short-term goals faster.  Fanatical pragmatism is not “cowboy coding” (rather it’s tangential to it) and it’s more about solving the businesses needs for the least cost than just getting things done quickly.

How scrum fits in

It fits in perfectly with agile development practices, particularly Scrum.  Scrum is a discipline-agnostic framework that gives developers the freedom to work within their own specific style.  For this reason, fanatical pragmatism works hand-in-hand with extremely short sprints and meeting changing customer demands.  It acts on high-level sprint planning (deciding what goes into a sprint) as well as low-level, day-to-day development such as exactly how to solve the tasks for a given sprint.  For this reason it can be embraced by both developers and management alike.

Some general rules

Some general rules I’ve found myself following recently:

• Broaden your knowledge.  I’ve spent the last couple of years running a software company focussed on web applications.  I’ve picked up a lot of skills that I’ve been able to transfer over to game development (and vice versa).  The broader your knowledge, the large the pool of resources you can draw from to solve problems.  The jack of all trades is the master of fanatical pragmatism
• Focus on the goal.  The key to keeping pragmatic is always looking at where you are heading.  Every decision from day-to-day task assignment to strategic planning should focus on where the team is heading.  All efforts should be in driving the team towards their ultimate goal(s).

Some general software development rules:

• Separate your concerns.  A big part of why MVC works so well for a game engine is that it keeps the obvious concerns (e.g. gameplay vs. rendering) separated from each other.  This keeps each person on the team focussed on their part of the problem domain and helps to reduce complexity as the software grows in size
• Clean Interfaces.  Keeping loosely coupled systems is a great way of isolating your code so that any mistakes made, or changes needed can be done with the least amount of hassle in the future
• Build strong architecture where it’s needed.  For some large, complex system’s it’s important to spend the time up front designing the architecture for the system.  This gives everyone a foundation to build upon.  This should only be done in rare situations though.  It’s easy to get caught in the trap of doing lots of big design up front, however fanatical pragmatism calls for this only when absolutely necessary, and enough information is known.

Conclusion

So that’s fanatical pragmatism in a nutshell.  Share your thoughts on the topic and let me know how you work best in achieving your goals.  I’m constantly evolving the way I work and I’m always looking for the best way to solve problems so please leave a message with your best practices.

The course runs over two full days and was the first course of this length where I didn’t fall asleep.  The content was of a high quality and was kept interesting with lots of interactive tasks and small group discussions.  Clinton began with a great overview of Scrum and then dug deep in to the details, explaining all concepts in great detail, without bogging down in minutiae.  While there was a slight programmer emphasis he covered all facets of game development.

Clinton has a lot of experience with general game development and is a pioneer with implementing Scrum in game development.  His stories were not only interesting but served as a great way to show how Scrum is being used in the real world.  He has worked with some big studios including CCP (creators of Eve Online) and Bioware.  This gives him both credibility and a great insight into how large companies have made successful games using Scrum.

The last part of the second day was spent simulating a handful of sprints to get a feel for how the interactions worked between ScrumMaster, product owner and the team.  The use of lego to create a small world was surprisingly similar to software development and served as a great way to simulate a small development cycle.  This brought the whole group together and let them experience the realities of working with Scrum in a group of people.  It allowed us to put into practice what had been learnt over the past two days.

An obvious benefit is the certification received at the end of the course.  However more important was the knowledge gained during the course.  I had a fairly good understanding of Scrum before the course however this helped to fill all the holes and even correct a number of misconceptions I had.  There are a lot of resources on the net and in books that can teach the basics of Scrum however I found that the interactive and hands-on nature of the course taught me things I would never have picked up through reading or trying to implement Scrum in a vacuum within my own team.  This is the primary reason I would recommend the course to anyone looking to adopt Scrum in the software development team.  Most people admitted to using a “version” of Scrum which by the end of the course proved to not have some of the essential ingredients.

One of the great points of the course was the high level of interactivity.  We could ask questions at any time (which people did) and Clinton would often integrate his answer into the rest of his talk give context rather than a simple answer.  He was happy to answer the hard questions about Scrum including where it has its problems and where we are likely to run into trouble.

I highly recommend the course to any lead’s or project managers.  While the cost of $1500 is fairly high (it’s the standard cost of any ScrumMaster course) it pays for itself in the payoffs you will experience within your team.  It’s an enjoyable two days where a lot is learnt and most will be inspired to fix the problems with the way their teams are managed.

Have you participated in a certified ScrumMaster course?  Have you attended one of Clinton’s courses or talks?  What do you think of Scrum and its relevance to video game development?

.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

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.

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.

For some time now I’ve been asked by a few people to write up my thoughts on a coding standard. To me, coding standards are like source control, until you use them you don’t realise just how awesome they are. Coding standards are a requirement for large software teams, however even if you are working alone I’d recommend adopting at least a simple coding standard.Keeping code consistent and readable is helpful when reading other people’s code as well as when reading your own code weeks or months are it was written. In effect a coding standard is trading development time for maintainability time. I’ve found that the ratio of dev time to maintenance time grows from 1:1 on a small project to something approaching 1:∞ on larger projects.

I’d like to formally thank Greg for showing me the light on a lot of these points. I’ve spoken previously about pair programming and just generally mixing the experience level of developers to help the younger ones. I think that these kinds of relationships are invaluable for making great programmer as it’s something that you just can’t pick up from textbooks or coding by yourself.

As always, please add your thoughts and complaints. I think that just talking about these issues is a good step in growing as a software developer, even if everyone doesn’t always agree.

General Tips

1. Be consistent

This is the golden rule with coding standards in any language. Every other rule below is pointless unless there is consistency. If you completely disagree with all of my points below that’s fine, so long as you set out a standard, and everyone conforms to it. The only thing worse than a bad coding standard is not having one or having one that isn’t followed by everyone.

This can be an issue for some programmers as their ego’s get in the way however it’s vitally important that everyone follows the standard otherwise it will quickly turn into bedlam. This consistency should ideally cross both the programmer boundary and the project boundary. It will be much harder to have consistency between projects, however if this can be achieved, any programmer within the company can switch projects freely (even if only to assist briefly). This also increases efficiency on new projects when programmers who haven’t worked together already have this coding standard in common.

2. Get everyone involved

To get the best “buy-in” and to reduce friction amongst the team, it’s important to get everyone involved in the discussions. I’d recommend writing up the standard once “complete” and passing it around as the first draft. Giving people plenty of time to comment also gives leaders more ammunition when enforcing the standard. If people can voice their thoughts on the subject they are more likely to follow the standard in the future.

There is always going to be the inevitable ideological disputes where programmers won’t be able to come to a conclusion. There are really two options here:

i. Military style: The highest ranked programmer makes a decision, and everyone follows suit. This may be the only way to solve the most ideological debates but has the side effect of lowering morale.

ii. Politician style: Both sides put their case forward and the entire team (or key members) vote on which to choose.

Specific Tips

3. Curly braces – on the next line

if (condition)
{
}

This is pretty much the standard I’m seeing everyone use these days. There are some strange lecturers and Java programmers that keep the brace on the same line, but otherwise most people seem to have unofficially agreed to this. This has the added advantage of allowing the condition to be commented out quickly (using //)

Negative: It takes up less space having it on the same line.
Response: It makes code far more readable, and white space is free and should be used.

4. Always put curly braces in

The main reason for this is that it reduces errors in code such as a macro hiding the fact its multiple statements. The secondary reason is for maintainability. If the single statement becomes multiple statements it takes longer to update, and can lead to errors if people miss adding the braces.

Negative: It saves time to leave braces out.
Response: Saving time at the expense of readability is bad. If all conditions/loops have braces then the source will be far more consistent.

Negative: It takes up less space without braces and more code can fit on the screen.
Response: Fitting more code on screen is not as important as having error free, maintainable code. As desktop resolutions increase this argument holds even less weight.

5. Prefix members and arguments

class MyClass
{
int m_myInt;
};

void MyFunction( int a_myParam )
{
}


Firstly, adding these prefixes is NOT Hungarian notation. Rather than describing the type of a variable adding these prefixes gives context about what the variable is. This context is the key reason for adding prefixes. Prefixes make it easier to build a map in your mind of what the code is doing as you can quickly tell what variables are arguments/parameters, which are members and which are simply local variables. You can also add g_ to globals, however I’d be advocating the use of globals then J.

If m_ and a_ are too verbose then the alternative is simply appending m and a.

void MyFunction( int aMyParam )
{
}

Personally, I prefer the full prefix (m_) as it makes the code more readable, and it follows the convention of the first character of the variable name being lower case.

Negative: With modern IDE’s you can mouse over variables to get extra information
Response: Mousing over is slower than simply perusing code. The information given is usually just the type which doesn’t give context, it only gives further information.

Negative: It takes too long
Response: Again, readability is more important than saving a few seconds on typing

Negative: Underscore is hard to type
Response: Once you’ve been using it for a while it becomes quite natural. Also with tools like visual assist the underscore can automatically be added in for you.

6. Put modifiers (* and &) next to variable type rather than variable name

MyClass* myVariable;

This point actually goes against what I am seeing most people using in their coding standards at the moment. It also goes against what I was taught at university (whether that’s bad or not I don’t know). Before you dismiss it though, I recommend you actually sit and think about the alternatives and why you would use them. The modifier (pointers or reference) is modifying the type of the variable and therefore it should be placed next to the type itself. The negative to this is one I gave when first taught this, however after thinking about it I realised the error of my ways.

Negative: The modifier should go next to the variable name as it is misleading if you declare multiple variables per line. In the example below, the first variable is a pointer and the second is not, this is misleading.

MyClass* myPointerVariable, myNonPointerVariable;

Response: Declaring multiple variables on one line is really the exception to the rule. Should you be making a decision about based on the exception or the rule? If there are any modifiers like this, don’t declare them on the same line. The worst issue here is a bit of extra typing and more screen real-estate being used up, neither of which should be an issue. Having the pointer next to the variable name makes it harder to reader when skimming over code, particularly if there are a number of spaces (or tabs) between the type and name.

7. Create const on functions and function arguments where appropriate

Const correctness for variables is a bit like cleaning your teeth. It’s annoying to do, but everyone agrees that you should do it. There are three main benefits:

i. More descriptive code. A quick look at a function tells you whether it changes the state of an object, and whether it changes the state of any variables passed in.

ii. Faster code. Giving the compiler more information about constness allows it to optimize your code.

iii. Less errors. If a function or argument is const then anyone changing the function will get compile time errors if they do something the function was never intended to do.

8. Conditions/Loops should have a space after them

if (myVar)
{
}


This is the most readable way of writing conditional and loop statements I’ve seen. I personally recommend this usage, however the main reason for this point is to get you thinking about how it should be done. If you disagree, that’s fine, just make sure you remember point #1 and decide how you want your code to look and keep it consistent.

9. Camel case variables, capitalize classes and functions and full capitalize constants

I’ll finish up with an easy one. Most people agree with this standard but I thought I’d list it anyone. The best way to show this is with examples:

Variable:

int myVariableName; // camel case

Class and functions:

class MyClassName {} ; // camel case with capital first
void MyFunctionName();

Constants:

const int MY_CONSTANT_NAME = 5;

Below is a short list on how I believe managers can foster a good software development team.

1. Fire bad programmers (and don’t hire them)

I decided to start with the controversial one; however it’s one of the most important. Nearly every team I’ve worked on has had someone on it that should have been fired but the company just wouldn’t do it. There are many benefits to be made from firing the bad programmers, some of which aren’t immediately obvious.

a. The obvious one is that bad programmers add bad code. This in turn causes more work for the rest of the team, adds to maintenance time and pushes deadlines back. This also leads to software entropy where good programmers will be forced to work with bad code which often encourages other bad code.

b. They bring the morale of the team down. Any good programmer can pick a bad programmer after only a few weeks of working with them. It’s very demoralising to be forced to work with someone that is no good, particularly if they are getting paid just as much, or more than the good programmers.

c. They teach bad habits. Keeping bad programmers on gives new programmers bad influences to look to for support. By letting them stay on within the team, managers are basically saying that they don’t mind having bad programmers working for them. It makes it hard to foster good quality coding standards when members of the team are openly ignoring them.

The only caveat to this is mid-development of a product. It may be detrimental in the short term to remove bad programmers immediately; however this often turns into apathy where the programmer simply stays on to the next project or milestone. Look at the schedule and actually mark off when the time is right to remove them. Once this date comes around bite the bullet and get rid of them.

2. Give rewards

I’m surprised how many programmers when asked how work is going will mention certain perks or rewards they receive from their bosses. This can be anything from having a few days off after record profits to free food/beer/game nights once a week. One of the biggest problems with ‘working for the man’ is that there’s no direct connection between the quality of work programmers do and their rewards. This was one of the key points in Office Space and every programmer I speak to has had this problem at some stage in their career. The main purpose here is to tie the success of the company to the employee’s that are creating this success. It can range from profit sharing to simply taking everyone out for a big meal (with free drinks for those inclined) after meeting a big milestone.

In the grand scheme of things it doesn’t end up costing much, and the productivity benefits returned will easily pay the rewards back many times over.

3. Give good direction

There’s nothing worse than having a project that’s just aimlessly drifting towards it’s goal. There need to be set goals that the entire project is working towards as well as sub-goals for each individual team. Programmers are logical, methodical people and they like order in their lives. The more you can make the project’s direction fit in with this view the more the programmers will ‘buy in’ on the future direction.

Programmers will look at the project as if it were a program in itself. There’s a bunch of commands the team is following (create the UI), with conditions (if there’s time, add in flashy feature 53) and iteration (each milestone). If you can learn to think like programmers do and show the direction of the project in a way they’ll understand you’ll see productivity gains.

4. Be transparent

I touched on this in an earlier post, so I’ll keep this one short. Basically let the team know what’s happening within the company. You don’t have to give them every detail, but make sure that the important information is propagated. This can be as simple as a company newsletter or an internal website that has the news. Those who are interested can stay up to date and others who don’t care can just ignore it. People often worry about their jobs and not knowing what is happening can often lead to a drop in productivity.

Conclusion

I’d like to hear from people if they have other ideas or whether people agree or disagree with my list. As things move forward with the business we’re hoping to set up a software team in the near future so I’ll start posting on how implementing these and other ideas I’ve blogged about works out in reality.

The demo (shown in the screenshot) renders a scene with ~40,000 triangles and 255 lights! It reaches a staggering 82fps using his LIDR technique compared to 12fps with multi-pass forward rendering. Using this technique would allow for a far more dynamic environment than we are currently seeing with only a handful of lights in the scene.

This is Damian’s second amazing achievement, the first being GLIntercept, a program that allows debugging OpenGL calls.

Auran Developments went into liquidation late last year. Many of us saw it coming for at least a few months, if not years. Below are my personal thoughts on why Auran went bust. I’m writing this to try and help other struggling software or game development stduios from ending up in the same way.

To get the legal stuff out of the way. When I mention “Auran” I’m talking about Auran Developments. That is the company who hired me, and the only one I ever really had any interaction with. Auran Games et al. are still running fine and have nothing to do with the following article.

Listen

The first main problem was that Auran wouldn’t listen to anyone. This was the core problem I see as its tentacles really reached out and touched every part of the company. I don’t know how many people would talk to me about how they’d made a suggestion months or years earlier only to have it ignored and then the exact problem they foresaw coming up. While it’s important that people high up are the ones making the decisions to direct the company, they also need to know where their weaknesses are and seek advice from the best people in each field.

When I started at Auran there were a LOT of extremely talented people that had thoughts on the direction the company should take. Unfortunately, most of their requests were ignored, and the majority of people simply left the company as they could see that the wrong decision was being made. By listening to people who are skilled in their particular field, they would have been able to keep these skilled people on, further increasing the company’s chances of success. The bottom line is that good people have good advice, and not listening has a twofold problem. The company fails because they don’t do the right thing AND they lose the good people giving out this advice.

Keep Good People

This leads into the second problem, the number of great employee’s I saw leaving was astounding. This also has a snowball effect because when great, senior, people leave everyone below them wonders if there’s something they don’t know about. For me, the first sign that something wasn’t quite right was when one of the star graphics programmers informed Auran he was going to leave if he wasn’t put on something interesting. This guy (while never admitting it himself) was basically Carmack 2.0. He is the kind of person that good companies would give almost anything to have on their team. However, at Auran, they just let him slip away even after giving them a direct option to resolve the problem. The other problem was when the three leads (programming, art and QA) all resigned within a couple of weeks of each other.

Be Transparent

The other main problem was the lack of transparency and communication. It’s vital, for any software project that crucial information flows down to “the trenches”. There’s nothing worse than reading in a magazine or website that the company is in trouble, or that it’s just received another round of funding from investors. Many companies have this problem, where you need to be on the grape vine to find out information that directly affects your job and your life. This was compounded at the end when people were literally sitting around waiting to find out if they were fired or not.

The transparency part comes from sharing the vision and direction of the company with all staff members. Most of us had to simply guess what would be happening in the coming months. Part of this problem comes from having the wrong people too high up in the chain of command. As soon as you have less qualified people above more qualified there’s going to be both conflict and misdirection with the company.

The B team

I was part of a second team at Auran (not Fury). Let’s call it the “B Team”. This team worked really well together, produced a great product in a short time and was ready to move onto producing more great products. What’s the logical step Auran should have taken? Good companies know that good people are hard to find (and even harder to replace). Good teams though, they are like the holy grail of software development. If you have a good team, you do anything you can to hold onto it, foster it and mainly, make a crap load of money from it.

Not so at Auran. We were broken up, forced to work on crappy projects that we would rather resign than work on (as was the case in my situation). A number of people pleaded with Auran to keep us together and to make money from us. That’s all we wanted to do, work together in a great team making money for Auran. It seemed this direction was not the same as Auran’s.

Don’t Keep All Your Eggs In One Basket

The next big issue was focussing on one single product. I’m not going to get into whether Fury was a good game or not. Either way, it is too much to risk an entire company on a single game. I heard this almost daily from people around the company, but no one would listen. Generally, when an age old proverb is written about something, it’s a good sign that you should heed its advice.

The games industry is a hit driven industry which means there’s a great chance you won’t succeed off a single product. Sure, there’s a chance you could make it to the big time, but there’s a far higher chance all your employees could be jobless just before Christmas.

Software Development, It’s Hard!

Finally it just comes down to software development. Software Development is really hard. Personally, I love it; I’ve found what I want to do for the rest of my life. I’ve also come to the conclusion that I’ll spend the rest of my life trying to do it perfectly, and never succeed. There’s no “silver bullet” and you certainly can’t treat it like running a regular non-tech company. While software development is relatively young, compared to the other schools of engineering, it’s also full of great techniques. Unfortunately, most of these weren’t employed at Auran. Good games development practices weren’t employed either. I’m a strong believer of making a game fun, then working out how to finish off the “extra bits”.

Conclusion

So that’s what I see that Auran did wrong. I don’t blame any individual people and I don’t think that anything can be gained from doing so. I loved a lot of my time working at Auran; it was the dream company I’d wanted to work at since Dark Reign came out when I was in high school. I did a lot of soul searching when I decided to resign, and it made me really depressed to think of what could have been.

If I had to put down one single moment when I knew it was over, it was a lunch time in September sitting in one of the back rooms with Shauno, the artist on my team. I was flicking through the booklets of Dark Reign with every newspaper clipping relating to it. I remembered back to when I read those very newspapers/magazines 10 years earlier and what I had dreamed working at Auran would be like. I compared it to what was happening at the time, and the decision was pretty much made for me. I’d like to thank everyone I worked with at Auran, and I hope that others can learn from the mistakes made and we can see the Australian games industry flourish in the coming years.

The picture for this blog was done by Shauno again. It’s actually based off the original picture he drew for my farewell card when I resigned.