So when I browsed the boards for a bit, I discovered that there seem to be two or three quests throughout the game which are broken in case you use a cracked version of the game. For instance, there is one quest reported where a progress-critical NPC will not show up. During another quest you are supposed to get into some kind of dungeon but if you play a pirated version of the game you arrive in another dungeon with no exit instead. Sounds fun, huh?

Basically I really think this kind of game breaking copy protection is ingenious - if only done right! Radon Labs/dtp made one critical mistake: they do not show the player directly that he ran into some copy protection. At a first glimpse it seems to be a nasty bug. A really nasty bug since it eventually breaks the main story line in a story driven RPG. As expected this leads to annoyance due to the “bug”. In consequence players raid the dev’s/publisher’s boards and complain about the game being heavily buggy, or even worse, they start rating the game down at online stores or with their friends.

“It’s only the pirates, so ‘who cares!’”, you may state but then you miss some points.

Firstly there are players that buy games but crack them in order to play them without changing discs every time (I myself sometimes belong to this kind). If I would know about this kind of copy protection in advance, I would not do so. In Drakensang’s case though, you did not get any information about this, neither in the manual nor in other media coming with the game. Since the save games are corrupted by the copy protection, too, you cannot even erase the crack and go on from your last saving point. This way you as a dev really scare off your customers since you cannot assume that every customer looks at your bulletin boards. Accordingly some customers may take above mentioned measures.

Secondly there is the risk that your copy protection incorporating this “game breaker-feature” may not work as intended on systems other than your test ones. This happend with Drakensang, too, so they are now having some angry customers posting on their boards and calling the customer support. Once again the lack of information poses the risk that these customers may leave and even advise against the game.

To avoid these issues I would suggest a possible solution that erases the information deficiency in both cases and still provides the same protection as before. First of all, add information about the copy protection mechanism clearly readable to the manual and to the installation and start-up screens. This way you can make sure that most of the honest customers at least get enough info to not make any mistakes.

Second to that, inplement the “game breaker-feature” in a way that clarifies what just happened. Let’s take the example from Drakensang where the NPc will not show up to complete the quest. A better solution would be having the NPC show up but not tell the player about the quest, but instead tell him that he probably is playing a cracked version of the game.

When that happens to a pirate, he will either not care and delete the game or he will be already drawn into your game and will spend some money for a legal copy. On the other hand, a customer will not think of a game-breaking bug but call the customer support instead. In either case do not break the savegames! Customers will be annoyed if they already spent some hours in the game only to discover that they have to restart just because of a faulty copy protection. And with pirates you provide them some support if they really decide to buy your game since they can play from the point where the game broke for them. Why punish a software pirate if he turns into a paying customer? A working savegame is more of a incentive to buy the game already.

To come to a conclusion, I’d really love to see more copy protection working this way. It is not that difficult to integrate when thought about in design phase. It will not annoy paying customers with DRM that requires an internet connection or complex and unhandy serials. And you save time for a demo of your game. Why? Every game gets pirated sooner ar later. Use this fact for your own advantage. Put the time required for demo development into debugging and deliver a better game. This way you may at least harvest these pirates that claim themselves only pirating games in order to try them out and buy them if they are worth it. They are even taking care of distribution by themselves. And last but not least it does not pose more risk to malfunctions with your copy protection then it would anyways.

Classification

At first it is neccessary to define the scope of some phrases I’ll be using throughout this series.

I will use the term “project” to describe an endeavor that is defined by the parameters time, goal and people. A project is generally a temporary endeavor with a set final date. Until then a pre-defined objective has to be achieved, generally creating a product or service. This output is delivered to a customer and the process of creation involves one or more people.

Another term I will use often is “team”. A team consists of at least two people working together for a special purpose. In this series of articles this purpose will be a game project. I will focus on bigger sized teams with at least 5+ members since such a team actually needs some kind of management. Mostly everything will be applicable to smaller teams, too, but it may not always be neccessary.

By “management” I mean the activities of planning, organizing, leading and controlling both the team and the project. With bigger teams it is advised to have one person dedicated to management. In smaller teams it may be reasonable to have one member do the management aside the normal work.

When talking about “students” I refer to people that are currently attending classes or courses at some school or university for the bulk of their time. A lot of the topics in these articles may apply to hobbyist projects or even independent projects, too, but my focus is on students explicitly.

Finally, the term “game” is used mainly for a piece of interactive software somehow providing entertainment. Again, I only want to point out the articles’ focus.

Analysis

The differences between student led projects and company projects derive from a wide range of issues. Some will merely have any impact on project management, others may have tremendous consequences.

First of all there are some rather obvious differences:

