Whew, it's been awhile since I've been here for a post! It's a new semester and new course this time: CCC-410, my Capstone course. For those that don't know about it, read the following paragraph. If you do know what it is, feel free to skip ahead!
Most people know that Capstone and a thesis are completing the same goal: assess your mastery of your field. The same goes for my Capstone, with some twists. Game majors at Champlain College complete Capstone projects as a team to create viable games while using industry-level concept and iteration practices. Teams that can't function well enough together are in trouble though; they're at risk of being disbanded come Spring, which is an extension of the surviving Capstone projects through a course called Senior Production (Game Studio III now). We're basically working together and competing to get game ideas from concept to Greenlight status by November.
I'll be posting these Capstone reflections as part of the course requirements. This first reflection focuses on our initial concepting practices, more specifically about how I made compromises with my team regarding refining our list of ideas. The first thing we did was generate a large list of possible ideas, which involved 0 compromise or trade-off decisions because it was a messy spitball where almost everything counted. After that stage, however, we did have to make lots of compromises. For every single concept, I wanted to focus on two criteria: does this idea provide each member the opportunity to do what they want, and does this idea have enough depth to push it past Greenlight. I mainly did this because I really really want everyone on the team to learn more about their respective disciplines and specialties, as that is the most valuable thing we can all get from a course like this. Additionally, I want to get a full, well-rounded experience of taking an idea, iterating, polishing, and maybe even releasing it. I personally have never released a game before, and by the end of this year I would really like to see one of our initial ideas get to that point, hence why "depth" is one of my main criteria.
As we were shaving down our list from 50+ to 9 to 3 ideas, I actually made the decision to ignore scope. It sounds weird and wrong, but why should we discard an idea because it's too big? The point of this course is to prove a concept, and we can prove a big concept with 1 or more small prototypes. That's why a game like Corpse Jockey or Hellracer made it through my cuts. The next consideration I made was, of course, team capability as compared to mine. For example, I have experience in Unreal Engine, and a few of my teammates do as well; however, it isn't enough cumulative experience to warrant using the new tech. This consideration was much more important than scope, in my opinion. If an idea uses tech or mechanics or art that is far too complicated for the time and knowledge that the team has as a whole, then it shouldn't be considered for this class (duh).
I think that my personal criteria for choosing concepts is effective for extracting strong concepts that could carry us through Greenlight, but there are inherent dangers in my methods, namely the scope of the games we've presented. These ideas are going to be really hard to demo with just 1 week to work, but if we are able to pull it off, we'll be left with a fantastic base to jump into Greenlight and maybe even beyond.
Comments