Korku Postmortem

Where We Started:

When we started making Korku we wanted to make a multiplayer FPS game where the players could customize their mech’s load out. We quickly realized that with the time we had available this idea was over scoped. We eventually settled on a cooperative player vs AI game. We wanted each of the two players to feel important so we tried several different ways to divide up the tasks that each player had to do. The second player was given a UAV to scout the area and a buffing mechanic to power up different parts of the mech. The first player controlled the mech and fired the main weapons. We also decided to have our game set during World War 1.

Where We Ended:

When we presented the game to the faculty we had come a long way. We had improved the second player’s mechanics to streamline their game play and allow them to be more active in combat. We gave the second player heavy weapons to give them a role in combat and cut the UAV mechanic. The biggest change for the second player was changing the buffing mechanic from its original puzzle based game play to a resource management mechanic. Through QA testing we balanced the weapons and got the shooting to feel right. We ended up cutting the customization mechanic from our original idea since it required a lot of art assets and we only had one artist. Our final level had the player destroying a convoy and escaping the area.

What I Learned:

The biggest lesson I learned this semester was the importance of communicating with my artists during level design. I had worked on level design before but it was by myself, this was the first experience I have had working with another person on a level. When creating our games level I would send the changes I made to my artist and he would give me feedback. The entire team agreed that this helped improve the level a lot. I really liked having a second pair of eyes on the level to help me make it feel populated and interesting. This is going to be a very useful lesson next semester because I am doing level design again for a different team and I will be working with the same artist from my old team. I also learned about the dangers of making a game with networking. We had the two players in our game connect to each other using a online network, this ended up causing a lot of problems for us. We did not realize how difficult it was to get a network working without bugs. We had problems testing due to networking issues and we also had network problems during our presentation to the faculty. Another lesson I learned that will be helpful next semester is ways to cut down on the amount of memory a level uses. My artist showed me ways to conserve memory which will be helpful next semester when I am creating levels and want to optimize them so they work on lower end computers.

What Went Wrong:

There were only a few things that went wrong this semester. The biggest thing that went wrong was our networking issues. Our game required a working network to play and when we presented to the faculty we had issues that caused our game not to work during the first play session. We got it working by the final play session but the damage was done, not everybody got to play it and it was clear that the issues left a bad taste in peoples mouths. The other big mistake we made was over scoping, our initial idea was really ambitious and we quickly realized that we needed to scope down. Once we took out the player vs player aspect we did not want to take out much more, however the game was still over scoped and I feel that we were worried about scoping down any more even though we should have.

What Went Right:

There were a lot of things that went right while creating this game. I had an amazing team working with me, everyone was always communicating and the meetings had a friendly atmosphere. Nobody in the team was afraid to speak their mind and everyone took critiques very well. The strength of our team was the reason we wanted to make Korku, we had two other potential ideas for games to make but even though Korku was the most ambitious we all loved mech games and we knew our team could pull it off. Another thing that went right this semester was our QA sessions, we went to QA at least once a week and got great feedback about the game. There were several testers that were super excited about our game and we were happy with the responses.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s