The biggest complaint I hear (and face) from working full-time at home is the fact your “always on”. Unlike trudging off to work for 8-12 hours per day where there is a definite line between work and home, the line is blurred. This list is mainly ways I go about emulating that distinct line between working and relaxing.

Kill Switch

The best way I can shift my mind from work to relaxation is what I call a “kill switch”. Some activity that completely resets your brain, clears out everything you’ve been thinking about and lets you get into the relaxation zone (rather than the work “zone”). For me this kill switch is Company of Heroes (CoH). As soon as I finish for the day, I have a game of CoH and everything I was thinking about is blocked out. I put 100% of my concentration into playing the game and come out the other end with a clear head ready to relax for the evening. For other people this kill switch comes in the form of WoW. After a hard day they sit and relax, focussing their mind on Azeroth to help forget the stresses of the day.

Whatever the game or activity the important purpose is to put a barrier between work and “not work”. Many people already have this activity they perform, but don’t consciously do it at the end of the day to form a barrier. It becomes a routine and lets your brain form the habit of switching off after the activity is complete.

As game developers, the bonus of this kill switch being a game is that it forces me to actually play a game (even if it’s just one). One of the most noticeable differences in my life since becoming a game developer is that I play a lot less games. I believe it’s vital for game developers to play games to keep a view on the gaming landscape as it changes from year to year. It’s also important to see our craft from the other side, as a gamer.

Working Area

The second important way of differentiating my time is having a separate area that is used only for work. In the current age, this can be quite difficult as often the computer is the centre of both work and entertainment. By keeping my working area separate from everything else at home there is a definitive area that is my work station. I pretend like I’m “heading to the office” when I walk over to my desk and when I’m here, it’s all business.

I find my iPad is a great way for me to be connected while not “working”. Rather than sitting at my computer surfing the web or sending personal emails, I’ll sit on the couch with my iPad on my lap.

Laptops are also perfect ways of physically relocating to be outside of my work area. If I need a computer for something personal, I’ll take my laptop and sit on the couch. It may seem silly, but this small difference is enough for me to not feel like I’m working.

Set Standard Hours

This is an easy one. I’ve found a lot of Indie friends begin working sporadic hours when they start working from home. While its great fun to stay up until 3am getting that last task finished I’ve found it has a detrimental effect in the long run. I like to get 10 hours of work into a day and so I set myself a start and end time. I begin work around 6am and finish at 4pm. I’ll set my status to “do not disturb” and I’ll work through as solidly as I can. One important key is that if something comes up that interrupts me, I don’t count that time towards my day. So if something takes my attention for an hour, then I at it to the end of the day and finish at 5pm. After a few days of working 6am-7pm I quickly realised the importance of cutting out interruptions.

Whether you want to be as strict as that or not, the key is keeping consistent working hours that are sustainable for a long period. Software development is a marathon, not a sprint and it’s important to schedule your day to fit this. If you find you’re burning out after a few days or weeks then look at adjusting your work hours to better fit the long-haul.

Write Everything Down

“Getting Things Done” is a great book that I’ve spoken about countless times in the past. I recommend it for everyone, particularly those working from home. It helps you to become more productive and sort your life out. The main key I get from this is that I make lists for everything. As soon as I think of something, particularly if it’s outside of “work hours” I write it down, set a reminder in outlook for the next day and don’t think about it again. If I am laying in bed and something pops into my head I’ll add it to my to-do list and then forget about it.

Email Separation

This is another easy one. I like to make sure I can’t get work emails during non-work time. This is easy when working in an office as when you’re away from your desk you usually can’t access your email. It’s important to set up a similar barrier when working from home, much like the physical workspace. I set up different rules on my iPhone so I don’t get push notifications for work emails. If I’m at my desk working it’ll arrive in my inbox but if I’m out for the evening I won’t be distracted by it. There’s nothing worse than getting an email you need to act upon, or that has bad news in it when you’ve finished working for the day. This is particularly important when working with overseas publishers or customers with emails coming in at all hours.

Conclusion

Do you have any other tips for working from home on indie games? Whether working full-time or part-time at home, how do you go about keeping a good work-life balance?

Facts

