Today I was given a $5000 budget from my investor to build a prototype version of my MMORPG. I want to spread that budget as thinly and effectively as possible. My investor has cautioned me to consider this a hobby project with a chance to make it big, and this is pretty much how I intend to run things. I do not plan to pay staff at this point, nor will I be paying myself. When the game reaches a commercial level and there are some profits in existence, then people will start getting paid. I know this is a line oft repeated here on Gamdev, but I mean business ;) So basically my question is this: How best would you suggest I spread my budget at this stage? I am not working to a strict deadline, so development will be casual, as I said I want to make the best use of my money - anything which can realistically be achieved without payment upfront, should be. I've mapped out some of what I consider my key requirements at this point: Staff related: Alpha client build - client programmer(s) Alpha server build - server programmer(s) Environment art/UI - Currently covered, but additional artists certainly would not go amiss Character art - Concept artist, 3D modeller, rigger, animator Game lore - writer Game systems - assistant designers Website - flash designer Resources: 3D character models with animation/rigging. Is there anything crucial or important I have missed here? I already have a good linkup possibility for the client and server programmers, so my main concern is character art (which is why I would consider spending some money at this stage on outsourcing a handful of quality pre-rigged/animated models, as a prototype will manage fine with humans, some equipment, and a couple of monsters), but I could probably get all the art resources I need for a few hundred $s, so what to do with the rest? One major expenditure I have been considering at this point is the outsourcing of some 3D models, with rigging and animation. I suppose I could allocate a few hundred $s for token upfront payments, if this would be likely to make a difference, but these would be purely symbolic, merely to show that I my intentions are serious. All suggestions and pointers are very much welcome, particularly from those with experience in developing an indy MMO! Jonathan

I am the development lead and environment artist.

The code for the prototype probably will be used for the finished product, because chances are it will be a modification of an existing project anyway (one which is structurally near completion, but does not currently use any original or licensed art resources. That lead is not something I can 100% rely on at this point, and if that collaboration fell through then it would change things entirely.

But for now let's assume that it works out. Client and server can be considered tentatively "covered".

Zerowolf in case you missed it in my original post, this is the budget for a prototype, not for the game. The staff list is also for the purpose of building a prototype, and is structured accordingly.

I do not need a large amount of designers, environment artists, or dedicated art lead at this point. The prototype is a proof of concept, not a fully featured game.

Let's get the nasty bit out of the way, first: you will not achieve the kind of popularity or scalability you require to actually achieve the 'massive' part in "MMO." Certainly not with that kind of budget, certainly not with the apparent skill and experience level of your (currently mostly non-existent?) team. If you are lucky enough to create a game that gains enough popularity for you to pass through the first scalability tier, you will likely find yourself with an extremely unstable, crashy game on your hands and you will need to be prepared for that PR disaster because you will need to handle it while you recover and refactor your servers so that they can actually handle the load. This may or may not kill your game, and it will happen many times (assuming your game continues to gain in popularity) until you get it right. Such is one of the primary dangers of this kind of project for inexperienced teams. No matter how dedicated you are, that won't substitute for the technical expertise you require ("you may be ambitious, but that doesn't mean you have a clue").

Now, that said: the less work you have finished already, the less people you need to "hire" (and obviously by hire I mean 'get to work with you'). You need a single programmer until you have a reasonable prototype. Use programmer art. If you're a developer you can pretty much do this yourself.

Then you might want to look at finding an artist so you can turn your prototype into something that looks better than programmer art so that you can use it to attract other developers when you need them.

You will not need any writers or website-related people, period, until well after the prototype stage. You probably don't need any kind of game designers during prototype developer either, and you may be able to delay bringing these people on board for a very long time. It will probably be beneficial for you to do so. The longer you wait to bring a designer on board, the more of your technology base will have been developed. This will give you extremely clear, rigid guidelines in which your designer can work: you do not want to deal with the management nightmare of some overzealous designer planning out all these crazy ideas that are technically infeasible. If you have a strong technical framework in place, it's a lot easier to tell him "no." The inability to say 'no' to even a single errant designer can spell doom for a hobby project.

And on that subject, don't be afraid to kick people off your team. The second they stop pulling their weight or causing more trouble then they are worth, warn them, then boot them if they don't shape up. Such things can all too easily destroy indie projects.

Getting back to your specific questions about the prototype itself, I would think that you only need to pay the artist. I would suggest paying him on commission for sprite sheets or models or whatever assets you need to make your programmer art suck less. This will likely feel safer for the artist. Since money is changing hands, of course, you may also want to consider paying a lawyer to look over all your legal needs. That's often a thing that's overlooked.

I have prior experience producing MMO related projects, but never a game itself. The art will not be programmer art to begin with because the basis of the artwork is already completed (sample: http://img186.imageshack.us/img186/5831/pixel2hj3.jpg). It was on the basis of this, my development proposals, and my investors own experience in MMO production, that secured the funds available.

I understand the concerns about popularity aswell, but actually I have an almost guarenteed fanbase for my project.

I may be ambitious, but I'm not completely ignorant of what I am trying to achieve, and the level of involvement it will require. I am currently available 24/7, and have experience in sticking at succesful projects for several years.

I understand it's nescessary to beat me down with a bit of realism, and I'm taking it on board, but at this stage my plans are unlikely to change dramatically.

Cheers,
Jonathan

Quote:
I have prior experience producing MMO related projects, but never a game itself. The art will not be programmer art to begin with because the basis of the artwork is already completed (sample: http://img186.imageshack.us/img186/5831/pixel2hj3.jpg). It was on the basis of this, my development proposals, and my investors own experience in MMO production, that secured the funds available.

That's good, that means you can avoid retaining the services of an artist for a while and just sit on the funds (assuming whatever legal agreement you have with your investor allows that).

Quote:
I understand the concerns about popularity aswell, but actually I have an almost guarenteed fanbase for my project.

An established fan base or a guaranteed fan base don't actually necessarily help or hinder you in any way. It's not about the people, it's about the capability to handle those people. What will matter more is the nature of the experience you acquired by 'producing' those other MMO projects -- what projects were they, and what did you actually do for them? Were you involved with the development of the networking infrastructure? What was your server architecture like, what was your estimated achievable and practically achieved peak concurrency and for how long did that peak last or remain stable?

The "better" your answers to those questions, the less you may need to plan for the eventually that your existent server architecture will fail under load. Multiple times. Of course this is all beyond the scope of the prototype.

Quote:
I understand it's nescessary to beat me down with a bit of realism, and I'm taking it on board, but at this stage my plans are unlikely to change dramatically.

I'm not really trying to change your plans (because quite frankly I've stopped caring whether or not hobby MMO projects succeed or fail). Just to point things out.

Quote:
It was on the basis of this, my development proposals, and my investors own experience in MMO production, that secured the funds available.

So again returning to just the scope of the prototype... I can't see anything you really need to plan to spend too much money on right now, since you have what looks like a pretty decent pool of art to draw from. As long a you are technically competent enough to build out a prototype on your own I don't see a need for you to bring too many people on board for a while. You still may want to talk with a lawyer if you have not already done so to make sure you are not breaking any agreements you may have signed with regard to the funding if you don't spend it. I guess you could spend some of it on trying to bring a programmer on-board to help take some of the workload off you -- or the entire workload if you don't think you can do it -- but it's harder to make deals with programmers than artists in these sorts of scenarios.

Beyond that, I'd save the money for any legal consulting fees you need and for eventualities that are as yet unseen.