next »

[aeiowu]

Thats a rather naive and inefficient advice - then again, getting married may be a bad advice in the first place :-P

Conflicts of interest are normal, unless you have robots working on something (and even then, conflicts may arise , because people have different intentions. While its true that open and clear communication is important, and that its the only way to resolve conflicts, some conflicts cannot be resolved without someone doing something which he/she doesnt really want (thus, the conflict isn't resolved, but just "subdued"). Such unresolvable conflicts can only be ended by both parties not colaborating in that aspect. To put it simple: Some stuff just doesn't work together, no matter how hard you try.

Thats why its important to have a clear idea about the path forward in the first place, instead of having problematic surprises later. That way, such "incompabilities" can be avoided from the beginning on.

Most importantly: Mindsets matter! Small ability deficits can fixed by learning, new situations can be adapted to - but different mindsets stick with you for a long time.

Why is that naive and inefficient? I'm not saying conflict is bad or avoidable in any way. I'm just pointing out what spawns it.

Mindsets are _very_ important, but I find those can be sussed out by working with someone for a short time with some experience. You've gotta know what you're looking for.

"It's debateable whether it's easier to find someone that has the right attitude but needs to be taught a certain trade or find someone who's great at what they do and doesn't have the right attitude."

While the Super Combo does exist, it's rare, and I think the point he's making is that attitude is just as important (if not more) as skill.

[AdamAtomic]

skills can be taught

[Lyx]

@aeiowu:

I think we're misunderstanding each other a bit, because we understand "conflict" a bit different. What you mean with conflict, is what i'd call an "active conflict". When stuff gets ugly, then thats just the surfacing of the conflict... the discrepancy often was there already beforehand, but just wasn't that relevant until that point. So, we dont actually disagree that much with each other - when you'd say "lack of communication spawns conflicts", i'd say "lack of communication turns passive conflicts into active ones" (and perhaps even amplifies them, if someone gets more and more frustrated for staying silent instead of talking about it openly).

[Derek]

Thats why its important to have a clear idea about the path forward in the first place, instead of having problematic surprises later. That way, such "incompabilities" can be avoided from the beginning on.

Ha, this seems a lot more naive to me, actually...

I understand what you're saying, but I've never been able to map out a game's development like that at the outset, and my experience coupled with stories I've read and heard from other people has led me to believe that most games change drastically at least a few times during production.  Also, it's impossible to know how a team is going to feel several months into development (probably a lot more tired and cranky!).  I think the "active conflicts" are inevitable and unavoidable, and you'll rarely have the luxury to simply not collaborate on an aspect of the game where you differ.

There are cases where its valuable to tap an artist who hasn't done games before specifically because they are fresh to it. (unique style, different perspective, etc)

In those cases its worth having some way to demonstrate exactly what work is involved in creating art assets for the project so you can get on common ground quicker.

Still, its dangerous to assume that when people say they can and will do something that they're actually aware of what they're doing - even if you've explained it in great detail.

Yeah, that's true.  I would love to see more of that "freshness" in the game industry.  If you look through the portfolio of an art farm like Massive Black, you start to understand why all (Western) mainstream games and movies look kinda similar... the art is awesome on a technical level, but oh so bland.  I'm not even talking about how everything is a hot chick/muscleman with shaved head and hoodie/biomechanical horror - you can do tits n' monsters with panache, and it's fine by me (e.g. Bisley, Corben, Moebius, etc.).  I just mean that the shit all looks the same!

That said, you know these fuckers will get you your art on time and not blank out on you.  But you'll get boring art.  So I agree, a unique artist who acts professionally is the way to go.  There must be a good way to vet someone for those qualities.  (Maybe we can ask Jon how he worked things out with David Hellman.)

"It's debateable whether it's easier to find someone that has the right attitude but needs to be taught a certain trade or find someone who's great at what they do and doesn't have the right attitude."

While the Super Combo does exist, it's rare, and I think the point he's making is that attitude is just as important (if not more) as skill.

I like that quote!

[Lyx]

Thats why its important to have a clear idea about the path forward in the first place, instead of having problematic surprises later. That way, such "incompabilities" can be avoided from the beginning on.

Ha, this seems a lot more naive to me, actually...

I understand what you're saying, but I've never been able to map out a game's development like that at the outset, and my experience coupled with stories I've read and heard from other people has led me to believe that most games change drastically at least a few times during production.  Also, it's impossible to know how a team is going to feel several months into development (probably a lot more tired and cranky!).  I think the "active conflicts" are inevitable and unavoidable, and you'll rarely have the luxury to simply not collaborate on an aspect of the game where you differ.

What you are pointing out was not covered by what you quoted. Of course i was not talking about preplaning every single minor detail. However, overall things as well as the mindset-stuff is something which one can know beforehand, if one has already a mostly complete "concept", and is "now" simply looking for colaborateurs to put the finishing touches on the concept, and then implement it. If one isn't doing ones own first larger project, one does already have a few "tried and tested" mates with which one can go through most of the project concept phase... so that when hiring, the overall path as well as mindsets are already clear. What then can go wrong is:

- the concept overally turns out to be flawed. Bummer. Start from zero.
- Minor disagreements in concept details appear. Those can usually be fixed via compromises, without hurting the project as a whole too much.
- Disagreements in teamwork during implementation happen. Those typically aren't disagreements about the project, but disagreements about the style how one works and interacts with others.
- Persons turn out to have overestimated their abilities. Well, in that case, make minor modifications to the team lineup while the project is already underway. Thats something which needs to be expected.

Did i miss anything? Well, those are the situations i have experienced in the past with non-game related software projects. In all those cases, the above strategy didn't fail me: plan the overall path beforehand with existing teammates. Recruit, pay attention to mindsets, play with open cards from the beginning on, finalize concept, start implementing, communicate, if necessary replace teammembers en-route. It may very well be that this approach has flaws which i dont know yet, because i haven't encountered them yet.

P.S.: One important detail may be, that i do have the luxury to exclusively work with people which have matching mindsets. I understand that for many people, this isn't possible - however, if the team doesn't coherently fit together already at the beginning, then yes, of course conflicts will follow.

[Derek]

I wasn't talking about pre-planning details, either.  I meant broad, sweeping changes in fundamental aspects of the game's design that are impossible to pre-plan.  Usually you need at least some type of basic prototype with art and code in it to prove that the concept is even viable.

Like, the entire thread is about art and artists... I want to make sure that when you say "non-game-related software projects" you're at least talking about something where artwork (music, etc.) is an integral part of the development.

But yes, I agree that it's important to try to be on the same page when you start and be flexible in the middle.  That certainly goes for anything one would work on.

[Triplefox]

Just wanted to chime in with some of my own recent experiences. I was tapped as a potential game design contractor for an early-stage startup. Having known everyone involved beforehand, I was ready to climb aboard temporarily and at least see what kind of work I'd be doing. I did a little bit of work here and there for a few weeks as they organized the business side of things, and the terms they were planning sounded quite good and included sweat equity, but in the end I realized that I was just waking up every day and saying "Do I want to work on my stuff, or their stuff?" and the answer became obvious that I was not interested in the startup at all, so I announced my departure yesterday.

The founders were happy to have me go, because as they put it, they knew it was more important to focus on the most motivating work, and it would not benefit anyone if I was on board and torn between the two projects. Fortunately, I hadn't signed a binding document yet, so it was easy to step out.

For my own work, I've already decided that I will do as much as possible by myself and learn whatever is necessary. If I ever do outsource anything, it'll probably be very small or mechanical work, things which are time-consuming but straightforward.

[Alec]

I think generally its good to have a 'living' outline - one that is loose and open to evolving.

Not every detail has to be laid out, because its likely to not work or end up changing. (as long as you can visualize how it will work in your head)

The projects I've worked on that have become successes are the ones with the least design documentation.

In terms of collaboration, I like leaving things open enough so that the partner can add their own creativity into the mix. In my current case I have a project that is very personally important to me, and I have a very clear idea of how I want it to feel - but it could be put across in a number of different visual styles that would all work well. So I'm open to considering a lot of different options.

The way I'm trying to vet artists now is by having them do some prototype work with me so we can see how it goes. In some cases this is paid, in some cases not. (depending on what situation the artist is in)

That way we can actually see how it goes without having to give up tons of $$ or a big % of the IP right off the bat.

[Craig Stern]

Derek, you really think this is boring?



Sorry--I don't mean to get things off track. I just happen to find this picture very interesting and dramatic. Unless you mean that the style is sort of been-there-done-that?

[AdamAtomic]

one counter-example does not refute an accusation of broad generic production   el coro and andrew jones have independently produced some very cool stuff, but I don't think that necessarily typifies the bulk of MB's production!

[mewse]

That said, you know these fuckers will get you your art on time and not blank out on you.  But you'll get boring art.  So I agree, a unique artist who acts professionally is the way to go.  There must be a good way to vet someone for those qualities.

I once worked with a team of four artists.  All of them were fantastic (and I'd very much love to work with any of them again, but over the past few years each of them has left the games industry and gone into film special effects), but of that team, one in particular was stunning in terms of his animation style and the speed with which he could work, though he was lacking in organisation and technique with the software.  So when we had stuff that really mattered, the team of artists basically reconfigured itself so that that one artist would blaze his way through all of the art which needed to be created, and the other three would spend all their time cleaning up after him and making sure that everything was in a form such that it could actually be used.

It was really effective and got us great results.. but I can't imagine that it would have been a very creatively satisfying job for those three artists on "clean-up" duty.

[Lyx]

I think generally its good to have a 'living' outline - one that is loose and open to evolving.

Not every detail has to be laid out, because its likely to not work or end up changing. (as long as you can visualize how it will work in your head)

The projects I've worked on that have become successes are the ones with the least design documentation.

I'm curious how you applied that style to Aquaria? I mean, the gameworld is huge and the gameplay isn't "basic". How did you do with just a small design spec and flexible overall outline? I mean this question seriously - i'm interested in how you did this that way.

In terms of collaboration, I like leaving things open enough so that the partner can add their own creativity into the mix. In my current case I have a project that is very personally important to me, and I have a very clear idea of how I want it to feel - but it could be put across in a number of different visual styles that would all work well. So I'm open to considering a lot of different options.

Agreed. Details like specific art-style, items, control, etc. shouldn't be nailed in place early on. The overall concenpt, "feel" and "message" is what may be determined beforehand - how in detail that message is communicated, can be adjusted en-route.

Hmm, bonus question: What are your preferences regarding prototyping? Do you tend to prototype all along the way, or prefer to pull as much of the prototyping as possible to the beginning? (I prefer the second approach, because near the beginning, sweeping changes to the concept are easy to do).

---

Maybe some practical examples are more useful than discussing on a purely abstract level. About a year ago, i for fun started to think how i'd like to do a paradroid successor. I never really had the intention to collaborate with others for doing it, because with a new programming language, web community, bookseries and an IF backburner project in the pipeline, i'd overstress my abilities if i'd start another project. Still, i conceptually sketched away anyways because this specific "what-if" scenario was fun to me.

Anyways, i quite early decided, that i'd want to keep the core gameplay and arcade-feel of paradroid 90, but would like to escalate what one does in paradroid more (being a covert intruder in a droid-collective, and basically working like a parasite). I especially wanted to make the player feel being that much more (atmosphere, immersion). So i scetched basic gameplay elements, like that the other droids would be on the lookout for the player (they'd regularily scan each other, like police checking peoples ID), that sensor ranges should matter (but not too complicated), that the player could go into "sleep mode" in which he'd be unprobable to be detected (with the visuals and sounds reienforcing the impression of sleeping, yet being in enemy territory), and borrowing some ideas from other games (security alarms (SS2), searching for datafragments (Impossible Mission), station self-destruct countdown (Alien Breed) and there being droid factories which's production one can reduce by sabotaging generators (Raid On Bungeling Bay)).

So in total, a generic idea about the "feel" of the game, and a handful of ideas how to create that feel... but without details being nailed down. Thats how i tend to do first overall concept drafts - and then some quick'n dirty prototypes (if i'd do the paradroid thing with others, it would be a simple one-screen tiled map, with placeholder graphics and some basic gameplay concepts in place to get a first impression).

