Overview

Our primary platform for Battle Group is iOS (iPhone, iPad and iPod Touch) while our primary development platform is PC. This took us approximately four months to complete and it took a further 10 days to port to Android, Pc and Mac. Our first two games were both iOS exclusive so this was our first time developing for the other three platforms as an indie team.

Input Changes (Mac and PC)

One of the biggest challenges was making the game work well with both touch and mouse input. Back when we created Flick Buddies I created a unified input system so that the mouse and touch are treated through the same code path. This went a long way to simplifying the process of targeting both input systems. The input basically boiled down to “On Down”, “On Move” and “On Up”. Unity’s “Touch” class is extremely helpful and saved us a lot of time. The only game specific challenge we faced was around ship selection. We made use of the scroll wheel and keyboard for extra player control, both of which only took an hour or so with Unity.

Overall we were really happy with the way the input worked across all platforms and we decided to keep them very similar.

Multiple Resolutions (PC, Mac and Android)

The area I’m least happy about with Battle Group is the multiple resolution support. While we support any resolution and aspect ratio, the fact we targeted iPad primarily (1024×768) meant the game isn’t really wide screen. We decided to fully support any aspect ratio between iPad and iPhone and add letterboxing to resolutions outside this. For gameplay reasons we could not allow an unlimited amount of aspect ratios without letterboxing. The biggest concern for me is that letterboxing usually runs along the top and bottom of the view and people expect this. In Battle Group, as we targeted iPad primarily, our letterboxing runs along the left and right handside for extremely widescreen aspect ratios.

The actual implementation of multiple resolutions was fairly straightforward with Unity. As Battle Group is a 2D game we were using an orthographic camera and I simply adjusted the size of the camera’s view area to accommodate different resolutions. The biggest complexity involved created the settings page allowing players to choose the resolution and full screen. Unity has amazing support for resolution changing, including full screen and windows. I have horrid memories in DirectX of lost context and all sorts of issues that are gracefully handled for us now.

One small point of concern is multiple monitor support. Out of the box, Unity doesn’t support locking the mouse cursor to the primary screen. There are some platform specific workarounds but nothing I was happy with and so for version 1 we don’t lock the mouse cursor. This is a personal pet hate of mine and so I was quite disappointed however timeframes didn’t allow me to obsess to long on this feature.

Demo Version (PC)

The PC version we sell through our website has a demo that unlocks with a CD key. I spent a while looking for example code for CD keys but couldn’t find any I was happy with. Instead I spent a few hours and threw together my own CD key generation and checks and it’s worked quite well. I used Unity’s built in text box for the CD key input and this actually worked quite well. Players can cut and paste the CD key from anywhere and I then do some quick validation. I always warn my students not to use the built in Unity GUI, however in this case it worked really well.

Mac App Store

We decided to release a Mac version on their Mac App Store to coincide with the iOS release. Having already ported to PC this was an extremely simple process until the very end. Unfortunately there’s a little monkey work that needs to be completed in the final step that Unity does not currently handle. Check out the following links for detailed instructions on how to complete this:

• http://technology.blurst.com/unity-games-and-mac-app-store
• http://forum.unity3d.com/threads/71340-Submit-Unity-games-to-the-Mac-App-Store!

One key point is that you need to make sure “Player Log” is turned OFF. We failed certification the first time as we were still writing out our log file.

The Mac version of Battle Group is actually our best seller at the moment. We were featured in “New & Noteworthy” and we are currently the #4 game in Australia and #12 game in the US. This was a great surprise and we were really happy we took the time to port to the Mac App Store.

Android

After initial issues setting up the ADB driver for my Android device this was another smooth process. The Android shares nearly all the code of its iOS sibling and the only major difference was supporting multiple resolutions and aspect ratios for all the different Android devices. I had already completed the resolution code for the PC version and therefore this all “just worked”.

Post release, we had a small hiccup with “1 star spam” where someone (probably a competitor) spammed our game with 40 1 star ratings in under 30 minutes. Thankfully Google were quick to rectify this, however it was not a great feeling.

Performance

I spent a week or so heavily optimizing the game and rendering for Battle Group about three quarters of the way through development. Per platform optimizations weren’t really necessary and we’re happy with the frame rate on all platforms. There were really only two limitations I put on our game designer as he created levels, both of which were increased at his request a number of times. These were mainly around the number of concurrent enemies on screen at one time as both the game logic and rendering increased linearly with this number. The only major outstanding concern I didn’t get enough time to look into was load times on some slower devices. For some reason Android particularly takes a lot longer to load than its iOS counterpart and this is something I am planning to fix in a future patch.

