A complete summary of the race can be found here over at SpeedRunsLive.

We’ve already discussed the prize with bony. No details for you at the moment as the thing is gonna be deviously hidden away somewhere in our next game.

Big thanks to everyone who participated! Also thanks to the crew over at SRL who came with ideas, helped me set this up and what not.

SpeedRunsLive uses a really nifty irc-based system to set up races, hook up streams and what not, so in order to participate in the race in the first place you will need to connect to their irc server ( irc.speedrunslive.com ) and join the #nimbus channel. For more details about this, check out the FAQ on their site. It should cover most things you need to get your stuff up and running.

The prize will be a piece of content for our current project (Nimbus+) designed by the winner. The winner gets to chose between designing a level or designing a massive statue to be placed somewhere in the game. It’s possible to suggest something entirely different, but due to time constraints it is likely to not happen. Still worth a try though. Also be mindful of copyright infringement and obscene stuff, we want to avoid being chased by someones legal team or put a giant penis in the game!

Race rules:

• The race will be an Any% run
• The race starts by entering the Intro-level
• The race ends when you clear the Credits-level
• You are required to stream your race
• You are required clear your game progress before the race

When:

• March 23, 19:00 GMT / 2PM EST

Where:

• irc.speedrunslive.com
• #nimbus

If you don’t want lose your progress you can find your save file in …\Steam\userdata\your user ID\50000\remote\leveldata.dat and copy it to another location before you clear it.

Also Due to a massive spam problem we’ve disabled the commenting on our site (that and a lot of other stuff will be fixed sooner or later) so if you have any questions about the race, ask away in the #nimbus channel on the srl irc. People there can fill you in and I usually lurk there as “Kval” as well.

I will update this post with further info if anything comes up.

Good luck!

Some progress updates then:

Nimbus+ is coming along just fine, there’s been no real problems so far. There have been quite an up front tech investment for the ps3 port, however, and we’ve spent some time on fixing stuff properly so the tech can be used for future projects. While not necessary for the completion of Nimbus+, the extra time spent on that stuff will be a big time saver in the future as it will let us re-use the code. Also, it will be a while still before the game runs and renders as intended so we can start showing off some of the new stuff in the game.

The game also recently got a major deadline. We don’t want to say the exact date at this point, but it’s a bunch of months away and we’re looking to have the game complete by then.

We’d also like to release another free mini-game in the spring or early summer, but chances are that the workload on Nimbus+ will get so big there will be no time for prototyping. Besides, our next major project is more or less decided, so there is no real need for prototyping a new concept at this point. But we will see what happens!

Anyway, some month ago we started building a new website for noumenon and thought it would be cool to launch it together with a small game. So I fixed up the jam game.

We named it SPACEMAZERACE and it sort of plays like asteroids on a race track with simple side objectives (shoot and loot). The game is only seven short levels long, so consider it a bite sized mini-game or prototype. It’s made in GameMaker 8.1 (an excellent tool for rapid prototyping) so I have little knowledge about how well it works on platforms other than windows. Probably not at all unless you hack around with bootcamp or whatever, sorry guys.

SPACEMAZERACE.zip (windows) 4.76mb

Jukio Kallio, a good friend of mine made the music for it and the sound effects were made with bfxr.

So what about that website that was supposed to go live with the game? Well something broke and sebastian, who codes around here, had to leave for a trip over the weekend before he had the time to fix it. It’s up on monday instead, probably.

And yes, we’re still alive and kicking, hard at work on Nimbus+. Most of the underlying engine work is complete and we’ve just recently started being able to run our new editor on PS3. As soon as we get it a bit more polished we’re hoping to show something new

• Three new levels, located at the end of world 3
• Greatly improved load times & performance
• Dead zone of analog stick is now tweakable from settings menu
• Spawning lights is a ton faster, so if you had problems on levels with turrets it’s hopefully going to be a lot better

As one incorporates more projects & configuration options into your build process it becomes a burden to modify & keep everything up to date. Missing something as a define or linking to the wrong runtime library can break ABI compatibility and can be really cumbersome to track down, having to double check every dependency to make sure everything is linking to the correct lib etc.

