Now, when designing our own games, how can we make sure to provide an experience that would appeal to different sorts of people? How can we design something that’s attractive to groups of people that have completely different views on what having fun means?

With so many people in the world it’s not feasible to even think about considering the interests of each individual separately, but we do need to be aware of some common traits that players usually share and use this knowledge to our advantage.

This is where it comes in handy to know about which types of players exist, so we get an idea of what each of the usual profiles look for in a game.

Taxonomy of player types

According to Richard Bartle, players can be classified in four categories: killers, socializers, achievers and explorers.

Killers

This type of player loves proving their supremacy over others. They’re beings of competitive nature, who enjoy being at the top even if they need to use dirty tactics to step over other players.

Normally, these sort of players are more interested in games where interaction with others is possible, as they need to constantly compare themselves to other people.

Multiplayer games that offer competitive features, such like fighting games, are surely to attract this sort of player.

Single player experiences may not be as attractive to these people, although offering leader boards could be enough to gain their attention. Even if they cannot directly crush other players, it could be enough if we have a leader board where they can see their current position and aim to reach a better spot on the list.

Socializers

Just like killers, these sort of players enjoy games the most when they can share the experience with other people. As their name implies, they’re friendly individuals whose main aim is to socialize with others through the game.

Unlike killers, though, these people do not often care about being the best. They simply do enjoy the company, and tend to like cooperative modes and being able to help others.

Appealing to socializers will require adding features to our game where they can cooperate with others, so games offering multiplayer are more prone to attract them.

It’s more rare for people with this profile to be interested in single player experiences, although we could make up for it by adding something as simple as allowing them to send objects over to their friends. Even if this would just indirectly help their colleagues, it may be enough to make the socializer happy.

Achievers

This sort of player does really get immerse in games, and always aim to achieve everything that can be achieved in the game. For this reason, they invest time in learning everything about the game mechanics and becoming experts on it.

If there are trophies left to be unlocked, the achiever would persevere until they have got every one of them.

Unlike the two previous types, achievers do not particularly care about the social part of the game. Their focus is on the world in the game itself, so it’s easier for them to be attracted to both single and multiplayer experiences.

Adding extra challenges, trophies or unlockable content would mostly be enough to guarantee the interest of this profile.

Explorers

Of adventurous nature, what explorers seek in a game is the ability to explore new worlds. This type of player would have fun just by walking around the map, getting to know every piece of the environment and enjoying the scenery.

It doesn’t matter whether they play solo or with others: the aim is on getting to know everything that there’s to know about the virtual world with which they’ve been presented.

Open world games where they’re free to move around at their pace are a sure bet when trying to attract people with this profile. We can, however, still appeal to them with other games that provide enough room for them to explore and get to learn more about the game’s world.

Conclusion

Most people do not strictly belong to one of these categories, but are mixed profiles that shares the traits of two or more of them.

It’s, however, very interesting to know about the main types Bartle defined on his research, as it does a good job on summarizing the possible player profiles we can encounter.

Ideally, our games should have at least something for everyone. Thus, knowledge on this taxonomy would certainly play to our advantage when designing a game, as it would enable us to add features that could comply with the preferences of each player type.

Problems of the traditional methodology

Traditionally, software development was created by using what’s commonly called the waterfall methodology. By using this technique, the development process was performed on a single stage. Once the client had made their requisites clear, all of the information was recollected on a document that would become the only source of truth for the project. This document would contain the detail of all the features that had to be developed, as well as a planning with estimations on when each of those parts should be ready.

All through the development phase, the project specifications document would dictate how things should be done and what the final product would have to contain. The client would not be involved anywhere in this process: once they’ve specified their initial requisites and approved the content of this document, they would not catch a glimpse of the product until it was finished.

The main problem with this approach is the lack of flexibility, as well as the high risk of having an unsatisfied customer. As they won’t ever see the product until it’s finished, it could happen that what they had initially requested don’t match their expectations and they’re unhappy with the result. If that happens, the client may want to request for changes or new features that would end up on a new waterfall cycle with the same risks as the original.

The longest the project is, the more inconvenient this model is: it’s not only a matter of being unable to provide what the client really wants in a way that satisfy them, but it’s also a cause of frustrations among the developers that spent months working on features that are finally discarded or they need to rebuild them from scratch because the client has changed their mind after seeing their old ideas implemented. Unless the client really sticks to what they initially wanted (which is hardly ever the case), using this methodology can lead to tons of wasted time in creating things that are no longer wanted.

Agile methodologies, such as Scrum, were born in an attempt to mitigate this problem and allow for more flexibility during the development phase, as well as involving the client to collect their feedback earlier in the process.

Scrum to the rescue

Scrum proposes a structure in which development takes places in multiple steps. Each of these iterations is called “sprint”, and they’ll have a fixed length that can vary from one week to a month depending on the project size. At the end of each stage, the client should be presented with the work we’ve done so far. This will allow them to see how the products evolves over time, as well as having a chance to give us feedback on it and requests changes as they see fit.

The main advantage of this approach, thus, is that it’s easier to adapt to the client’s demands. In the traditional model, were the client to request changes, it may already be too late: in the worst case scenarios, many of what had been worked on would need to be discarded and rebuilt from scratch. However, by listening to their feedback regularly during the development process, those changes requests would not have such drastic effects.

We’ll be working on small pieces of the software, one at a time, and so this allows us to adapt the product to the client’s needs and wishes more easily. We do not need to have the final result in our heads from the very beginning: we’ll build the road as we go, always considering the client’s feedback to ensure their satisfaction with the output.

