Trials and Tribulations of “Bit Heroes Connect”

As my capstone project nears a close, I want to look back at everything that went wrong with the project as a kind of postmortem. I’ve learned a lot, hurt a lot, and lived a lot in these recent 7 months and want to share things that I will be carrying with me on future projects.

What Went Wrong

Working Alone

I began my capstone project alone (as my partner took an opportunity between years) and it had a serious negative affect on my motivation. The primary problem was that I had no team to consult with. This lead to a lot of workshops being void of its utility. It sucks when you’re told to “get into your teams and discuss X” because you can’t. It’s annoying when you’re constantly reminded that you have to work on your own to get by. By the time I hit the Ontario colleges’ strike in mid-October I was regularly late and burnt out. It was a bit of a blessing as I took that time to focus on my own projects, making the capstone project more interesting and seen with a fresh pair of eyes when I began work again 2 weeks later.

Perhaps the thing that was most insightful was that when I did end up getting partners to help on the project, I immediately had better designs quicker as I was talking them out. It seems strange, but the presence of available people will naturally bring out design questions and problems, making them more apparent.

Thinking the Game Matters

Because in the end it doesn’t. As a student, it’s hard to believe that we would slave for 8 months and not have a game at the end. Isn’t it the point?

As a question for any student wondering why, ask yourself this: is the employer going to hire you because you made a game or because you are experienced at making games? Anyone can make a game. Anyone can learn to make a game as we all have. Not everyone is willing to grind for 8 months to make a game.

As another way to illustrate this, what is more important below? The screenshots of the game, or the context in which I can show it being played?

Employers aren’t buying your game, they’re hiring someone who understands the process of making games. This 8 month endeavor is truly to promote yourself as an individual capable of living the life of a game designer and not as a final test to prove you can produce a game. Capturing the progress of this experience is much more valuable to not only yourself but employers.

Debugging

This is more technical but hugely invaluable. As a primer, our game has network functionality and multiple devices at play, including 2 separate builds of the game (one for server and another for client). This makes it quite difficult to debug as the main infrastructure for that is handled by the network.

I had not considered how I would debug these network messages nor how to poke, prod, or verify the data. This later cascaded into tremendous frustration and confusion as both builds needed to be synced, on a specific WiFi channel, and could not be run in-editor meaning tons of time-consuming builds had to be made. I had many moments that resulted in something like this:

It was ugly and painful. However, literally this Friday I was fed up with the circumstances I was developing in and, with very little effort, found a quick and easy way to test server messages from within the editor on the client side.

Had I taken about 1 hour if not less I could have prepared the groundwork for rapid iteration for my entire project 5 months ago. In hindsight, I probably lost close to 50-70 hours of work because of it, if not more (and inflicted by an immeasurable amount of stress).

It’s strange, too, that I spend a lot of time working on making my code work in circumstances it should not be in to prevent crashes yet had not considered all of the ways I can set up my code so that debugging is a breeze. I recommend making a contingency plan and looking into ways to debug your code as it will greatly increase quality of life and mitigate stress.

Don't Fix What Ain't Broke

There is always the temptation to improve what you have already. In one such case, I thought I could improve my IBinarySerializable interface, something I use in my reverse-engineering projects as a way to serialize and deserialize by hand. Since the networking requires byte arrays, I thought this an opportune time to improve it.

Where it went wrong was in testing. I changed the format of the implementation thinking it would streamline the process and immediately ran with it. It quickly backfired but by that point rewriting seemed like a pain so I pushed on. 4 months later, I still use this asinine system.

Thus, I provide this advice: do not change what works fine for your needs if you don’t need to. When you do decide to improve it, verify how it feels and how you need to think about it. The last thing you want is 10 hours down the drain because you forgot that your new system requires an arbitrary constrain due to a fundamental design flaw.

What Felt Wrong Was Right

I wanted to write a bit about what went right but due to constraints I can only provide this one tidbit. What may feel wrong for you or the project may in fact be the right thing to do. Gut feeling can only get you so far with limited experience.

This project is experimental in nature, using some cutting edge technology for a non-traditional purpose. It was not my original idea or direction but that of one of my mentors. It was hard to come to terms with at times, but following the advice of your mentors is incredibly fruitful.

I could never have though that making a serious game for police targeting youths 8-12 would lead me to anything. I could not be further from the truth. Looking back I can now see that this project not only distinguished me from the crowd, but it has lead to partnerships with the York Regional Police, Hewlett-Packard, and a host of up-and-coming AR business in the area. Many more opportunities have say “been there, done that.” It may not be what or where I see myself in 10 years, but I can always work my way back if I wish. As one of my mentors says, "you can make regular games once you're in the industry."