[bulak]

The problem with indie adventures
A practical project management approach

For years, I have seen many promising projects perdure for years and then sadly sink into oblivion. The reasons are almost always the same. Lack of spare time, exhaustion of working on a complex project, quarrel between team members and lack of organization and leadership.

Everyone wants his project to get done and attain expected results, but all of that comes at a price. You'll only notice the harsh hurdles of game crafting when you've worked for some time on the game. By then, there will be a developed attrition with colleagues and a general lack of interest in pursuing the final result, in an unorganized team. But what can we do to avoid the work of so many talent people being wasted?

Many of the guys responsible for the technical work (and the artists and creative minds, to some extent) in this line of business are on this because of their passion for old-school games. They tend to be proficient at software development/creation but they usually lack the skills of enterprise software engineering and project management, which are essential for any relatively medium/large project like adventure games.

It needs to be conveyed some set of rules which will allow the developers to align themselves under a common leadership and pursue the exactly the same goals dictated by the project manager, thus bringing a formal general entrepreneur behavior and feeling *to the team, even if they work in their spare times. More specifically I'm talking about bringing some basic concepts of the PMI for the sake of "getting things done".

Enough of this intro, I'll cut to the chase by my experience as a project manager:

*Many of these projects are conducted by a team of 2 to 4 friends who have old-school adventure games as a common passion. There we have 4 men working theoretically at the same time in the same project. If we could merge 2-3 "group of friends" into working together in the same project we could double or triple the speed of production.

*Each "group of friends" --which I'll call a 'subteam'-- can indicate a single 'subleader'. Of the 3 subleaders, one should be voted as the project manager, which is responsible for the general direction and good flowing of the project as a whole. Important aspects and directions of the project should be voted among the leader and subleaders.

*After the above steps are set, every team member must sign a "virtual contract" stating that every member must compromise himself to the project to his best efforts and accept and carry on the decisions of the leaders even if he doesn't agree.

*The whole team must assemble and hold a 'virtual meeting' to craft and decide the main elements of the game: history, concepts, graphical style, development patten and platform, task partition etc. These must be documented and well detailed (the details are sharpened as the project progresses) into a standardized document only available to the team.

*The work must be distributed by the leaders of their respective teams so no one gets overloaded nor no one idles. Each individual task must be set with a reasonable deadline and after this, a few days for eventual rework, corrections and/or alterations.

*Periodical virtual meetings should be held to decide and revise key points of the project and as to assure everything is running as planned. Everything must be recorded and clearly informed to all members.

When you work with such basic organization not only you feel you want to get it done asap, but you also feel what is like to work with a greater team and you don't want to disappoint the other team members nor your "boss", who are counting on you.

It's sad when I see a WIP game being scuttled because lack of organization. These guidelines are merely a means of helping people to get things done faster and better, and most importantly, a means of helping a game to get to the gamer. I encourage developers and artists to talk amongst themselves and make new contacts, new opportunities.

[Ascovel]

Good topic. And those are some nice workflow goals. Especially for someone who sets to create indie adventure games full time. But of course that's not always the case.

So let's say you're an amateur team and no one makes money from working on the game. What to do if a member of the team or even every member of the team keeps failing at delivering the needed work for the deadlines? How to discern a "reasonable" deadline from an "unreasonable" deadline for things you never done before in your life?

What if the whole team starts to hate the project because it starts resembling too much their dayjobs? It's damn hard to build a team of people passionate enough about such projects to give up all their afterwork time for it.

I think those are some very serious problems of this kind of organized approach.

There's actually at least a dozen of solid indie adventure games coming out each month, so fortunately many people manage to get the hard work done. However, the biggest challenge might be having the individual indies develop their skills as designers instead of burn out or lose interest after the first attempts. I think a greater amount of moral support (than we see at the moment) from the genre's fans would help the teams immensely stay motivated and to release new games more often.

[bulak]

There are many topics and details that can't be covered in a single post, I tried to be as brief as possible. The subject is so complex that it deserves a book on itself.