Closing Thoughts

Overall I was overjoyed with how well the porting process went. I consider it one of my least favourite parts of video game development and the fact it went so quickly and smoothly was excellent. I always listed cross platform support as one of Unity’s biggest drawcards and now I can confirm this. Not just that, but the simplicity of this cross platform development is a real plus. For a small studio, spending months porting to new platforms simply isn’t an option for us and this has allowed us to hit all the platforms we wanted on the same day.

Instead of spending time porting we can now work on updates to Battle Group and future games that we have begun prototyping.

What’s Working

• Tools

The biggest change I’ve seen in our game development lives in the last few years is the ubiquity of high quality game engine tools. It’s no secret that I’m a big fan of Unity and we’re currently using it to create our third game. Unlike our first two games, this time we’re planning to release on no less than 4 platforms simultaneously. Without the power of Unity this would simply not be feasible for a small indie company that’s still in startup mode. I’ve heard the promise of “write once, deploy anywhere” a number of times in the past but it seems like this is the first time it’s actually come true. Unreal and CryEngine are now free giving indie’s great access to high quality development tools.

Along with multi-platform support is the breadth of features found in these tools that means we can create small to medium sized games with multi-month development cycles with only a single programmer in the team.

• Distributed Development

Internet communication has reached a level where we can build an entire game together from the comfort of our respective homes. Leasing an office at this stage in our company would cost more than the rest of the games development combined. With the use of Skype, Dropbox and Acunote we can work seamlessly together sharing ideas and large files as if we were in the same office. There’s still a few issues that come up, but most of these are resolved with weekly face-to-face meetings. We’re still planning to get an office in the near future, however it’s not as pressing a concern as it has been in the past.

• Platforms

Something else that’s changed considerably since I left mainstream game development is the number of platforms we can target. It’s easy to take this for granted, particularly as they’ve grown at a fairly linear rate over the past few years. I’ve always been a firm believer in letting a game design pick the platform that suits it best, however not until recently has this been a feasible option for indie game developers. We can now choose between console, mobile, web and more traditional platforms and have the ability to target them with even the smallest budget. With the barrier to entry being measured in the hundreds of dollars even a hobbyist student can forgo drinking for a few weeks to fund their next game.

What’s Not Working

• Games still take too long to make

I’m continually frustrated with the time it takes to create games. Every game I’ve ever worked on has run overtime, often by over 50% of their original estimate. After speaking to other developers, thankfully this is not just something I struggle with. I’ve found there are two major milestones a game developer reaches in their career. The first is actually finishing a game, something I had trouble with when starting out (I still have countless half-finished projects laying around my old HDD). The second is finishing a game within the original estimate, something nearly every developer I know still struggles with no matter how many years they’ve been working.

I spend considerable time and effort trying to solve this problem and I feel as though each project we refine our process and things are slowly getting better. Despite my first point, I feel tools are the biggest opportunity for us to solve this issue. When I started out in game development I had a very negative view on tools development and felt it was not my job to create tools. I’ve since learnt this is a very closed minded view of game development. Team Bondi’s recent game (and closure) is a perfect example of this. I’ve heard a number of developers share anecdotes of the development where making simple changes (such as the placement of a trigger) would have a turn-around time measured in the tens of minutes. Small issues like this add up over time and cause games to blow out their time and budget.

• Australian Game Industry

I left Auran two weeks before it closed down back in 2007. Since then I’ve watched as many of my closest friends and ex-colleagues lose their jobs as the number of large studios dwindles. There are countless reasons for this downsizing but what’s important is the fact many of the smartest people I’ve worked have been forced to move overseas to find work in the game industry or worse, move into more mundane jobs to make ends meet. I am hopeful that the growing number of independent studios forming from the ashes will see success and we will have a second chance at building the Australian game industry while learning from our previous mistakes.

I’ve heard Alex speak a number of times in the past and a recurring theme is that he is always being asked when his game is finished, and when it will be released. Alex has some strong views on this that I completely agree with, relating to quality levels required before a game is ready for release. Our own game Battle Group has been pushed back from our (internally planned) release date a number of times in it’s 4 month development. It’s a recurring theme on every game I’ve worked on, both independently and at larger studios, they are always late. The question is, how can we objectively determine when the game is finished?

“You’re game is finished when someone who hasn’t played it before can play through it’s entirety without assistance” 

Lets dig a little into what this means. Firstly you (or a few key team members) need to sit and watch people play your game. If you’re not doing this, your game shouldn’t be released, period. Without sufficient playtesting there’s no objective way you can determine if your game is ready or not.

