I’d like to break my reflections of my Capstone semester into 3 parts. This first one, focusing on my individual work, experiences, success and failures. The second, looking at my team as a whole, and what went wrong and right. And lastly, more general look at everything that’s gone down, after talking with everyone else.
The first thing I’d say when talking about my Capstone, is that it was incredibly nerve wracking. Stressful and tiring? Yes. Fun and educational? Yes. Disappointing and satisfying? Yes. But more than anything, I was incredibly nervous the whole way through. I think the nerves came from three different places. First, was the simple fact that I didn’t want to let my team down, and as I’ll go into later, I think I did in many ways. Second, was the general nervousness around the scope of project. There were many fears I had about what we were getting into, and unfortunately, a few (but not all) of them were well founded. Lastly, the expectations were getting in my head too much. Not just the expectations of making a good game for capstone, as everyone has. But, the success I had last semester, with Rolling Thunder, being the only juniors to go to PAX, made it feel like I had too much to live up to. Ultimately, there were multiple reasons why the project didn’t quite come together, but I think me being more collected would have been a big difference maker.
One of the biggest things I learned this year was the importance of communication and honesty. Not just with the team, but with yourself. I wasn’t a big fan of our game, and I know for a fact that I wasn’t clear enough when expressing that to the team. Nor was I outspoken enough about the concerns I had with the scope. But more so than that, I should have been more honest with myself. Capstone expects us to put in about a dozen hours or so a weak, but to really meet expectations, artists and programmers especially, have to do around twice that. With all the other classes, projects and jobs we’ve got going on, that’s no small task. But, when you love what you’re working on, it’s very doable. I didn’t love what I was working on. Yet, I told myself, I would still be able to power through, and put in the necessary hours. As the weeks went on, it became more clear, that wasn’t happening, nor was it going to happen. I don’t want to make it an excuse, but I need to be more conscious of the different amounts of effort I’ll put into a project, depending on how I feel about it.
On a more technical note, this experience has definitely helped me get a better grasp on what kind of programmer I want to be, and the kind of work I enjoy. I went into the semester thinking I enjoy gameplay programming. Who wouldn’t? It’s where you get to be directly involved with the player experience, and I love playing games. But as the weeks went on, it just became tedious. I spent too much time tweaking things, and getting instantly visible results isn’t actually that nice when the results suck. I started having fun again when, far too late, I started messing around with tools and background systems. They made me feel powerful and in control, and the whole idea of making the computer do what I want is a big reason I got into programming in the first place. This has only further been backed up by my engines class, where I’ve now committed to a huge, multi-semester project, with some of my friends.
I’ve got a lot more stuff to talk about, like planning, scheduling, more in-depth discussion of scoping and communication, and a whole lot more. But I’ll save that for parts 2 and 3. To conclude about my personal experience and growth, I think what I learned this semester is far more valuable than what I produced. You learn through failure, and I experience a whole lot of that. Being able to mostly answer what kind of programmer I want to be is a huge step, and not at all what I expected.