3 ms·
The majority of the work in games is making assets and delivering code. Neither of these have fun as a KPI. Further, defining fun as a KPI presents challenges
by syntheweave 4y ago
The majority of the work in games is making assets and delivering code. Neither of these have fun as a KPI.
Further, defining fun as a KPI presents challenges of sociology, psychology, and philosophy: People are happy to exclaim "this is fun!" And then quit playing within a few minutes. Absent a very, very careful understanding of the belief structures that drive the combination of purchase and interest that makes someone a "fan", the metric degrades to raw "engagement", which leads to meetings where it is determined that the engagement metric should be boosted through the introduction of gambling-style addictive loops.
In other words: lots of people like playing good games. Almost nobody knows precisely why they like a game, and therefore they do not know how to make a game equivalent to what they like. What the industry does instead is to clone whatever worked last time and try to give it a twist or add a little more scope. Whatever formula worked for another game, everyone is going to try adding to theirs, whether or not it's sensible. Specific game teams manage to see farther and make exceptional work by dint of being able to frame the discussion appropriately, so that it brings in everyone's perspective. Without that, every meeting is just a discussion of deliverables. But in many, many cases, the team has to make the game twice to be able to sink their teeth into the problem. Hence the common thing of game sequels being much better than the first entry.