I'm still kinda new in the games industry, but I've worked for several studios as a programmer. And something I've noticed but never questioned until now for some reason, is that most Jira/Trello tickets for new features are titled like "As a player, I want to do X" Why are they titled that way rather than just simply "Implement X"? I'm genuinely curious because there must be a very good reason I just can't see right now. How is naming tasks that way more helpful?
In my experience, it’s a reminder to consider the issue/feature from a player perspective and how it will be received and used by the player. This often affects the design and implementation of the feature in subtle ways - you’re not just making X possible, but you’re thinking about the preferred way for X to be presented and the edge cases where the player might exploit how X works.
As an example, at one point I was working in an engineering role on a rogue-inspired game and tasked with building a talent system. The player would earn talent points, then spend them to choose from three (or more) talents randomly selected from a pool of available talents. The “As a player...” perspective reminded me to consider how players usually interact with such systems - the motivation is, of course, to optimize the heck out of things. Thinking about it in such a way also made me consider the edge cases and player mentality.
For example, if I were the player I might try save scumming (i.e. seeing the talents offered, then reloading/restarting the game until I get acceptable results) to get better talents if I don’t like the ones I’m offered. This incentivizes some potential bad-feeling behavior among players - behavior that will negatively affect their play experience (even though it is self-inflicted). We usually try to guard against such frustration points to make the overall player experience better. One of the additional things I did while building the talent system was to save the offered talent options when the player saw them for the first time, and display only those offered talents for that tier for the choice until the player chose one. This insured that the player couldn’t keep reloading to get better talent choices, but still have randomized talents offered when restarting the game from the beginning.
It isn’t absolutely necessary for such things to always be made explicit in design documents or feature requests, but I find it helpful to be reminded to look at player-facing features from a player perspective in order to tackle the spirit of the request, rather than the letter of the request. After all, our ultimate goal as game devs isn’t to build a bunch of features according to the spec, but to craft a game experience for our players. Thinking about things from the player perspective will often uncover additional issues that need consideration, and framing the issue description that way helps remind me of that.
[Join us on Discord] and/or [Support us on Patreon]
The FANTa Project is being rebooted. [What is the FANTa project?]
Got a burning question you want answered?
Short questions: Ask a Game Dev on Twitter
Long questions: Ask a Game Dev on Tumblr
Frequent Questions: The FAQ
