next »

[Problem Machine]

I wasn't sure where else to put this. If there's a more appropriate forum for it, feel free to move it there.

So, basically, as I've begun to take this whole game dev gig more seriously and try to move forward, it's become more and more apparent that aside from the 'creative' stuff (art, music, etc) and the 'technical' stuff (code, frameworks, etc) that there's a third discipline that's necessary to finish a project, which would be I guess the logistical stuff. These are the things that, in a larger project with more specialized roles, would be under the purview of the producer: Delineating what needs to be done, when it needs to be done by, and scheduling hours towards achieving that goal.

I dunno about you guys, but I hadn't anticipated that on top of having to be a programmer, an artist, and a composer I would have to be a producer as well. It was a considerable tripping point for me. It had simply never occurred to me until I had multiple discipline failure meltdowns, and I had to think long and hard about why it kept happening. The fact is, however inspired I am, I usually come to a point at which I'm confused about what aspect of the project to work on next, and nothing saps creative energy like confusion.

So I guess the purpose of this post is twofold. First, I want to make people more aware of this as a separate discipline that needs to be practiced: In fact, I think this issue is why it tends to be taken as a truism that, for the most part, only the small projects get finished. If we train this skill, we can approach larger projects with less risk of them collapsing-- and, for those of you who already intend to tackle large projects, I hope that perhaps this post can save someone the years of confusion I had to work through.

Second, I'm looking for pointers, useful software, techniques, or whatever else regarding this kind of discipline that I can apply to my own work. Right now, I mostly get by by writing up daily schedules for the next day at the end of each day. Something like "1hr animation, idle cycle" or "2hr coding, display class" or whatever. This helps keep me focused on basically what I should be working on, but has the considerable drawback that if whatever I pick out to work on isn't clicking at the moment I can't really switch over to another part of the project. If I had a master list of everything that needed to be worked on at any given time, it would give me far greater flexibility, but developing that kind of project outline is a job unto itself.

So: Whatcha think, tigs?

[doihaveto]

I can speak to your second point.

What I end up doing, is maintain a master spreadsheet (I call it a "burndown list") with all the little line items that need to be done. Each line has a bunch of fields: what needs to be done, priority, deadline (if applicable) - this way I can see at any moment what's needed soon, and switch to it as needed. Every todo item gets a line in the spreadsheet - especially the tiny ones, because they're a lot of fun to cross out after only 5 minutes of work.

Yes, it takes a while to come up with the initial burndown list. But then once you have "v. 0.1" it's easy to update and add new items as you discover more stuff. Also, it's a good thing to keep me from going off-tangent, the list of "all the stuff that still needs to be done" keeps me on track towards finishing it.

[ஒழுக்கின்மை (Paul Eres)]

that's a good point about an indie needing to be a producer -- a lot of indies don't realize this. they think they're a programmer, and maybe an artist and musician and writer, but they don't even consider that to be successful they need to also be a marketer and a producer, and be very bit as good at those as they are at programming, art, music, and writing

anyway, there's already a lot of threads on this topic, basically, read threads in this forum about:

- productivity
- motivation
- design docs
- to do lists

there's nothing really i can say here that i haven't already said in those threads on specific aspects of being a "producer"

[ஒழுக்கின்மை (Paul Eres)]

well, i guess specifically with regards to scheduling i can say this: a lot of game development teams (mainly commercial but also some indie) use the concept of monthly milestones, which is a form of timeboxing. basically you assign certain features to be completed in certain months. so, for instance, february might be 'enemy AI', march might be 'balance', or whatever -- and in those months you focus on just that

i use this myself with SD, but i'm a bit lax with myself and don't always finish a particular feature in its assigned month, leading to it bleeding into the next month. but i still think it's valuable, otherwise you won't know *what* to work on, especially early on in a game's production when there's so much that you can work on

the "ideal" hypothetical milestone schedule for a basic game would probably look something like this:

1. create the design doc
2. create the basic engine and player controls, basic rules, title screen
3. create the level editor
4. create the game resources (sprites, etc.)
5. create the enemies (code behavior, AI, etc.)
6. create the levels and code the map elements (e.g. traps, spikes, whatever)
7. create the options menu, credits, ending, and other "polish" stuff
8. beta test the game for balance, get feedback, implement suggestions that make sense
9. create the trailer, website, installer, and release, and then market/promote the game

