[University of Central Florida graduate Christopher Darin looks back at Scarfell, a student project with a driven and passionate team, but also a project that saw its fair share of mishaps and challenges along the way.]
On pitch day we were all a collective ball of nerves. At the University of Central Florida's Florida Interactive Entertainment Academy, pitch day didn't just decide which games would be selected to be developed -- it also decided which team we were put on. The pitches ranged heavily, and all had significant merits, but in the end it was a popular vote that would decide which games went through. After making us wait a suitably frustrating length of time, the professors gave us the results and I found out I was on Scarfell.
Scarfell was a game of opposing forces, inside and out. From the initial pitch all that was clearly understood was its basic premise: all light had been snuffed out from the world save for a torch held by the player, but light could be restored if that torch was brought to a distant lighthouse. Beyond that premise things got hazy. The pitch mentioned magic, an ancient war, and some theoretical mechanics involving staying in the light -- but none of those concepts congealed quite the same in people's heads. Although greenlit by a popular vote, everyone voted for their own interpretations of Scarfell -- interpretations that varied as much as the day's pitches.
Still, that fact didn't dampen the newly forged team of 11 students' excitement. We had a lot of work ahead of us (starting with agreeing on what the game was) but we could all feel that there was something really exciting at the game's core. Something difficult to describe with words, yet easily connected with -- evidenced by the fact that we all had.
With only a dim idea of what we were making, we stepped bravely into the darkness.
What Went Right
1. Finding Scarfell
Everyone got something different out of the pitch. Some interpreted it as a fantasy-driven tale of supernatural elements and magic. Others saw it as an exploratory adventure more akin to Mist. Even a few derived something abstract and indie. Everyone had an idea, but none of those ideas could answer even the basic questions. What was the core mechanic? Where's the soul? "It's dark" just doesn't cut it. We were itching to draft concepts; start rolling models and features out but we needed to find Scarfell.
As a project lead this was my first experience denying the democracy, which is difficult to do when surrounded by peers you respect. The team was willing to trust me on it though, and in turn I trusted that with their efforts we'd find our answers.
Artists began drafting fast concepts with mostly silhouettes -- focusing on colors, shapes, and feeling. We explored our options and littered a wall with these images. As a team we discussed various ideas for our protagonist -- always asking ourselves "Why?" and "What will this mean in our game?" We were all on the same page on the importance of having an underlying consistency, a thesis. We didn't think of it as spending a lot of time to get it right; we spent a lot of time to get it wrong: respecting every dead end as another part of the process, and even iterating on our process the same way we iterated on the product.
As we started identifying the things that fit our game the most, we needed a way to solidify it - so we made a mix CD. The CD was made with the premise: what would the game sound like? When we listened to it, we could "feel" Scarfell -- even though we were still finding the words. One song in particular became practically an anthem - hummed absentmindedly, listened to on repeat as we worked - it was the thing we connected on first. We all knew that if what we were working on fit the song. It fit Scarfell. It became our center.
2. Solving Questions Early
We knew there was plenty of work we could get done while trying to craft a vision. Work that would save us trouble later, and keep the game moving while we gave ourselves adequate time for pre-production.
Programmers from our team and the other two Vision Engine teams collaborated on a central base project, exploring all the inevitables and finding solutions to questions we knew we'd have to answer. As an entire cohort we quickly had models animating, input being taken, and various tech samples of systems like particles, shading and lighting.
The designers split into two parts. The two leads (project and design) began working out various prototypes, all with specific goals. One was made in Blender to demonstrate navigating a dark environment with a torch using various styles of light. Another, also from Blender, had cones which would stalk you but always avoid light -- and you could nudge the light sources around. The last was 2D made in XNA, acting as a test bed for exploring other light mechanics and pacing.
The two other designers explored the toolset that came with the Vision Engine. One focused on level design and the other on scripting. They quickly set up example scenes showing off functionality we didn't know we needed yet, and became the go-to people when everyone else had to start learning the engine and its tools. This saved us a lot of time, and let us "have our cake and eat it too" while working out the details.
