game designer role

Hello after reading the colaboration fórum I understood a bit more about the game designer role but i continue with some doubts, so I would like to know if you could help me.
My main doubt is if the game designer can do the jobs of a project manager and a producer specially in indie projects?

Because besides being in charge of all design documents and deciding how the game will function, the game designer act as the linking point between the departments so he would be able to define deadlines and calculate estimated times for tasks.
I would also like to ask what would be some work created to other departments by game designers and since they are the ones who think how the game will work is it possible to have a screenwritter in a team if there is already a game designer?

 

Indie teams seem to include several hats for each member of the team. It is not unusual for the designer to be the project manager as well as other titles. However, that is not the usual role of a designer. The project manager should be the person best at handling the paperwork and managing the team, so someone who is good with people. Producer is a little different, as that is often the people who bring the money.

You can have whatever you want on your team. Look at the people you have and decide who is best at what. Then start looking for folks to fill the holes. Remember, an all volunteer team can be a fantastic bonding experience, but volunteers often do not stick around for long and need to be given tasks. I ran a team of 10 volunteer writers and while some of them were prolific, others had a tough time without hand-holding. Since they are volunteers, you have to be sympathetic and patient. Remember, they are collaborators, not paid workers.

Seriously, I suggest to all new game developers that they work on the game with their primary group, maybe two or three people. Once they have something to show, a nice prototype, some videos, etc., then start looking for outside help. If you bring in people too early, you won't get the quality you might want and they may not stick around through all the boring beginning processes.

Besides, you have a lot of decisions to make at first and too many hands in the pot can make things too difficult.

 

I think designers can calculate milestones based off of the estimates given to them by lead or senior artist/programmers, but a designer calculating estimated times for tasks to be completed based on a desired milestone date is a receipt for eventual crunch and missed milestones. Not good.

 

Teams got to get pretty big before you need a specific role just as a game designer. And it's not the transition from guy with ideas. In an indie team it's more likely to be a coder or artist with the aptitude for management and design that gets the role. Not some guy off the street.

Once you have a few years under your belt as a designer you might get picked up specifically for your design skills.

As to the how of estimating, this is mainly done based in expert opinion and previous experience. Coder A always takes twice his estimate. Artist b will only make progress if it's due tomorrow an so forth.

Artists an coders first

 

The way I like to think of it, if you get an artist and a coder, put them in a room together, and say make a game, not only will their be disagreements, they wont understand each other. Its two completely different walks of life. A game designer works in many ways as a conduit between the two.

Really, a game designer must be able, and willing, to do pretty much everything, but they'll never be a master in a single field.

 

The definition of a game designer does vary from person to person and the discussion can become quite complicated. What the OP describes as game designer I would rather call a leader or director. The term creative director became more popular in the last few years and I think it is a good title for such a position.

I have to disagree if we speak about the role of any game designer. Quite a high amount of game designers do have little knowledge on programming or art. It has to be some kind of lead in the team which has knowledge of various areas. In small and indie teams it often is the (only one) game designer and that is why this position is often seen as the one in charge.

At movies the director is seen as the mastermind, which on my view is not often the case. But if directors such as Christopher Nolan or James Cameron do the screen writing, have ideas for the artistic style and do some technology related stuff then they are definitely in a leading role. In that case the director is the mastermind of the project.
Game designers are often compared to directors but in my view they are rather screenwriters. The director is the kind of person keeping charge of the project but also is the one who is responsible for its success - so is the producer as well, but we talk on development positions only here.
The art director for instance is responsible for the art department (which can be seen as a sub-project). The AD will estimate and approve tasks, assign and manage artists and provide guidelines for how to work.

Its different to any project who the leader is. There can be more than one as well. In the industry it often is the one with the money or an experienced person in the studio. A huge amount of projects on the forum for instance start with a guy in charge with a vision and no additional knowledge. That's not the right person. But it does not belong to any position by default.

The point of this post is that I believe the game designer is not the right person. But that does not mean that the right person can't be the game designer as well.

 

