Archive for the ‘Blog’ Category

Long Time no post

Tuesday, September 23, 2014

Oh boy,
it has been a long time between posts… lots of things happened.

First, we got a game out the door:
http://store.steampowered.com/app/254200/

We’re still working on it, currently finalising early access. We’ll post about details on this game more often in the future

Let see, we’re dusting off Projectorgames for events:

We went to abunaicon this summer with Projectogames and had a blast as usual.

We ordered two DK2 oculus rift kits to make games and applications with, and are looking into partners that would like games or interactive Oculus experiences.

We’ll talk about these things more in detail the comming weeks. Lets just say we’re still in crunch-ish time for Fortresscraft evolved, and preparing for new projects.

-Govert.

The business side of running an Indie games studio

Wednesday, June 13, 2012

The business side of running an Indie games studio

Warning: this post is just a list of tips and guidelines for starting one’s own company and the way we went about it, as usual your mileage might vary. And as I’m just writing this from the top of my head thus this post will go all over the place. For in-depth articles you’re welcome to glean the sources at the end of the post.

In the Netherlands starting a company is pretty easy: register yourself at the chambre of commerce (kamer van koophandel), choose the type of company you want to be (BV, VOF, eenmanszaak) and then troll the revenue services for a VAT number. Afther that you’re all set to go… Piece of advice, don’t do this before there’s an actual need to, like you’re about to sell the game or when investors start showing up or you’re actually making costs that need to be declared. Also do get an accountant as soon as cash starts moving, they are well worth the money if it saves you hundreds of hours trying to do it yourself 🙂

At some point we’d advise you to get a legal aid insurance, this doesn’t cost too much, and should you accidentally write skynet you’ll be able to defend yourself legally before the robots come to get you. This is especially important when you start signing contracts.

Get yourself some backup systems, we chose to use  SVN because that was available at the time, at this point GIT might be a better idea because it’s new and shiny. But be sure to keep your backup system in a different physical location than your work computer! You don’t want to lose years of work due to a fire burning down both your computer and your backup.

Keep financial records dutifully in a spreadsheet, and update it ASAP, not at the end of the year (trust me, it gets ugly pretty fast). Be consistent in this for your (future) accountant.

Naturally, the biggest question is how to handle the Money and lack thereof. There are plenty of options:

Start from your mom’s basement: This works fine but you should really leave it after a year, if only for health reasons.

Start with investors: We have no experience with this as we took another route. Our research in the matter however suggests investors and game companies don’t mix very well as the high-hopes of investors don’t match the realities of making games. Basically, you end up selling a large part of your company before you’ve even made it worth something. And if that’s a controlling interest, you may end up not calling the shots. One tale of caution about investors: they can, and usually will, kill a game company. Horror stories galore on the interwebz.

Find business coaching and other university instances (there are plenty ones out there) that help people set up companies and let them help. They might give you a loan to start your company and enable you to leave your mum’s basement. This is currently a good option but you’ll have to be able to make up your own mind when their advice doesn’t match with the weird industry that is the indie industry. And they usually have very strict repayment demands on loans that can be problematic to meet if your company flops.

What we actually ended up doing was something different: Catnip Games started out as a part-time project – we kept normal wage-paying jobs for half the week and spent the other half working on projects. The normal jobs are dialled down when the company earns enough to compensate for lost income. This means you can’t fully focus on creating stuff, but it also means you don’t have to fear paying your rent next month. If the company flops then no harm done and we can move on without debts. If it works, we can ease into full-time self-employment almost immediately.

The best way to describe our development process we have found so far is to compare making games to writing a novel: it takes a long time to write, you can’t know if you have a best-seller until you start marketing it, and a complete flop or a huge success are always on the table, thus people “risking the bank” on investing in game development usually have to be made aware there is no guarantee whatsoever you’ll make any returns on your first game… but if they’re fine with losing money in the short run and make a buck in the future that’s up to them (and you).

Making a game is a R&D process, some solutions might be found in a day, but unforeseen issues might set you back weeks, experience is definitively something acquired on the job, even if you think you know everything. In building a game will you encounter weird unexpected issues and have to fix them, or find it’s unfixable without too much hassle and force you to start from scratch*.

This is usually the part where investors start giving “advice”. You can guess how much help that advice will be when coming from a financial analyst trying to comprehend why the physics engine has bugs in your new platformer/rts/shooter game.