We have 3 build types, Debug, Release & ReleaseCandidate where Debug is mostly used during development, where we link to debug runtimes, use no optimization’s and overall have everything tuned for maximum debug-ability. In this build the game is running at a poor but playable framerate so is mostly just suitable for programmers. In Release we have all optimizations on, this build type is very close to what we ultimately want to ship but have cheats turned on for making development easier. For example we have a button in these builds & Debug builds which unlocks levels. Release builds also have asserts turned on, this way we can often catch errors early and sort them out. Release builds are used almost exclusively by everyone except people programming internally, the framerate is generally good and overall it’s a fair representation of the game. The last type, ReleaseCandidate, is only used when we’re making a release candidate ( surprise! ). In this build all cheats are disabled & everything which negatively affects framerate is removed. I would say these 3 types are a bare minimum, other popular build types is for example release type build but with generated debug information and “Paranoid”, where everything conceivable which could potentially go wrong is super checked, these type of builds usually have super poor framerate.

To this we add the different platforms, in our case PC & PS3. PC in our case is synonymous with a steam dependent build, but the plan is to have steam as a third platform, in which case we would have PC, PS3 & PC – Steam. The different build types & platforms then combines into all the different configurations, which if we incorporate steam on/off into the mix would be a total of 3 * 3 = 9.

At last we consider the fact that we have about ~35 projects on which Nimbus depends which needs to be built, in total 35 * 9 = 315 separate project/configuration types. Some are disabled for PS3 and vice versa for PC, but overall there’s quite a few. This is where the pain begins, lets say you missed the fact that all builds in Visual Studio which uses their standard library needs the define _SECURE_SCL=0 in all release configurations. The process to fix this is to right click a project, choose properties, then expand Configuration Properties, expand C/C++, click Preprocessor, click Preprocessor Definitions field and place caret at end and then paste it in at the end. Repeat process for about 35 * 2 = 70 project/configuration combos. There’s a trick here where if you have a slew of projects with the same defines ( rather unlikely ), then you can select them all and do it in one go. The same goes for if you have build types with the same defines, which is also unlikely. There’s a few more small trick which makes this a bit more tolerable, but overall it’s a very unpleasant experience to modify options across configurations and projects. It’s easy to miss something or accidently enter something for the wrong config, which at best leads to a compile time error and at worse a hard to track down crash in your binary.

All of this is a known shortcoming of Visual Studio and something I’ve heard they made strides on in Visual Studio 2010 ( even if it’s still fairly lackluster from what I hear ). So I took a look around to see what sort of options there were, having the following requirements:

1. I want to work inside Visual Studio, I don’t want to maintain my Visual Studio projects in addition to adding my files to external scripts when my projects grow
2. I don’t want to depend on tools which requires installs, ideally I want something which is self contained and easy to put in our source control
3. I want to have the same work flow as I already have inside Visual Studio, that is, it needs to support building & debugging inside Visual Studio seamlessly
4. Relative paths! I thought this was a no brainer, but there seems to be a few options out there which doesn’t handle this simple requirement
5. Low learning curve

As it turns out there’s almost nothing out there which meets all of these requirements. Most fail at a combination of 1, 2 or 5. Scons, jam/bjam seems to fail at 1, 3 & 5. CMake fails hard at 2 and is overly fond of absolute paths for the generated project files, not overly important but this always rubs me the wrong way. There’s also Gyp which seems to pass pretty much all of my tests, except maybe 2 as it depends on python, but with some fiddling I’m sure that wouldn’t have been to hard to embed. Gyp is certainly something I would’ve considered an alternative, but in the end I went with Premake, which is what most of this article will be about. Premake is a single binary which is totally self contained, it’s dead easy to learn ( if you know lua you’re already half way there ). As a bonus it’s very light weight and as soon as you’ve figured out how it works it’s very easy to modify pretty much any aspect of it. Except for a few implementation level niggles I have with premake the only downside I’ve found so far is that it’s a bit lacking when it comes to feature set, there’s some features which I can’t live without which Premake doesn’t support. As it turns out I’ve been able to add all of them as well as converting all of our projects in about a week however. Follow me to the next page for the low down!

