During the first Workshop I class, the professor picked groups randomly, causing us problems from the very start.  Our team, Sitting in the Dark Games (christened as such after a first meeting in someone's very depressingly lit living room), only had one dedicated animator, many more programmers than artists, and the majority-elected producer quickly showed that he was not cut out for the task.  My "assistant producer" position shifted more and more to "co-producer" as the quarter went on, and balancing that with also being programming lead was no easy feat.  The programming team was always on task and reliable, but the artists consistently had problems with missing deadlines due to having trouble and then just giving up rather than seeking help.  It also became my job to organize full-team work sessions, which often turned into all-nighters, just to get everyone into one room and make sure they were working on what they needed to be.  There was a huge problem with motivation and work ethic, which led to about three people trying to do the work of ten by halfway through the quarter.  Workshop I was the most demanding class I've ever taken.

​

The idea for S.P.A.R.K. came out of our very first brainstorming session: asymmetrical gameplay where two robots work together to build and destroy objects in their environment.  Unfortunately, it seemed our professor had a different vision for the game than we did, so we were constantly walking the line between preserving our idea or our grade.  He also had some very specific ideas about level design: rather than just making cool levels, he told us to create a dictionary of "challenges", categorize them by skill type, setpiece, and difficulty, and then mix and match those to create final levels.  The problem with this was that he wanted us to concept out hundreds of these challenges, nearly all of which would end up unused, and to do this while trying to solve the problems with animation and finishing the rest of the game.

​

A heavy emphasis was placed on pitching.  We were required to make weekly "sell presentations", as if we were going before a company and asking for funding.  We had a lot of trouble with this initially, because we were always showing what the game "was", rather than what it "could be".  The professor wanted us to talk more about our half-implemented and out-of-scope ideas than what we had already accomplished, to emphasize our code tools and that unreasonable level design process to convince "investors" that we could do a lot of work for cheap.  In the end, we did what he wanted...only for our Workshop II professor to laugh and tell us to go back to what we had done originally.

​

I didn't enjoy Workshop I because of all the problems I wasn't able to solve, either because of not having the necessary art skills or by not being able to encourage the whole team to take responsibility.  The code I wrote was pretty cool, though; I designed the entire modular Build System.  It starts with small components like gears or batteries, called Buildables.  They can be put in Sockets to open doors or activate other setpieces, or they can be combined with other Buildables into Machines, tools which can be freely moved around in the level to solve more puzzles.  Machines and filled Sockets are both classified as Deconstructables, meaning they can be broken back down into their components.  This reusability is the foundation of our resource management challenges, my personal favorite to design.

​

In the end, I think S.P.A.R.K. is a pretty cool game...it just killed me to make it.  There was a lot of potential, and I was sad to see it be limited by the team working on it.  It was not chosen to continue production in Workshop II, which is unfortunate because I think the extra manpower would have been just what it needed.