one of the hardest diplomatic skills i think game designers should learn is how to ask your team for assets to support a prototype when you don& #39;t have full confidence the prototype will work out. this happens a lot in development-- you have a hypothesis you want to test. (cont& #39;d)
it& #39;s a good thing to try out several possible directions for a feature (if those directions have some merit) whenever you can. but often this will require someone else to give the designer some supporting assets: an animation, a sound effect, some vfx, or some new code/component.
in the best possible scenario, your team is equipped with a large & #39;DIY& #39; library where designers can easily pull vfx/sfx/retarget animations to fit a variety of temp or prototyping needs. some projects i& #39;ve been on have this. some do not, and then the convo gets harder.
things i think help make this work feel less painful for the artist/engineer/audio person who will give you assets:

1. clarify your confidence in this feature up front. a prototype you have 85% confidence in is very different from a hail-mary wouldn& #39;t-it-be-nice 25%.
2. intentionally ask for bad. sometimes craftspeople, especially in AAA, like to *always* go hard and give you something amazing. i usually try to frame the convo as "please give me the quick and dirty thing, because there& #39;s a likelihood it gets cut if this doesn& #39;t move forward."
3. try to ask for assets which aren& #39;t hard-coded to your specific use case and can be flexible if the needs of the prototype change. e.g. a "windup" sound effect which is set to exactly 3 seconds, vs. a more generic "looping windup" --> "burst" which can have a variable length.
4. make sure this convo is happening with your producer& #39;s visibility, for traffic control. asking an artist who is already overbooked to make you extra stuff is a very bad look. your producer SHOULD be able to help you carve out prototype time if you can make a case for it.
(and to be clear, the "making a case for it" is also part of your job as a designer. if you can& #39;t demonstrate the thing has value and sell your team on the value of spending some time prototyping it, well, that& #39;s a whole & #39;nother skillset.)
5. learn who CAN do "quick and dirty" on the team. some folks will always just give you gorgeous 10/10 work and then get bummed when the prototype gets killed. some are like "i checked in something basic i did in 10 mins, hope the prototype goes well." you want the latter camp.
6. realize when you& #39;re being disrespectful of someone& #39;s time. do you really need to ask your sound designer to rework that prototype sound 3, 4, 5 times? can you just squint and see how a different sound would work better if this feature moved forward? if you can, do that.
the goal of the prototype isn& #39;t to feel perfect, it& #39;s to get you enough of the way there that you say "ok, we proved we want to do this feature for REAL, let& #39;s get the gang together and re-evaluate what we need here." be a good partner to your teammates. don& #39;t be a perfectionist.
and, lastly, 7: make sure everyone really understands the GOALS of the feature, not just your specific proposal/design for it. i love it when my teammates are like "you asked for X, but now that i understand what you want from this i think Y is better." often, they& #39;re right.
what goals are not: a literal description of the feature

what goals are: the player behavior this feature should evoke. the reasons why a feature like this would be healthy for the game.

give your teammates space to suggest something different or better, and they often will.
anyway, i learned all these lessons the hard way by bumbling through every bad behavior in the "baby& #39;s first prototype" handbook, so learn from my mistakes and go forth and make delightful things!!
You can follow @kchironis.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: