Categories

A Semester in Review Part One: Scoping Too Big

With my school’s semester coming to a close and my last final exam approaching, I thought that this week, the best thing to write about would be a reflective piece on my first semester in game development, though when it came to actually thinking about what to write down, I realized it may take more than one post to discuss everything in a reasonable word count.

I was invested in game development long before I started studying it at school, and I found that one of my favourite resources became Extra Credits. In so many of their videos, the Extra Credits team stresses how easy it is to scope too big while planning your projects. Armed with this information, I was 100% positive that I would always critically analyze my plans to ensure that none of my projects ever went over scope in the slightest … so I was a bit disappointed in myself when my first project did just that.

Surprisingly, our first project was actually to create a board game, not something digital. I think part of the reason our team went over scope during this first project is that we overestimated ourselves and underestimated the difficulty in fleshing out our board game. Difficulty, in terms of technical skill, was minimal, there was no need to program or bug fix, and our rules weren’t set programmatically but rather by the boundaries created by our board game’s world. By difficulty I refer to how I underestimated the amount of time it would take to create and develop physical assets for our game because unlike a digital one, we needed a physical board, cards and game objects.

Once we had our mechanics fleshed out, we started to add a variety of monsters and weapons by name into our game, and then balanced out all of the health, damage and drop statistics afterwards. Looking back, our issues began to emerge around here. It was a scramble to balance out these statistics while still waiting for our artists to draw the monsters and weapons, place those drawings onto our card templates within Photoshop, and then print out all our assets, especially because we had such big plans for how many monsters and cool weapons we could add.

All of this lead up to a very literal last minute hand in effort. We rushed our game to our instructor minutes before the end of our class, which is when our project was due. In these last few minutes, we were still organizing our cards, monsters, game board and rulebook. We had put way too much on our plate and it was very evident, while I can’t speak for the rest of my team, I know I was feeling the pressure.

Now this story has a relatively happy ending, we didn’t fail (always a plus) and I’m on good terms with all of my previous teammates.

The board game project was one out of three games we were required to develop in our first semester, but it was the only one where we had to design our own rules and mechanics. The other two had us recreating already existing games in a text-based environment.

Perhaps this was intentional, perhaps the theory was that by introducing us to creating our own game design without the added technical challenge, we would learn what not to do while developing a digital game of our own design. In second semester our “big” project will be 4 months long and introduce us to this very concept, using a 2D game engine. Is it possible that this first project was designed specifically to make us aware of these common mistakes early rather than later?

At first, a board game seemed too easy, too simple, and as such we unintentionally began scoping higher and higher as we progressed. My first big takeaway of the semester was this: have a design plan in mind, stick to that design plan, never underestimate the difficulty of your current project, and SCOPE SMALL.