Reply With QuoteUnless you mean Google Scholar when you write "Google", I would say that you're using the wrong kind of place to search.
Ask your university library about databases for papers and such.
So for my Game Industry class in my design course, we have to write an estimate - teacher called it an FDD - for milestones and costs for a game we mock-designed. I chose to mock-design a conducting game for the Wii, and now I'm having trouble getting all the information I need!
The real problem is that my Google-Fu is weak, and the teacher is useless, so I have no clue where to look. But I really want to get the assignment done and done well, so I'm asking you guys for help! :)
Thus far I broke down my game into four different parts: The demo, the alpha/skeleton, the beta, and the release version. Each is a milestone; I figured 3 months for the demo and six for each of the other three, including some time for slippage (mostly on the release phase). However, I don't know how realistic this is.
I further broke down my game into the following tasks, which I need to do research on to find out costs and time they'll take. If I missed anything
feel free to call me an idiot and correct me. Some of this stuff I've already sent emails asking about, specifically what's related to music licensing, but am waiting for responses. *grumble*
Demo - 1 song, hard and easy difficulties: Get a debug Wii and the SDK. Find out what development tools will need to be developed in-house and which can be purchased as middleware, and hire programmers/middleware experts for that purpose. Program an initial scripting language for the songs. Decide on styles of music and find out licensing costs/information. Advisory services for business and marketing. Buy art programs (ex., 3DSMax), and hire artists/animators and/or purchase models for a pre-rendered background movie.
Alpha - Technical aspects ready, design ready including concept art, engine ready, placeholder graphics: Engine/low-level programmers OR buy an existing engine, finish scripting language. Hire professional conductors to help configure the gameplay. License all songs needed (re-record or use existing recordings?). Design and program the UI/GUI. Implement the skeleton of any online/multiplayer and career modes. Concept art; how many animations per character, how many characters, how many background movies and what's in them.
Beta - Leve design and graphics completed: Start QA definitions. Fine-tune the engine. Finish online functionality. Songs all completed and scripted. All graphics, animations, and modelling done.
Release - Game ready: QA, marketing, fine tuning of the game, and tutorials/manuals.
What I need to figure out:
How many people to hire (programmers, artists) and how much to pay them, what expertise they'll need, and how long to hire them for (ideally the whole cycle?).
The cost of whatever middleware we'll purchase.
Development costs of whatever we don't purchase.
Cost of QA, marketing, and servers for online functionality.
Anything else I've forgotten!
At the end I need solid milestones for each sub-assignment (ie, scripting language done in this much time, concept art in this much time, etc), who's working on it and when, and cost.
If you guys can point me at the proper places to do the research, that would be like a huge start!
Unless you mean Google Scholar when you write "Google", I would say that you're using the wrong kind of place to search.
Ask your university library about databases for papers and such.
My university library is 100% Hebrew. No help.
They probably have access to JSTOR and other databases, though.
I just walked over and asked, and the response I got was 'What?'
They have no clue even what those are. :(
I should be able to access those databases when I visit the US soon, but this college has jack for access to anything.
FWIW I put together a small game design & dev book list awhile ago. I'm pretty sure Raph has something too (like his Amazon book list).
For actual rule-O-thumb estimates, there may be something in Dan Irish's The Game Producer's Handbook. If not, its great anyways. I think the PMI says that there's only realistically 1350 or 1500 hrs of work in a year that can be counted, which only provides 37ish weeks of work. Most people in sw don't count on that though:)
It sounds like you may be asking How to estimate and What is the level of effort from your description. Those are two different things. Ultimately, you and your technical designers will only be able to know bottom-up from your proposed features and timeline how many and what kind of resources you'll need (i.e. time, money, personnel, libs, assets). Strangers can't. Just remember: 40 hrs in a week and less than 52 weeks in a year (holidays, sick and leave).
If you make it a train conducting game, there's someone on this board who could probably guess with great accuracy what that would cost to develop. He may even have it written down.
Not anything to do with what you're asking, so many apologies, but can I just say that this actually sounds like a great Wii game and exactly the sort of thinking that I hoped the Wii would encourage.Originally Posted by AaronSofaer
Also (genuinely no offense) but is Game Industry a course which will help you get a job in the industry?
Please, genuinely understand, I am not having a go at your degree but genuinely curious how these sort of studies would be viewed by the 'old salts'. I really think that these sorts of degrees are a great idea but wonder how they are viewed.
Really sorry if I have offended.
First of all, you want way more than 4 milestones. They need to be granular, and each milestone has to produce discrete results. Having a milestone which essentially says "When the first half of the game is finished" doesn't really mean anything.
The benefit of having shorter milestones is that you can tell when you are starting to slip; if your first milestone is a week late, you can calculate accordingly. If your first milestone is alpha, and you are a full month late, welcome to development hell.
Secondly, I know this is probably going too far ahead of what you are doing, but never program your own scripting language. There's a million of them out there; programming your own scripting language is way more trouble when it's worth, when you can simply grab lua or python or whatever.
Anyway, on top of that, your priorities are all jumbled up. Let me reorganize them for you. Anything I've added I'll put in bold.
Pre-production:
Demo - 1 song, hard and easy difficulties:
-Concept art; how many animations per character, how many characters, how many background movies and what's in them.
-Decide on styles of music and find out licensing costs/information.
-Find out what development tools will need to be developed in-house and which can be purchased as middleware, and hire programmers/middleware experts for that purpose.
-Buy art programs (ex., 3DSMax), and hire artists/animators and/or purchase models for a pre-rendered background movie.
-Engine/low-level programmers OR buy an existing engine, finish scripting language.
-Get a debug Wii and the SDK.
-Design and program the UI/GUI.
-Advisory services for business and marketing.
Production:
-Technical aspects ready, design ready including concept art, engine ready, placeholder graphics:
-Hire professional conductors to help configure the gameplay.
-License all songs needed (re-record or use existing recordings?).
-Implement the skeleton of any online/multiplayer and career modes.
Beta - Leve design and graphics completed: Start QA definitions. Fine-tune the engine. Finish online functionality. Songs all completed and scripted. All graphics, animations, and modelling done.
Release - Game ready: QA, marketing, fine tuning of the game, and tutorials/manuals.
This may be getting too nit-picky, but wouldn't there also be a technical feasibility portion to determine how the music and conducting would work? I say this because of how Guitar Hero works; the guitar (and in II rhythm guitar and/or bass tracks) are separate tracks from the rest of the music, because they need to be interrupted and/or pitch shifted by the whammy.
For a good conducting game, depending on the design, wouldn't each set of instruments in a song need to be on a separate track so that the game would have, well, some amount of complexity to the gameplay?
That may up costs, as it would seem to indicate a need to rerecord each song.
Fortunately, licensing for classical tracks should be relatively, well, free. But the charges for getting someone to record them wouldn't be.
To make a better contribution to your thread, I would just like to back this up. I don't know a lot about game design, but in any project that I run, I always make sure that there are concrete, realistic goals to hit. Small steps in this way are far more realistic, and provide a far better psychological push as you know that you are achieving things and can see results as the project takes shape. The end is always in sight that way.
It is better to hit a lot of small, manageable targets than to miss or struggle to hit a few large ones
Well, this specific "Game Industry" course is actually a course in games, their genres and specific things that differentiate the genres, the industry and how it's put together, and a whole load of other associated stuff. It's a very general class that's under a name that translates to "Game Industry".
And as for how this degree course will hold up... I don't know. :) I'm taking it because it's here, more than because it's great.
Charles, Tide - Thank you for the input! I'll definately look into making more milestones, and getting some of those books.
Charles, a question for you on that note: What if I made sub-milestones? Like, the alpha milestone is 6 months after pre-production, but this that and the other thing should be done by month 1, these should be done by month 2, and those by month 3?
That's cool, I just always wonder how these industry-specific courses go over in the industry concerned.
Whilst Charles will be able to give a far more game-specific answer, my advice would be to cut things into as small chunks as you can without being silly about it.
For example, I recently oversaw the translation of a CSR report for a major Japanese bank, which was 60 pages in under 4 weeks. The first thing I did was agree on a deadline for all of it with them. Then I cut it into 5 parts and chose deadlines for each part. Then I cut each part into chunks that I could ask people to translate for me. Somethings divide themselves up well. For this report I chose units of two pages and then parcelled out accordingly. Other things may require more arbitrary cutting.
Basically, you need to cut the project into sets and subsets that can be worked on easily and quickly, but, when put together, move you along your road. Four small deadlines will help you hit one big one and so on.
I hope Charles will weigh in with a more game industry answer but that is the way I would approach things and I don't think it can be too different.
Good luck with the project.
It's common to have an alpha milestone, and a beta milestone. But those are discrete milestones after a batch of other milestones covering prerequisites. You have the right idea.
As you reach the smaller granularity of a week or so, you are pretty much working on the individual level, for individual tasks. At that point, you are down in scheduling and planning, which are the building blocks for the milestones themselves. If you have 10 employees, and each can manage 4 tasks in a given month, then those 40 tasks should complement each other and all be in support of the monthly milestone.
From my experience, monthly milestones are great for production, while slightly larger ones are better during preproduction. But my experience is with large AAA games, rather than smaller games without 3d worlds and such, so YMMV.
I suspect for this particular task, you don't need to go overboard with micromanagement. But it's always good that your high level planning gets things in the right order, and allows for slipping and safety buffer zones.
Of course, whether or not that's good in your teacher's eyes, I cannot say, so you'll have to use your own discretion.
It depends on the piece. Many 20th Century works are still under some sort of copyright protection, so you'd have to tread carefully if you wanted any newer music. For instance, film composer Hans Zimmer was recently involved in a lawsuit with the estate of Gustav Holst, which was attempting to sue his pants off for ripping off Mars, Bringer of War in the Gladiator soundtrack. Holst finished writing The Planets in 1916.
If you select music that is in the public domain, you'll still have to contend with tracking down a decent printed edition of the music with which to work--many public domain scores are sketchy at best--but the cost of that would pale in comparison to licensing a copyrighted work.
As far as recording goes, I think nijimeijer makes a good point. An orchestral recording (or even a mockup with high quality sample libraries) would sound great, but it would be difficult to make it responsive to a virtual conductor's motions. The real time DSP required to speed up or slow down a recording without serious degradation to the sound would be very CPU intensive, and if you plan to implement things like cueing it would be necessary to have the various sections recorded on different tracks. In a dense score, you're talking about 5 sections just within the strings; you could easily hit 20+ stereo channels for a full orchestra.
Some possible solutions:
1) Do it all in MIDI. This is the most flexible and least resource intensive option. It would also potentially be the cheapest, since you wouldn't have to contract and record a whole orchestra. It would also be the shittiest sounding option, as you would have to cram the samples for the whole orchestra into the Wii's miniscule RAM. There was a Japanese PS2 conducting rhythm game a while back that took this route, so it's been done successfully. The sound was basically garbage, but it was the best way to go given the goals of the gameplay and the limitations of the hardware.
2) Do it Parappa the Rapper style, where you have several recordings of the same piece and you switch between good and bad-sounding recordings depending on how successful the player is. It would sound a lot better than MIDI, but it would also be less flexible and much more expensive if you use a live orchestra. You could trim some expense by hiring someone to mock it up with good quality samples rather than having a live orchestra play it.
I'm sure there are other possibilities too. It just depends on what sort of compromise you'd like to reach between sound quality and responsiveness (and, of course, how much money you'd like to spend).
And I have no experience with games at all. I would also like to add though, that balance is necessary. Too small milestones are no good to anyone.
In my experience, any form of micromanagement is not usually desirable. Of course, it is often unavoidable, but a good team should know what their jobs are and be able to perform them without constant prodding, and a good manager should know this, assign tasks and supervise accordingly. Sadly, not always possible.
The technical discussions are fascinating to me -- wish there was more of that on this forum.
The milestone advice is good, and basically applies to all software projects -- you want short, informative, achievable milestones, so that you can make course corrections and avoid demoralizing the project team.
Sorry, I didn't mean for actual game planning, but for his assignment for his school. :)
As I have been trying to say, I think this doesn't apply to just software, but to any large projects. Manageable but meaningful is the way to go.
I picked up several books suggested here on game design over the course of last month. Game Architecture And Design is really good, I'm only 5 chapters in but it seems to cover just about everything you need to know.
I also picked up the Indie Game Development Survival Guide, it may help you with what's needed for a smaller project. The First book seems to cover bigger projects.
Greetings:
Like Charles, all of my experience is in the larger games space, so some or all of this may not apply.
On milestones, you want these to be between 4 weeks (anything shorter is really scheduling rather than milestones) and 8 weeks (anything longer and you lose the ability to respond to changes/over-runs). You can call out key milestones (like Alpha, Beta, etc.), but these should not be the only milestones you have.
For costs, take a reasonable yearly salary and divide it appropriately for your milestone length (12 for monthly milestones, for example). If you want to be slightly more realistic, you can throw in 20% for overhead. You should be able to find reasonable salary numbers through job listings, or you can go by the game developers annual salary survey, both of which are available on gamasutra. Again, if you want to be slightly more realistic, you can build in a spread of senior/junior people.
As for how long to have people on, it's pretty easy to build a staffing plan by milestone. You won't need as many people in pre-production as you do during production. For example, there's no reason to have a UI programmer before the UI design is done, or QA staff before Alpha. You will want to have a full set of leads for the length of the project, then build out individual groups as they come on-line. You can tail off a little on the back-end, but don't let all your staff go before you're done, as there will be bugs in all areas of the game.
I don't know what the assumptions are for the assignment, but things like QA and marketing are generally handled by a publisher; if self-publishing is part of the exercise, though, you'll need to ball-park these in. Keep in mind that there's a real difference in quality and staffing cost between QA Leads, who run the testing process, and QA staffers, who can generally be had for quite cheap. I would suggest having the QA definitions (test plan) in place prior to beta so that you can hit the ground running. For marketing costs, 10-20% of development cost is probably a decent range.
One other tip if you're modeling a Wii project: build in time for submission. Console games need to be approved by the platform holder, and this can take as much as 4-6 weeks per submission. Most projects should be scheduled for 2 submissions, as there are often issues that show up the first time that need to be fixed before approval.
Hope that helps.
Best,
Michael.
What I was thinking was that yes, it would be a little absurd to have 20+ tracks of music, it might be possible to group them. Let's say you have four tracks of musical instruments plus one track for something like cymbal or big bass drum cues (for dramatic effect, fun times). Would that be more technically feasible?
There's already been a proof-of-concept Wii conducting thing by Nintendo, but from what I read it wasn't well-designed as a game, as opposed to a proof-of-concept. So they must obviously have found some way to do it, and I know they didn't use MIDI for it.
As far as recording/licensing goes, I had hoped to license mostly music that is public domain or by relatively unknown composers (who wouldn't charge as much as, say, Holst's estate). Also, if re-recording is necessary, I don't think the budget of the game (it's not supposed to be that huge) would stretch for a full orchestra, if you know what I mean, but there could certainly be quartet music involved, and I could totally see hiring a quartet for a studio gig.
As far as dynamicness goes, I wasn't planning on having the music change while the game was being played. As in, I don't intend that if you miss a cue the guys don't come in; that would be kinda nifty, but you wouldn't ever learn what it was supposed to sound like, and I think it would be absurdly intensive CPU wise, right? I don't know if you were thinking I would do this.
That's another thing to research, I guess... how much does it cost to rent a studio? At least I have music-industry friends that might be able to answer that. *grins*
Edit:Thanks!
I disagree with Michael on leaving QA to the publisher -- the people who do that, in general, end up with lower quality games than those who have their own QA and do a large part in-house. Publisher and console manufacturer QA are only interested in stopping crashes -- they aren't going to help you with weird gameplay bugs or balance issues. In-house QA is often the difference between a good and a great game.
From my understanding, the definitions for Alpha and Beta are different to yours.Alpha - Technical aspects ready, design ready including concept art, engine ready, placeholder graphics: Engine/low-level programmers OR buy an existing engine, finish scripting language. Hire professional conductors to help configure the gameplay. License all songs needed (re-record or use existing recordings?). Design and program the UI/GUI. Implement the skeleton of any online/multiplayer and career modes. Concept art; how many animations per character, how many characters, how many background movies and what's in them.
Beta - Leve design and graphics completed: Start QA definitions. Fine-tune the engine. Finish online functionality. Songs all completed and scripted. All graphics, animations, and modelling done.
Alpha Candidate: this is like an internal Beta. Every feature is in, and we are feature locked, i.e. no more features can be added. Not every feature necessarily works that well, sometimes they don't work at all, but you should be able to play the game from start to finish, with a bit of luck. Obviously still quite a few bugs at this stage.
Beta Candidate: this is still not polished, but good enough to go external, usually only to external testers, marketers, localisers, etc., but sometimes to the general public. Most bugs have been ironed out, but there's still some optimisation to be done. You definitely wouldn't leave the online functionality until this late in production.
Both the Alpha and Beta candidates come late in production. Sometimes becoming pretty much the same thing when things get to crunch.
The Gold candidate is obviously the next stage.
Tim, are there any better names for the milestones that I listed? Those are the ones that my prof wants us to use as our primary milestones, so for the sake of the assignment I'll have to stick with them, but if there are better names for them...
Greetings:
My point was simply that as an educational exercise, I was uncertain whether the model was self-publishing or traditional development contracted to a publisher. That changes how much you have to account for.
I agree that developers should have QA in-house, definitely a lead and at least a few full-time testers. It's just much more efficient, plus it generally helps the publisher/developer relationship if bugs are caught before milestones are submitted rather than after.
And I agree that console platform holders aren't going to do much more than test TCR's/TRC's and crashes, so you can't rely on them for any real testing efforts.
However, I will disagree, once again, that publisher QA is worthless. That depends entirely on the publisher, and rather than toot my own company's horn, I'll put in that the folks I know who've worked with Microsoft have been quite happy at the level of testing they provided. I will happily acknowledge that many publishers skimp on testing and/or do not have the expertise to track and weigh in on weird gameplay bugs or balance issues, but I know from experience that this is not the case with all publishers.
Best,
Michael.
Yeah, I know not all publisher QA is bad -- after all, I work for a developer who's also the publisher, and our QA is fantastic. But I like to play better safe than sorry. I've seen too many nearly good games ruined by poor QA. And since this is half an advice thread, I'm willing to throw it out there as a rule in order to influence a potential future developer, and perhaps exact change.
Milestone periods:
I'm partial to 8 weeks during active development, configured as follows:
6 weeks feature development
1 week integration shock
1 week planning for the next milestone (here is where you kill/modify features, reshuffle things, etc)
Additionally, you cannot have a feature and a dependency in the same milestone, if either is scheduled to take more than 2 weeks, and they are assigned to the same person/sub-team. If they are in the same milestone, the dependency must be completed no later than the 3rd week of the milestone or it is counted as failed. (This keeps the dependency from cramming in at the last minute and declaring that they "met" their deliverable, and the fact that the other guy slipped isn't their fault).
Terminology:
Alpha: One example of every major feature is in. For example, you might have one knife, one sword, and one gun, even though the game calls for a lot of variations. But you can't have the grenade launcher missing and still call it "alpha".
Beta: Feature complete. Nothing is left but bug fixing, and fit and finish. And the last three levels are not "fit and finish" work.
Edit Notes: Edited to highlight that the issue is dependencies that aren't on the same person or sub-team.
Last edited by Dave Weinstein; 01-22-2007 at 01:19 PM.
The main milestones are pretty much as Charles described them:
Pre-production
Production
Alpha
Beta
Release
People's definitions of these phases vary, but it pretty much boils down to:
Pre-production: everything you need to design the game and plan its production
Production: everything you need to make the game actually play.
Alpha: an early playable version that you use internally.
Beta: a playable, feature complete, and almost finished version that you can show externally.
Release: the finished product.
What you do during these phases, and the actual definition of phases like "beta" and "alpha", would depend a lot on your publisher. That's largely because your funding will be dependent upon you making a certain level of progress. You'll be expected to have milestones, for example, where you produce something that the publisher will use to review your progress. A typical milestone would be a single level demo that shows off your core game mechanics.
Or, to be more sarcastic:
PreProduction: Mythical
Production: Art before engine, engine before design, it's traditional!
Alpha: Spend a month bolting a demo together with chewing gum and bailing wire for E3
Beta: Can run without a team member pointing out the things that will cause a crash
Release: When funding runs dry
Posting Permissions