• Students generally won’t get paid for their project work, employees do.
• Students have to work on projects in their spare time, employees do it during their working time.
• Students do not have set working times, employees do.
• Students are hierarchically coequal, companies have a hierarchical structure, even if it is very flat.
• Student projects lack a real customer, companies always have a customer (even if they are the customer themselves).

But there are also some differences that are not this obvious:

• Students’ resources are strictly limited, companies are rather able to invest in projects.
• Students lack experience, companies have at least some “senior” employees.
• Student projects rarely have any legal framework, companies contract most of their issues.
• Students have no obligation after a project is finished, employees still work together at their company.

All told, you can see that student projects differ from company projects mainly by various deficiencies. These lead to various problems special to student projects.

First of all the project manager is restricted by the ways he can induce motivation since there are no monetary incentives or long-term achievements like career advancement. Second to that insecurity increases as it is uncertain that the project will ever suceed under the given circumstances. Also it is a double-edged sword that students normally have nothing to lose when the project fails. On the one hand this leads to a higher readiness to assume a risk. This may result in a neglect of risk management which is essential to a project’s success. On the other hand the nothing-to-lose-attitude may lead to reduction of determination when the project gets to a critical point and requires some gritty decisions to get back on track. The lack of authority due to the equality among the team members can cause lots of exhausting delays with the decision making. It may even lead to displeasure within the team when decisions only consist of compromises which threaten the project’s vision to become softened up.

These problems obviously pose a risk to the success of the project. Therefore you need to be especially aware of them besides the “normal” problems and challenges you will face when trying to realize a project in general. Now that there is a basic understanding of the differences between student and company projects and some problems deriving from that, I would end this article with a note: I recommend having some basic knowledge about project management in general as well as with software projects in special when reading this series of articles since I will mainly focus on solutions and tools that help with managing student projects and avoiding the described problems in my future articles in this series. One book I can recommend for software projects is “Software Project Survival Guide” by Steve McConnell. For a short introduction to team and conflict management take a look at “Team- und Konfliktmanagement” by Udo Haeske, although it is only available in german language.

Feel free to comment on this and other articles, I would really appreciate any feedback and critique.

The experience Daniel Cook’s wife had with WiiFit clearly shows the impact of games on human psyche and how to make good use of it in a beneficial way aside from mere entertainment - not completely removing the fun from games though.

1. Grinding != Playing

When you look at people playing MMORPGs you find quite a few that actually play the game for fun. But others are rather working, grinding their way through a world that offers nothing but the feeling of having achieved something - even if this achievement is marginal or the way to get there was tedious and exhausing. That even goes as far as  playing for hours or days to get this feeling - a process I call play-working. As soon as I saw this I began to think about a way to use this phenomenon and put it to a prolific use. So the idea was born to try to motivate people to work on tasks by integrating the work into a game that works similar to a MMORPG like the before-mentioned. Let’s try to get from play-working to work-playing!

2. Analysis: The Seven Rules

To make this work you need to analyze the core mechanics of games that evoke this phenomenon of play-working. (Note: besides MMORPGs other games also make use of “achievement grinding”, i.e. TeamFortress 2 and Call of Duty 4)

1. Community
2. Milestones
3. Clear, short-term tasks
4. Perpetual gain of small achievements
5. Vizualization of achievements
6. Persistence of achievements
7. Usefulness to the player

Let’s get a little bit into detail on these.

Community

First of all there has to be a community the player is part of. This obviously is a common feature of MMORPGs by their nature of being driven by multiple players engaged in one world simultaneously. A community is important for enabling the players to “show off”. Achievements are worth nothing when there is noone else to recognize them. Hence the community creates some sort of competition amongst players, motivating them to go after achievements.

Milestones 

The player needs to have a milestone, a destination for his journey. This may be a level-cap, as often used in MMORPGs, or even something as simple as offering the possibility to be the best player in the community and having it recognized. Maybe a milestone is not truly neccessary but it helps the player to get an idea of the length of his journey. Thus it takes away the uncertainty to some degree and motivates the player to start journeying.

Clear, short-term tasks

According to MMOs these are the quests given to the player by NPCs or other players. Quests need at least a start, a destination/goal and a specific challenge to bear. More complex quests feature multiple locations and/or multiple challenges and may even hide information from the player to raise difficulty. Yet aiming at the achievement the player prefers clear goals, as long as they don’t kill the motivation by being too easy, i.e. when challenge and achievement are imbalanced.

Perpetual gain of achievements

It is not enough to provide a player with one big achievement at the end of his journey. The player needs to have a perpetual gain of smaller achievements to stay motivated and go after the milestone. More interesting than this is an occuring side-effect: you can give various tasks to the player that are repetitive in their nature but often hidden behind a nice coulisse as long as they yield a reward. One needs to be aware though that the demotivation on the player’s side rises exponentially with the amout of repetitive tasks.

