Business Planning / Game Development

[Sean Doherty]

I have been reading the book "Why aren't your own boss?"; I guess I am hoping to find out. Anyway, in the book the talk about setting 5 goals either daily, weekly, or monthly depending whether you are one the fast track, steady track, or the sure but slow track.

I pretty sure I can't be on the fast track with a full time job. Having said that; I have a question:

Assuming your on the steady track the book says you should initiate five tasks a week; and follow up on five tasks previously initiated. How would this relate to developing a game; even the smallest tasks can take a fair amount of time? Maybe I need to do five tasks a month?

Also, what do other people do around setting and tracking goals towards the completion of their games?

[Mithril Studios]

Hm, sounds like an interesting book. :adds it to his to-read list:

Would it be possible to break your tasks down even further, until they fit within a weekly time frame?

Anthony

[Sean Doherty]

Hm, sounds like an interesting book. :adds it to his to-read list:

Would it be possible to break your tasks down even further, until they fit within a weekly time frame?

Anthony

Here are some sample tasks:

Implement game play Starmap
Implement game play Sound
Implement game play Music
Implement game play Explosion Effect
Implement game play Plasma Weapons

Not sure how to make them small enough to be initiate in a single week. Well I guess I could easily initiate them all; but after a couple of weeks I would have a growing list of things that have been started but not complete. I could go to the slow but sure track where the need to be initated within a month?

All goals are suppose to be S.M.A.R.T. Goals:

Specific
Measurable
Obtainable
Relevant
Time Bound

[Mithril Studios]

How about this:

Music
Create/locate artist for song 1
Define game music classes & interfaces
Code playCombatSong ()
Create unit test for playCombatSong()
Hook up play music libraries/classes


I guess I could see this as a further breakdown, and depending on their scope most look to be accomplishable within a week's time (and some less than that.)

Anthony

[Jim Buck]

