2016 Workgroup Topic Proposals

Design Centric Process

Process in video game development is often driven by production and process trends are driven by engineers in the wider tech industry. What about designers? We know process! We have opinions! We could start methodology trends and make millions as consultants too! What would a development process for video games look like if it was design driven? What if everything centered around design (schedule, workflow, prioritization, etc?) Honestly? We’d probably never get anything shipped, but I think it could be an interesting exercise. In my studio I often see design accommodate and compromise for the other disciplines because our workflow is flexible and our goals less defined. Holistically, this is a good thing and helps us ship reliably and maintain a good collaborative environment, but it also means we sometimes put design concerns last and sacrifice risk-taking and design iteration. Since Horseshoe is a time for designers to self indulge so let’s dream up a process that is all about us!

3 thoughts on “Design Centric Process

  1. Do we intend this to be an exercise where we don’t care about what time or other resources are consumed in the process? Or, are we thinking about this in the context of real world constraints and practical tradeoffs that come with such a process?

    1. I would definitely want to start with the focus of everything being subservient to design including time and resources and see where it takes us. If there was time we could try and take an approach to a practical place but it wouldn’t be the primary goal.

  2. We tend to have a design centric process though I’m not sure how it scales. Maybe one data point.

    Some ideas:
    – Have a primary leader who is a designer. So much of culture flows from founders or product lead. If you have someone who sets the vision by predominantly referencing art, code or business you will likely never get a design centric process. Bonus: Call her ‘The Prime’ and encourage offerings of scented honey cakes.
    – Prototype first. Make lots of prototypes that seek to *prove the fun* vs *pitch the fun*. Completely different processes. Many great system-focused designs are unpitchable abstractions before prototyping proves them out.
    – Educated judges and broad early gates: Only let people that know how to look at prototypes (seeing potential vs surface flaws) judge early prototypes. Ideally the team is the one killing their babies, not executives. That’s more about self empowerment.
    – Have clear goals for gates: Like we use X minutes of fun for various states.
    – Lots of cheap experiments.
    – Bring in art late. Art is great, but it lies in the most glorious fashion. There’s a back & forth that is needed, but it can happen after the systems are *functional*.
    – Build refactorable designs, art and code. Great design is the result of iteration. If the underlying architecture of your game is not amendable to refactoring design is handcuffed. So build a culture of spotting rigid large laborious structures and replacing them with modular, orthogonal, easy to change systems.
    – Treat code as a technical risk. Constantly ask is there a way to achieve design goals while reducing technical risk. You still need to bend and compromise, but it removes the tendency to treat tech as a differentiator.

Comments are closed.