Comments on: Absolutely Everyone is a Game Designer… right? Hi, very interesting posting! Always great to see game companies sharing how they work and not just the technical intricacies of their tool or engine implementations. I couldn't agree more with the whole introductory part. Having people only thinking within department boundaries can be a huge problem.. especially once a team grows in size. I'm having a little issue with your article structure though and the way it criticizes scrum (I suppose by "sprint", you mean the way its used in scrum). I think that your process is actually not as different from scrum as you might think or I'm wondering why you think it is. The main difference that I see seems to be that your feature teams have leaders, which is something which scrum does not necessarily have. It is an idea that has come up a couple of times also in our company also, but I personally feel like this contradicts your "Work needs reason" paragraph, by taking away the team ownership and commitment and putting it on just two shoulders inside of the team. I agree with the point that you are making in the "Motivation Needs Room" section. I don't understand why this would be an argument against sprints though, since one of the main ideas of a sprint in scrum, is to allow the team to come up with their own solutions and ideas in their own time schedule without being micro-managed from higher up management. The whole point of sprints is to provide "room" by having the management commit not to change the goals randomly during the sprint. Regarding the "Management Overhead is Annoying" point, again I agree, but I think there is just no way around having to invest more time for communication once teams get bigger and I'm not sure if it can be held up as argument against sprints, since your process probably also has a meeting where you decide on which theme to tackle next, and a meeting where you talk about your progress and a meeting where you show off the results. I'm really not trying to come off as a scrum fanboy here, but just trying to understand your process better. Would you agree that the feature team leadership is the biggest difference to how scrum handles teams or do you also see other major differences? Hi,

very interesting posting! Always great to see game companies sharing how they work and not just the technical intricacies of their tool or engine implementations. I couldn’t agree more with the whole introductory part. Having people only thinking within department boundaries can be a huge problem.. especially once a team grows in size. I’m having a little issue with your article structure though and the way it criticizes scrum (I suppose by “sprint”, you mean the way its used in scrum). I think that your process is actually not as different from scrum as you might think or I’m wondering why you think it is.

The main difference that I see seems to be that your feature teams have leaders, which is something which scrum does not necessarily have. It is an idea that has come up a couple of times also in our company also, but I personally feel like this contradicts your “Work needs reason” paragraph, by taking away the team ownership and commitment and putting it on just two shoulders inside of the team.

I agree with the point that you are making in the “Motivation Needs Room” section. I don’t understand why this would be an argument against sprints though, since one of the main ideas of a sprint in scrum, is to allow the team to come up with their own solutions and ideas in their own time schedule without being micro-managed from higher up management. The whole point of sprints is to provide “room” by having the management commit not to change the goals randomly during the sprint.

Regarding the “Management Overhead is Annoying” point, again I agree, but I think there is just no way around having to invest more time for communication once teams get bigger and I’m not sure if it can be held up as argument against sprints, since your process probably also has a meeting where you decide on which theme to tackle next, and a meeting where you talk about your progress and a meeting where you show off the results.

I’m really not trying to come off as a scrum fanboy here, but just trying to understand your process better. Would you agree that the feature team leadership is the biggest difference to how scrum handles teams or do you also see other major differences?

]]>
By: BOBZ/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-740 BOBZ Sat, 12 Feb 2011 16:27:36 +0000 @mcloister - sorry.. the html formatting screwed up my reply to you there - for smaller teams, say less than 5 you shouldn't need this kind of system as everyone should be sharing responsibilities and just going all out, however for our prototyping and as projects start out, in order to increase the sense of sharing and community in-between the teams we have a director's meeting for a no. of projects simultaneously and some people will take part in several of the smaller projects, which helps kick-start them. @mcloister – sorry.. the html formatting screwed up my reply to you there – for smaller teams, say less than 5 you shouldn’t need this kind of system as everyone should be sharing responsibilities and just going all out, however for our prototyping and as projects start out, in order to increase the sense of sharing and community in-between the teams we have a director’s meeting for a no. of projects simultaneously and some people will take part in several of the smaller projects, which helps kick-start them.

]]>
By: Dylan Cuthbert/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-357 Dylan Cuthbert Wed, 09 Feb 2011 14:43:11 +0000 very interesting. sounds like a different twist to attack groups.. In that system (which I really think is the best I've experienced) you break your workload into "themes" like above. Something like "player controls" would be assigned to a programmer, animator and designer. They would move desks and sit together and work on that topic as a collaboration until it was nailed.I've heard of some development houses having mobile desks just so they can quickly and efficiently form different attack groups each couple of weeks. very interesting. sounds like a different twist to attack groups.. In that system (which I really think is the best I’ve experienced) you break your workload into “themes” like above. Something like “player controls” would be assigned to a programmer, animator and designer. They would move desks and sit together and work on that topic as a collaboration until it was nailed.I’ve heard of some development houses having mobile desks just so they can quickly and efficiently form different attack groups each couple of weeks.

]]>
By: Joe Valenzuela/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-355 Joe Valenzuela Tue, 08 Feb 2011 21:18:43 +0000 .

]]>
By: JurieOnGames/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-354 JurieOnGames Tue, 08 Feb 2011 15:39:13 +0000 )

]]>
By: mcloister/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-353 mcloister Tue, 08 Feb 2011 14:13:25 +0000 @kriss - you come across a little aggressive and condescending, is that intentional? If you have nothing constructive to add, don't comment! kthxbye!@MikeNicolella - we've found that #3 does tend to be followed, especially if the team is a fairly large one, but it needs to be flexible, sometimes the best person to do the work just happens to be the director (or assistant director) on the theme. Play it by ear.We've found that the theme teams are very fluid. Be flexible - quite often a theme is put to sleep for a while and then re-awakened later in the project when tools and resources become available, you may use a particular director/asst director combination on one theme, and a completely different pair on another theme.Themes tend to last just a few weeks on average. I think the limited presentation time in the director's meeting helps you naturally reduce the scope of the themes. @kriss – you come across a little aggressive and condescending, is that intentional? If you have nothing constructive to add, don’t comment! kthxbye!@MikeNicolella – we’ve found that #3 does tend to be followed, especially if the team is a fairly large one, but it needs to be flexible, sometimes the best person to do the work just happens to be the director (or assistant director) on the theme. Play it by ear.We’ve found that the theme teams are very fluid. Be flexible – quite often a theme is put to sleep for a while and then re-awakened later in the project when tools and resources become available, you may use a particular director/asst director combination on one theme, and a completely different pair on another theme.Themes tend to last just a few weeks on average. I think the limited presentation time in the director’s meeting helps you naturally reduce the scope of the themes.

]]>
By: MikeNicolella/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-351 MikeNicolella Mon, 07 Feb 2011 17:42:28 +0000 Congratulations, you have discovered that management systems and business process with names and cult followings are bullshit.This is the first step to enlightenment.For your next step, try to remember this when you are promoting your system to other people. Congratulations, you have discovered that management systems and business process with names and cult followings are bullshit.This is the first step to enlightenment.For your next step, try to remember this when you are promoting your system to other people.

]]>
By: Dylan Cuthbert/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-349 Dylan Cuthbert Mon, 07 Feb 2011 15:59:47 +0000 I like the idea of more people having their voices heard and acted upon. The peer review of everyone's progress is excellent. Two things I wonder about in this scheme: do you have problems with overall feel of the game getting disjointed because there are so many creative leaders, and how does this scale? (what's the size of the teams currently using DTS?) I like the idea of more people having their voices heard and acted upon. The peer review of everyone’s progress is excellent. Two things I wonder about in this scheme: do you have problems with overall feel of the game getting disjointed because there are so many creative leaders, and how does this scale? (what’s the size of the teams currently using DTS?)

]]>
By: Dylan Cuthbert/2011/02/07/absolutely-everyone-is-a-game-designer-right/#comment-347 Dylan Cuthbert Mon, 07 Feb 2011 15:45:10 +0000 A lot of good thoughts here, but I have to admit that I am usually opposed to the mindset that everyone is a designer. I say this coming from a student's perspective where too often an artist or a programmer gets into the mindset of "I'm also a designer" and then stops doing the work that they have to fulfill. On a team of 4-8 people, losing a programmer or an artist can be absolutely crippling. If someone steps up to a task and then doesn't finish it because they were "designing level X that won't make it into the game because I didn't have time to make the editor," then no one is benefitting. This is the poison that I think some students latch on to.However, I totally agree with what Dylan's underlying message is - that everyone should strive to be a good designer and make their decisions with game design in mind. I think this is true of any team set up, "Director Theme System" or otherwise. But students need to understand that the design part of their job is inherent to their role as a programmer or an artist. They shouldn't let their expertise fall by the wayside to do design work or else they can fall into the trap that many student games get caught in - never getting finished.I suppose my thoughts on programmers wanting to be designers are analogous to designers wanting to be "idea men." Not getting your own work done should be distressing. I still applaud John Carmack for sitting down and writing code every day, I would hate for business to pull me away from my expertise. A lot of good thoughts here, but I have to admit that I am usually opposed to the mindset that everyone is a designer. I say this coming from a student’s perspective where too often an artist or a programmer gets into the mindset of “I’m also a designer” and then stops doing the work that they have to fulfill. On a team of 4-8 people, losing a programmer or an artist can be absolutely crippling. If someone steps up to a task and then doesn’t finish it because they were “designing level X that won’t make it into the game because I didn’t have time to make the editor,” then no one is benefitting. This is the poison that I think some students latch on to.However, I totally agree with what Dylan’s underlying message is – that everyone should strive to be a good designer and make their decisions with game design in mind. I think this is true of any team set up, “Director Theme System” or otherwise. But students need to understand that the design part of their job is inherent to their role as a programmer or an artist. They shouldn’t let their expertise fall by the wayside to do design work or else they can fall into the trap that many student games get caught in – never getting finished.I suppose my thoughts on programmers wanting to be designers are analogous to designers wanting to be “idea men.” Not getting your own work done should be distressing. I still applaud John Carmack for sitting down and writing code every day, I would hate for business to pull me away from my expertise.

]]>