If you’re a frequent reader, then by now you probably have a pretty decent idea of what working on a game project entails. You know how to select your team, how to budget your project, and of course, how to market your game. But what would happen if you were only given five weeks to develop that game? This is what was asked of me in a Software Development class I recently took. The entire class was sectioned off into teams of five, given a couple of C++ frameworks, and told to come back in five weeks with a finished project. With time as a constraint, I learned a couple of important lessons.

 

You Live and Die By Your Scope

Before starting the project, our professor asked us a question, “How much would you charge if someone asked you to clean every single window in the city?” The initial answers varied wildly, from ten thousand, to ten million. Our professor bid us to consider just how long this endeavor would take, and reminded us that we would have to use part of this money for our daily expenses, bills, food, and transportation, thus taking away from our final profit. On top of that, students started coming up with questions and realizations- “Do we have to clean windows inside of buildings too?” “Do we have to clean car windows?” “Do we have to clean all reflective surfaces?”

While the scope of the window project would be large, almost every student realized that it would be more work and more complex than they could even imagine. This thought game was played so that we could get an understanding of how scope projection works. It was an exercise that would only become all too relevant soon.

 

Organization is More Important Than You Think

It’s easy to break the game development process off into several self-contained pieces- to assign people to work on art, or programming, or sound. The catch in our project however, was that in addition to these elements, everyone was also required to produce 200 lines of original code. Now we had to create a game small enough to be made in five weeks, but also intricate enough to have five separate programmers writing unique functions for it. As development continued, we realized that sometimes it is harder than it seems to make sure that everyone has a task they can complete.

After some initial confusion, we were able to figure out the functions our game would require, and then split them between ourselves. Despite this, we failed to consider how the code would be reconciled when done. We had a github repository and knew how to use it, but we didn’t discuss or look at each other’s code until everyone was done- the result was disastrous.

Our code retained a consistent convention and was well commented, but the ways in which we each implemented our functions ended up being drastically at odds. Each function was elegant, but each function was written to be implemented with their author’s own idea of what our main framework would look like.

sketches1

 

Your Requirements WILL Change

Eventually we were reaching the end of our project, having gotten past the initial hurdles of scope projection and team coordination. Everyone figured out what they were supposed to write, how it would be implemented, and when it was due. Everything was looking on the up and up.

Then our professor made a small change in the assignment, each github repo was to be a maximum of four megabytes in size. Our design utilized many textures and sound files, making it aesthetically one of the better projects in the class. However, these resources required space, and while it was still an incredibly lightweight project, it was well over the four megabytes required by the professor. What’s more is that even if we scaled down the quality on all of our images and audio, the project would still be sitting above four megabytes. We needed a new design.

We were able to get around this requirement finding ways to reduce the number of resources used. Instead of having each map render dynamically, we created pre-baked maps. Much of the art and sound design was also changed to a reflect a much more retro and minimalist approach, lowering the amount of graphical fidelity required by our earlier photo-realistic look. Similar changes might happen to your game, and you will need to be able to come up with your own creative answers.

 

Conclusion

It’s been a long and unexpectedly challenging road, but the lessons I have learned have been priceless. Hopefully by sharing this experience, you might be able to benefit from the very same lessons. Get practice with scope projection by doing constant thought exercises, don’t underestimate the importance of team management, and most of all- prepare for the absolute worst. Five weeks might seem short, but even two years can end up passing in a flash.

 

Please be sure to share this article if you enjoyed the read!

————————————————————————————————————

         Do you develop video games?

               Looking to get your indie game viral?

                     Click Here to find out how Black Shell Media can help!

————————————————————————————————————