Ten Games In A Year: The CalArts Game Makers Post Mortem

A little background info to start, I am a fourth year student of CalArts Character Animation. This past year I started a group on campus for those of us interested in making video games, something that CalArts does not officially do. I decided that, since the workflow of making films is so similar to making video games, we could start up a production of a few games and see how it would go. After a school year’s worth of game-making, and with 10 video game prototypes under our belt, I do hereby declare it a resounding success! So let’s discuss what made that possible.

Management of the Round Table

Call me King Arthur, but I prefer everyone to be on equal footing. No one officially in charge, just a group of like-minded individuals taking on the roles they believe they were best suited to taking on. Project leads stepping up as a necessity, but not treated as higher than their teammates, just being the person responsible for keeping the team moving in a single direction.

The advantage of this system is that everyone is capable of offering up suggestions, and a wide variety of ideas are tossed around. Being a group of people from a college that focuses so heavily on creativity, we were definitively suited towards an environment conducive to creative thinking.

The disadvantage of this system comes in that the team lead ends up carrying the whole project on their shoulders, coordinating everyone’s tasks while doing a large chunk of production work themselves. There simply isn't anyone else for people to report to, so the project lead does it all. And then there's ego. I ran into a couple situations where I tried stepping in where I wasn't wanted because I felt like I was the person running the group. Fortunately, my team was willing to tell me to back off  when I overstepped a boundary. Actually, my team was the fortunately in every way, they were simply amazing, and every time we hit a road block, someone was able to find a way around it.

T-Shapes

Part of the reason that the open management system worked well for our group was the fact that our team was entirely made up of " T-shaped ” employees. Every year at CalArts you can find people working on their own films, their own stage productions, their own music, etc. You can also find people helping those people create their works. Animators make films, but only with the help of sound designers and composers. Musicians perform the pieces composed by their peers. This atmosphere makes CalArts students very knowledgeable about a variety of subjects.

When making our team, I was very much aware of the type of student I had at my fingertips. I knew I could trust people to figure out what tasks they could do, because they'd done them all before. My job, and the job of the other project leads, became simply to ensure that everyone knew what needed to be done next. Not in a micro sense, but just that tasks were listed somewhere that everyone could find.

Strict Goals / Fluid Tasks

Trello was a great task management system for us to make sure everyone had access to a list of what needed to be done, but we also had to keep them interested. I had to keep the interests of busy students who were not getting class credit for showing up to my little meetings every week, and two strategies did me well here.

First, I set strict, short-term goals. I gave us a month on our projects, and set two projects in action at a time. This meant that at any given time, we required no students to take on more than a few weeks’ worth of commitment, and that tasks were available in a wide assortment of difficulties. Each task tended to be only a week’s worth of work, no different from another homework assignment. If a student was busy one week, they could simply pass on a task until they had more free time. Some students were unable to offer help on entire projects at a time, but because no project lasted longer than a month, that tended to be a fairly minor problem.

Second, we split the tasks up into small pieces and denoted those tasks on a Trello board that everyone had access to. For instance, one of our projects needed the entire contents of a fridge to be modeled individually. Rather than assign one artist to create all the assets for an entire refrigerator, we made a list of objects that would make sense in that context (as well as a list of objects that wouldn’t make sense, because the goal of this game was to sort the reasonable from the wacky), and allowed artists to take on as much or as little of that as they felt they were capable of producing. This means that a majority of those objects were created by one or two artists, but it also means that several people were able to contribute small pieces as they found time.

This approach changed a little for different departments. Ours is an art school, so while we were able to distribute art tasks among people as they had time, programming tasks tended to only have one person that could approach them. For these, communication was the key. Asking the programmer what was possible and reasonable kept us moving forward smoothly. Luckily, we happened to recruit some of the most insanely productive and talented programmers one could ever ask for!

Unity

