Harrison Short

Online Portfolio

Things I learned in the BGIE final year project...

A couple of weeks ago, I was having a conversation with a student just starting the BGIE capstone project. We mainly talked about what to expect in the project, and after I realized that I had a few tips to give from my experience with the units, I thought that a post may be helpful to not only students in the project this year, but also myself as a refresher. So I decided to write this up! It turned out to be a lot longer than I thought it would be, so I hope I haven't waffled on for too long.

This post is being shared on the QUTGDC group page, but feel free to show other students not in that group.

  • Play to your strengths, but don't be afraid to experiment

This first point is probably far more relevant at the current stage of your final year project (as of posting this) than any other stage, but it can be valuable to keep in mind down the line, too. Basically, stick to (and advertise) what you're good at for the most part in this project. If you're a programmer, don't decide all of a sudden that you're also an artist, for example. You want to look enticing as a team member and you want to be able to do this best for your team throughout the year, because time is absolutely limited. 

However, never forget that you're in university, and if there was ever a chance to make mistakes during a big project, it's right now. For instance, if you've dabbled in sound design in the past and find it interesting, but your main discipline is art and animation, you should give sound design a go if the opportunity arises (and you don't already have someone more suited to that role)!

  • Don't leave marketing until last

Throughout Bees Won't Exist, we were constantly pushing deadlines and sneaking things in when we really shouldn't have been. This meant towards the end of the project, while we should have been investing time in marketing the game and getting it in front of players, we were instead frantically trying to implement fixes that we deemed necessary, but may not have actually been. We were at least a week behind during the marketing phase and the game suffered greatly in terms of player numbers because of it.

Not only that but during marketing, we were able to obtain some feedback from players on the Internet, which would have pushed any post-semester development in a more worthwhile direction, as we could see exactly what players were clearly having issues with. In one case, we had a player who gave us an extensive list of issues he found with the game. Had we given more priority to marketing, we would have seen more of this player-developer interaction.

In retrospect, I personally think that the best option is to not only place great value in the allocated marketing phase of the unit, but also to get a head-start on it. You'll most likely gain the most traction in the first few days of creating your social media pages and inviting a bunch of people to like and follow those said pages, but in order to keep attention high, posting periodically about the game throughout development is your best bet... And you can't do that without creating those pages early! (Check out this article about what can happen when you create the right post at the right time)  If I would have to say a period of time to create social media accounts and get the ball rolling, I'd say maybe two or three weeks into your second semester this year.

So, in conclusion, don't leave marketing until last minute! Speaking of things that can't be left to the last minute...

  • Don't let music be an afterthought if your game needs it, and don't EVER let sound become an afterthought

When it comes to including music in your game, this may only be relevant if music is actually completely necessary, and will greatly enhance the experience for your players. For example, a mobile infinite runner is unlikely to need a diverse range of music, as not only will the play sessions be small, but player's are likely to be playing whilst listening to their own music, or without music whatsoever. On the other hand, if your game is going to be a longer with multiple levels, areas, etc., you should definitely be keeping music in mind, even if you're not a sound-minded developer. Going into Bees Won't Exist, I knew that if this Legend of Zelda/Bastion-inspired style of game was going to work, it would require a diverse soundtrack in the vein of those aforementioned games (and not to toot my own horn or anything, but I'm pretty proud of what I managed to accomplish!). 

In terms of sound design, for the love of God, don't leave it all until the last second. At the very least, plan the game's sound throughout implementation of different features in your game, and then add sound when it's possible. Not putting enough effort into sound - either whatsoever, or until the last second - can really make or break how the player feels playing your game. A sword slice or discovering a secret can go from feeling really rewarding, to falling flat without good sound. In addition, it's also quite likely that you won't have a sound designer on your team, which means two main things: 1) you won't realize how long sound design can take, and 2) someone will have to learn sound design or you'll need to bring an outside person in to do your sound, which can be an endeavor in itself.

Remember, sound is important! It adds emotional value to your game! Don't forget it or leave it behind!

(Check out Akash Thakkar's (Hyper Light Drifter) GCAP 2016 talk where he talks about emotional impact using sound, as well as a whole range of other sound-based topics)

  • Don't tell people about your game if you know you can get them to test later on

This may be a little unorthodox and probably hard in practice, but hear me out. If you didn't already know, in semester two you'll be tasked with finding a certain amount of naive testers, who should in theory provide unbiased feedback when playing your game. A naive tester is any tester who doesn't know a thing about your game. As you have to be hitting weekly quotas (with actual data to match!), holding off from telling your close friends and family about the game could make the process a little easier when you get to it.

Furthermore, you'll get better data from your testers when they have no idea what they're in for. Your brother doesn't know that you're making a first person hack-and-slash RPG? Good! See how they adjust to getting sat down and thrown into the experience. Eventually, you'll organize to have naive testers come back as deep playtesters anyway, meaning they'll get more opportunities to play your game before release.

  • Submit to anything

This one is pretty simple. If there are any competitions or showcases that coincide with stable, near-final builds of your game, you should consider submitting your game (assuming you're at all comfortable with how the game is)! We submitted our game on a whim to the GCAP student showcase and got accepted. You never know what might happen! It's also a great marketing opportunity if the game does end up going somewhere. 

  • Always scope down

Just... do it. Never forget to do it. Always be doing it!! 

But more seriously, you'll definitely come to points throughout the project where ideas will snowball and your game concept will grow, and you need to learn to rein all of that in. Always be aware of how big ideas are getting, and always be conscious of your time frame. A good producer should be on top of this, but it shouldn't all be on them. It's a team effort to control the scope of your game, as much as your design lead wants to go bigger and bigger. (😉)

That's all the tips I have for now! If you ever want to have a chat with someone who's been through the process of not only the final year project, but an honestly pretty poorly scoped project that saw each team member consistently putting in 30 hours a week, just message me on Facebook! Hope to play your games in future, probably at a QUTGDC playtesting party!

Harrison Short