Harrison Short

Online Portfolio

Filtering by Tag: sound design

Plunder Pups ver. 0.2.0. preparation

In the past couple of weeks, work has slightly stalled on Plunder Pups. This was due to getting more shifts at my day-job as well as a bit more time spent socializing... But one of those times was with the QUTGDC, so I guess it counts as game development time, right? According to GitKraken, the following has been done since my last devlog/blog post:

Overview

  • The game now knows how many human players are playing and will set up the HUD, players and necessary cameras
  • Organized and added a number of prefabs for different elements of the game
  • Began working on make a better looking scene with AxeyWork's Free Low Poly Pack (downloaded from the Unity Asset Store)

Prep For Next Release

Unfortunately, due to the smaller amount of work done in the last couple of weeks, a few things may need to be cut from this release. In particular is the game's sound, which I was hoping to make it in at a basic level. In this project I'm hoping to utilize FMOD as it's an industry standard, so the sound is unlikely to be a quick job (which it could be if I implemented it as I did last year in Bees Won't Exist). I had also wanted the menu system to be polished and robust but unfortunately this is proving to be more difficult as I lack both the knowledge and artistic skill for User Interfaces. 

However, on the other hand, with some hard work in the next few days, I should have a new version of the game released, which will include local multiplayer, Xbox controller support and (hopefully) a better environment. For the most part, this is what I wanted to be in this release, so I'm actually somewhat content with putting this out as v.0.2.0. Currently, this is due out this Sunday (02/07/2017).

I am also planning to push back the date of the "final" release of the game, due to a number of reasons, but actually I think it's quite justified! I'll post more about that after the next version of the game is released.

Until next time!

- Harrison Short

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

 

An overdue update!

It's been a while since I've posted here! I had intended to write a new blog post on several occasions, but most of the time I would remember when I was driving, and it seems like 5 seconds later the thought leaves my mind without a helpful reminder set anywhere... Well, I finally remembered by myself!

Though it's been a while since I updated this blog, there's actually not all too much to say on the game development front. I decided to take a much needed break from intense work, instead opting to just... Play some video-games. I hadn't had that liberty for the better part of this year, so it was refreshing to just be able to sit back and relax. I finished Watch Dogs 2, spent a fair bit of time playing Pokemon Sun, and also finished Sleeping Dogs (which was a Games With Gold freebie). I plan to go back and complete as many achievements as possible in WD2 and SD, but I also received the Bioshock Collection for Christmas, so I've been devoting some time to replaying those games (which has been both brilliant and nostalgic to say the least).

Having said all that, I haven't been completely game development free (nor would I want to be!). Wanting to broaden my horizons as a programmer, I've begun taking a Udemy course for learning C++ through the Unreal Engine. It's been fun so far, but my laptop has some issues running Unreal, which means that at this stage I'm unlikely to be working on any Unreal projects until I build my own computer (which is likely quite far off).

I've also had some semi-regular meetings with my capstone project team about the future of Bees Won't Exist. At this current stage, the only thing that is certain is that we will be pushing on with development of the game (as in, adding features people have asked for, fixing various issues, etc.), hopefully for release on a larger platform. This should start in February, so I'm trying to get all the practice programming and time for relaxation in while I can!

On top of this, I've lent some of my time to the QUTGDC (QUT Game Development Club) to help out with their university holidays project. I initially came on wanting to do more programming than anything else, but through both the freeform nature of the project and my own lack of organization, I sort of fell back and worked on some atmos tracks. Going forward, I'm likely going to have to drop off the project to focus on both working my casual job in preparation for taking BWE back into development, as well as continuing that C++ self-teaching. (Note to self: Atmos is pretty hard when most of the nature sound effects usually expected come from objects and entities within the scene!)

So, that's what I've been up to! I'm again off to Melbourne this coming Thursday for Unify Gathering 2017, which is sure to be amazing. I'm so, so hyped to finally see Alexisonfire, not even my closest pals realize!

Harrison Short