Someone can only play through your entire game once you have no show stopper bugs. I can play a game I’m working on for days on end and never come across an issue which a play tester finds within the first few minutes of playing. The game also needs to teach them enough to be able to play through it’s entirety without your help. This is a really difficult task when watching someone make seemingly simple mistakes in your game. I’ve spoken about this previously with “Virgin” playtesters and spending the weekend watching people play Battle Group only reinforced this for me. If you have to help someone through a certain part, something is wrong.

Related to bugs and assistance is the requirement that you are happy to show people the game in it’s current state. This seems like a no brainer, if you’re not happy to show someone, why would you release? Surprisingly, I’ve seen a number of people so desperate to “just get it out there” that they break this rule. They were all apologies and excuses when I tried to play the game but they felt they were still ready to release it to the world, as if people they don’t know would be more forgiving.

When deciding when a game is finished, there are two areas that people run into trouble:

1. Some people fall into the “it’s never finished” trap. They are usually small teams that aim for absolute perfection and are never happy with the game. These games often disappear and the team gets bored and moves on to something else.

2. At the other extreme are games that are shipped far too soon. These often come from larger studios with external time and money constraints imposed on them.

Either extreme is dangerous and obviously we want to aim for the middle ground between these. Knowing which end of the spectrum you are more likely to favour is important so you can set expectations at the start of the project. The further a game progresses in development the easier it is to diverge towards one of these extremes. When talking about setting the quality level before you begin production on a game I use the analogy of going out drinking. It’s important to set the number of drinks you plan to have in an evening before you start drinking as once you’ve started down that path, your judgement is impaired. The longer your on a project, the more impaired your judgement becomes. Either wanting to “get it out the door” because your sick of working on it, or not wanting to waste the months you’ve been working by releasing an imperfect game.

Only by setting your expectations at the beginning of a project can you have a reasonable chance of setting the quality bar at a safe level. Look at the team makeup, objectives of the game (retail success vs portfolio piece) and project budget/length when deciding what quality bar to aim for.

Speed Dating

Game Connection is described as “speed dating” with publishers. We had 30 minute meetings with as many publishers as we could cram into our time. We had 1.5 of the 3 days Game Connection runs for as we shared a booth with the guys from Last Level Games. This ended up being ample time for us as we met 22 publishers and a few PR/marketing people. Our goal was to form contacts and show off our two prototypes we are developing for iOS, Android and web.

This “speed dating” style was a great way to get in front of publishers we would otherwise never have a chance of meeting face to face. Being from Australia, we are on the other side of the world to many of the publishers, particularly the larger ones. Also, there are a lot of developers pitching their games and having this condensed period for us to briefly meet was perfect.

I had heard from a few people that it is frowned upon for publishers to turn down a meeting with you no matter how small you are, which is perfect for a small team like ourselves. Thankfully, this was true. Nearly every meeting I proposed was accepted and we managed to meet all the publishers we were hoping, from the largest to many small unknowns.

The Process

The process for setting up meetings is fairly simple. A few weeks before the event, the system opens up and you can request meetings with as many people as you have space for. After a set period this shuts down and the system automatically matches you together and sets up a room for the two parties to meet. For the most part, we stayed in our booth (about 3x3m) and publishers came to us. Any spots that are free after this time can then manually be filled in with other publishers. The system does a good job of letting you know whether you both have a free spot at the same time.

My only complaint about this system is it’s a little harsh as I ended up having 16 meetings in 8 hours on my first day. This left me no time for grabbing lunch, let alone a break to use the amenities. Thankfully some of the meetings ran under time (and I had a single no-show) which gave me time to dash off for food and a comfort stop.

Response

Our two prototypes were very much in the prototype stage. I had spent a couple of days coding them and our artist had put a few hours into turning my primary coloured abomination into a nice looking tech demo.

Despite the simplicity of the demos every publisher could see the core of the game and judged it upon its merits. I was blown away by the response from the publishers with all but four giving us amazing responses. Everyone loved the ideas with a number of people giving amazing feedback within only minutes of seeing the games. We even begin discussing specifics of deals with a number of publishers during our short meeting.

One of our demo’s particularly shined and based on the feedback we received we have decided to pursue it next and look at our options for funding and publishing with the people we’ve met. Unfortunately I can’t give any more details as we move forward with our dealings, suffice to say we are extremely happy with the response.

Cost

We were extremely fortunate that the Queensland Government helped pay a large percentage of the usual cost of taking part in Game Connection. This support combined with sharing a booth made it affordable even for a small indie developer such as ourselves. If it weren’t for this, we likely would not have been able to justify the full price of 2,700 to 4,700 Euro’s for the event.