Regarding subsidies: we currently haven’t found any that matched our criteria for a healthy indy dev studio, as subsidies are usually applicable to salaries and a starting indie game company can’t afford employees. Other subsidies are available but will take you up to two weeks in a month of filing papers instead of making games. If you think it’s worth it be my guest, we didn’t. Most subsidies requirements mean you are only eligible for them when you no longer need them in the first place.

If your business takes off you might have to face other problems like managing a team, managing business contacts, going to network events, game days, and other events where like-minded people hang out. But those are luxury problems.

 

Well hope you enjoyed a piece of mind, for more concise information there are always these sources of in depth information:

www.gamasutra.com

http://www.gamedev.net (especially the forums)

http://www.develop-online.net/blog

 

Kind regards,

Hoxolotl

*from what I’ve heard losing a month or even a years worth of work does happen

Tools we use

Monday, December 13, 2010

In the coming months we’ll try to give you a small look into the kitchen of Catnip Games. There’s a lot happening behind the scenes:

We’re working on a  Zombie Survival game together with Projectorgames. Martijn is coding the game engine, squishing bugs and fixing Govert’s pipeline when needed. And Govert is modelling, animating and rendering away, occasionally reworking his art pipeline to have all those sprites rendered in one go.

Then there’s our “pet summer project” RPGM which from a simmer went to taking a day (up to two) a week, with the volunteers still pitching in regularly, but as it’s mostly code for the world generator there’s not much to see, and thus not much to show either. Move along…

Bullet Crave is frozen until further notice, but it is far from being off our minds, we’ll be probably reworking it with the new game engine around second quarter 2011. I was about to say “February”, but I’m learning to keep the deadline vague enough or else they make that well known “whooshing” sound as they go by.

Lets see what could we use for show and tell right now? a screen shot of our node setup in Blender will do:

Node Setup in Blender

Node Setup in Blender

This is just a small example of a pipeline here’s what it does:

From one render layer it almost directly gets the shadeless diffuse (colour) of the model and makes the diffuse.png.

From the other render layer, in which a special height color material is used it jumbles the orientations so the normals fit our game engine, add the alpha and makes the normal.png.

Then from the same layer it takes the height colour (black=floor to white=ceiling)  rips it out and puts it back in so we can code height into the RGB channels of the height.png, because we need that much precision.

Of course this all would be easy peasy if one sprite was enough, it turns out for the levels we need 4 angles (3×4 sprites), then for the animated stuff we use 8 frames for each sprite under 16 angles (3x8x16 sprites=384), and then all those sprites have to be put into a sprite sheet, then the height has to be set and some magic fairy powder added (that’s Martijn’s job) and you have a game…pfew.

Soo, have a nice week,

Govert. /aka Hoxolotl.

Narritivium

Saturday, December 4, 2010

The worlds in RPGM are randomly generated – random geography, random people, random histories. Yet we want players to have fun playing adventures in them. The natural line of thought would be to also randomly generate the stories for these adventures. This is easily said, but if you’re a game developer or academic involved with AI, this should raise several red flags.

The current state of the art for random story generation is not glorious. In the academic world, the main focus these days is on story telling, guiding players through game content in an interactive way that keeps the game fun. While ofcourse very interesting, that’s not what we’re talking about here. The few bits of actual random story generation research out there deliver results that read like it was written by a four year old. With ADHD. This did not seem like a good direction for RPGM.

So instead of randomly generated stories, we’ve chosen a different approach: We apply prewritten stories to a generated world. We swap out the main characters for those that exist in the world and make them play out the scenario. While trying to describe this system to others, it hit me: We’ve introduced Narritivium. Narritivium is a concept thought up by Terry Pratchet for the fantasy world of Discworld. It is that which compels stories to happen. Narritivium is what makes the damsel in distress wait in her tower for the eligible bachelor hero, instead of, say, hitting the guard with a frying pan at two in the morning and making a run for it. It is the stories wanting to happen.

In our worlds, we’re making stories happen according to predetermined scripts – the actors change, the settings change, but the stories remain the same. It is how we can fit human-written narative in an otherwise completely randomly generated world.

Now, ofcourse all of this is a gross oversimplification of our actual system – it’s actually growing into an immensely complex beast of a system. But we’ve had our first randomly generated story to go help a farmer in the tavern, and it works!

To quote ‘The science of Discworld, part II’:
“If you understand the power of story, and learn to detect abuses of it, you might actually deserve the appellation Homo sapiens.” I wonder if it also counts when you’re the one doing the abusing yourself?