I assume that if you work with computers, it is because you like it. And you like making games even more. Otherwise, you'd be working on something else and wouldn't even bother making games. Said that, everyone who works in IT (or everything else) should know that to obtain results you need to commit yourself (No pain, no gain). Things don't come easy, everything has a price. Most artists/athletes/businessmen etc you see on TV, struggled for many time to have their work recognized. Some succeeded, some failed. That's how life spins.

If one thinks he doesn't want to commit himself, then he is not suited for indie development (and a lot of things).

These guidelines are not to put pressure on the team, it's merely a successfully tested way of organization, which is essential for the medium-to-large software development process. If some are fine the way they work at their games, and things are flowing, then fine. They don't need to change something that is progressing (unless it is progressing 2% per year). This is targeted to groups that are having the aforementioned issues.

But, answering your question, it is the role of the project manager to manage and administrate the work team. If someone is failing the deadline the PM should temporally substitute him, or even "fire" him", in the worst case. The PM must be a well-articulated person with leadership and who gets along with everybody in the subteams. Above all, everyone needs to use his common sense. At first, if one is not delivering, he should have conscience that he is impacting the whole project and ask to leave, before he be asked to leave.

[Datadog]

There's some very good points being made here. I've had a lot of experience as a project manager and I've fallen victim to all of these same prat-falls with organization.

One thing I could speak out against is the idea of having the whole team decide on the game design. Unless the whole team is made up of extremely good friends who all think alike, directing a game as a democracy can fall victim to lots of time-wasting arguments, conflicts of philosophy, and tons of inconsistency. Strong leadership is key.

The other big problem is the jump from pre-production to actual production. Pre-Production is more-or-less the best part. It's the part where everybody dreams, designs, writes, creates, pats each other on the back - and in the end, once you've completed that design document, it feels like the game is right around the corner. Then, once the REAL work starts, everyone looks at their watches and remembers they have day-jobs. Suddenly, a lot of them realize it's not fun anymore.

In the industry, people keep telling me that any good team is made up of many great developers with small egos, who are are managed by very few leaders with big egos. I think many indie projects fall apart because the team egos are generally unbalanced. We can either have a group of committed developers taking all the time in the world to retouch their work and never actually get anything done, or a group of ego-centric leaders all trying to creatively hijack the project from each other *raises hand in shameful guilt*.

Sadly, you have to be a bit delusional to find incentive sometimes. Leader or developer, you have to convince yourself that the final product's worth it. That it'll look great in your portfolio and resume, that it'll be good experience, or even change someone's life person's life. A good team always believes in something, and a good leader can keep them believing.

[Ascovel]

Originally Posted by Datadog

The other big problem is the jump from pre-production to actual production. Pre-Production is more-or-less the best part. It's the part where everybody dreams, designs, writes, creates, pats each other on the back - and in the end, once you've completed that design document, it feels like the game is right around the corner. Then, once the REAL work starts, everyone looks at their watches and remembers they have day-jobs. Suddenly, a lot of them realize it's not fun anymore.

In the industry, people keep telling me that any good team is made up of many great developers with small egos, who are are managed by very few leaders with big egos. I think many indie projects fall apart because the team egos are generally unbalanced. We can either have a group of committed developers taking all the time in the world to retouch their work and never actually get anything done, or a group of ego-centric leaders all trying to creatively hijack the project from each other *raises hand in shameful guilt*.

Sadly, you have to be a bit delusional to find incentive sometimes. Leader or developer, you have to convince yourself that the final product's worth it. That it'll look great in your portfolio and resume, that it'll be good experience, or even change someone's life person's life. A good team always believes in something, and a good leader can keep them believing.

This actually makes for a very good argument that the only viable working method/ethic for big companies might not be the best choice for indie hobbyist game-making.

Making games with no guarantees should be first of all FUN throughout the whole process. The way the work is organized and managed should be tailored to the group of people that decide to make a game together, and not set primarily on competing with other games out there.

The usual problem is people start way too ambitious, as well as they make their projects too inflexible for indie development. What they often don't realize is that they can start very modest, and when they see it's working they can effectively rework it into something bigger and better.