each one could be assigned a month, and then you'd have a 9 month development schedule

[Klaim]

I understand the energy waste of being confused, and when I reach this point, it's time to do a diagram.

What I do is a very simple diagram of how the whole game should be structured (features), something high level. Immediately I see the hole to be filled. If I don't, I just make the same diagram but more detailed. Lower level.

Most of the time, this confusion occur when you just finished a big feature. A good way to manage it, I find, is always having another big feature that you want to do next, by starting to think about it (but not work on it yet) when you're in full production mode in the current feature.

Also, as noted elsewhere, todo lists.

[Problem Machine]

Thanks, this is giving me some interesting ideas to think about (also I felt kinda down about having no responses after a day, so this makes me feel a bit better, heh). Right now I've just been taking down notes on a legal pad, since I find there tends to be less resistance for me when making marks on paper than there is in starting a computer file (I can always make the file later). So, around the time I was writing this post, I made these:


The left sheet is a breakdown of the broad categories of work required for the project, IE level flow (I guess one would consider that the design document), level architecture, entity behavior, etcetera. The right sheet is a breakdown of the intro sequence with each of the things required to be completed in each category: Almost certainly incomplete, and eventually will require a further breakdown for what goes into each of those tasks, but a guideline anyway.

Now, having gotten that far, I'm very quickly getting discouraged in this work. It doesn't feel like real work, even though I know it will probably pay dividends in the long term. Ironically, I think it's listing out all of the things that need to be done that tends to make me restless with working on the schedule.

That design flow makes a lot of sense Paul. I've been kind of jumping from thing to thing, maybe it would make more sense to completely finish one part of the project before moving onto the next. I tend to get restless when I work on one thing, but that's no worse than the other emotional garbage I have to fight through to get something done. How close do you stick to that style of schedule?

[ஒழுக்கின்மை (Paul Eres)]

my own milestone schedule was much more complex than my example, but i generally stick to it. there are of course times when i start working on my intended part of the game, and then set it aside instead to work on another random part instead, but generally (80% of the time or so) i work on what part of the game i planned to work on, the part assigned to that milestone or month's goal. i think it's okay to do other things too as a diversion or a break, especially bug fixes (which generally should be fixed as soon as they are found), as long as *most* of what you do is for the current milestone

[Xienen]

I definitely agree with Paul's direction. Finishing a single part of the game at a time tends to work well and taking breaks to fix bugs as soon as they are found can keep things from feeling monotonous. Not to mention that fixing bugs as soon as you find them keeps your game in a mostly solid state throughout development and will really help you not ship a buggy game in the end.  Even some larger companies fail to debug as they go and end up shipping an awesome game with hundreds of annoying "low priority" bugs that get mentioned in every review and end up destroying the game...not pointing the finger at any of my former employers

I'll also add that I have found creating 1-2 month milestones for my team works very well when I give lists of "must haves", "should haves", and "extra credit" tasks for each of them.  I also make sure, via these lists, that everyone knows what everyone else is working on and what the final version of the next milestone should look like.

[Problem Machine]

I guess more specifically what I'm wondering is are your project milestones that tightly localized to one aspect of the project, IE design->code->asset production, or are they a bit more vertical slicey, like level 1->level 2->level 3 etcetera, or something in between?

Also, Xienen, what would some of those milestones look like?

[Moczan]

That really depends on how you already manage your project. I tend to maintain 2 list, one with long-term milestones and one with smaller to-do like items which are my daily chores. That way you have you day to day plan, but also don't get confused when your 'next up' list gets empty and you have to repopulate it with task.

[Xienen]

I think it all depends on where you are at in your project.  When you are still pushing toward an early alpha build, I would tend to focus on bringing each of the game's mechanics online(in an unpolished state) and one version of each type of level, as creating multiple levels when you haven't nailed down how the game should play is just wasteful.

While building a beta, those game mechanics should be being refined and polished while the alpha levels are being polished and new ones are being made.  This would also be the time when the menu system is getting completed and/or refined.