Visualization of achievements

As mentioned above the player needs to have his achievements shown to other players. This works best by visualization. The more the player can brag with his achievements the better because it stimulates competition.

Persistence of achievements

This is especially important if the player spends quite some time with the game. Everything the player achieves has to stay visible to others to not lose its value. Maybe the player will still feel proud of his achievements personally but not being able to show them publically hurts the motivation to get more achievements.

Usefulness to the player

One thing that helps with achievements is making them meaningful or useful to the player. A plain number or some coin motivates less than a new powerful weapon.

3. Applying the Rules

So these seven rules are critical to the success of making players play-work in your game. Let’s see if we can find some analogies when applying them to a games project.

The community is the team working on the project and everyone involved is a player in this “game” called work. Then there’s at least one milestone - the day when the project is finished. This date may not be as accurate as a Level-50-Cap but it can at least be estimated and serves its purpose as destination for each player’s journey. Actually every milestone can be set as THE milestone, but for this article I’ll assume our journey’s destination is the project’s completion. The tasks are simply the assignments given to each team member. Having a task-driven development cycle like Scrum helps a lot since it already requires tasks to be very short-term and clear.

The tasks need to reward the player. The simplest form is to compliment the proper team member upon successful task completion. Since compliments can be used more than once they allow for a perpetual gain of achievements. Yet they lack the potential to be visible and persistent to others. So we need to refine our system and that’s the point where we actually design our game to make people work-play.

To keep it simple let’s assume the game is a virtual layer sitting on top of the actual “real” work. Every team member gets its own representation in this virtual layer - an avatar. Keep in mind that this virtual layer may be digital as well as analog so the avatar can either be a 3D-Model of the player, an Excel spreadsheet or simply a stickman painted on a sheet of paper and pinned to the wall. Now that there is an avatar it is possible to visualize achievements.

As said before the assignments will be the tasks that yield the perpetual achievements. The tasks need to get weighted in order to assure some balance since tasks normally differ in time consumption and complexity/difficulty. A simple approach would be to assign points to the tasks ascending with the degree of time consumption and/or complexity. The amout of points is used to determine the reward’s quality.

Now that we have build the framework this is where the fun and creativity comes in. The team can now think of various achievements, the graphical representations and the rules for getting them credited, i.e. special items or badges rewarded at X points collected within Y time units. The only importance is with obeying the seven rules that reinforce the system.

4. Chances and Risks

So far I was not able to gather much information. Me and my team are currently implementing a game following this pattern into our Scrum-based development cycle. Hopefully we will soon be able to evaluate it.

So far it is only possible to try looking for potential risks. First of all you really need everyone to get involved. Team members that do not engage in this game will likely be a kill-joy to the others.

Developing the game can become quite complicated. You need to watch for balancing issues since they will likely create displeasure if competing players get the feeling of not being competitive anymore (i.e. programmers getting more points than designers because complexity of tasks is overrated).

Also when looking at competition, motivation can turn into envy and thus into demotivation. This is especially dangerous in teams with varying qualification.

Despite the risks this approach may result in higher motivation within the team since the team members may think less about work as tedious must-do activity and instead link it with something fun. Providing the right achievements is one important step towards this goal.

Have fun play-working!

Now the last task obviously is my one. Accordingly this is the reason why I will write a series of articles on that topic - managing a team of students for a videogame project.

On a first glimpse you may say, “So what? Get a book on team management and game producing and get it on!”. This also was my first thought but then I realized that all these books assume projects and teams being intergrated into a company. But there’s some huge differences between a team consisting solely of students and a team formed of employees. For the future articles I will try to isolate single discrepancies and provide possible solutions fitting the needs of students trying to manage a game project.

So what’s it all about? Basically I’ll try to regularly update it with my thoughts on game design and game development.

Why did I chose this particular topic? Because I think that games are the next step in media evolution. And although the industry around this interactive media is already huge, the medium itself has yet to mature. But this is only possible if people start thinking about games and what they are all about. So when I decided to study “Game Design” at Mediadesign University of Applied Sciences in Munich, Germany, I did not only want to start developing games but also learn about the things behind the scenes of this fascinating medium. I hope this blog will allow me to share my thoughts on game design and development with many people at least as passionate about this topic as me.

What to expect? I will try to post on at least a semi-monthly basis. Since I mayself am very interested in team and project management, game design, storytelling and a little bit of coding, I will mostly write about these topics. I am also looking for a nice design and working on additional pages about me and the stuff I am doing.