This cost will also likely be restrictive to many indie developers. It makes it hard for me to recommend the event to smaller developers where this amount of money makes up a substantial amount of their entire game budget. It really comes down to what you want to get out of the event. We managed to talk to many of the big publishers and a lot of smaller publishers from around the world that we would simply never be able to meet. If you factor in flying overseas to meet with a publisher this price point quickly becomes reasonable for the sheer volume of people you can meet.

I highly recommend any smaller indie thinking of taking part in Game Connection next year to check out the competitions on offer such as this years.

Should You Participate Next Year?

I highly recommend Game Connection to anyone looking to get their game published. It’s the perfect place to meet with a multitude of publishers to cast out the widest next possible. We found a few publishers we’d never heard of that seem like almost a perfect match for our small indie team. Meeting face to face is vitally important and this was a great way of achieving this.

In the end, it really comes down to the money. If you can afford $2-4k Euro’s then I highly recommend, however if you can’t I’d recommend petitioning your government to see if you can get assistance as we did. I would love to see an “Indie” pass or similar offered by Game Connection for a shorter time at a lower cost.

Conclusion

Have you been to Game Connection or do you plan to go next year? Or is this cost simply too prohibitive?

Single Responsibility Principle

“There should never be more than one reason for a class to change.”

The first principle is the cornerstone of the set and gives the greatest return on investment when followed correctly.  It states that each class should have only a single responsibility and therefore reason to change.  Keeping each class small and tightly focussed allows developers to know exactly where to go to find or add particular functionality to the game. 

Why is having more than one responsibility bad?  Multiple responsibilities means there is coupling between separate pieces of code.  Changes to one responsibility reduce the ability for the class to meet the requirements of the other responsibilities.  This leads to fragile design that breaks often and in unexpected ways.  “Why did changing from rendering API break jumping in the game?”

The way to fix code that breaks this principle is to separate each responsibility into its own class.  The first step can be to extract an interface per responsibility.  Other classes can then rely on these interfaces rather than the class itself.  The class can then safely be split up into separate classes for each responsibility that each implements a single interface.

When have you got it? – The usual culprit breaking this principle is that one (or group) class that’s hundreds or thousands of lines long.  You know the one I’m talking about. Often it’s the GameObject or Entity class that everyone seems to throw code into.  This class usually has about 500 reasons to change, and therefore 500 responsibilities.  It’s usually involved in the heinous bugs that crop up constantly.

Open Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

The goal of this principle is for each class to change as infrequently as possible while allowing it to be used in as many situations as possible.  While these two requirements may seem at odds they actually complement each other to generate robust design.  A class is open for extension means that the behaviour of a class can be changed in new and different ways as the requirements change.  A class is closed for modification when no source code changes are required for these changes in requirements to be met.

This principle can easily be resolved with data driven design.  By passing the required configuration data to a class it can easily be extended reducing its need for modification.  Any variables (in the mathematical sense) should be passed to the class so that the classes definition itself (the code) does not specify the functionality of the class alone.  I find this the easiest to think about in terms of the basic OOD principle of data and operations.  The class defines the operations it can perform (its functions) and the data that it operates on.  As much of this data as possible should be passed to the class/function.  This moves the configuration of its data outside the class itself to the calling code increasing its ability to change.

When have you got it? – This is the file you dread checking-in because everyone seems to be working on it all the time.  No matter what system you’re working on, these files always seem to be involved.

Liskov Substitution Principle

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Inheritance and polymorphism are powerful mechanisms for solving complex problems with simple solutions.  They are also powerful mechanisms for creating bugs and problematic code.  This principle involves making sure inheritance hierarchies are sound and not being abused by code that introduces bugs that are hard to find.  While it seems simple on the surface, this principle can be quite complex to solve correctly.

The first steps to solving this problem are to find instances of checking for an objects type – both its own and that of objects it’s working on.  Beyond this easy first step comes a principle known as “Design By Contract”.  Each function has a set of conditions that must be true before it is called (pre-conditions) and a set of conditions it guarantees are met after its completion (post-conditions).  These are often implied conditions kept in the mind(s) of the programmer(s) working on them.  The first step is formalising these conditions into code.  Once this step is completed the following rule can be met – “Derived classes can only weaken pre-conditions and strengthen post-conditions”.  Put another way, functions of a derived class should expect no more than their base class and promise no less.  This principle is important because of the fact a model viewed in isolation cannot be meaningfully validated.  You don’t know whether your new “Tank” class is valid until you run it in the context of its parent, siblings and other game system.

