previous arrowprevious arrow
next arrownext arrow

Project Information

Einar is a single-player 3rd person hack and slash based on Norse mythology. The player takes on the role of Einar, who is on a quest to kill the inhabitants of a Norse fishing village who are infected by a mysterious material. Use different weapons such as the bow, hammer and axe to clear the village of the monsters.

  • Role: Producer
  • Project Type: Game Project
  • Project duration: ±32 weeks
  • Team size: ±40 developers
  • Duties: High-level planning, agile development with Scrum, tracking tasks, organizing meetings
  • Software used: HackNplan, Google Drive Apps
  • Playable link: Play Einar on Steam

My work

previous arrowprevious arrow
next arrownext arrow

Details about my work

I joined the project when it was at its midpoint of the production phase. The project was just a few months before the deadline for shipping the product. I knew beforehand that the project was highly ambitious and that it was striving for a small game with AAA quality, especially in the art department. The leads of the project tried to recruit as many students as they could possibly get. Which worked, because the team was just above 35 developers, with a couple of freelancers. However, the project did suffer from a couple of things, one important aspect was the constant switching of the producer in the team.

The first thing that I wanted to dive into, is the product backlog, but unfortunately, that was not made yet. The team often switched producer and suffered from it. There were many production aspects that were not done or up to date. One of which, was the product backlog. Which was a real shame because now I had no idea what they were working towards, what priority was and what was done. Therefore, within the first few working days, I sat down with the leads of Einar and created a product backlog.

When I knew what needed to be done, I made some restructure changes in the feature teams. I prefer to work in feature teams, so it was pleasant that they were already working with feature teams. However, the way they were formatted was not working for me. There were 7 feature teams: Lead, Level, Gameplay & UX, Combat & Camera & Controls, QA, AI, and Characters. Why the AI feature team was separated from the Characters feature team was not working for me. The whole purpose of feature teams was broken. You want to have cross-discipline communication and collaboration, which you can be endorsed by making the artists, designers, and programmers work together on one specific feature.

Scrum was already implemented, but not the way I would like it to be. There were daily stand-ups but they only were done with the leads. Which destroys the ownership that you want to accomplish with Scrum. Besides that, you want to keep the whole team informed about what is happening within the team and product. Furthermore, there were no retrospective meetings. This is something I give great value in because in this meeting you can look back with the team to see how the production went. This is the agile aspect of Scrum, being able to adapt the project and its direction.

After each sprint, we had a retrospective meeting and a sprint review meeting. With the data of each sprint, I could make a burndown chart with the estimated line of work and what we were actually doing. What I saw was worrying but not surprising. I knew from the beginning that the project was highly ambitious and most-likely over-scoped. Now that I could see this visually, I needed to make some hard and tough decisions. Some of the leads were not happy with this information because it could break their original vision of the AAA-quality aspect of the game.

Now that I have the data to support my idea to down-scope, it was time to look at how and where we could down-scope and what we want to keep. I was thinking of multiple ways to do this and described them in the Einar Survival Plan. This was the plan to save Einar, without any form of scratching or down-scoping, we would never be able to ship a complete game.

In the Einar Survival Plan, I looked at Environmental Art, VFX, AI programming and Combat/UX Design. Environmental Art is in here because, as I mentioned before, the art department is really striving for AAA-quality art for the game. We first had three different environments planned and they were even in the game a few months before launch. We had a cave level and an end level that has meteor impacts all around, the glowing virus and a lot of enemies. Options were to either remove 1 or 2 levels, lower the quality of the environment or put some character artists on it. This is one example of how I looked at things and discussed it with the departure leads.

After the down-scoping, I restructured the way we kept track of assets and its progression. Now that we are in the last few months of development and we have a more realistic goal, I restructured the assets lists and how to track them. We didn’t have a system for that as well, every developer had their own list that they worked on. This was something that I saw could be improved. The reason is that everyone uses a different listing system, so it was harder for me and the other leads to track it.

In the last 3 weeks, everything came together and the game felt like it was nearly done. This was a huge relief because we were working hard with the little time we had left before the deadline. The features that everyone was working on came together and at one point when we had the build, it was really fun to play.

Now it was time to get the game out in the world. We went to Indigo to promote Einar on the Epic Games booth. One of our developers had contact with an old student, who is working at Epic Games. We had quite some attention at Indigo and people were very enthusiastic. A few days later we release the game on Steam and it got some traction.

Project Reflection

Einar Survival Plan

I should have acted earlier with my plans/suggestions to save Einar. The Einar survival plan was a good idea, and I think it has saved the project. However, I should have seen the problems earlier and I should have acted directly. When I joined the project I already knew it was too ambitious and over-scoped. This is a problem when you are on a schedule and you have to ship the product in time.

Spreadsheets VS HackNplan

I should have been more consistent with either HackNplan or google spreadsheets. When I joined the project, they were using HackNplan for their day to day tasks. However, it wasn’t being used much and it got somewhat left behind. This was also a big reason why there was no product backlog when I joined the project.

Myself, I like to use google spreadsheet or Microsoft Excel, because I can make my own system that works best for me and the team I am in. Therefore, I wanted to disband HackNplan all together and step over to Spreadsheets. After a few months, most students didn’t use spreadsheets anymore. I tried to combat this by going back to HackNplan because it is more simple, therefore more likely to get picked up by the team.

All this switching and redoing cost me so much time, which was essentially wasted. What I have learned is that I should stick with one planning software and stick to it. My preference still goes to spreadsheets.

Sprint Reviews

At the end of every sprint, I organized a sprint review to look back at the work that we had set out and what we had achieved this sprint. However, in retrospect to this project, I didn’t do this well. The major point that I missed was to have the team not involved enough. I talked about the things that we had achieved per sprint with the leads.

Looking back, what a better method would be, is to have each feature team present their work in front of the others. Let the lead explain what they did, and what progress they have made. This way everyone can see how hard other features are coming together, what other developers have been working on and what the results are. The team would be way more involved and will most likely increase the motivation all around.

Playing the game at the end of a sprint review is also a great thing that I should have implemented. By playing the game altogether, you see your own work directly into the game and how it affects the player experience.