Should I ask volunteers for my game?

News & General Discussion
1

I’ve been developing a FPS multiplier game for almost a year, and the sheer work that has to be done is starting to show itself. I would like to hire people to work on it with me, but I only have a few thousand to spare and would blow through that instantly.

I never liked the idea of asking people to help for free. I personally never had any interest of working on someone else’s project for free. Even if I did get a percentage of royalties when it started to sell, there’s no guarantee of return of investment. Should I expect other people to think the opposite? The only reason I could see myself wanting to volunteer for a project is if they are virtually making the exact same game I want to build.

Ok so maybe if someone does wants to help, I could help them in return by doing stuff for their game. But this doesn’t really add more manpower to my project, because if they are helping with my game, I would presumably have to work on their game as much as they are with mine to be fair.

Your thoughts on this? Should I continue to work on my game alone until I can get enough done to present to kickstarter? Or try to find more help?

thanks

my game
http://forum.unity3d.com/threads/154536-Steampunk-FPS-game

2

Think of it more along the lines of starting a band than along lines of exchanging work effort. Teamwork can be its own reward.

3

That’s such a good comment. I don’t feel I can add anything… skulks off

4

Yeah, penguin is right and just like in a band there will be creative differences, narrow-minded leaders, slackers, tons of motivation deprivation and mistakes.

If you are going to have a team, particularly if it’s going to be an online team, you need the following:

For all:
-Solid, clean, intuitive, streamlined and yet comprehensive Game Design Document.

-Effective leadership skills, project management, charisma, work ethic (lead by example).

-A demo of your game that shows one segment of your game that appears polished and close to finished.

-A video-chat application, for internet teams, like skype, make sure everyone can participate.

-A file sharing program that is tested to work. Version control, naming conventions, procedure, outlines for use of the directory.

For Artists:
-Reference art, (internet images, ideas for your game, this doesn’t replace concept art, just a place to start from).

-Concept art that establishes the art direction, if you don’t have it, then that is the artist’s first job.

-A planned out pipeline for art assets to be designed, developed and integrated.

For Programmers:
-Just this and a quiet dark place.

Working with Musicians:
-It’s important to understand that all musicians without exception are drug addicts of some kind.

-You will have to be persistent in explaining the simple ambient loop you need and that you don’t need or want a funky dance beat.

-Have extraordinary patience.

-Try to get classical composer type musicians or musicians that are older and past their druggy phase.

…Some of what I said might be helpful.

5

I don’t really agree with the bit about needing a Game Design Doc. I think they’re most useful when you’re working for a client (so that you and they are both agreed on what will be delivered) or when you’ve got a team so large (tens of people) that such documents are the most effective way of communicating the game’s vision.

That said, I’ve never been a fan of rigid up-front design, because I believe that designs should be living entities that are constantly updated as a project evolves to better meet the needs of users / enjoyment of players.

6

If you’re going to work with a team on what I assume is a somewhat complex game (not pong or angry birds) then you absolutely better have a GDD. Or at least that’s what I heard from the industry pro speakers at my college. It makes sense. The bottom line is that you need a list of instructions to give your workers, those list are the GDD. Even if you don’t write them down but just remember it all in your head, a Game design idea exists one way or the other. If the project is large, then the ideas should be documented somehow.

A complex game made without a GDD is like a complex drawing made without under-structure or a building constructed without blueprints. Things will be off.

7

In a team, GDD doc is important if you want to finish, otherwise you end up with unlimited scope creep.

8

Yes, I have been in one of those projects when I was younger. The project had no GDD and it was nebulous and ever growing. Every stupid idea accepted and usually forgotten or poorly conceptualized. It was like the tower of babel.

9

And you will most likely continue to encounter these sorts of projects during your career as a coder (assuming its your job). Ive worked for multi-million dollar companies that will start/run projects without tech docs and they just drag on and on, and end up with buggy as crap software.

10

I agree with this entirely, but there are many ways to skin a cat, of which a GDD is just one. As I said, there are circumstances under which I would (and do) use one. There are also circumstances where I wouldn’t (and don’t). And I’ve had success in both cases, many times.

A GDD is just a tool, and you should use the right tool for the right job.

11

Any documented plan to make the game is a GDD, what alternative is there that does not fit that definition?

I may be off-base, but I think the “you don’t need a GDD” point of view I hear going around here (it’s been discussed before) is the result of GDDs being boring to make. People want to see their work come to life, and if they set out to make a GDD, they will lose interest in the project before it begins. I think this is a fundamental problem with people’s approaches to making complex games, not an issue with GDDs.

12

Well, as I’ve said, I’ve done stuff successfully with GDDs before. So I’m certainly willing to make them if they fit the task.

An example of where a GDD isn’t suitable in my opinion is my current hobby project (which has a publisher and is to be released inside of a month after three years of development, so the fact that it’s a hobby project doesn’t make it a write-off). It was built with iterative prototyping, with the design undocumented and changing often based on player feedback, and a small team where we kept the design and scope under control through regular meetings and lists of ideas. Sure, I could have put everything in a GDD as it was locked down, but that would have dragged the project out and added nothing. When would we have ever referred to a document that only told us how to do things that we’d already finished?

13

