Daan Kools - Game Designer
  • Home
  • Einar
    • Design Vision Changes
    • Design Supervision
    • Developer Stories
    • Additional Tasks
  • Charlie Ticklefingers
  • Internship
  • Other Projects
    • KYODT
    • WAK!
    • Mine Drift
    • Strings
  • Contact
Einar - Developer Stories

​​​This page contains a few Developer Stories, which will highlight certain problems we faced during development, managerial situations or any other important moments for my work as Lead Designer. It will also contain the solutions we came up with for these problems. When I say "We" in these stories, it usually refers to me and the other leads.

Developer Story #1 - Game Feel

​The Problem:
After our first block of development, we felt that the game wasn't what we wanted it to be. Einar wasn't a bad-ass viking, slicing his way through enemies. Instead, the game was very static. The player would awkwardly kill an enemy, and then move on to the next. That was it.

How to fix it:
I sat down with a few team members, and looked at Shadow of Mordor. I wanted the game to head towards that feeling and it's what I used as base for the combat. We looked at videos and all elements of the game that we could take away from. Here's a short list of the key things:
 

- Change the attack animations. Currently, they are too basic and safe. Vikings are known for their brutality and blood lust-like fighting styles.
- Include levels to have more "arena"-like spaces. As long as the player doesn't have the room to fight multiple enemies, it will keep being clunky.
- During combat, pull the camera back in such a way, that we frame all enemies on screen. The player will always have a good overview of combat and can plan out accordingly. We already have the automated soft lock-on system to support it.
​(Reference: Assassin's Creed, Shadow of Mordor) 

Conclusion:
​These core changes helped to refocus the project and put it back on the track we originally wanted it to be. It gave the whole combat design team a clearer goal to work towards.
The Complete List From The Meeting
File Size: 404 kb
File Type: pdf
Bestand downloaden


Developer Story #2 - Scope

The Problem:
Einar was intended to be a student project, that tries to reach a AAA quality. The team size was big enough and the talent for it was present. A problem we continually faced though, was scope. When I joined the project, I reduced the scope of the project significantly (about 50-60%), but this wasn't enough to reach the quality we initially wanted to reach. Especially the level was too big for the environmental artist to get to that high quality. 

​We kept getting mixed feedback from our supervisor about the scope and we were never really sure what to do. We couldn't just kick people out of the team, so reducing the scope would also mean that certain members wouldn't have work anymore.

Decisions Made:
Nearing the end of development, we were really starting to feel the pressure of finishing the project and seeing that we wouldn't be able to with that current scope. We decided to cut out 1/3 of the level. The level was in a non-functional state at the point, so it wasn't the hardest decision.

It did mean that I had to talk to a Level Designer and tell him that the work he deliver the past few moths would be thrown away, which is quite a heart-wrenching experience. The team agreed that we did owe it to him to make his level functional again, so he at least has a portfolio piece to show. He took it as well as he probably could have; understanding it, but not being very happy about it. In the end, it was a lot better for the project and the team also regained motivation for finishing the game.
Picture
The World Map after this down scope
Picture
The area we threw away

Developer Story #3 - My Biggest Failure on the Project

The Problem:
After I re-designed the game vision and put it back into focus, I failed to push that vision through to the others. This is arguably one of the most important tasks of someone in my position, so it still stings that I didn't succeed in this. I sat down with the designers and we talked through my new design vision and also discussed the current level and the changes we had to make to it. Everybody seemed to be on a very similar page at that point. Everybody aside from 1 Designer.

I had a lot of trouble working with this particular designer. I talked about my vision for the game and he said he had the same vision, but that wasn't really represented in his work. Throughout the whole 1st semester of work this stayed a problem. He kept doing his own thing, which didn't fit with mine. The bigger problem was that this started confusing people a lot. He worked closely with AI programmers and they were working more towards his goals instead of mine.

What should I have done differently?
Personally, I think I should've been stricter with him at the start. I should have made clear that when he tells programmers to create a specific feature, he NEEDS to run it by me first. This way I can either sign-off on it or not. Aside from that, I should have had more personal talks with him in general, to keep pushing towards the right direction.

​It was a difficult situation for me though, because I just couldn't find a way to connect with him. Also, at this point I just started out in my role as Lead and was still a bit too scared to confront people with difficulties.

Developer Story #4 - Even More Scope

Picture
The final version of the world map
Picture
The level that we cut
Picture
The new combat arenas
The Problem:
The whole team gathered for a play session of the project, to see where we are standing and what it's looking like. After doing so, certain people suggested to cut a second level from the game. Suddenly, the whole team started voting and about 30 people voted to do so. This was quite problematic for me and the other leads, because we were the only ones voting against it.

For me, cutting the cave meant destroying the enemy pacing and turning the game into a 5 minute demo. Art was the main vote for cutting the level, because they wouldn't be able to finish the whole thing, which is fair, but a biased decision. The team lead and I started looking for alternative solutions together.

​The Solution:
The team lead and I were both convinced that cutting the second level would only lead to destroying the pacing of the game. I was also afraid that it wouldn't give the team a boost of motivation but instead more of a reason to slack.

We then also discussed a different problem: The level design didn't really accommodate the combat anymore. The spaces were cramped and filled with assets, so there was no room for actual fighting. We then rebuild the entire first level, to fit more open spaced arenas (which would also help out the games performance issues).

​After doing this, we were both convinced that cutting the second level was the best decision, because it meant we could get the first ones design on a much higher level. Implementing the new, open design to the second level as well, would be too much.

Proudly powered by Weebly
  • Home
  • Einar
    • Design Vision Changes
    • Design Supervision
    • Developer Stories
    • Additional Tasks
  • Charlie Ticklefingers
  • Internship
  • Other Projects
    • KYODT
    • WAK!
    • Mine Drift
    • Strings
  • Contact