When have you got it? – Classes breaking this rule are really easy to find.  Look for any base class that uses run-time type information (RTTI) to interrogate its own type (or the type of an object it’s working on).  As soon as the GameEntity class is checking if it’s of type “Tank” to do some special code, you’ve broken this principle.  The class should be able to polymorphically call functions without caring about the actual type of the object.

Interface Segregation Principle

“Clients should not be forced to depend upon interfaces that they do not use.”

Interfaces should be used for communication between different objects to encourage clean, modular code. This principle takes that concept further by making sure that the interfaces we use are themselves clean and unified. The larger the interface, the more the client is relying on functionality of another object. By keeping small segregated interfaces each object will rely upon only the smallest set of functionality it actually requires. This reduces the complexity of links between objects and more importantly, lets someone reading your code know exactly what each class relies upon. Rather than one “fat” interface we break the interface up into multiple smaller groups of functionality that each serve a different client.

This principle links back to the single responsibility principle nicely. In this case each interface should have a single responsibility. This lets you explicitly state the functionality requirements of each object based on the interfaces it requires.

When have you got it? – Look at all your interfaces (abstract classes) and make sure their listing of functions are homogenous.  An easy way to tell you’ve broken this principle is when there are small groupings of functions within the interface definition.  Whitespace is the key here, the more whitespace between the groups of functions, the more disparate they are.

Dependency Inversion Principle

“High level modules should not depend upon low level modules. Both should depend upon abstractions.”

“Abstractions should not depend upon details. Details should depend upon abstractions.”

This is a key point that I had not heard of at all in game development until recently. This principle is quite the opposite of how many developers are used to working. Usually, if a class depends on another class, the client will instantiate an object of that class and then act upon it. Dependency Inversion (also called Inversion of Control) turns this on its head. Instead of the client being responsible for creating the object, it is given the object it depends on. This takes the control away from the client and moves it to the owner of the client, often the game engine.

A good example of this is in a rendering system. Rather than instantiating a rendering object, or directly calling the classes of the rendering API, the rendering system should receive an interface to the low level rendering functionality. By relying on an interface that is given to the rendering system, the low level rendering API can be changed without making breaking changes to the client rendering system. It becomes obvious if breaking changes occur as the low level rendering API’s interface will require changing.

When have you got it? – When two systems are talking to each other, how do they do it?  If they are using concrete classes then look for opportunities for them to rely on interfaces instead.  The best way is for the class to take as parameter to its constructor an interface reference to the class it needs to work on.  This also makes it obvious what sub-systems are particular class is reliant on.

Conclusion

What are your thoughts on the SOLID principles? Do you see benefit from adopting these in the games industry as web and application development has done?

SOLID Motivational Posters, by Derick Bailey

1. Set Your Goals

It’s important to decide exactly why you’re making the prototype, and what you hope to achieve. These goals show you where to focus your time while developing the prototype. For us it’s about testing gameplay mechanics and proving the core concept of the game. A secondary goal is having playable prototypes we can show potential publishers to quickly get across the feel of the game.

Without these goals, it’s difficult to know where your time is best spent. Is this about testing a mechanic on a particular platform or finding whether certain gameplay is fun? Could the game better be served by a pen and paper prototype first? It’s worth spending some time before you begin, deciding the best use of your resources.

2. Timeboxing

I always set a specific limit on how long I can afford to spend on the prototype. It’s easy to get carried away once I start and I can easily lose a lot more time than is necessary. Timeboxing forces me to focus on the most important elements of the prototype as I can’t do everything.

The actual length of time allocated depends entirely on your situation. I allocate 20 man hours per prototype which fits nicely into two work days for me. I find two days is the perfect length for completing the core elements while keeping time short so I am forced to focus.

3. Throw It Away

This is a tough one for some people, but I always recommend planning to throw the prototype away. This has a number of core benefits:

1. Pragmatic – This stops me from doing any big design up front and forces me to do just enough to get the task done. It puts me in a completely different mindset while developing as I just want to get it done as quickly as possible.
2. Lessons learned – When you begin work on the real game you will have previous experience in implementing the same features and solving the same problems. This will help improve the design of the game, both at a software and gameplay level. With some particularly complex problems (“wicked problems” according to McConnell) we must try solving the problem first, before we can fully understand it and find the optimal solution.
3. Less Constraints – If you’re throwing away the prototype there’s less constraints on how you build the prototype. You can use whatever technology is best for prototyping, rather than the best for creating complete games. If you don’t follow company (or personal) guidelines during the development it’s less of an issue, as it’s a completely separate act.

Rather than laying the foundations for your game your doing the opposite, investigating the best way to build it so that when the time comes to lay the foundations you’re in a better position.

