Archived

This topic is now archived and is closed to further replies.

If Designers aren't programmers then...

This topic is 5746 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I know lots of you out there design and program, but all the time I see these websites that say ''you don''t need to program to design.'' So if that''s true, then what do the designers who don''t program do once the design documents are done?

Share this post


Link to post
Share on other sites
... ie. become producers.

As has been argued here many times before, the industry in general tends not to have ''designers'' in the sense of the word that is often used on here. A designer will tend to fall into one of three categories (terms are my own):

- technical: the designer is a programmer with an interest in design. Or a designer with an interest in implementation - same thing. After the initial design, he will help code it. This is probably going out of fashion these days, despite the fact that some of us think it is the best way to work ("The fact I am not a programmer is a real problem for me. It''s not a debilitating problem I hope, but it is an issue. If I were a programmer I could do my various jobs better." Warren Spector, 2002.)

- organizational: the designer is one of the team leaders who will oversee the various teams and ensure they are working together smoothly. For example, Tim Stellmach, lead designer on Thief, says that he is "coordinating the project on a day-to-day basis" on his latest title.

- practical: the designer will go on to develop assets for the game, usually in the form of levels/maps. Taking another example from the Thief team, all the designers except one had a hand in one or more of the missions. (That last designer was writing dialog, and only worked part-time anyway.)

In short - there are hardly any positions for someone who just thinks up the game plan and specifications.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
You can''t do everything... well you could, but it''s way more effective to design the game, and work closely with a team to get that game made.

As the designer it''s your job to ensure that everyone understand what you''re trying to get made. This of course has to be done without being bossy.

Always be open to ideas, and always be open to suggestions. If you can''t trust the programers to program the game you envision... you may as well pack it up and stop there.

Share this post


Link to post
Share on other sites
There was a letter in CGW from a designer who described his job. He had also learned skills in programming and artistic skills to a junior level.
So it wasn''t a matter of _what_ he did specifically, he was also able to measure what others were doing, how long, and at what cost(money-wise and time-wise) so he could make a choice about the balance of things and the progress. That''s my point of view of the designer.
Do we have time for feature X?
Asking the programmers: what is the cost of such a feature and understanding how it would relate to the artistic tasks.
Keeping in mind a clear goal.

A producer would also describe this job as well. But at a more financial basis.

ZoomBoy
Developing a iso-tile 2D RPG with skills, weapons, and adventure. See my old Hex-Tile RPG GAME, character editor, diary, 3D Art resources at Check out my web-site

Share this post


Link to post
Share on other sites
... deliver pizzas.

Seriously, if you have ever been involved in a building construction project, you will notice that the architect is often on-site answering questions and clarifying things that come up. That would be very similar to what the game designer (i.e. the "architect") would be doing in order to make sure that his vision is being built correctly.

Dave Mark
President and Lead Designer
Intrinsic Algorithm Development

"Reducing the world to mathematical equations!"

Share this post


Link to post
Share on other sites
The designer is usually responsible for tweaking all the data, balancing and making sure that the level designers understand what is to be done.

I think the role of a designer depends a lot on the size of the company. A large sized company is more likely to have lots of specialists. A lead level designer, a writer, scripters etc.

I worked for a small sized company and had the role of designer, level designer, scripter and writer... Lots of different hats.

::aggression is the result of fear::

Share this post


Link to post
Share on other sites
Add to what Grimjack said that one company may have a different ''pipeline'' in place than another, so in one case (depending on many different variables, including team size, project type, funding, etc.) the designer might have very specific and limited tasks and in another they might be involved in a wide variety of things. I know a designer who only writes dialogue. I know another who actual creates levels and scripts AI. Lots of variety in the industry...

Share this post


Link to post
Share on other sites
And don''t forget... when the game development is going to be completed (if it''s not before...), you need to think of new projects to keep alive the studio and to get funds

Share this post


Link to post
Share on other sites
The role of a game "designer" can very in so many ways that a "designer" can be looked at as totally different jobs from one team to the next.

Very generized roles.

1. Designer with programing background will tend to write more code, duh. He will need a visual team lead that understands his vision. This designer might use a project leader though, to keep people on track through the different teams.