In 2008 Swedish reggae artist Timbaktu released the album “A high 5 & 1 falafel”, while I might not be much of a fan of the music I believe the title rings true with a lot of what independent games development stand for, as well as what those going down this route must be prepared for; you aren’t in the business for the monetary gains, money is just a necessity to being able to stay in the race, to continue working on new products. I like money just as much as the next guy, but in case you’re going into games development in any capacity, independent or not, with the belief that you’re going to be earning a lot of money you’d better stay away. Yes, there’s a selected few who do become financially independent for life, but in case that’s your plan there’s areas where it’s both easier and requires a whole lot less sacrifice ( I hear investment banking is a good bet ). As it turns out there isn’t much need for money when being an independent games developer anyway, as most of your wake hours will be spent working on your game or dealing with something related to it.

As I was on a mini conference not long ago I got presented with figures further striking this point home, I don’t have any source for verification but I’ve seen similar figures in the past. Out of a 100 game start ups you probably haven’t heard of 90, as they don’t even make it to market. Out of the 10 that do make it to market, only 3 are left after a year. While I haven’t heard any statistics for the long term I think it’s fairly safe to say that they aren’t particularly good, especially for the independent developers. Every time the industry shifts, which it tends to do in regular intervals, a large slew of developers have to close due to the investments and changes it entails. Overall it’s safe to say that it’s a rather harsh industry where we know for a fact that most people work a whole lot for fairly low compensation.

In case you, just as us, don’t think the poor conditions are enough of a deterrent to stay away the next step is to decide on the primary business. Some start ups focus on mainly contract work, usually taking on work from larger developers or publishers. I’ll just touch on this very briefly as it’s something I don’t have a whole lot of experience with, but I believe studios mainly focusing on contract work have a hard time staying alive in the long run. Unless you focus on a small niche which you’re proven to be really good at you’ll be competing for low rates in a market where there’s definitely significantly more supply than demand.

In case you’re going to be focusing on your own IP instead there are a few different options. The first is to go for venture capitalists, this means someone else will be funding the development; sadly it also comes with a lot of strings attached. Usually the VCs will have the controlling majority, they’ll own the IP when the game is done, and in reality you’ll be working your ass off for a poor salary and a royalty share. Of course the contracts will vary, but VCs have the money and they’ll likely be having the upper hand when negotiating contracts as that is what they do. Due to the extremely poor odds mentioned earlier you’ll be hurting a lot in negotiations if the studio doesn’t have a track record, and even more so if the individuals involved doesn’t have an impressive resume. There are lots of horror stories mostly boiling down to the developers getting abused due to unrealistic expectations & being stuck with a poor contract.

The second option is to go to a publisher and ask for them to fund the project. There are a lot of horror stories down this route as well, but overall a publisher will bring more to the table than a VC. Publishers usually have the whole machinery in place for all the different areas which a developer is likely to be clueless about: marketing, distribution, focus testing, QA and a huge network of business contacts. It’s easy to forget about these areas as a developer as we often like to think that the only thing that matters is a great game. The publisher just as the VC will probably want the IP, a large degree of control over the development process, and as there’s a surplus of developers looking for publishers you’ll likely have to sign a contract that in effect means you’ll be once again working your ass off in order to meet project milestones and keep the cash flowing. As publishers usually know the industry better than VCs track record is once again the key to striking a good deal, expect to front something truly spectacular that’s already playable in case you’re fresh.

The last, and in my opinion the best option, is to fund the development yourself. This is what we decided to do for Nimbus. This way you’ll have complete creative freedom ( for better or worse ), you’ll be in total control every step of the way and you’ll reap the majority of the rewards in case you do make it to market.

Nimbus took about a year to develop, but the company had been around for almost ½ year before development of Nimbus started; working on our tech, exploring business opportunities, prototyping and taking on minor contract work. The key to succeeding in self funding a studio start up is to keep expenses & risks low. The alternatives to keeping expenses low is to either amass a lot money before starting, which unless you have rich relatives will likely take you a considerable amount of time, or interleave the development of the game with a considerable amount of contract work, which is both difficulty to find and even harder to rely on.