Scrum team

When working with Scrum, we need to have small teams up to 9 people. There are 3 roles involved in this methodology:

1. Product Owner

The “Product Owner” will be the person in charge of communicating with the client. They’ll be responsible of managing the “product backlog”, which is a list where all the work that has to be done will be defined.

2. Development Team

The “Development Team”, as the name implies, consists on the group of people who will develop the product.

These teams have to be reasonably independent, so we’ll typically need to have a mix of profiles on it: there must be people enough to be able to implement a full feature without relying on external teams.

In the specific case of a web application, for example, this would mean we’ll need a team with people who can build server-side code, UX designers and front-end developers.

If developing a game, then we’d need not only people with the ability to write code and implement the game’s behavior, but also designers who could create the assets or specialists who can set up the music or sound effects. If the team was lacking people with any of the forementioned skills, then it wouldn’t be able to successfully build a functional product, and so it wouldn’t qualify as a good Scrum team.

3. Scrum Master

The “Scrum Master” is a person that’ll guide the whole team in how to successfully apply the Scrum methodology.

This is mostly a temporary role, whose only aim is to teach other people about the different processes involved in Scrum. They do not need to know anything about the product, and they do not need to be directly involved on its development either (although they could).

Structure of a sprint

As mentioned before, sprints are the different iterations on which the development stage will be divided. A small overview can be observed in the picture bellow:

When the project starts, the first thing to do is to define the length that our sprints are going to have (they cannot exceed one month). All sprints will have a goal, and by the time one finishes we should have something that adds value to the client, preferably something that they’re able to see and touch (like a functional demo for the developed feature). The length of the sprints will remain constant during all the life of the project, so it’s important that we choose a duration in which it’s feasible to develop at least one feature that could be shown to the client.

Scrum defines a couple of events that should take place at every sprint, which will consist on meetings to which every team member is required to attend. Each of them are described below:

1. Sprint planning

“What are going to do in the upcoming weeks?”

The sprint planning is a meeting that takes place at the start of the sprint, and it’s probably the most important one. In this meeting (that could last up to 8 hours for a sprint of one month), the product owner will present the team with the highest priority tasks and features that the client desires to see in the short-term.

During this session, thus, they’ll go over the most important elements in the “product backlog” and decide, along with the rest of the team, which of those would be implemented during the sprint. These items will be added to the “sprint backlog”, a list that will contain only the work planned for the current sprint.

Once that’s been settled, the development team will then need to estimate how long they believe it would take to complete each of the selected tasks. If the amount of estimated hours is not reasonable for the length of the sprint, then they may re-negotiate with the product owner to either add or remove some of the tasks currently in the sprint backlog.

At the end of the session it should be clear which the goal of the sprint is, and what are we going to hand over to the client at the very end.

Given a simple example of a blog, for example, the aim of a sprint could be to allow the user to successfully create a post. The sprint backlog should contain all the tasks required to give shape to this feature, such as generating the database structures necessary to store the data or the creation of the form that users can use to write their post.

2. Daily stand-up

“How are we doing so far?”

The daily stand-ups are very short meetings that, as their name implies, are scheduled to happen on daily basis, always at the same time of the day.

They can take up to 15 minutes, and they’ll consist on the development team members taking turns to briefly describe what they did on the previous day, which problems they’ve encountered and what they expect to be doing today.

The whole point of the meeting is to keep track of the progress, helping to identify potential issues that could lead to delays and allowing everyone to know what everyone else’s working on.

3. Sprint review

“What did we manage to do in this period?”

This meeting, which can last up to 4 hours for a sprint of one month, takes places at the end of a sprint. On it, the product owner will go over all the items in the sprint backlog and validate which ones have been completed or not. Those that weren’t finished will be re-estimated and moved on to the next sprint.

In this meeting we’ll also evaluate the final result, the output of the sprint which we handed over to the client. Did it live up to our standards? Did we managed to reach a satisfactory result? If not, why was it that we didn’t make it right? Which problems we had and how can we do it better this time? Did we underestimate the tasks and were too positive on our initial estimations?

All of those questions should be answered during this meeting, and the feedback we collect from everyone would allow the whole team to be aware of the problems and come up with solutions to improve their performance on future iterations.

4. Sprint retrospective

“How well did we work?”

Similarly to the sprint review, the retrospective is also a meeting that takes place at the very end of the sprint. The aim is similar: to make an exercise of self-assessment and come up with solutions for those things in which we could have done better. In the sprint review we focused on the product, whereas in this case we’ll be looking into the team’s way of working.

On these sessions, what we should be evaluating if not whether we managed to complete the tasks or not. What we’ll be evaluating is how we work together as a team, and if there’s some aspect in there that could be improved.

Problems between team members or having insufficient communication are some of the issues that could surface here. Then we could come up with solutions such as start using new tools that could help in our daily communication, for example.

Conclusion

As we’ve seen above, Scrum offers quite a few advantages over the traditional waterfall methodology. It encourages open communication between the client and the team, providing clients many chances to see the work that’s being done and provide feedback.

It also favors communication and transparency inside the team itself, with its different events allowing people to be open about different aspects of the development process. Also, Scrum is built with the premise of self-improvement in mind, so it provides the team with multiple chances to evaluate their own work and come up with new solutions that could be implemented in future iterations.

Does this mean using Scrum is always better than the traditional way of working? Although it may be a good alternative in many cases, the answer is no. Actually, it all depends on our team and, more importantly, on the nature and size of the project. For relatively small projects where requisites are unlikely to vary during development, the cascade methodology may work just fine.