The definition of a game designer is different in indie and AAA games. Since I am quite sure the OP is an indie developer, then it is perfectly fine to have the game designer as the lead of the project if that person has the capacity to do so. I am a game designer, with a little knowledge in everything. I am a writer, a 3d artist, a texture artist, and while I don't code myself, I can read code enough to know what it means and I have a pretty good grasp at what is possible and what is just "pie in the sky dreams" when it comes to games. Since we are a small team, I also manage the team, keep a record of our assets and the work done. I make sure the website is up although someone else does moderate. I send out notices to people when needed. I contact asset store developers when we have issues and deal with finding outside tools for the team. I really need two of me.

On an indie team, that is the way it works. We all wear many hats.

I don't think the OP has visited us since he first posted this thread. My guess is we didn't really say what he wanted to hear.

 

This, many times over.

 

Yes, indie teams rarely have someone who is just a game designer. That is all too often "the idea guy", which is not viewed very fondly in the indie community.

My main role is game designer. However, as I'm an indie developer, I'm also the project manager, creative director, GUI artist, programmer, and writer. I currently work with one other person who does concept art, 3d modelling, texture art, rigging, etc.

In short, indie teams are far too thin and rickety to support someone who is just a game designer.

 

At the studios I worked the designers were doing scripting/markup for quests/missions. Only a few of the designers actually did systemic mechanics or big picture planning. I think all the designers had at least one tool they knew well enough to actually implement things in the game. The "parkour" designers knew Maya and had special plugins for doing all the markup. The mission designers knew a proprietary scripting language. For instance designers of Skyrim need to know how to author NPC conversations using the construction kit. A designer without some means of implementing things into the game is hardly a designer imo. If an "indie team" has a dedicated designer (which isn't a bad role for someone to be dedicated to), I'd think the programmers would need to code some custom inspectors/tools so the designer is empowered to actually author content.

 

That is what I keep telling my programmers!

Seriously though, there are a lot asset store tools that have allowed me to do more than just design and artwork. I have to leave something for the programmers to do.

 

I've recently been tempted to write a program in which I can visually write and assemble the dialogue for my game then export it to XML. (My dialogue is looking to be rather specific and tricky.)

But... I'm also the programmer for the game, so it may just be a waste of time.

 

Know what Jonathan Blow (Braid), Will Wright (Sims & Simcity), and Jenova Chen (Flow & Journey) have in common? They gained fame as designers by developing (aka coding). Surprisingly, they all started as solo developers.

Gigi

 

I'd call this a 'system'. And, over time, I've learned to be suspicious when I find myself using that word instead of following Jonathan Blow's advice.

 

Wouldn't chatmapper do all that?

 

I've looked into a lot of tools (chatmapper, dialoguer, etc), but like I said, my dialogue system is rather specific. Even if I were to use them to generate the core XML, I'd still have to go through each file and make changes and additions to do what I need.

 

I wrote something like that. It took me 3 work days and it ended up being a very good decision.

 

I love that talk, and i love jb. But he writes his own engines for crying out loud. Don't you that's a bigger waste of time than any system one could ever make?

 

Even in the big studio world, Game Designer has mixed meanings, that fuzzy definition only gets even more fuzzy as indies put more hats on them, as it were.

Think Jake Solomon (2K Games) vs David Cage (Quantic Dream). Both are 'Game Designers', but both fulfil greatly different roles.

Solomon worked on XCOM Enemy Unknown.
Solomon performed more technical work, getting game balance and systems to work as envisioned, even coding prototypes to get it just right. He didn't have much to do with story or theme though.

Cage worked on Beyond: Two Souls (among others).
Cage 'directed' the game, envisioned the story, plot, characters, and made sure the production stayed true to that vision. Performed a more artistic role.

Those 2 completely different roles share some things in common, the jobs done reflect the experience of the person taking the position, they use what they are good at to drive the production. They also both share a vision for the game they want to make. Ultimately, I think this is the main goal of a designer, keep the game going along the route originally intended. What individual tasks are taken to get there, depend on the individual.

Bringing indie into the equation actually just makes this easier, it's the person in the team who has that vision of what the game should be, and can drive it forward by making sure everyone is on the same page. You also start to see why a designer as a singular role doesn't really exist in small budget indie teams.

Note this is mostly my opinion, besides the facts about Solomon and Cage, so pinch of salt and all that.

 

The combo I usually see most often is Designer/Developer, especially in indie teams...
Designer is almost always the initiator of the project, and either has to take one of two main branches after that; either the Designer knows code, so becomes de-facto Lead Developer, or the Designer doesn't know code, and takes on more of a Director/Admin/Producer role.
I've also seen several Designer/Artist combos.

 

I'm at work so I can't check out the advice you linked after this. But if the implication here is that you shouldn't build systems where you can just do the resulting task... I think there's a bit more to it than that. To me the question is always "will this save more work than it will create?"

With that in mind I don't try to make "systems" which do complete jobs, I try to make systems that reduce human workload. Sounds like the same thing, but it really isn't.

 

Yeah. And I think Jonathan Blow is explaining that he eventually realized that his sophisticated solutions were an attempt to optimize 'performance', 're-use', or 'human workload'. After much experience, he became more productive by implementing the most obvious solution. And he found that the straight forward solution was often better anyway. In fact, 'performance' was rarely an issue; 're-use' rarely pays as we expect; and 'reducing human workload' often means the solution is just more fun.

Even with 20 years experience, the video was a paradigm shift for me.

Gigi.

 

Yeah, that makes sense.

I have a few rules of thumb I use when determining whether to automate and/or make tools for a task, based on the following questions:
1. How often does the task have to be done?
2. Does the task commonly have to be done on short notice?
3. How time consuming is the task?
4. How error prone is the task?
5. Once done, does the output of the task have to be tweaked a lot (i.e.: can the customer ask for case-by-case changes)?
6. Is there an obvious method of automation that helps significantly with some or all of the above?
7. Are the requirements likely to change?

Obviously no single question trumps all others here. Clearly if something is repeated often, time consuming, error prone, won't change and is easy to automate it's a clear win. But sometimes it's useful in other cases, too - even if a task is nominally easy and quick, if it's something that always happens in crunch time... well, that could be a good candidate too, because spending some "cheap" time can save you a bunch of "expensive" time. Or if it's quick but clients want to change it every 15 minutes and automation helps avoid errors, that's another potential case (not for the technical functionality, but for the service implications - happy customers are a benefit).

Clearly I'm not advocating Arbitrary Condiment Passing Systems here. The first step is to identify the job. The second step is to automate that job - not a job you think is cooler, not a job you think might be handy elsewhere, and not a job that builds in unnecessary help.

Something else to consider is the balancing act between speed and flexibility. Automation makes things faster, but it also makes them harder to change. That's a win-win when you deliberately want to make something consistent. It is not always a win-win elsewhere.

 

I'd like to chime in here to give a little perspective. I've been a professional Game Designer for 22 years and in that time I've worked on teams with as little as three people up to eighty. The simplest way to think of a Games Designer in your team is 'the glue' that holds the vision together.

When you have a team focused on making a game the dynamic breaks down a little like this.

Programmers are be clearly focused on creating a solid architecture for the game that fulfils the needs of the design and is optimized for whatever device you're targeting. Systems need to be built that allow input from both the art team and the design team to allows them to influence the code to create something that looks beautiful and play well.

Artists are clearly focused on creating something that gives the game immediate visual appeal while working in the limits of the technology. All art needs to service the games design and create a world in which the overall vision can take place.

So what do Designers do?

Designers are essentially the architects for the game. It's the closest analogy I can find. A good designer builds structure for the game that is solid and as fault free as possible. Designers should also have an overall vision of what is being made and can communicate that clearly to the team and to interested parties.

Most importantly, designers should be able to project their creative thought and see the finished system in place and think through all the possible permutations of how that system can be abused.

This is where the team comes together. 'Fact checking' designs to make sure they are solid before implementation. A good programmer will be able to spot those edge cases and cracks quickly and before implementation. Artists can find inspiration in an idea and create something beautiful.

In production, if your design doesn't hold water you are wasting money, time, and trust with your team.

No one is perfect and sometimes seemingly solid designs simply don't work. That's were a good prototyping phase before production starts can help find the larger problems and refine the design. Once in production the rest of the team is looking to you to deliver work that can be quickly implemented and fit perfectly into the bigger picture of the final game.

So does an Indie team need a Games Designer?

It depends. It's really hard to find good games designers and if you're working in a small team that has a clear vision it's probably better to keep things as they are, rather than hire someone untested. The last thing you want as a designer is to be seen as just the ideas man with no foundation. That leads to tension in the team dynamic.

That being said, a good Games Designer will get you out of project hell and move a project forward, allowing all other disciplines to focus on creating a great game.

Should the Games Designer be your Project Manager?

Never. Games Designers are creative people who will always want to push for something more in the game. This goes at odds with a Project Manager who is responsible for pushing forward progress. A good PM will discuss the impact of any new design decisions and clearly show the team the impact of implementing new ideas. If you're accountable to investors or a publisher then the PM is the guy who has to explain why the game slipped or went over budget. Sometimes this can be for a good reason and having the backup of a PM to clearly explain decisions on more business terms can smooth out relationships with the people you are accountable to.

"Look Nic, were just a couple of people with a cool idea and we want to make it..."

That's awesome, go do it. I just wanted to give some perspective on where a Games Designer fits into a team that thinks they might need those services. A good designer knows that good ideas can come from anywhere and anyone and there as some great examples of developers that can do it all. Using the architecture analogy there are plenty of people who have just grabbed a hammer and made an amazing family home.

Being a Games Designer can be a little frustrating as it's often hard to explain exactly what you do. Most people I talk to that are outside the industry think I'm either a programmer or an artist. When you try and explain exactly what you do, eyes glaze over.

To be honest, I kind of prefer the Japanese term for Games Designer, 'Planner'. It's more representative of what we do day in, day out.

Hope this has been useful!

Nic.

 

I agree with Nic that Designers make poor project managers. I've been in game marketing for 12 years and recently-ish moved more heavily into game design... and pretty much I am always arguing with my project manager. That is a GOOD thing, as we have one person advocating getting the project done vs. getting the project better all the time, and that tends to produce the most constructive overall path to a complete, good, game. Whereas if I wore both hats we'd probably never finish anything!

That said as the designer I often HELP with project management. Since we're usually working on multiple projects and I know the design very well, if the PM tells me to keep my eye on the art team and make sure their stuff is implemented to spec, I can do it. Basically as the keeper of the design I am often tasked with the project-managy type of task that involves making sure the work that is getting done is getting done correctly - and all that arguing about what needs DOING goes on in the background. Once we come to a decision after our "debates" we then implement that plan as a team.

Anyway, that said since we're not super huge I also end up as the guy fetching temporary art assets, helping with level design, helping with sound effect selection... I pretty much support everyone by taking on the tasks that are time consuming but don't require a massive skillset. In this way not only am I doing the design, but I am also close to every part of the project, which lets me catch design mistakes (either in the design or in the implementation) much faster.

 

Have you tried, "Yes ... And"? My wife and I used to have lots of arguments when iterating our software. Until, one day, she came brought a new idea home from work. In simplest terms, "Yes ... And" is about removing the word "BUT" from your vocabulary. Within hours of learning it, we had completely changed the way our review sessions went - from soul-crushing, blood fests, to productive iteration cycles. I've since used it with my boss, my employees, and these forums. It's a paradigm shift that changed my life.

Example:
I say, "We'll never finish on time"
She says, "Yes, we're struggling to meet our deadlines. AND maybe it would help to explore some alternatives"

My employee says, "I hate conversations in games"
I respond, "Yeah, conversations can be pretty boring. AND, since the main mechanic of our game is conversation trees, maybe we can brainstorm some ways to spice them up."



Yes, that's my license plate.
Gigi

 

Actually before I worked in games, I put myself through college as a professional juggler... no really. Anyway, one of my regular gigs was doing the Ren Fairs all up and down the coasts of Florida. Well, one of the improv training items we use is a game called "Yes, and..." which teaches you that important lesson: You can not do an improv sketch if your replies are using "but" or other conflict words that negate what your partner(s) are trying to say.

So kudos, I agree wholeheartedly with the Yes And... but that doesn't change the fact that my product manager and I have different views We're not nearly as confrontational as my post made it seem, haha. More like

"I think this map needs to be redone!" "We don't have time to redo it!" "Well, what about redoing this area and spiffing up this art." "Can we re-use that art anywhere else?" "Maybe, probably..." "Ok, lets redo that art and you've got only 1 hour to clean up that area of the level."

Something like that (Note: That was not a real conversation, I'm just ... improving?)

 

I wonder if there may be a powerful nugget of wisdom in this. For those that look.
Gigi

 

har dee har har

 

Yes, and also a great example.