All those "Implement game play [something]" tasks are so general that they would absolutely need breakdown (as Mithril Studios had done for Music) in order to be estimatable in a schedule. Just the mere act of thinking through each enough to break it down will help you to figure out how to implement each. (And if you don't know what the sub-tasks are, you need to research each area until you do know.)

[Morphecy]

Developing a game isn't fast track (as defined in the most extraordinary book Rich Dad, Poor Dad). If you are doing the work then you are on the rat race. If somebody else does the work, then you are on the fast track.

Developing a business will put you on the fast track. Developing a business means gathering assets - one asset can be your game.

Forgive me if I speak with other terms, "Rich Dad Poor Dad" I have read... not "Why aren't your own boss?"

But on consideration of developing a game I think it's about dividing tasks and completing them. You may divide the work into sub-tasks. Task "develop gui" could contain sub tasks like "design gui", "draw graphics" etc. and "draw graphics" could contain sub-sub-tasks like "draw menu buttons", "draw health bars" etc. Then you can put any of these sub (or sub-sub) tasks into your weekly list - and complete those.

[Sillysoft]

I was also influenced by the book 'Rich Dad, Poor Dad'. I would highly recommend it to anyone that hasn't read it.

http://www.amazon.com/exec/obidos/tg...56130?v=glance

[Mithril Studios]

I hate to derail this thread further but I've got to speak up about Rich Dad Poor Dad...

Kiyosaki's material is fabricated. While his concepts may be good and correct, do you want to pay your hard earned money to someone who blatantly lies to you about their route to success? Talk about lack of integrity. There are plenty of other books out there which discuss the same topics, whose author's didn't need to resort to fabricating their story.

@Sean,
I think the key take away for your project is to think about and further refine the tasks that you have listed. It takes a bit of practice, but you'll get the hang of it soon enough.

Anthony

[Sean Doherty]

I don't know?

I have a background in Project Management and a Masters Certificate in Project Management from George Washington University and I have always been a taught that the average size of a Work Breakdown Structure package should be about 40 hours. Anything less is generally to detailed to track and bench mark against your initial estimates.

I was thinking of something like:

- create an initial list of 3 development task (20-40 hour duration).

Each week:

- complete the easiest / shortest development task on your list
- if you get done early you you can work on one of the other development tasks
- at the end of the week cross off the completed development task and add a new development task to your list; bringing the total back to 3

I am thinking this would allow you to ignore tasks you don't want to do; while making sure you make progress on your game.

What do you think?

[Valen]

I hate to derail this thread further but I've got to speak up about Rich Dad Poor Dad...

Kiyosaki's material is fabricated. While his concepts may be good and correct, do you want to pay your hard earned money to someone who blatantly lies to you about their route to success?

Fabricated??? You mean he didn't actually remember the conversations he had when he was 9 years old with his nonexisting "rich dad"?? I agree with you that it's pretty lame to do this kind of stuff, but I just look passed that to the valuable insights he offers. I think his reason to put the books into that cheesy format was to make them easier to digest by the general public. Of course it's still pretty low to pass things off as real when they're made up. Shame on you, Mr. Kiyosaki!

[Sillysoft]

- complete the easiest / shortest development task on your list
- if you get done early you you can work on one of the other development tasks

I think it should be the other way around. Start with the hard tasks. They have to be done eventually, if you do them NOW then all that's left is easy stuff

re: Rich Dad, Poor Dad. I do not really mind that some of the stories are made up. The important things are the points behind the stories. I didn't read it to hear true stories about some guy, I read it to learn how to get rich

[Mithril Studios]

Keep in mind though Sean, WBS' are a project management tool and usually too high level for the nuts and bolts details associated with programming. Can you use them that way? Yeah, but I've usually seen it where the PM or PL will pass off a WBS item to a developer, who will then further break it down into smaller scopes.

And don't forget -- the 40 hour time frame is assuming you are able to work on it full time.

Anthony

[Morphecy]

Top-Down is good.

getting off-topic, sorry for that: but RICH DAD, POOR DAD was a very good eye-opener for me. Today I would be $10 000 less in student debt (I would have taken NONE if I could have seen what my eyes & mind didn't see ) and I wouldn't pay $1000 loan interest a year. If I had read that $10 book 4 years ago I would be a lot nearer to be a wealthy man today, but now I have to get myself up from the hole I dug.

I don't know whether the stories are true or not, but the guy said he had no money on his thirties and now the guy is millionnaire and making more money than he spends. And that - I presume - is a true story. And as sillysoft mentioned: The important things are the points behind the stories.

Besides - I know many people will possibly say the same things, but I also know which one I prefer: reading boring school lecture notes (where everything is dull) or reading stories - and learning when having fun reading these stories

I strongly recommend.

[MattInglot]

Top-Down is good.

getting off-topic, sorry for that: but RICH DAD, POOR DAD was a very good eye-opener for me. Today I would be $10 000 less in student debt (I would have taken NONE if I could have seen what my eyes & mind didn't see ) and I wouldn't pay $1000 loan interest a year. If I had read that $10 book 4 years ago I would be a lot nearer to be a wealthy man today, but now I have to get myself up from the hole I dug.

Don't be so sure. While I can't really back any of this info with independent research, here's some VERY interesting reading: http://www.johntreed.com/Kiyosaki.html

[Mithril Studios]

I didn't read it to hear true stories about some guy, I read it to learn how to get rich

The take away being to write stories about learning how to get rich?

(Sorry, I couldn't resist!)


Ahhhh, sorry to derail the thread further Sean!
Anthony

[MiCo Games]

These are just my personal opinions, so take it for what it's worth...

- complete the easiest / shortest development task on your list

This sounds like a recipe for disaster to me! Surely you would want to get the toughest, most boring parts out of the way first (taking any dependencies into account)? In risk driven development (which I happen to like) you try to identify the biggest risk of the project, eliminate that, and then pick the next one that is the biggest risk. That way, it should, in theory that is, become easier and easier the further into the project you get. If you start of doing all the easy stuff, you might also fool yourself into thinking that the project is shorter and easier than it actually is.

I am thinking this would allow you to ignore tasks you don't want to do; while making sure you make progress on your game.

Now, maybe it's just me not understanding this, but why on earth would you want that? Surely, if a task is on your list, it should be done regardless of whether you want to do it or not? If it is not important, it shouldn't be on the list, if it is on the list (and hence important) why would you ever choose NOT to do it? Surely the decision whether to do it or not should be done well before you put it on your task list, not at the point when you're about to start on the task?

just my 2 cents...

[Coyote]

My solution in the middle-stages of development (when things became less fun) was to break up tasks into groups of three.

Task 1 was a task I really didn't want to do, but I had to get done in order to continue progress on the game.

Task 2 was a task I really WANTED to do - something cool and flashy or something I've always wanted to experiment with.

Task 3 was something QUICK that I could get done in < 20 minutes and get one of those nice progress-indicating checkmarks down on my sheet.

I couldn't start a new 'triple' of tasks until all three tasks were done. The desire to move on to another fun or quick task motivated me to slog through the less interesting one.

[otaku]

For those who wonder about the easiest/hardest task first, can I direct you to “Eat That Frog!” which is a worthwhile read. Definitely the ugliest task first. Unless you just make it so there are no "ugly" tasks. Read on for how to smooth that out...

As for scheduling: I am notoriously busy, I teach regularly at two colleges, write regular articles & reviews for Game Developer (and other journals on an ad-hoc basis), and have a regular weekly book review column (well, it was regular until they decided to reshuffle the dept and the editors became confused over who was supposed to post the reviews but it seems to be getting back on track) and also (currently) hold down a full-time “day job” consulting for various companies so that my company can remain in business and fund development of the next couple of games.

I keep several separate task lists, those tasks I have to do for my personal life (laundry, grocery shopping, pay bills), a list of tasks for teaching & writing (write out lesson plan for X, review book Y next), a task list for my company (install & configure new backup software, deposit royalty cheques in bank, speak with accountant).

Finally there are the task list(s) for any games currently in development. These are the most detailed, mainly because I will be collaborating with other people during development, may have other people handle development, will need to schedule other people to have art/audio/levels/code ready by a particular date, etc. I break all tasks down so that any individual sub-task will fit in 2 hours or less, but never less than 15 minutes. This usually gives me a really good idea of what’s done, what’s left, how well I’m tracking, who’s behind, who’s ahead, and provides a lot of feedback of just how well the estimate was so I can integrate that feedback in to future scheduling. The list usually begins with a couple of dozen large primary tasks that equal several hundred small sub-tasks. As development proceeds more tasks are added, old tasks are removed because the design changed, and other tasks are refactored to change the subtasks or alter the time estimates. The schedule is not sacrosanct, nor is it cast in stone (something that many project managers & producers need to learn).

The actual scheduling of tasks is a task in itself, which is placed on the schedule (kind of a recursive task :-). Six month projects usually require about 40 hours of mucking about with the schedule over the course of the entire project. As I do a lot of iterative design-on-the-fly for the game play of the kind “Ooh! Ooh! Wouldn’t it be cool if…” the schedule has a tendency to grow quite a bit. Initially I probably don’t spend more than 10 or 15 hours laying out the schedule.

The schedule for me is the amount of time elapsed, the amount of time remaining, and a checklist of all the things that need to get done to ship the game. The schedule is like the game design document in bullet point form -- I usually spend about 40 hours total over the course of a project creating the project documentation, about 20 hours of that is spent in up-front design while working on the prototype as complex ideas rarely leap fully formed on to the screen but grow organically (I just had a neat idea for adding “power ups” that I never even considered four weeks ago when I was messing about the prototype).

As artwork and technology is implemented for the games much of it can be re-used, so the future schedule time will either go to zero, or will be spent on integration of previously developed solutions so the newer schedules will get marginally shorter.