• On the 31st March 2011, CoHO will shut down the beta servers – source
• After 31st March CoHO will no longer exist, there will be no release after beta.  Relic is no longer working on the product – source
• Commander data will be lost – source
• Company of Heroes has generally had equal or more players online – source
• It has nothing to do with the death of Brian Wood – source
• Development will continue on CoH and Relic are still continuing the franchise, without CoHO – source
• If you registered before February 1 2011 you can get CoH Gold for $4.99 – source
• The Chinese and Korean versions of CoHO will also be closing – source

Verdict

This has come as a surprise to myself and a lot of other people. However, I had just been thinking the other day though that the incentive for me to invest money isn’t really high enough. I would have happily paid $15/month of in-game items however there was no need as I was able to buy everything I wanted entirely with in-game currency.  The more I played, the more in-game currency I earned. This seems the wrong way around to me as it’s the people that play a lot of CoHO that would be willing to fork out the cash.

It seems that having both CoH and CoHO side-by-side was a watering down of their market. It makes sense that if one has to go then the free to play is the best option. It was obviously not generating enough revenue for them.

Solution

The best solution I can see to the problem is for Company of Heroes 2 to be released. While I have inside information that another of their great titles is getting an expansion, I’ve been unable to source info on CoH2. This seems like the logical next step for them to take. We’ve seen it with their Dawn of War franchise with great success. My only hope is they don’t go too far down the path of simplifying the game as the did with DoWII with bad consequences.

I’d also like to see an expansion of CoH set in the modern era. I think this could work really well with the tactical style and upgrade system. I can just imagine driving my ASLAV’s around and upgrading them with slat armor (anti-RPG protection). It would work well for the current “war on terror” with the terrorists having a completely different feel to them and using guerrilla tactics. This would give Relic a 3rd series in using the same core engine and open them up to a lot of new customers. There have been countless numbers of WWII RTS games in the past, however the number of modern day realistic RTS games is a lot lower.

Conclusion

What are your thoughts on Company of Heroes Online closing? Did you play it and are you disappointed as I am?

The game will be available on the app store on the 15th December and we’ll have more info in the coming days on Facebook and Twitter and our site.

Check out our first trailer below and watch this space for updates on the game and behind the scene’s look into how we created it.

As Opticode expands during the coming months we’ll be looking to take on a few more programmers so shoot me an email if you’d like to work for an agile company working on some of the latest Microsoft technology.

I’m still working away on the back story to CIC which has become my spare-time hobby. I’ve been asked by quite a few people about CIC’s status and I’m happy to report that while the direct development is on hold, the design is always evolving and the game will be released eventually.

Quite a few people recently have been blaming Java for part of the downfall in current computer science (CS) graduates. While I don’t particularly like java, I’d like to go to its defence to say that teaching Java is not the real reason that a lot of CS graduates are no good these days. I know this is a touchy subject for some people so I apologise in advance if I’ve offended anyone.

It’s not about Language