How many people here have heard of a little game called Bestowers of Eternity?

[Trumgottist]

Originally Posted by Ascovel

How many people here have heard of a little game called Bestowers of Eternity?

Most of us, is my guess.

[TimovieMan]

Originally Posted by Trumgottist

Most of us, is my guess.

I had to look it up...
Don't hit me!

The only thing I've ever taken out of the AGS community is Robert Redford Saves the Day, because that was hilarious...



I can definitely understand the trap of doing something far too ambitious and consequently not being able to finish. I'm prone to make those same mistakes all the time, and I don't develop games...

[gray pierce]

Originally Posted by Ascovel

The usual problem is people start way too ambitious, as well as they make their projects too inflexible for indie development. What they often don't realize is that they can start very modest, and when they see it's working they can effectively rework it into something bigger and better.

Hm guess you're right. Perhaps better I put my large and highly unconventional partly written script in the fridge and go for something a bit smaller and more traditional. Let's spin those braincogs again!

[Trumgottist]

Originally Posted by gray pierce

Hm guess you're right. Perhaps better I put my large and highly unconventional partly written script in the fridge and go for something a bit smaller and more traditional. Let's spin those braincogs again!

I can understand making something smaller, but why go for more traditional? Isn't being unconventional traditionally a strength of smaller things?

[Datadog]

It's still a matter of preference. For some people, dabbling in traditional methods can prepare them (or even inspire them) to create something new and original.

[gray pierce]

Originally Posted by Trumgottist

I can understand making something smaller, but why go for more traditional? Isn't being unconventional traditionally a strength of smaller things?

Yes but if you're gameplay is so unconventional it doesn't fit any engine(or at least none I know that can be downloaded) meaning someone has to build one than you have a whole lot of problems on top.

[Ascovel]

Originally Posted by gray pierce

Yes but if you're gameplay is so unconventional it doesn't fit any engine(or at least none I know that can be downloaded) meaning someone has to build one than you have a whole lot of problems on top.

Gray pierce is absolutely right. I made the mistake of gravely misjudging how long it will take to code and polish a new type of gameplay myself. And not so long ago either - with the project I'm working on now...

If I didn't successfully complete a much more traditional adventure game a year ago, I might have succumbed into doubt after things not going according to the plan. But as it's not my first game project, I just treat it as a lesson about what is the price and risk of certain bold choices.

[Pyke]

I find that most projects are over before they even begin because of ONE factor:
Planning.
The truth is that people get super fired up when the first 'spark' appears for the project-and jump in feet first. Carrying that enthusiasm forward is the difficult thing.

It sounds like an obvious piece of advice, but before ONE piece of artwork, ONE piece of programming, ONE person is even contacted, the entire game MUST be planned. Every story element, chapter, screen, and every puzzle.
Its something that I am very guilty of, and as a result I lost out on about 6 months of development. Now the advantage is that I *just* wasted my time-but if I had a team of people, and I'd thrown away 6 months of their spare time and weekends, I can tell you now that most (all?) of those people would have dropped the project in a heartbeat.

I also think its VERY important to break up the game into very distinct chapters, as this allows for a delegation of work easily, as well as giving you are very clear idea about the progress of the game.

I also think its important to keep things interesting for the people involved. By having a solid clear and COMPLETE design document, you can assign tasks to people all over the game world. Lets say you have some areas that take place in a jungle, but the last 3 chapters take place on a floating steampunk city-the dude working on jungles for 3 months is more than likely going to drop the project if its just more of the same. Mix it up by having people cycle to different pieces of the project.

Granted Im in a pretty unique situation in that Im a team of one-but the ways I motivate myself are, Im certain, the same as if I had a few people working with me.

Focusing on the more traditional game play styles really isn't a bad thing. Especially for a first project. The tried and tested UI's and game play conventions in Adventure Games are absolutely FANTASTIC, and at their core, are really easy to implement. Working within the limitations of the genre can be surprisingly freeing. Instead of trying to figure out how your incredible new game play style will work in certain situations, you can focus on the important aspects of an Adventure Game-Engrossing Story, and awesome puzzles.