Generally a GDD implies more than just “any document”. For example it would be rare for someone to consider a project plan, which is certainly a “documented plan to make the game”, a GDD given that it barely touches on the games design.

The “you must have a GDD” point of view I hear going around here seems to be the result of inexperienced teams failing and looking for something simple and concrete to blame. :slight_smile:

GDD’s are often useful but the use of any supporting artefact needs to be informed by your own experience. In my experience small teams can function quite well without them. As Angrypenguin mentioned iterative development where the prototype IS the design can work quite well (again I can only talk to teams of 2-6, I don’t have large team experience).

14

In my mind, a good GDD is a good quality outline, not too complex, not too simple. It’s the backbone of the project, it sets the rules and gives structure to what you’re working on.

The iterative approach can be fine in some cases, but it’s limiting and and prone to bad mutations. I think this method is as necessary as the GDD however, they should both be used.

After a GDD is established, you can have a back-burner list of potential features. The GDD should be followed religiously until the core game is finished. Then when you have an actual game (still not close to finished, but playable through) under your belt, that is the time for iterations and community feedback and busting out that back-burner list of ideas. If you try to take everyone’s advice and build on top of nothing and expect it to turn into something, it may or it may not, probably not.

In a way I suppose it’s possible if you work very neatly to use a prototype game as a game design document itself as long as you aren’t frequently adding extravagant features at that stage. Still it sounds like a bridge to nowhere. If I’m going to join a team, I want to know what is being designed, not just watch it come along and whatever it turns out to be it turns out to be on the fly.

I don’t give much regard to traditional definitions of what a GDD is. To me, it’s a definition of what is to be made, the scope and if needed the story and character details. The common Baldwin template is overly convoluted and redundant to be of any real value IMO. In my first post here I mentioned streamlined.

I can’t imagine what these small teams would achieve without any actual planning.

15

If you have an iOS device and a testfight account you’re welcome to the join the beta of one of my games that was achieved with no more planning than emailing feature ideas back and forth. PM me :slight_smile:

Of course your definition of GDD is pretty fluid so for the most part I agree. There’s usually some design artefacts floating about. My issue is that GDD tends to imply a heavy, detailed document, not necessarily of the complexity of some template, but still with a fair amount of content behind it.

One point of contention is that I still don’t agree with this:

I’d just much prefer to be flexible, as long as the project leadership has the drive to “get stuff done” ™.

16

@JohnnyA,

I imagine that much of the disagreement on this issue is due to semantics. I don’t think too many people think an extremely in depth GDD must always be used (except perhaps AAA CEOs). The reason I think GDD should be followed so devoutly is because it prevents mutations. While the GDD should be able to be changed, changes that are nothing more than adding new cool features should be avoided and instead added to some back-burner list. My discipline is that only changes that are of the nature of fixes should be applied to the GDD. That is careful measured refinement and not bloated thoughtless adding on.

I looked at some of your games, spellchain is the one that stood out to me as having complexity, still the premise is simple, not a bad thing at all, I can see a game like that being developed without a GDD. When I said complex games, I meant games attempting to rival AAA block busters like mass effect, skyrim or pokemon mmo.

17

Most of the stuff on my site are solo projects, built in weeks or even days (Vibre = 24 hour coding marathon :slight_smile: ). However the stuff I’m working on these days both internally and freelancing is quite a bit more complex.

That said very far away from a AAA level of complexity. If you are talking about something like that then I completely agree, I can’t see those being built without some pretty hefty design artefacts :slight_smile:

18

I think you’re doing it wrong, then. :wink:

From my experience with the method I really couldn’t describe it as “limiting”. To the contrary, it encourages trying multiple things to see what turns out best, where a rigid GDD approach encourages making decisions and sticking to them - despite the fact that you made the choice at the point of the project where you had the least information possible with which to inform the decision. And it certainly can be “prone to bad mutations”, but only if you’re unwilling to discard things which didn’t work out (which is necessary because you’ll be trying lots of things to see what works).

This should be reached within days of starting the project, if not hours, especially with the availability of tools like Unity. You can’t iterate until you’ve got something to iterate upon.

Of course… But if you’re just doing what everyone else says your hardly designing a game, are you? You’re just implementing a whole bunch of reactive ideas from other people who don’t share your vision. But also, people giving you suggestions is only a tiny bit of the process.

What’s far more important is reactions and responses to the game in general. Watch them play. What bits do they enjoy? Where do they get frustrated? How long do they play for? Do they pick up on all of the key information you’re trying to deliver? The job of a designer is to know the responses that you want to get and to craft the experience to evoke those responses.

I’m pretty stoked at a trade show if someone plays my game for 20 minutes and then gives me non-commital or negative verbal feedback. Why? Because they darn well played it for 20 minutes! On the other hand, I don’t get too enthused by people who walk off before they’ve even finished the first level, because obviously I didn’t strike a chord with them.

19

Glitch double post!

20

Indeed, I have a project that was similarly planned and designed. It’s the same one that’s getting published in a few weeks, developed iteratively with a focus on player response.

Interestingly enough, that player response was exactly what netted us the publishing deal. A publisher walked into a trade show where we had the game on display, watched a small crowd playing it for a while, gave us a business card and said to give them a call if we were interested in publishing.