4. Key Gameplay Only

I only focus on what’s different about the current game. If I’m making a clone, then really, what’s the point in prototyping? I pick out the gameplay elements that make the game stand out and test those to make sure they work and tweak them. One of our prototypes is a new twist on the platformer genre. I spent as little time on the platformer elements and focussed on “the twist”.

Another way of looking at this is to test the highest risk elements of the game. Gameplay that will make or break the game is important to test as early as possible. Often I find some ideas simply don’t work, and it’s much better to find this out in the first few days of development.

5. Allow Tweaking

I expose as much as possible to my designers and even play testers so they can tweak the gameplay. The game will be in a very rough form and allowing rapid changes to core gameplay can help steer the game in the correct direction.

Another of our prototypes is an asynchronous strategy game. I’ve exposed the start and win conditions and all unit stats. Small changes to these completely change the way the game plays. This is perfect for a prototype as it lets anyone play with the values and suggest changes to the originals. This pushes the burden of experimenting, balancing and tweaking off the prototype team and onto anyone else that plays the game.

6. Divide The Game Up

If I’m working on a large game I’ll divide the different elements up into separate prototypes. For example in the “Total War” series I would make the strategic and battle maps completely different prototypes. This has a number of core benefits:

1. Separate teams can work on each prototype if needed
2. Different technology and tools can be used if helpful
3. Each individual part of the game can be judged independently. Perhaps some areas are less fun than others? You can look at each part as its own game and easily see its strengths and weaknesses.
   

7. Run On Target Platform

I always find that to get the full user experience of a prototype it’s best to run on the target platform. This is core to the gameplay experience and for certain platforms will completely alter the reaction to the prototype.

The only time I don’t do this is when it will blow out the schedule to do so or if there are other constraints that make it impossible (e.g. platform owner restrictions). In this case I do my best to imitate the platform it will run on to get the user experience as close to the real platform as possible.

8. Have External Material

Some things are better completed outside of the prototype itself to save time. I often write tutorials and help screens as a series of screenshots of the game with instructions overlayed. This is far quicker to do in Photoshop than implementing within the prototype. While having screenshots as a tutorial isn’t as good a user experience it saves time that can be spent implementing other features of the prototype.

Another time saver is to walk people through the prototype personally, replacing the tutorial. I like to watch people playing the prototype as much as possible and explaining the game to them is the perfect way to open up a dialog about the prototype.

Conclusion

What are your tips for prototyping? How long do you like to spend and do you throw them away once finished?

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?

Multi-platform development

If, like us, you’re making games for web and iOS then this is really a no-brainer. The extra development time is not something we can afford when there’s a perfect alternative in Unity. With Flick Buddies, we developed the web and iOS version simultaneously without any extra effort. All our games in the future will see simultaneous releases for both web and iOS which will help drive customers from the free web version up to the paid iOS version.

The main argument against using Unity is that with such a low penetration rate (for arguments sake we’ll go with 1%) users will bounce from your site when they hit the Unity installation page. Taking the statistics (from Unity and others) lets go for the low end and say that 50% of users will bounce when they see the Unity installation page.

Rather than looking at it from percentage of users being lost, let’s look the other way around. If you’re developing an iOS game you can release a web version for relatively little development cost and capture 50% of the potential web market. If you were to instead create a flash version you would have the full development costs of porting the game to get 100% of the market.

Looking at the cost/benefit ratio the Unity version is a much better option. The only time this becomes a negative is if you have a highly successful game, in which case losing 50% of the market will end up costing an order of magnitude more than the development costs of porting to flash. In that case, go for it! There’s nothing stopping you from later creating the game in flash once you know there’s a large enough market for it.  Where the cost of porting the game will easily be made up by the 50% more users you’ll receive.

Another interesting point I’ve heard is that the more popular a game is, the lower the bounce rate.  If you have a highly successful game that people really want to play, the act of installing a plugin will be less of an issue for them. This goes some way to negating the lost sales for a highly successful game.

Web games only

What if you’re making web games only? In this case it’s not quite as clear cut and we have to dig a little further. I’m still inclined to go with Unity for web only games for a number of key reasons:

1. You can give a richer game experience including 3D. While 3D is coming to Flash soon, it’s at a lot lower level requiring far more development time and cutting out many less experienced developers.
2. Much richer tools and pipeline. I’ve previously discussed how much I love the Unity editor and asset pipeline. This lets you get your games out faster and cheaper. This saving offsets the 50% bounce rate.
3. There’s the opportunity to have a unified language running between client and server when using C# within Unity.  This simplifies communication as well as allowing the exact same code to run at both ends if required.