2. Designer with Art background will tend to invest more time into the visual side of the game. This designer will need a programing team lead that understands his wants and needs. This designer might also use a project leader.

3. Designer with Game Design background, will spend the majority of his time keeping the timeline, and peeking over the shoulder of every team. He will need a programing lead, and visual lead, that understand his vision. He acts as the project manager.

*One thing that I feel is necessary for any "Designer" is, he has to know a little of everything. He needs to know the limitations of his team, and his technology. Having a programing and visual team leads that are on the same page as the Designer is a must also. A good Designer, doesn''t always mean he''s the best coder, or modeler. It might mean he''s the best at surrounding himself with the best coders and modelers.

Just my 2 cents.

Darktalon

Share this post


Link to post
Share on other sites
I think games would be much better if they weren''t so pre-planned. If you consider the design document to be the final word, your game will suffer. You need to program and play the features you design to see if they work well, or if there is a better way of doing things.

So often in game reviews, I see the reviewer mentioning annoyances in the game that anyone playing it immediately notices. So I figure the reason they were left in the game was either that the designer thought they''d be a good idea and didn''t play the game enough to notice the flaws, or the team just ran out of time to polish the game.

~CGameProgrammer( );

Share this post


Link to post
Share on other sites
Actually, I belive a lot of games change quite a lot in their development process, (such as said in this book).
I think the development process should be organic and actually expect their design to be modified along the way (a good example of this was Starcraft).

Of course, the best person to design and organise a games development would be an expert in all fields; programming, art and game design; but this is unlikly isn''t it?

Perhaps we need more general purpose people?

Share this post


Link to post
Share on other sites
I disagree. Most of the problems with games, such as running over budget, shipping late, having gameplay balance problems, and bugs, tend to come from a lack of accurate and detailed planning. For example, you can get a system 95% balanced on paper just by applying a little basic mathematical knowledge, but it will take you months to achieve the same effect through trial and error (ie. playtesting).

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
Allow me to make an observation. Many people seem to think that you can get down nearly everything you need on paper first.

It is good to try, but I think these people are thinking about computer games like tabletop or pen and paper games. The difference is, in a pen and paper game the written rules really ARE the whole game. In a computer game, they are just the starting point.

When describing a game like a FPS, there are millions of details you simply cannot include in a document. How fast do people move, turn, change directions, accelerate, etc? Sure, you can say "slow" or "fast" but you can''t attach numbers to those with any real confidence. If getting hit slows you down, by how much does it do so, and what is the consequence of that?

How do you know if a design is fun until you actually play it? Yes, you can have some idea, but the implementation is the only way to know for sure. What sounded like great fun on paper may be pretty boring.

Also, what about artists and programmers? What if the staff you have is good at some things and bad at others? You have to adjust for that.

Basically, with a paper game the paper is the end point. The written rules are literally the entire game. With computer games this is not true at all.

I much prefer the Japanese idea of director, who is the designer and oversees the game. The idea that someone can just write some document and then hand it off to someone else and be done is absurd! They need to be revising, fixing problems, tweaking, clarifying, changing when needed, making sure the game reflects the design and the design is fun, etc etc etc.

Look at Warcraft 3. Who is tweaking that? Who decides to increase the HP on some unit or make burrows into farms for orcs? The designer.

Share this post


Link to post
Share on other sites
Generally, if they don''t program at all, they test prototypes and tweak. And they do this repeatedly. When the art''s being prototyped, they''re looking at it, giving feedback. When the publisher says "We want the game to have more appeal in the 15-25 year range" The designer responds to that.

Like Anon pointed out, there are a lot of details that arise durning the creation of a game. The designer should be made aware of them, and track them. And I do agree that you can''t just rid yourself of a designer after the initial phases, because someone''s going to need to hold all those details in his head.

And Anon, for the record I personally believe that when new details are added (walking 2 meters/sec, running 6 meters/sec, max turn on the xy plane is 400 degrees/sec) they should be recorded in the design document (or a sub document therin). And by pen and paper games, I''m going to assume you''re referring to things like board games.

Share this post


