The creation of a new Video Game Studio

I have a great general understanding of many things, but I am a Level Designer not a Studio Director or in any financial stuff.

Click to expand...

then focus on those two first.

You definitely need someone who can manage/lead a team and who can help you take care of setting up the production-line ('cause that is what it really is once you trim the fat) and all the required software & know-how.

The bad news ? Guys/Girls like that are expensive ...
The good news ? It's been done before and there are dozens of books and guidelines out there, so if you really want to you can do it yourself.

And don't ... (no really don't) ... underestimate the value of proper planning, design and documentation.
It's not something you can do all at once before you start (though it may look like it) so you are going to want to keep that under control as well.

I think the best approach is to write posts on game forums about how changing the core gameplay of a game will make it a better game.

If you've already made some games then you could show them off to companies or something perhaps?

If you haven't made any games yet then get cracking. For example, you could make one in which you shoot people with laser guns.

Hourence has writtern a couple of books. one might help you. actually Hourence himself might be able to give advice

http://help.hourences.com/

if you need a freelance mapper we could talk.

Hyrage said:

Exactly, this is why I'm taking care of that it's fortunately one of my strength.
I'll search for these useful books, if you have any titles in mind it would be appreciated.

Thx for the advices

Click to expand...

You could try :
Head First : Software development

There's stuff like :
'RUP' (Rational Unified Process) : http://nl.wikipedia.org/wiki/Rational_Unified_Process
Agile : http://en.wikipedia.org/wiki/Agile_software_development

The book covers a bit of everything and a bit of generic advice.
Most books tend to be pretty heavy on the theory and extremely light on the practical application of those theories.

Amazon has a pretty extensive range of related texts. I would have to say that being apart of one of the groups on Moddb would certainly help you get a feel of team managment (with people being in far distances from each other it turns the whole ordeal into a challenge).

Are you going to have a physical place/operations HQ/bunker of solitude? Or are you going to be Net based with your employment of others, I'm not sure on the legal side of things.

Will you need someone who takes care of your legal/HR/accounts/Production/QA/payroll/etc. ? Are you going to have standardized processes for being a small business? Have you met with a business consultant in regards to any of the prerequesets of business status?

I have a few books at home, but none that deal with 'setting up a studio'. Everything I have tends to be the game development process.

I don't mean to say this in reponse to anyone's post here, but there seems to be a huge implication that setting up a studio is all about who wants to do levels and who does modelling.

Best of luck with everything. Keep us updated with it all.

If you don't want the reality/truth/negative then don't bother reading my post. Here goes.

First off, I am more or less a few steps a head of you in terms of where you are thinking, and I have gone and setup my own software development. We focus a lot on games, but we also diverge out into web and business development too.

First of all, do not try to make a 'AAA' game as your first title. Make something much smaller first to wet your feet. Reasons:

You have little or no experience in managing a team, and managing a team is not a particularly easy thing to do. Managing a localized team is hard, and managing an international team is even harder. Without the proper experience in managing people, its possible to just run your own studio into the ground without even realising it. A 'AAA' game is a huge feat that requires a large team to make. Managing people isn't just about telling them what to do. It's keeping them happy, excited and motivated to continue working on your project.

Money. You have very little. Do not depend on anyone else for it. Coporations, business's , friends, family and government may offer it, but whether they actually give it to you is another thing. We're not talking a few 100 quid here. We're talking thousands upon thousands to handle this sort of thing. For example, if you decide to have a studio office, rent is going to set you back a certain amount. If you decide to pay people, expect to pay around about $40k per annum for low entry programmers and upwards of $55k to 80k for medium entry programmers, and unknown amounts for consultants. Can you afford that? Probably not likely.

Experience. You haven't got any real shipping experience. Any software company is not a software company until they release 1.0 of their first game or application. Shipping that first product is insanely hard. It's a constant struggle to just keep everything balanced and upright, and if you don't, it'll all collapse.

Books can only give you a small insight. They won't give you experience. So you may have 100's of books on success stories but until you've released version 1.0 of your game, no one is going to believe that you can do it.

Once again, why do a 'AAA' title? People expect a lot from a $50 - $60 game. And for the love of all things good, do not try to make an MMO of any sort.

Proper planning is what you need man.
Get an idea for a project (rough... and i mean rough), and count up the positions you need.

I don't suggest working on a project until you have the backing behind you.

elmuerte said:

Are you kidding me? RUP has no place within game development. RUP could be useful if you're managing a product line with a lot of people working on it.
An agile approach is the only way for a gamedev studio to work, because you will always have to adjust your plans. Some things (e.g. game elements) simply do not work well or at all. And that's something you need to account for. ....

Click to expand...

As if that is that different from regular software development ?
Whether it is a user/client that suddenly changes his mind or a technological feature that proves to be problematic. Both result in similar problems that need to be detected and solved as soon as possible to prevent serious problems.

Neither RUP nor Agile are *the* perfect solution.
It really depends on what works best for you. Some people/teams may like a more structured/strict approach, while others may want something that is extremely flexible.

Having a financially backed game project is the first step to even remotely be able to attract serious senior developers. Having at least x amount of total years experience in the games industry is the way to get dev and test kits. (afaik)
Starting small to grow big can be an effective way of proving yourself as a developer before wanting to get a project signed that is multi-million, multi-platform and/or for a big publisher.

JaFO said:

As if that is that different from regular software development ?
Whether it is a user/client that suddenly changes his mind or a technological feature that proves to be problematic. Both result in similar problems that need to be detected and solved as soon as possible to prevent serious problems.

Neither RUP nor Agile are *the* perfect solution.
It really depends on what works best for you. Some people/teams may like a more structured/strict approach, while others may want something that is extremely flexible.

Click to expand...

There is no such thing as "regular software development".

RUP isn't suitable for projects where goals and requirements change often. This is simply due to the extensive paper trail/red tape/bureaucracy. But that's also a good thing because it dictates stability in a project. But with stability you lose flexibility.

Building a game engine (which other teams use) is something you would use RUP for. The other teams need to be aware where the engine is going to, and that it's not going to suddenly change drastically.

Clients that suddenly change minds wreck havoc in any process. It's an unreliable factor because it ruins direction. But an agile process is more protected to those changes. A process like RUP isn't, those changes can only be entered in the next iteration (unless you are going to damage a couple of the pillars of RUP). Also in projects wre they use RUP a "sudden" change in mind of a client can have a time span of a month or even more. An most RUP projects employ other techniques like component-based software engineering and configuration management.

But anyway, you can use any process you want. I'm just handing out some advice/perspective.