The Minecraft example

I like to use Minecraft as an example of bounce rate when discussing Unity and Flash. Minecraft requires an .exe to be downloaded and run before the game can be played. This is far more intrusive than a browser plugin and yet it’s still had great success. With Unity developers can create something as successful as Minecraft with a lower bounce rate due to installation and have the ability to port to iOS and other platforms easily.

Flash was once like this

I remember when Flash was at a similar position to Unity, albeit with web pages rather than games. Many people said that you shouldn’t make websites with Flash as it required users to download a plugin if they didn’t have it. Not only did Flash reach the penetration rates it desired, times have also changed in Unity’s favour:

1. Faster downloads mean there’s less of an issue in the download time of the plugin
2. Seamless installation reduces the bounce rate with unsophisticated users
3. Larger sites (like Kongregate) are getting behind Unity which makes it more trustworthy in users eyes

What can Unity Technologies do about it?

I saw a similar issue with Silverlight penetration and I find myself again thinking of inventive ways for companies to increase penetration of their plugins. This could be as simple as a referral program, offering 1-10c each time a user installs the Unity plugin on your site. This motivates developers to make awesome free games with a guaranteed return as an alternative to advertising. Unity can then buy installations for as little as $10k per 1 million users.

It’s in Unity Technologies best interest for penetration rates to go up as quickly as possible and I’d like to see a novel approach to achieving this. While the penetration rate will naturally increase over time, it will take quite a while.

Conclusion

What are your thoughts on Unity’s penetration rates? Is the bounce rate just too high for you to switch over?

Introduction

Unity (often referred to as Unity3D) is an authoring tool for creating 3D games for a large range of platforms (ranging from iOS to PC and recently Xbox360 and Wii).  It has been out for a number of years although it’s popularity has sky-rocketed in the last couple of years with the release of a PC version of the editor to compliment its original Mac version as well as moving to a free model for independent developers.

Since going free, Unity seems to have been surrounded by an ever increasing amount of good news.  It’s constantly adding new platforms to its list, is being used by an increasing number of developers and provides consistently useful updates that solve many of people’s concerns.  The only negative press it’s received of late was when Apple looked like they were going to ban 3^rd party engines like Unity from running on their iOS devices.  This never eventuated and Apple has since relaxed their restrictions.

Unity comes in a number of different price points:

• Unity (basic) – Free
• Unity Pro – $1500
• iOS – $400
• iOS Pro (requires Unity Pro) – $1500
• Android Pro (requires Unity Pro) – $1500

Pros

Unity has been an absolute pleasure to work with.  I’ve worked with a number of engines in the past both proprietary and off the shelf (such as Torque and Unreal) and I’ve found Unity to be the most enjoyable to work with.

Platform Support

The biggest drawcard for many developers is the huge list of platforms Unity supports.  At the time of writing, this list included:

• Web and stand-alone – with support for PC and Mac
• iOS – iPhone, iPad and iPod Touch
• Android
• Nintendo Wii
• Xbox 360 & PS3

While each platform has different pricing points, the fact that a game can easily be ported between these various platforms is a massive advantage for Unity.  For a small indie company like ourselves, without the resources to port games to different platforms, we find it invaluable that we can simply change the destination platform and create a build.

Unified Editor

A strong list of platforms is great, however what makes this ideal is the unified editor.  Unity’s unified editor means that you work within a single editor interface and share all your code and assets between projects.  Unlike the previous version of Unity (pre 3.0) where a different editor was required for the iOS build, everything happens within the single, unified editor.

Small amounts of conditional code can be written for different platforms, however of the ~4000 lines of code we wrote about 5 of them were conditionally compiled out.  I also wrote a small class that handled finger and mouse input through a single code path freeing up the design to treat both PC/Mac and iOS platforms in a similar way.

Unity also supports per-platform settings for all your assets, for example setting a maximum texture size for iPhone to keep you under the 20MB wifi budget.

Great Visual

Unity has great support for advanced effects.  It has a large list of built in shaders and materials as well as full custom shader support.  We primarily used the built in shaders, however in a few special circumstances I dropped into writing a few simple shaders for some custom effects.

The great visuals also scale down well on iOS devices.  While the game looks much nicer on PC with full anti-aliasing and higher quality lighting, for the screen size the game still looks amazing on iOS, particularly the iPhone 4’s retina display.  There is a strong limit on the shader capability on the iOS devices however due to their lack of processing power.  This is not a major concern for us, but means you have to employ some old-school tactics to get the best looking visuals without resorting to costly shaders.