[Derek]

Derek, you really think this is boring?

Hey, Craig-

First off, what Adam said, of course.  There are artists that work for Massive Black that I like, and they're definitely all uber-talented, with technique up the butt that I'd love to have.  I kinda feel like a dick now for singling them out, but it was the first example I could think of.  Some of the pieces in their portfolio are rad, too.

Regarding that picture, actually, I think it's just okay.  Thematically, it's hot chick + biomechanical horror, which, again, I have to emphasize is a theme that I enjoy, but still... then I'd like to see it rendered in a more interesting way.  The composition is kinda boring, in my opinion - it's basically side-view and there's not much depth or value to the piece.  The colors are too muted.

When I see that piece...



It gets lumped in with these:









I see a lot of stuff these days that looks like amorphous gray/brown blobs of flesh+metal to me, when there are all these other ways games could be influenced by art:




(Moebius was actually a big inspiration for Panzer Dragoon.)











etc. etc.

Even if you're going for a typical tits/monsters/fantasy/sci-fi thing you can put some pizzazz into it:



Gears of War could have easily looked like a Simon Bisley painting - it's got all the beefy attitude and everything.  But sadly, it doesn't.  The most creative monster they could come up with was like a gray fleshborg with sharp teeth and spider legs.  (And I had fun with this game, by the way.)

Anyway, end rant.

[Alec]

I think generally its good to have a 'living' outline - one that is loose and open to evolving.

Not every detail has to be laid out, because its likely to not work or end up changing. (as long as you can visualize how it will work in your head)

The projects I've worked on that have become successes are the ones with the least design documentation.

I'm curious how you applied that style to Aquaria? I mean, the gameworld is huge and the gameplay isn't "basic". How did you do with just a small design spec and flexible overall outline? I mean this question seriously - i'm interested in how you did this that way.

We just had very basic outlines that we kept changing. (we changed direction a few times) Basically the world grew from a basic outline (we'd map out the levels as just empty spaces to start, to see if they were about the right size) and then adding more details and making connections.

In terms of collaboration, I like leaving things open enough so that the partner can add their own creativity into the mix. In my current case I have a project that is very personally important to me, and I have a very clear idea of how I want it to feel - but it could be put across in a number of different visual styles that would all work well. So I'm open to considering a lot of different options.

Agreed. Details like specific art-style, items, control, etc. shouldn't be nailed in place early on. The overall concenpt, "feel" and "message" is what may be determined beforehand - how in detail that message is communicated, can be adjusted en-route.

Hmm, bonus question: What are your preferences regarding prototyping? Do you tend to prototype all along the way, or prefer to pull as much of the prototyping as possible to the beginning? (I prefer the second approach, because near the beginning, sweeping changes to the concept are easy to do)

For Aquaria we just jumped in and started making what we thought would be "the game" but it turned out that it was just a prototype.

So now I would lean towards doing more prototyping up front... but I'm still wary of having a completely separate prototyping phase for some reason. Maybe because it can make things too simplified or "sterile"? I prefer games that feel more organic...

I also am really interested in the way that visuals, audio and interaction collide and mix together - so I feel weird doing prototypes with just boxes and no atmosphere. I don't think games are, at their core, just about collision shapes moving around in different ways.

[Lyx]

We just had very basic outlines that we kept changing. (we changed direction a few times) Basically the world grew from a basic outline (we'd map out the levels as just empty spaces to start, to see if they were about the right size) and then adding more details and making connections.

This is interesting, because it sounds more like an artist approach (first doing the overall sketches and outlines of the image - literarily - and then adding detail).

For Aquaria we just jumped in and started making what we thought would be "the game" but it turned out that it was just a prototype.

So now I would lean towards doing more prototyping up front... but I'm still wary of having a completely separate prototyping phase for some reason. Maybe because it can make things too simplified or "sterile"? I prefer games that feel more organic...

Hmm, perhaps for early prototypes a "testbed sandbox" would work? I mean something like first creating just a small area to first test things small scale - and then after one got an idea how to approach the rest, extrapolating that stuff to a full gameworld? That wouldn't limit you to "sterile" testing of unconnected "atoms". Downside of course is that this way, you cannot test mechanics which span larger areas, or traveling between areas.

I also am really interested in the way that visuals, audio and interaction collide and mix together - so I feel weird doing prototypes with just boxes and no atmosphere. I don't think games are, at their core, just about collision shapes moving around in different ways.

Definatelly, yes. However, a full simulation would mean spending a lot of effort on content, at a time, when it is very probable that things get discarded often, no? The compromise which i use, is that i dont look at such "placeholders" as what they are, but just use them as cues to imagine the rest ("assisted imagination" or smth like that ;- ). I guess this also depends on personal thoughtstyle - for example, i rarely think purely "abstractly", even if from my posts, it may seem that way - i typically also imagine what i think (not just entities, but especially how things are connected).

To me, it seems that simplistic early prototypes are okay, if: 1. You do not just see "boxes" but in your head add the rest / 2. It isn't black/white "Early prototype -> Full Implementation" but instead one or more steps in-between, so that a transition can happen. Or do you think that there is an alternative to simplistic early prototypes, which doesn't require a lot of effort?

[aeiowu]

A few things i learned early on considering the creative process. In this case it was for fine art (learning to draw)

General to Specific. Get your structure laid out on the page (screen) first, if you're not amazing and haven't been doing this for decades this will be a struggle. But it will be worth it.

At some point you have to stop looking at the still-life (plan) and start responding to the drawing (game) itself.

I think both of those speak to Alec's process. They are certainly true for ours. For our current project Liferaft we had one idea. Basically a world seen from one persons perspective. It grows from there. I've redone the art about three times now and that's not unusual. I think we redid the art for dinowaurs (at least the menu system) about 7 times. For a collab I'm working on now, Protonaut, I've scrapped the art three times over a span of a few months.

I don't know what I'm doing 100%. And I'm not going to let some almighty preconceived plan or previous iteration get in the way of both the learning and making the game way better. That's what they mean when they say "Kill your darlings".

[Lyx]

I don't know what I'm doing 100%. And I'm not going to let some almighty preconceived plan or previous iteration get in the way of both the learning and making the game way better. That's what they mean when they say "Kill your darlings".

Try doing that with a large project.

Info: There is something beyond "total control" and "total chaos"... has something to do with "guidance" i think.

[AdamAtomic]

Try doing that with a large project.

I mean this in the nicest way possible, but I am really tired of your condescending rejections of sound advice from experienced devs

[Lyx]

Well, since this is your thread, i will accept your rejection by not continueing to participate in the thread. Though, i would like to remark that your rating regarding "condescending" by itself is only morally relevant, but *by itself alone* logically irrelevant (it does i.e. not say anything about truthfulness). Also, i'd like to thank Alec for some of his descriptions, because those already spawned an interesting and practically useful discussion between me and someone else.

Have a nice day.

[AdamAtomic]

It is not my thread, but you talk a lot of crap:

Though, i would like to remark that your rating regarding "condescending" by itself is only morally relevant, but *by itself alone* logically irrelevant (it does i.e. not say anything about truthfulness)

what does that even mean??  No matter how you slice it, laying this out there:

Try doing that with a large project.

is a really condescending thing to say to someone who has been developing games publicly for a few years now, especially when you yourself have no game dev experience.

I like the discussion that is happening here, but replying with longer and longer brute force explanations of why everyone is wrong without backing it up (and when the majority of both small and large scale indie dev serves as direct evidence against your claims) is not furthering the discussion of work habits/design docs/project planning.