Link to post
Share on other sites
quote:
Original post by AnonPoster
It is good to try, but I think these people are thinking about computer games like tabletop or pen and paper games. The difference is, in a pen and paper game the written rules really ARE the whole game. In a computer game, they are just the starting point.

Why? A computer game runs from potentially stricter rules than a board game or a pen and paper game. If anything, the rules become more important as there can be zero deviation from them.

quote:
When describing a game like a FPS, there are millions of details you simply cannot include in a document. How fast do people move, turn, change directions, accelerate, etc? Sure, you can say "slow" or "fast" but you can''t attach numbers to those with any real confidence. If getting hit slows you down, by how much does it do so, and what is the consequence of that?

Why can''t you attach numbers to them? You may not be able to state pixels per second, but you should be able to say how long it takes for someone to cross the game map for example. Or you can express speed in terms of game distance units per second. Since you can choose your units arbitrarily, there''s little reason why you can''t pick something reasonable.

quote:
How do you know if a design is fun until you actually play it? Yes, you can have some idea, but the implementation is the only way to know for sure. What sounded like great fun on paper may be pretty boring.

Prototype it. You won''t even know if it''s fun or not when you play it. 20 people in your office may love it, but the world at large may not.

quote:
I much prefer the Japanese idea of director, who is the designer and oversees the game. The idea that someone can just write some document and then hand it off to someone else and be done is absurd! They need to be revising, fixing problems, tweaking, clarifying, changing when needed, making sure the game reflects the design and the design is fun, etc etc etc.

Well, of course. But just because it''s impossible to write up a perfect specification up front is no reason to give up trying. The better your specification, the better the development process will be, and mistakes made and rectified on paper are a thousand times cheaper than mistakes made and rectified in code or data.



[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Kylotan
But just because it''s impossible to write up a perfect specification up front is no reason to give up trying.


Unfortunately, and quite annoyingly, I get this attitude a lot from my boss. I say we should plan things out a lot more than our last project. He says, there are so many unknowns, like A, and B for instance. Basically his philosophy is, since we can''t plan more than 80% of the project, we might as well not plan at all. What miffs me the most is, our team is so talented. We''ll probably pull off an alright game, but we could do so much better. I pulled a few strings and got a few architecture discussions. Better than nothing I guess.

Share this post


Link to post
Share on other sites
I wonder how a current game could be completed without any planning... (maybe "small" games from the 80s were done like this but even such games might have been planned).

I think a designer should have "a computer" in his mind. To simulate and imagine the result... You know which games exist today, so you know what it's possible to do, and as it's always possible to go farther and improve current technologies you can think of new concepts, new ideas for gameplay and so on... If a designer doesn't play games he won't be a good designer (or it'll be hard for him).

With a classical team, say between 8-15 members, I don't want to imagine the result if nothing was planned and supervised !

Let's take 3 members of the team : (I let you extrapolate with all the team...)

- artist 1 : "wow !! I will do this 3D-model with 1.000.000 polys so it will look very nice and detailed "

- programmer 1, thinking : "hmm well we want to make this game, well I'm going to code this and this and this"

- programmer 2, also thinking : "yeah great game ! gonna code this and this and this..."

3 months later ...
- programmer 1 to programmer 2 : "hey why did you code this !! I already did it !!"
- programmer 2 : "oh sorry!"

- programmer 2, thinking : "I should remove this code..."

- programmer 1 : "I should remove this code..."

and so on ....


I think that planification + communication are the best way to bring safely a project to the end...

Don't forget that publishers will ask you a lot of documentations during the development phase (for each milestones...), if you want to be paid ... and firstly they will ask for a schedule (so all things should have been planned at first...)


[edited by - brunow on March 23, 2002 5:24:25 AM]

[edited by - brunow on March 23, 2002 5:24:45 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
Well, of course. But just because it''s impossible to write up a perfect specification up front is no reason to give up trying. The better your specification, the better the development process will be, and mistakes made and rectified on paper are a thousand times cheaper than mistakes made and rectified in code or data.




I did not mean to imply you should not plan in advance. What I meant to point out that planning in advance is just the start, not the finish.

In a pen and paper game, when you have all the rules nicely written down, you are done. The same is not true in a computer game. A goog initial plan is step 1 out of many.

Share this post


Link to post
Share on other sites