To jump straight into it, the first language that students learn doesn’t have a lot to do with how good they will end up. Most of the “core languages” (Java, C#, C/C++, VB.NET etc) that you see being taught at universities allow the teaching of the core programming principles:

• Low Level – sequence, conditions and loops

• Mid level – functions, objects and recursion

• Hi Level – Modular design, design patterns, API creation

• High level optimizations – orders of complexity and algorithmic optimization

These principles cover a large amount of “learning to program” and you can teach all of them in any of the languages listed above. So what things are missing from some of these languages (particularly, Java)?

• Pointers
• Low level optimizations
• How operations map down to machine code

The important point here is that these are a small subset of the skills required to program and they don’t require the first language that is taught to students to be C/C++ (or equivalent). Teaching these languages early on is definitely required; however they can easily fit outside the scope of the core introduction courses. The extra bonus from not teaching C/C++ as the first language is that it forces students to learn at least two languages during their first steps into programming and this is a good thing.

So what is the problem with CS graduates?

1. Lack of Passion

Basically it comes down to the fact that lecturers aren’t getting students passionate about programming. One of the key qualities I look for in a great programmer is their love for programming. I’ve found that the best way to get passionate about something is for someone to pass their passion on to you. The best way of doing this is through teaching. I had this very problem while at university and thankfully during my course I did some Microsoft training where our teacher’s passion was passed on to me.

It seems that lecturers are confusing fun with enjoyment/passion. Something doesn’t need to be fun for people to be passionate about it and trying to make courses “more fun” and less boring is not the right approach. The ability to create something has an almost primal feeling of enjoyment and power. Lecturers need to tap into this and get students excited and passionate about what they are creating even if it is hard work.

2. Lack of algorithms and Mathematics

One area that could easily be seen as boring is algorithms and mathematics. If not taught correctly this can certainly be true. However these are a core part of learning to program. The fact that they are language independent proves that Java is not to blame, and that they are more important than mere language choice. With a solid understanding of algorithms and mathematics, programmers can write good code in almost any language.

If algorithms and mathematics are being dropped because lecturers think they are too boring, they need to find someone that can make them exciting! To give an example, I was taught matrix math both at high school and at university. At high school I understood it straight away and had no issues with its use. At university we spent just as long learning it, however it was so convoluted that it almost confused me into forgetting what I had initially learnt. The way in which it was taught was both dry and boring, but also counter-intuitive to the average student that doesn’t have a PHD in mathematics. Any subject matter can be boring if taught badly, lecturers need to stop blaming the content and start looking at their teaching styles.

Conclusion

So the problem at the moment isn’t java but instead the courses and those creating them. I don’t think it matters what language you teach. Without creating passion, teaching core algorithms and mathematics students are never going to be good programmers.

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;

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.

Pie in the Sky

At the most extreme level, the perfect education program would be one attached to a large development studio.  Imagine if Valve had “Valve Education” where you could do a 1 year course and learn everything they know about game development.  Developers from live teams could take time off to teach for a while, to mix up their lives and to pass on their knowledge to others.  While it would make quite a bit of money, the key thing here is that the top x% of students could be hired straight into Valve.  Think of it as a 1 year probation period, where the employee PAYS to be there.  If there are things you don’t like about game programmers in the world at the moment you have the ability to teach them what you want.  Have a subject devoted solely to software practices, and fail any of the kids that aren’t up to it.

Down to earth

So if you’re not Gabe, then the above paragraph may be a little out of reach for you.  Don’t lose hope though, because there’s room in my dream for a less restrictive model.  The main ingredient for me is to find passionate developer’s who can also teach other programmers.  Seniors and leads out there should be doing it all the time, and we just have to get them together to start teaching students.  With the average length of service in the games industry being 5 years, there’s a great opportunity here.  Firstly, it means that it IS worth training up kids as there are a lot of positions that need to be filled by people that don’t have any real world experience in games.  Secondly, it means that there are a lot of developers burning out and wanting to leave.  Rather than going off and becoming business programmers, why not give them the opportunity to use their precious game dev skills.

What’s needed here is a bunch of truly experienced developers getting together and teaching kids exactly what they need to know to make games.  In 1-3 years, the kids should be able to pump out a handful of little games, and one big collaborative game at the end.  Heck, you could even sell the large game at the end and give the students a discount on their fees based on how well it sells.

Bureaucracy and Money

The biggest issue I see with current game dev courses is the amount of bureaucracy that’s involved in setting up the course.  It’s obviously going to be better to have the course meet requirements for a Bachelor’s degree or equivalent, but try not to let this ruin the course itself.  From what I’ve seen in courses there is a lot of irrelevant material taught.  If this HAS to be taught then do it quickly, and get it out of the road.  The key here is teaching kids how to make games, and make them well.  If the course is set up to make money then there’s a good chance it’s not going to work.  The main focus here needs to be making good game programmers.  Once you start pumping out awesome programmer’s I guarantee you their tuition fees will be the smallest part of your income.  You’ll have people wanting to pay top dollar for your students, people will want to start advertising to your students to use their tech and you could even secure a deal with a certain large video card manufacturer to focus your education on their cards.

Conclusion

There is a massive market for game development education at the moment, a vacuum I see filling very quickly.  I just hope that at least some of the new courses are better than the ones I’ve already heard about.  So there is my dream.  I’m a little too poor and busy right now to set this up, so I’m leaving it for anyone else to try.  Let me know how you do and we can work out the commission I get later.

As fate would have it, my 4th anniversary for being in the games industry comes up tomorrow.  While I’ll still be working on games tech as a contractor, I’m officially no longer a full-time game programmer.  I’ve now moved into the realm of entrepreneur and business owner.  I’ve also just moved into my new home and am more over moving than I’ve ever been.  I’ve set up a small home office with a few computers, whiteboard etc ready for the business to begin.  I’ll keep you posted with how things go, however I’ll still keep this blog primarily game related.