Out of all the projects I've worked on at DigiPen, Guns with a Z (GWAZ) is probably the one that has undergone the most radical transformation. When I originally sat down with the team in the summer, we had three core principles for the project:
The prototype wasn't fun. Players didn't have enough agency in the world, and frankly it was easy for them to find each other using context clues and the miracle of human language. So we got to talking, and came up with a game idea in which the players would see different versions of the city. They then had to communicate to solve puzzles in tandem in order to meet up. As they got closer, the difficulty would continue to spike and enemies would start showing up. We liked the idea, but came across a stumbling block that as I was prototyping it, I realized just how hard that kind of game was to procedurally generate again, given the team size and time we had available to us. We went on trying idea after idea using a procedurally generated city until after a Team on One we came to terms with the fact that we all just wanted to have fun working on something silly. So we took a shot at making a parody.
Things started to turn for the worse because of our first pillar as a team, the cool technology. Procedural generation was it, and our devs were committed to working on it come hell or high water. But as time went on what became important to some became not so important to others. I still really wanted a super polished game. One of our devs dropped procedural generation and focused on working on graphical effects to sell himself better as a graphics programmer, leaving us with one programmer working on procedural generation. One of our programmers committed himself solely to networking, then failed to follow through due to pressures from classes and left the team. In hindsight, at this point we should have split as a team. We were working independently from each other anyway: myself, our graphics dev and the other designer working in a static environment I created while the other worked on creating a city. And when we finally brought the two together they didn't mesh at all. The HUD and many of our polish effects were designed around the space I had already created, as well as our enemy manager and didn't work as intended. Certain enemy logic didn't work in the procedurally generated environment, and by the time we got to combining them we didn't have time to fix them. As a result one of the coolest enemies, one that picks up guns and shoots them at you, got cut in the final version.
I think procedural city generation is one of the coolest things about our game, but I believe we should have cut it. We didn't though, because in the end I was the only one that felt that way. The dev working on it explicitly would have rather left the team and worked on it on his own than cut it, and the rest of the team really wanted to see it in. And I, at the time, didn't see the harm in letting him work independently until we finally tried to merge our projects. I personally fault myself for how badly combining the projects screwed up the game. If I'd tried to give the procedural generation dev more information as to the kinds of things we were doing in the game and what we'd need for it all to work, instead of just letting him focus on procedural generation combining the projects would have cost us way less time and energy.
GWAZ, while it has it's funny moments, was a failure that I blame myself for. I wanted everyone to work on what they wanted to work on, and I don't feel that was a wrong move. I'm no one's boss, and my team members certainly have a right to make decisions for our project too - especially on a team as small as ours was. I should have handled procedural generation better though. I should have released the procedural generation Dev, or given him better insight into what we'd need from a design standpoint for everything to work. There are a million little things I could have done better in hindsight, but didn't. But that's the beauty of student projects though, because now I know what to look out for, and will never make the same mistakes again.
- We wanted some cool technology our programmers could show off
- We wanted lots of polish. My past game projects at DigiPen have all been good, but none of them have really gleamed with polish. We wanted something that would look great in a video or portfolio reel
- We wanted a simple design that could be built on so we always had time for implementing cool technology and polish while still delivering on a good game.
The prototype wasn't fun. Players didn't have enough agency in the world, and frankly it was easy for them to find each other using context clues and the miracle of human language. So we got to talking, and came up with a game idea in which the players would see different versions of the city. They then had to communicate to solve puzzles in tandem in order to meet up. As they got closer, the difficulty would continue to spike and enemies would start showing up. We liked the idea, but came across a stumbling block that as I was prototyping it, I realized just how hard that kind of game was to procedurally generate again, given the team size and time we had available to us. We went on trying idea after idea using a procedurally generated city until after a Team on One we came to terms with the fact that we all just wanted to have fun working on something silly. So we took a shot at making a parody.
Things started to turn for the worse because of our first pillar as a team, the cool technology. Procedural generation was it, and our devs were committed to working on it come hell or high water. But as time went on what became important to some became not so important to others. I still really wanted a super polished game. One of our devs dropped procedural generation and focused on working on graphical effects to sell himself better as a graphics programmer, leaving us with one programmer working on procedural generation. One of our programmers committed himself solely to networking, then failed to follow through due to pressures from classes and left the team. In hindsight, at this point we should have split as a team. We were working independently from each other anyway: myself, our graphics dev and the other designer working in a static environment I created while the other worked on creating a city. And when we finally brought the two together they didn't mesh at all. The HUD and many of our polish effects were designed around the space I had already created, as well as our enemy manager and didn't work as intended. Certain enemy logic didn't work in the procedurally generated environment, and by the time we got to combining them we didn't have time to fix them. As a result one of the coolest enemies, one that picks up guns and shoots them at you, got cut in the final version.
I think procedural city generation is one of the coolest things about our game, but I believe we should have cut it. We didn't though, because in the end I was the only one that felt that way. The dev working on it explicitly would have rather left the team and worked on it on his own than cut it, and the rest of the team really wanted to see it in. And I, at the time, didn't see the harm in letting him work independently until we finally tried to merge our projects. I personally fault myself for how badly combining the projects screwed up the game. If I'd tried to give the procedural generation dev more information as to the kinds of things we were doing in the game and what we'd need for it all to work, instead of just letting him focus on procedural generation combining the projects would have cost us way less time and energy.
GWAZ, while it has it's funny moments, was a failure that I blame myself for. I wanted everyone to work on what they wanted to work on, and I don't feel that was a wrong move. I'm no one's boss, and my team members certainly have a right to make decisions for our project too - especially on a team as small as ours was. I should have handled procedural generation better though. I should have released the procedural generation Dev, or given him better insight into what we'd need from a design standpoint for everything to work. There are a million little things I could have done better in hindsight, but didn't. But that's the beauty of student projects though, because now I know what to look out for, and will never make the same mistakes again.