As mentioned, one of our biggest areas that we were lacking was programming. Our school does not have much in the way of programming, just a few classes that cover the basics. Because of this, we used Unity as a crutch. I figured that even if no programmers showed up to our meetings, we would be able to at least make a simple shooter game or something with the basic character controllers in Unity. The projects may not have been particularly interesting if that had happened, but at least we would have been able to make something.

Even with programmers on our side, it was a huge benefit to use the Unity engine. Our coders were able to use the large community that Unity has to supplement their knowledge in any areas that they may have been lacking, and Unity does quite a lot of the setup required to get a game playable quickly, so we were able to set the strict schedules I mentioned. If we had been required to program entire engines to run our games, we would not have ended up with anywhere close to the numbers we did, and they likely would not have been nearly as interesting to play.

What Went Wrong

So we’ve discussed what went right, let’s take a few minutes to look at what went wrong. The major thing that went wrong was communication. Group meetings were being held once a week, but in between those meetings we had no way to speak to each other beyond phone calls or texts. Because of this, it took the first two weeks for our first projects to get rolling at all. So while we should have had 5 weeks total for those projects, we ended up only having 3, maybe 3 and a half. Eventually we adjusted to the workflow, and perhaps this was all inevitable, but it stands as one of the most glaring issues of our year.

Another point, along the same lines, was our inability to work with those who were not on campus. When I started the club, it garnered the attention of many former students who were still in the area and wanted to participate. We found out rather quickly, however, that this was very difficult for us to coordinate. We simply did not have the infrastructure setup to work with students who were unable to attend the regular meetings. We eventually began broadcasting our meetings over Twitch and posting recordings on Youtube. These things, while helpful, simply weren’t enough. Off-site members quickly became frustrated by our uninclusive nature, and their interests waned. This is one of the most unfortunate parts of our year, and one I would like to resolve for the future. E-commuting is a common practice in today’s gaming industry, but my inexperience with leadership and lack of the knowledge of common practices led us to lose out on quite a few interested alums who may have added a new dimension to our team.

The final area of negativity was support from the institution. I tried to reserve a room for us to hold our meetings and was thwarted. I tried to get support to make it worth class credits and was similarly restrained. I tried getting software support for Unity and was given limited support for only a small portion of the year. In fact, by and large the school itself was unable or unwilling to help us in most ways. I was able to get my own department to allow us the use of a room for guests and events, which was great, but that was mostly due to having amore personal relationship with the people involved in those decisions. We ended up kind of a rogue body, taking help where we could get it. We couldn’t get a space reserved, so we penciled ourselves into a supportive teachers’ classroom during off hours. We couldn’t get official support for the software we wanted, so we worked on personal laptops with data stored on Google Drive. We even managed to get guest lecturers to visit campus for free, and without any official seal of approval or whatever else. We didn’t have the support of the administration, so we made it work anyway. Some people even made note that perhaps it was better this way since we could live more freely outside of the system.

The End Results

After all was said and done, we started the year without any of us having made a video game before, and ended the year with 10 to our names. 4 core projects produced on a one-month time frame, 1 48-hour game jam game, 1 personal project of mine that was being worked on throughout the year, and 4 side projects that various team members got together to create in smaller groups.

Replicating Success

So it’s great that my group was successful, but how does that help you, dear reader? Well here’s a rundown of what I would suggest to replicating our success:

1. Be aware of your situation. I was surrounded by artists, but few programmers. Who do you have access to?

2. Do your research. I researched management, but failed to look into e-commuting. What do you need to learn?

3. Be open-minded. I couldn’t get official access to a room, but a teacher was willing to help. How can you make things work outside of the system?

4. Use the right tools. Unity was great for an artist-heavy team, but doesn’t allow the freedom of a custom engine. What tools do you need?

5. And the most important part of the whole ordeal: surround yourself with talented, supportive people. From the project leads, to the designers of every kind involved in production, the people are what made my club a success story. I put out the call, but they carried us forward. Without the incredible team that came together for these projects, without their hard work and dedication to a group that didn’t benefit their grade in any way, I wouldn’t be writing this article. So more than anything else, when looking to successfully create your own game development group; look for great people.