An example of this is the outline we used on our characters in Flick Buddies.  We originally wanted a black and then white border to stylize the characters in a similar way to their 2D representations.  Instead of writing a shader I had to do the old trick of exporting the model a second time with its vertices pushed out along their normals and then inverted to get the same effect.

Excellent Editor

I’ve spoken about the fact the editor is unified, however I also wanted to touch on the editor itself.  With its intuitive interface it’s easy to get up and running quickly.  I gave a guest lecture at a local university and the entire class of 30 students were up and running within a couple of hours, navigating their way around the interface making changes and customizing the small game we created.

The only negative point I found with the editor was the lack of multi-select support.  You can make simple changes to position, size and orientation with multiple objects selected, otherwise though you have to make changes individually.  A couple of times during the project this was a real pain, however it was workable.

Maturity

With every passing month the tools and community seem to becoming more mature.  answers.unity.com is an awesome resource.  Nearly every issue I ran into had a solution which made life easy.  They are also quick to respond with new issues that arise.  Unity also has a solid list of example projects which are great for getting a head start on a game.  It’s also a great way to see best practices for usage within the editor.

With the recent release of the Asset Store, Unity has a good opportunity to create a thriving community that share assets of all types.  As this was released towards the end of our project we didn’t make use of the Asset Store, however we’ll be keeping an eye on it for assistance in future games.  While it currently has a limited selection we’re hoping it takes off in the near future.

Rapid Application Development

I love my RAD.  One if the biggest drawcards for me personally was the quick turnaround in producing our game.  Despite learning Unity as I created Flick Buddies, I still managed the following:

• Playable prototype up in a few hours
• First playable level within 10 hours
• Prototyped all 12 levels within 40 hours

I’m a huge fan of C# as a language to rapidly develop games.  Combining the ease of use of the editor with the robust nature of C# programming I found I could fly through all the features in the game with few bugs and only crashes in the last 24 hours of development (right when you don’t want them).

Cons

Unity is without its faults.  Whenever I explain Unity to someone, I usually list these three issues as it’s a lot quicker than explaining all the great things I love about it.

No Great 2D Support

Out of the box, Unity doesn’t have a sprite library for rendering 2D sprites.  It’s the number 1 request from developers and it will hopefully be coming soon:

http://feedback.unity3d.com/forums/15793-unity-iphone/suggestions/163934-graphics-native-fast-sprite-manager

Until this is released there are three workarounds:

• Use an orthographic  camera and manage your own 2D animation
• Use Sprite Manager or purchase Sprite Manager 2
• Use the built in GUI Texture – not recommended as it’s slow and hard to use

Bad GUI

The built in GUI in Unity is terrible.  It’s fine for rapid throwaway prototyping to get something on the screen, but otherwise I highly recommend steering clear of it.  It performs badly and has a major bug in it which averages the position of multiple fingers and produces a “press” in the middle (where there is no finger).

The simplest workaround for this is to roll your own GUI.  Flick Buddies was very light on with GUI so this wasn’t an issue, however for more GUI intensive games this may cause some problems.

Multi-Developer Support

This was the biggest issue we had with Unity.  As with the other issues there is a work around, however this one requires a fairly large investment for a small indie company (~$2000 per developer)

The Unity editor has a strange way of dealing with files, using a combination of a database and the asset files themselves.  This means that it’s not possible to use a regular source control system (like SVN which we use on other projects) for the bulk of the files.  The pro version of Unity does support a special feature which allows the use of SVN however it doesn’t just work out of the box, and I have heard of a few people having issues with this.

The ultimate (and most costly) solution is the Unity Asset Server.  For this you will need a Unity Pro license as well as the Asset Server client license.

We managed to work around Unity’s shortcomings as I was the only develper working on the game itself with our single level designer working on the “scene” files in isolation.  He would get a copy of the entire source tree, make changes to the scene (and occasionally animation files) and then copy the few files he changed back up in to the source tree.  We used Dropbox for this and other than a few minor issues it worked quite well.

I have still not solved this problem and I’m not happy with our current setup.  I will be investigating this further in the future and we may simply go down the Unity Asset Server route.

Conclusion

Overall I found Unity 3 a pleasure to work with and we plan to use it for all our games in the future.  Its tiered pricing model works well for indie’s of all sizes.

Have you used Unity?  Do you have thoughts on the pros and cons I’ve listed or have other items that should be in the list?

Flick Buddies:
http://itunes.apple.com/app/flick-buddies/id405424038?mt=8

Flick Buddies HD:
http://itunes.apple.com/us/app/flick-buddies-hd/id405425109?mt=8

Also, check out our launch trailer: