Comments on: Designers are Descriptive; Programmers are Procedural Your designers fucking suck =) Your designers fucking suck =)

]]>
By: Richard Fine/2011/06/07/designers-are-descriptive-programmers-are-procedural/#comment-5351 Richard Fine Wed, 08 Jun 2011 09:55:03 +0000 lol - only just saw this after putting my first post up, which is kinda related :) Good post Rich but, from a designer's perspective, it does sting a little (comes off as a tad elitist). Communication across disciplines is a tricky one, and you do have to find a medium where everybody understands what's being asked. Possibly it's one of main reasons why it's such an iterative medium - interpreting what is being asked for and how to refine what's implemented is a huge part of making a successful game. lol – only just saw this after putting my first post up, which is kinda related :)

Good post Rich but, from a designer’s perspective, it does sting a little (comes off as a tad elitist). Communication across disciplines is a tricky one, and you do have to find a medium where everybody understands what’s being asked. Possibly it’s one of main reasons why it’s such an iterative medium – interpreting what is being asked for and how to refine what’s implemented is a huge part of making a successful game.

]]>
By: Richard Fine/2011/06/07/designers-are-descriptive-programmers-are-procedural/#comment-5298 Richard Fine Tue, 07 Jun 2011 23:10:50 +0000 sup, mr pig? so doesn't that reduce to an argument for using test driven development, where you can describe your test sets as the behavour of the system (in designer speak), and wrap the inner objects with human-orientedly-named functionality objects? if you're designers can understand your tests, they can understand your system behaviour. i.e. CollisionDetectotron is wrapped by FastOrSlowObjectConfiguration and the test is something along the lines of: behavesSensibly(fastObject.collide()) behavesSensibly(slowObject.collide()) or something. do you see? sup, mr pig?

so doesn’t that reduce to an argument for using test driven development, where you can describe your test sets as the behavour of the system (in designer speak), and wrap the inner objects with human-orientedly-named functionality objects?

if you’re designers can understand your tests, they can understand your system behaviour.

i.e.

CollisionDetectotron
is wrapped by
FastOrSlowObjectConfiguration

and the test is something along the lines of:
behavesSensibly(fastObject.collide())
behavesSensibly(slowObject.collide())

or something.
do you see?

]]>