This post is about ownership of the development of a feature or mechanic in a video game. Many companies say that they need people who really own the tasks they have. Ownership is very important but also a little fuzzy concept.
What I understand for ownership is different from what you mean with the same word. It is also different from reality to reality. It is not the same to own the design and development of a secondary feature than to own the core mechanic of a new game.
To me, the secret of good ownership is being able to maintain a vision while adapting to the context. The term ownership can be easily confused with property ownership. If your duty is to own some feature, the best you can do is to build on what you have, leaving the borders of your property open.
Vision
In the world of data driven development it is very easy to fall into the trap of thinking “data is everything”, repeating the same mistakes over and over or offering the same formula to the Players.
Data is not everything. Data is a resource that has to be translated into information, otherwise everything can be read. Ownership means also to be able in doing this translation. You need to make hypotheses, you need to verify those hypotheses using concrete experiments and then you can discuss how to transform the information in actions.
It is very hard having the right data ready at the start of some new implementation, so that often you need to rely on other elements to form your vision:
- Your own personal experience brings inevitably something interesting to the discussion table.
- Never forget that game design is also art, you should put something very personal in if you want to really engage your team and Players in your vision.
- You need to know the state of the art, breaking down the same feature implemented in other games. It is not necessary to reinvent the wheel.
- You need to connect with the people playing those games and really understand what it works and why.
Context
It is very unlikely to create the next f2p success with a team of 3 developers and 2 artists and no QA, right? If you have a small team, a feature can take aeons to get right. Most of the times you cannot iterate properly, your manager will pass to the next feature and your work will cripple. This happens in the majority of companies, and it is completely normal. Owning your design means accepting this and move forward. It’s hard, I know.
From the other side, it is very hard to create a fresh core loop with a team of 80 people. Politics, meetings and dispersion of the information will make you struggle to properly transmit your insight with the rest of the team. In that case, it is way better to take a strong base and then focus on improving the experience in terms of UX. Believe me, you will save a lot of stress.
Being aware of the context is very important, the magic lies where you can do the best you can with what you have. When you have the feeling that you can do everything with no limitations, it probably means that the context is not clear to the leadership nor to the team. Red flag. When you own a feature, you should try to clarify:
- Goals with all the stakeholders
- Concrete deadlines with weekly/bi-weekly intermediate milestones
- Concrete quality expectations for the feature you own.
Final thoughts
The rise of automation is solving a lot of problems and saving us a lot of time. If we really want to be the professionals of tomorrow, we should focus our attention on providing the right solutions and vision according to the context we work in.
Ownership is one of the most important factors of the future landscape of professional game design.
What is your way of owning your tasks?
Be First to Comment