As developing games have only 1 significant expense you won’t be having a lot of options here, the good part is that minimizing this particular expense also means minimizing your risks. The expense & risk I’m talking about is manpower, the more people involved the greater the chance of conflicts and the greater the communicational overhead and need for management gets. As the team grow efficiency is likely to drop due to dependencies & asymmetric workload. Overall there are too many hidden costs & risks associated with being more than just a few people. At Noumenon Games we’re just 2 guys working fulltime, 1 coder and 1 artist. You’ll absolutely need a programmer, and as programmers’ art usually won’t be moving any copies getting an artist on board is more or less equally important. The other parts can usually be covered by either cooperation with someone outside of the team ( sound & music being a good example ), or by wearing multiple hats. A common mistake I’ve seen is to base a team on a group of friends which hasn’t worked together in the past, based mostly on the fact that everybody in the groups likes each other socially. This is a recipe for failure and broken friendship.

To do a simple budget calculation for Noumenon Games: We started with a total of ~25 000 USD in savings, while having a total burn rate of ~1 700 USD. As there was a large upfront programming cost in the beginning of the project we did some art contract work in the summer for a total of ~11 000 USD. When averaged over a whole year and split between us the income easily put us in the lowest income bracket, resulting in the minimum amount of income tax. This also means that the minimum amounts of sales needed for Nimbus to keep us alive is extremely low, and would put most other companies in bankruptcy. Keeping the expenses this low means that when you do go over budget it’s that much easier to rake in some extra $$$ from an external source to cover continued development. It goes without saying that this requires some special circumstances to work. You won’t exactly be living in central London as rent is easily the largest expense. It also means that you won’t be having a family relying on you supporting them.

So, in case you’ve done some rough calculations and feel like you have the financial part covered, preferably with a good deal of headroom, the next course of action is to decide on a project to bet on. With the market being hit driven it’s especially risky for self-funded start ups, as you’ll be relying very heavily on the performance of the first title. To beat these odds, and at least stay in the race long enough to even have a chance of stabilizing I think there are a few things to keep in mind. Chances are you’re going to bet all your chips on your first attempt in order to maximize the chances of being seen in the unending stream of games. I think the largest mistake at this point is to jump on the same bandwagon everybody else is on. A few years ago after the success of iShoot everybody was going to do iPhone games. Word around the campfire was that EVERYBODY were getting rich, Apple of course not being slow on highlighting the few success stories to be found. However, if you take a look at the broad picture it looks a bit bleaker, with the median revenue being $682 per year. The next “big thing” seems to be facebook games, hence Playfish being bought for USD $400 million, and Zyngas market value hitting USD $5.5 billion in late 2010. I don’t have any numbers here, but with the barrier of entry being very low I believe it’s inevitable that the chances of staying business doing facebook games are equally slim unless you have some serious $$$ to invest in order to get noticed & be competitive.

As you probably know in case you’re on the blog we didn’t go down any of those routes, instead we focused on Nimbus for a platform which most business analysts will tell you is dead, namely PC games, for a segment which is considered dead, namely the middle segment. I certainly think there are developers who’ve carved out a niche here with success. Of course, we have to use a different metric for success than the established studios; with success I’m referring to the “high 5 & 1 falafel” level of success. Frictional Games have been living in this market space since 2006, from what I’ve heard being able to just barely stay alive. Things now seem to be looking up for them after Dark Amnesia being very well received. If one takes a look at the indie section of Steam there’s quite a few having a shot at it, and although I once again have no hard numbers I believe the odds at great success is probably around 1 / 10, and “high 5 & 1 falafel” level of success is probably better than 1 / 2.

Nimbus is in the “high 5 & 1 falafel” bracket, and with the accumulated sales in case they continue as they are now we’ll have no problems getting another game out. And this I believe is one of the most important parts to take from this article in case you’ve already developed a game which perhaps didn’t set the world on fire; the first project is the most risky and most expensive, especially in case you’ve just as us invested in your own technology. For the next project we’ll be able to reuse a lot of our code base. We’ll be able to take advantage of the optimizations we’ve done to the development process from the get go. Hopefully we’ll also have an easier time generating some buzz for our next game due to positive reception of Nimbus. All the business contacts which we’ve made and are continuing to establish will make it a lot easier for us to monetize our next product. And of course, all the experience we’ve gained as individuals from the development of Nimbus will be continued to be built upon.

In the next article I believe I’ll try to do a post mortem on Nimbus, with some accompanying sales data. Suggestions for new blog entries or questions very much welcomed!