I would aim for each of these milestones to be 1-2 months in length, so you'll have to look at your team's capabilities to determine what all should be included in each milestone.

For example, during Break Blocks' Beta, we had a 1.5 month long push to get the final 3 enemies modeled, skinned, and implemented, while the musician was pushed to create 5 new songs(he was behind schedule, so we were trying to press him to catch up), and I was working on implementing the Leaderboard system, polishing the menus, and changing the amount of space on the board for blocks to be placed.

[Problem Machine]

BTW, for anyone else reading this looking for useful scheduling things, I'd suggest you check out Trello. I've been using it to construct to-do lists and I'm finding it super useful to get this stuff out of my head and into a list of items-- one which I can easily see an overview of and which feels a bit more professional and permanent than notes on a legal pad. Right now I'm bouncing back and forth between planning out the basic flow of my game on a legal pad, transcribing/editing those ideas into design document files, and then planning a task-list based on the tasks and assets suggested therein.

I think once I have the task list complete, it should be relatively easy to construct milestones out of these task lists. Then, it's just a matter of meeting them. Exciting! 

[Klaim]

I've been considering Trello for some time too, but I kind of fear having everything online, in particular todolists. Which is why I still use paper. It's unperfect but can use it in the train or somewhere I don't get internet access.
But I guess I'll use Trello in the future.

[Problem Machine]

Well, I think you can always print out the checklists if you need to work off of them on the train, and if you to add stuff it's not too hard to just jot it down and add it to your online worksheet later.

It's a valid concern, but I've had trouble with hard copies in the past: they're easy to make, but as the project changes they get invalidated and I usually end up discarding them and that's 100% of the work down the drain. With this, I can feel comfortable that I can modify it later on without having to redo the whole thing, which makes me a lot more comfortable investing my time into creating the task list in the first place.

[Klaim]

Well, I think you can always print out the checklists if you need to work off of them on the train, and if you to add stuff it's not too hard to just jot it down and add it to your online worksheet later.

Really it's more me not having a way to make sure I can work regularly at the same place, or even print something or even be connected when I'm using my laptop. Once I got a desktop and a more permanent place to live, I'll certainly setup a Trello. Don't bother about paper if you don't feel like it.

That being said, I like to make drawings, use my hands (to write, you pervert) when I'm brainstorming or just listing my needs. So I'm inclined to use paper or a drawing board first.

By the way, I've used and mastered tons of issue trackers before, even learnt linux server setup doing so. So I know that working alone on a project with an issue tracker is very time consuming and not a good idea in the end. However Trello works great because it's instantaneous setup and you organize it immediately without configuration.

[Klaim]

Holy shit I just figured that I now have a smartphone that can live more than one day without dying and there is a Trello app! That might partially fix my need for paper... I'll try see how it goes.

[Problem Machine]

That being said, I like to make drawings, use my hands (to write, you pervert) when I'm brainstorming or just listing my needs. So I'm inclined to use paper or a drawing board first.

Yeah I've gotten into that habit when it comes to the creative stuff, and I was doing it for task lists for a while too until I started to dislike it for the reasons I mentioned. It's still cool for shorter term task-lists, like bugs I've noticed in a module I'm currently working on, I just dislike it for anything I'll be using more than a week or two into the future.

[Mister Dave]

The one thing I've found to be invaluable is a PHPBB forum. Everything gets its own thread, and there's no excuses like "Oh I forgot about that". Whether on a distributed team, or working on your own I think it has value and works better than a wiki (we tried that first - it became too convoluted).

On our team there's no Skype meetings or phone or IM chatter. Everything goes into the forum. This way everyone can track the progress, make suggestions and post solutions, and it's always there as a complete record when an issue needs to be revisited. It also keeps our inboxes from filling up with anything but forum post notifications which we can safely delete.

We also post documents and how-to's and any other resource links, along with personal blogs so everyone knows who's doing what.

[Problem Machine]

The suggestion of using a forum for a one man project is super interesting. Is there a way to host something like that on a hdd, or would you need to get a webhost?

[Mister Dave]

The suggestion of using a forum for a one man project is super interesting. Is there a way to host something like that on a hdd, or would you need to get a webhost?

I suppose you could do it locally, sure. https://www.phpbb.com/