Harrison Short

Online Portfolio

6-in-6 July Retrospective: Swooping Season!

August's game is now out and can be downloaded from here! This was a very ambitious project that had some pitfalls, but it's a pretty complete, albeit short, experience and it really differs from Cyber Sale Simulator. We purposely planned to try to make a game that was vastly different in genre and style to our game for July, and it definitely seems like we've achieved that when the two games are put together side-by-side.

Like last month's retrospective, I'm going to boil my thoughts down to the dot-points below.


  • Began to implement SOLID principles
  • Messed around with Gizmos for the first time
  • We wrote up a Game Design Document for the first time
  • Learned that the structure of a prefab can change the functionality a lot: at one point, the way in which objects were structured inside a prefab was making or breaking the functionality of the code
  • Learned how use butler, itch.io's uploading/updating software
  • Learned about creating and uploading Mac versions of games, including working out a workflow
  • Learned animating through programming (slightly poorly)
  • Learned about the 3D properties of FMOD, which I had never really had to worry about before
  • Learned Cinemachine (to some extent) and more cinematic programming (screen fades, for example)
  • Learned about Facebook/Instagram advertising


  • Broke my rule of not going back to work on previous games, because there was a game breaking bug in Cyber Sale Simulator: should try to really make sure game breaking bugs are not present in future, and then this wouldn't happen
  • Have to work out how to use Unity Hub so that we can maintain Unity versions
  • Halfway through, I ended up reverting to my old standards, in terms of SOLID principles
  • We should have made more art assets, and probably could have, although external factors got in the way of this
  • Cinematic programming seemed very hacked together, in future I would really want to make proper systems (this was the key thing that pushed me out of SOLID programming)
too much screen shake.gif


  • Again, scoping down is necessary
  • Need to further make lists to aid this retrospective process
  • Keep up good work on recording progress and posting to social networks, and also put more effort into this
screenshot 1.png

Swooping Season in many ways improved on the success of Cyber Sale Simulator and further refined the 6-in-6 process. Going forward, many of the successes of SS should be pushed even harder, particularly those processes that can be easily copied, such as posting to social media and advertising. Now that we've done a 2D and 3D game on PC/Mac, in our effort to continuously push into new genres and platforms, we should look into a different platform, different controls or vastly different genres.

Thanks for reading! If you play Swooping Season, please give me your thoughts!

- Harrison Short




        6-in-6 July Retrospective: Cyber Sale Simulator!

        The first game of my 6-in-6 challenge is done and available for free here now! Sam and I are super proud of what we've been able to achieve in one day, and it's a good way to set the tone for the upcoming 5 months. A big thanks to David Upcher for providing the menu atmos and in-game track, without his help I'd be up to my neck in sound work! Check out the gameplay in the video below, and give it a go! 

        This post is going to be a retrospective/post-mortem on the game. As it's going to be a bit of a deep-dive, I'm going to present it more in a dot-point form, so I don't waffle on. In particular I want to highlight what we learned, what we could've improved on the game, and what we'll be improving on the process of 6-in-6.

        Stuff Learned/Experienced in Development:

        • Finally grappled the beast that is Unity UI
        • Have a really good idea of what sorts of systems I can quickly put together
        • Got more experience in cutting corners intelligently: for example, the reset feature of the pause menu was buggy, so instead of fixing this, I just removed the button altogether - this was very much fuelled by a game-jam-like mentality
        • I personally have the ability to bang out a simple MVP rather quickly
        • Applied some new knowledge from recent look into physics systems in Unity
        • Learned how to use PlayerPrefs: albeit in a simple manner, I now know something that I didn't four weeks ago
        • We could each identify what kind of workloads we could take on, as well as what the other member could take on

        Improvements on the Game We Could've/Should've Made: 

        • Left sound too late: my absolute pet hate, I can't believe I allowed myself to do this
        • There were a slew of features that didn't make it in, which we think would have made the game a lot better, these include but are not limited to: "sale over/out of money" screen at the end of game, reviews that pop up when a game is "bought," pause music when the game is paused, particle effects when games were bought or destroyed on the edge of the screen, power ups (extra sales, etc.)
        • There was a large emphasis on non-critical art that we should be very mindful of in future
        • The red border around the outside of the screen should have been a UI element: as it doesn't scale properly when in a resolution other than 16:9 (actually all game elements should scale appropriately, but it's also a time consuming practice)
        • There was a focus on comedic commentary with the game that was truthfully not that present in the game, if we had maybe moved away from that a little bit, we might be personally a bit more satisfied with all elements of the game

        Improvements on the 6-in-6 Process Going Forward:

        • Put less ambition into parts of a game that can take months of development: this is in direct response to putting a lot of stock into the comedic commentary of the game
        • Next time we should really go for an idea that incorporates stuff we haven't done before: some examples could be networking, or augmented reality, or messing around with a new engine
        • May have to downscale the idea in future in terms of game mechanics, especially if we pursue the above point: we made a relatively well polished game this month, so we could make one even better if it was a simpler idea
        • I may have to personally invest an extra day somewhere to work on sound for the project, as programming takes up too much of my time otherwise
        • Should take more screenshots on each development day to show the progress of the game, especially for these retrospectives in future
        • Need to make lists like this about what's going through my mind regarding the project, so that these retrospectives become easier later: this was a bit of activity in wracking my brain about the past four weeks

        Overall, Cyber Sale Simulator is a relatively strong start to our 6-in-6 challenge! It's fully playable, has minimal bugs and looks pretty nice! Moving forward I'm hoping we get more experimental and more polished, but this was a really good way to kick things off. Thanks for reading - and if you play our game, let me know what you think on my Twitter!

        Harrison Short

        I'm back! Here's a brief update on what I'm up to!

        I’ve left this blog very absent as of late... but I’m back now! After spending the back-end of last year working my day job and saving money, I finally got to use that money on my back-to-back trips to Japan and the US. After I returned from overseas in early April, I threw myself back into game dev by starting some rapid prototyping. I came up with some simple game ideas, a couple of which I want to actually go forward with in future, and prototyped them. 

        However, I felt I was missing some of the structure an actual project enforces, with deadlines and completion. I found myself not knowing when to stop rapid prototyping and say “I like this idea, other people find it fun, it’s viable to go forward with.” It also brought up questions like, “should I make this game with monetisation in mind?” All in all, I found myself making things with no clear direction, which for some may be suitable, but for myself, I like to have a clear goal in mind, and that goal is often a completed game. 

        That’s where 6-in-6 comes in. 

        6-in-6 is the half year marathon of making six games in as many months. Originally I got the idea from Louis Van Dyke, who undertook 6-in-6 in the back half of 2017. Louis structured 6-in-6 as an opportunity for rapid prototyping, in a single 10 hour session each month. The result of this exercise was a bunch of really cool and interesting game-based tech, although due to the timeframe the games were fairly buggy. On top of this, this structure lends itself to what I’ve been trying to get away from - a lack of completion. 

        As 6-in-6 isn’t an overtly established process, this gives participants the liberty to structure the undertaking for their convenience. For the next six months, I’ve teamed up with Sam Vidler, a good friend of mine (former QUT Game Development Club President) to make our six games. With programming and sound being taken care of by me, and Sam doing the art, we’re aiming to make more fully-formed games at the end of each month. After outlining our goals and expectations of our 6-in-6, we’ve chosen to structure the endeavour like so:

        Four 8-hour development days each month:

        • Day 1: Design and planning
        • Day 2: Development day #1
        • Day 3: Development day #2
        • Day 4: Development day #3, focusing on polishing and publishing, with no new content added

        We feel that this structure will allow us to create small but polished games that we can take further in future if we so choose, but can also serve as portfolio pieces in the meantime. It also takes after the “One Game A Month” process more closely, which we’ve looked into as we’ve planned the structure of our 6-in-6. 

        In contrast to Louis and his small group, Sam and I don’t work full time, so we have the means to invest more time into each project. To assist us time-wise however, we’ve also reached out to our friend David Upcher, who will be providing one piece of music each month. This way, I can focus on programming and sound design, without having the weight of having to produce a track on my shoulders too. 

        I’m hoping to get a post done after each month’s completion, outlining how each project went, the things we learned, and the things we could have done better (either in terms of development or the 6-in-6 process). In the meantime however, I’ll be posting about each project frequently on my Twitter account

        Thanks for reading! I hope you enjoy following our game dev journey for the next few months.

        Harrison Short 

        Future Plans into 2018

        So I've taken a week off (maybe a little longer...) from doing any work after Plunder Pups was released to just destress, chill out and try to plan out my next moves. I'm not sure what the rest of 2017 really has in store for me, as I'll be trying to work my casual job more in an effort to save for things like my trip to America, a couple of trips to Melbourne (GCAP!) and maybe a new iPhone! However, here's the general gist of what I want to spend my time doing:


        Play some damn games...

        When I'm working intensely on a project, or other necessary work back when I was in university, I get myself into this mindset in which I only work on that thing. Sure, I procrastinate by sitting around on my laptop not actually doing the work, watching YouTube videos or mindlessly increasing my useless knowledge on Wikipedia... But I still don't pull myself out of this workspace. This is probably something I need to work myself out of in future, but it's not as if I don't have any leisure time. Instead, I go out with friends to unwind.

        As such, towards the end of Plunder Pups I didn't touch any games, and I want to start getting back into them, firstly by finishing Zelda: BOTW, and then going onto play games like Silver Grapple, Mass Effect Andromeda and Bayonetta. If I knocked these out quickly, I could move further into my backlog, but I think it's highly unlikely.


        Get back into music production...

        One thing I took away from Plunder Pups was that I neglected sound and music production for almost 6 months. The suite of sounds was lacking and the game didn't feature original music. I want to get back into music production in a big way, really taking the time to teach myself the ins and outs of Ableton that I haven't learned in the past. One of the first pieces I want to aim to make will be a replacement for the music in Plunder Pups. Then I want to work on finding a unique sound, something that may amalgamate my various inspirations, as well as adding my own personal emotive and cultural element to the music. 


        Further my brand...

        I added my branding, Red Chung, to Plunder Pups, but didn't really flesh it out, as it was an afterthought in the final weeks of development. Red Chung is intended to be the branding for my future creative pursuits, whether it's music production, solo game development or possibly art down the road. Red Chung comes from two of my three middle names, so it's something uniquely personal to me, and I've always looked up to those who have a really strong overarching brand that ties all their work together (Odd Future instantly springs to mind).


        Game development...

        Of course, why would I be here without this topic? There are still a few things I want to fix up in Plunder Pups, but in terms of game development, I'm actually more keen to get another project going rather than fix these issues. In the not-too-distance future, I want to take some time to bang out some ideas and then get some quick prototypes going to see what is the most fun and the most viable going forward. I already have a couple of ideas, and I've got a few parameters in mind:

        • must be for mobile - Android currently, iOS down the line
        • must be simple - I want to get the game mostly done in one or two months, with support continuing past this time frame
        • can't be art-heavy - I'm not an artist and I doubt I could coax anyone onto the project as I'm mostly unproven
        • I want it to be financially viable - it doesn't have to make money, but I want to actually properly publish the game to app stores. This might mean that the game needs to be of a standard that people would be willing to pay a dollar for, maybe the game needs to have leeway for microtransactions, or the game needs to have advertisements integrated. Regardless, this is a BIG point, as I can't continue to "gain experience developing" for free.

        While I want to take care of some other other points above first, I'm almost inclined to really get this planning phase out of the way and have something tangible, as it would be good to show things to people at GCAP this year. Not completely necessary, but could work as a good ice breaker and networking opportunity.

        So, that's about my plans for the next few months! Whether that really pans out is another question, but at least I've got some things to keep me occupied into early next year. Thanks for reading!

        - Harrison Short

        Plunder Pups ver. 1.0.0 just came out!

        I just released ver. 1.0.0 of Plunder Pups! It's been a long, long time coming but I'm relieved and satisfied to finally have put the game out into the world in some finished state. While the game is by no means perfect, it's still a game that I've managed to design, program and release by myself all the way through to the end, and as far as I'm concerned, that's nothing to really sneeze at! This devlog is sort of going to be a bit like a post-mortem, but not quite to the extent of which other professional developers actually tend to write up. Instead, it'll probably focus more on myself, my learning and my process. So... Here we go!

        Developed alone through to completion: First and foremost, this is an achievement in itself. From what I know of the industry, one of the best ways to advance an amateur game dev career to simply finish games. Too many developers in my position tend to start projects and then over time, due to a multitude of different reasons, they'll drop the project. Over the development of Plunder Pups, I was always focused on getting to the end of the project, though my time management wasn't the greatest, which leads me to...

        Time Management: I never expected the game to take as long as it did. I've documented it thoroughly on my devlog, but different little hiccups in other parts of my life prevented development time at various points throughout the year, so it took me a few months longer than I would've hoped. According to my version control, my initial commit was made on February 28th, so the overall development time works out to approximately six months, plus some additional time spent writing up the design document. In future, I'll be looking to make smaller games in smaller time frames.   

        Greatly improved my programming skill: Throughout my university career, I was never a programmer. I didn't study the software technology major (which I now regret to some degree) and I didn't really learn much on the side. That was until the end-of-year break in 2016, where I decided that if I really wanted to be an asset to my team, I would need to pick up some skills in a game engine. I knew there was a good chance that we would be using Unity, so I picked that, and went through some of Ben Tristem's Udemy tutorials, which were extremely beneficial for me, and led me to picking up C#. My capstone project team then found that we needed programmers, so I put my hand up to help out. With a great teacher (Rory Dungan), I found myself loving programming. With Plunder Pups, the project really extended my knowledge and saw me taking on issues that Rory would have solved during Bees Won't Exist, while I took care of other features. I feel really confident in my programming of the lower level elements of games now, but still definitely have room for improvement, especially in games physics. 

        Didn't Experiment Much: I've always said that Plunder Pups was a project I undertook to teach myself more programming, gain more game development experience, and contribute to my portfolio so that in future, I can apply to game industry jobs with actual games under my belt. While I just said that Plunder Pups improved my programming skills, I didn't take the time to learn new things things such as shaders and particle effects. The quality of the game definitely suffered as a result, but in hindsight, perhaps the addition of these features would have increased the production time on an already long and financially non-viable game. I would love to use Plunder Pups as a base to learn these skills in future.

        Asset Store Use: As I'm not an artist, I knew that I had to outsource the 3D art for the game. While I was going to ask a few peers if they were interested in making some assets, I found myself perusing the Unity Asset Store one day and found assets available that worked perfectly for Plunder Pups. This saved a lot of time and effort, and while I have heard that using things off the Asset Store can be quite hit or miss for a lot of developers, I was able to really gain an advantage through using it. 

        Not Testing: During Plunder Pups, I was pretty reluctant to show off the game to people. In fact, during the whole development cycle, I only ran one test session with another player, who wasn't naive to the project. Most of the time I would justify this to myself by saying "well, it's a project set up to teach myself programming," but really, a lot of it came down to not thinking the game was very presentable (which should never be an issue as games never are as presentable as they could be during the testing stages), as well as not being confident in the project as a whole. Not only this, but testing the game was pretty hard because it would require setting up proper settings due to the game being multiplayer... But quite frankly, not ever seeing the game being played by 4 players is preeeeetty silly for this kind of game.

        (Also, as a sidenote, don't make a 4 player game when you don't physically have 4 input schemes... Don't know what I was thinking there)

        Sound!: While sound for Plunder Pups was not particularly difficult, I'm glad I managed to bang it out so quickly, especially in middleware that I was not very experienced with. I really wanted to try learning FMOD during this project, so getting a little bit hands on with it was great. Overall however, I think the sound could have been better, especially as I'm an aspiring sound designer. Which brings me to my next point...

        Sound...: The overall suite of sounds is pretty lacking. I wanted to include sounds like dog whines (for when a dog is headbutted), button click sounds and, well... A lot more. I chalk this up to running out of time, and really I broke my cardinal rule of not leaving sound until the last second, so there's nothing to particularly blame but my own time management and issue prioritization. I suppose because I was very focused on programming, sound slipped into the back of my mind. In fact, not even the music is unique to the game, it was lifted from the Bees Won't Exist soundtrack. I think in future I will definitely come back to work on Plunder Pups' sound as an exercise, especially to learn a bit more about FMOD.

        I'm sure in the coming weeks and months, especially as I dive into new projects, I'll probably realize and discover a few more things and take note, but off the top of my head those are my main takeaways from Plunder Pups. I've been taking a bit of a week off to sort of destress from the project - not that I was ever really that stressed about getting Plunder Pups out - and to sort of plan out my next moves. I've already got a few things on my mind of where to go next, and I've cooked up a couple of new game ideas, so I'll probably write up a new post on Sunday.

        Thank you for reading! I hope you enjoy playing Plunder Pups, and don't be afraid to give me some critique on the game.

        - Harrison Short

        So, about the past month...

        So, July turned out to be a far busier month than expected on various fronts, but also wholly unproductive in terms of Plunder Pups progress. Looking back at it, I'm not sure I've experienced a month in my life that has just vanished so quickly like that. I already knew that the first two or so weeks were going to be chock full of non-Plunder Pups-related work, but I wasn't expecting to be knocked on my ass with a sickness from Splendour (though really... how could I not have?). I'm still battling the remnants of a cold, but for the most part I've recovered and shouldn't have any problems getting back to work on my game.

        So, here I am, a month from the release of ver. 0.2.0 and... Not much progress has been made toward the final release. In fact, I didn't touch the project for almost exactly a month. Which makes my situation a little dire! I would've preferred having a bit more time to polish the game, but as it stands, I still want to avoid falling into a situation where I'm working on Plunder Pups forever. Therefore, I'm imposing the final deadline on myself: Sunday 3rd of September, version 1.0.0. will be released, and besides tweaks later on, I'll be done with Plunder Pups. 

        This gives me four full weeks to work on the game, and should be more than enough time to bang out all the priority issues that I've collated. This includes a number of things that I both want to do/fix and also think are worth doing/fixing in the grand scheme of things. As time whittles away, I'll likely have to scrutinize each member of the list to ensure I'm actually doing what's best for the final product. Currently, I've been working on sound, which I've neglected for the longest time now (which is very odd... considering I'm a sound designer...). That's been going less than successful due to my inexperience with FMOD and the complete lack of documentation, but I'll find a way.

        Pictured: The current bane of my existence.

        Pictured: The current bane of my existence.

        There's a lot more I want to write about, like moving forward after Plunder Pups and what I hope to achieve in the next half a year, but truthfully that can wait until later on. Right now it's time to work! (And actually pack some stuff because I'm going to Melbourne for a night... Oops...)

        Until next time!

        - Harrison Short

        Plunder Pups ver. 0.2.0 release!

        Today I released the second version of Plunder Pups! If you've been reading these devlogs, you'll probably know what's made it into this version, however here's a quick rundown of what's been added in the last month:


        • Split-screen local multiplayer has been implemented
        • Controller support has been implemented
        • Setting game settings such as player dogs and game length has been implemented
        • Began FMOD integration, though no sound has been implemented
        • Upgraded the game's overall environment
        • Fixed numerous bugs

        You can download the new version at the game's GameJolt page.

        As before, there's still a ton of bugs that are being logged and fixed everyday, and I'd love any testers to let me know if there's anything that should be fixed/changed! If you're reading this, you definitely have the necessary channels to contact me!

        Moving Forward

        As I've stated in the past, I'm planning for the next release of Plunder Pups to stand as ver. 1.0.0 and be the final major update to the game. While there is a chance that I may add to the game after it's "final" release, this will be mostly in the form of work taking place in an effort for learning. I've always found it hard to learn new skills when there's no base, so Plunder Pups (and any future project) could serve as just that, where I add things based on what I'm trying to learn (for example, online multiplayer). Additionally, I want to set a final release as I don't want to allow myself the "comfort" of leaving projects incomplete.

        Previously I said that the game would see a final release at the end of July/start of August. However, as I've got a ton of prior commitments this month, I've decided to push the release date back two weeks into mid-August. This I feel is justified, as I've been given a huge amount of shifts this month at my day-job (which will go a long way to saving for various things). In addition however, I'm going to be working with the QUTGDC for a week on a mobile game, which should serve to keep me in a game development mindset during that mid-year game jam. On top of that, I'll also be away from my computer for six days at Splendour in the Grass! So that basically automatically eliminates two working weeks (for the most part).

        As this next release will be near final, prioritization of features and bugs is absolutely key here. Sound is at the absolute top of my list when it comes to what I'll be working on next, and I'm also going to look into UI design (graphically, that is) sooner rather than later. I've been compiling a list of bugs as well, so those will likely be worked on in tandem with the major features yet to be added. 

        That's about it for now! Thank you for reading!

        - Harrison Short

        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:


        • 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

        Progress during my time off...

        It's been a productive week as I've had a ton of spare time to work on Plunder Pups! Here's a general overview of what's been done:


        • Finally found my controllers, which allowed me to continue controller implementation.
        • Set-up all controllers to work with the Unity Input Manager.
        • Fixed a bug where the player could start the running animation while the game was counting down.
        • Fixed a bug that did not allow the player to unpause whilst using a mouse and keyboard configuration.
        • Implemented controller support to a satisfying degree. Assigning a control scheme to each player is yet to be implemented.
        • Fixed various issues where menu items were not becoming highlighted.
        • Began FMOD implementation for when sounds are added.
        • Began adding functionality to allow picking the number of human players and setting up the game from there.

        I'm pretty happy with the amount of work that was done while I had a bit of time off from my day job, and I learned a few things along the way! I would say the biggest lesson I learned this past week or so was that once a game has gotten past the prototype stage, controller functionality should be high on the list of priorities. The game now feels all round better to play with the inclusion of controller support, which would have helped with internal testing.

        Reevaluating goals and milestones for releases

        This past week has given me a good idea of how much I'll realistically be able to work on the game until the end-of-June deadline. Realistically, I'm going to have to push back a few things and prioritize other features. I don't believe that the AI states will be complete in 15 days, which is a bummer, but it's one of the less notable things in the game thus far. There are still obviously a lot of bugs happening with the AI, so those will need to be cleaned up before additional states are considered whatsoever.

        On the topic of notable things, the game world is looking a little dull. I want to look into free models or possibly asking peers about small modelling jobs, in particular for the fences and "nests" (which I want to restyle into dog kennels). Additionally, the game is still completely devoid of sound, and while I could probably get away with releasing a new, "stable" build of the game at the end of the month without music, I don't think sound can be omitted.

        These are just a few of the things that I'm currently contending with, so it's going to be a hard race to the finish to complete things to a satisfactory degree by the end of the month. It's likely that I may end up having to cut various features, unfortunately, but that's game development!

        Thanks for reading!

        Harrison Short

        Game jam session and subsequent progress

        Over the past week I've actually made some decent progress on Plunder Pups! That mostly started on Saturday at the aforementioned game jamming session. This turned out to be a lot more casual than first expected, which I liked more than being in a mode of "must work," to be completely honest. As such, while a couple of my friends decided to start a new project (that didn't see too much progress made on anyway, ahahaha), I continued work on my project. 

        Over the past week, since releasing v. 0.1.0 of Plunder Pups, I've done the following:

        • Made the game's RuleSystem a Singleton
        • Added the ability to change the game's time limit
        • Started work on a split-screen system and adapted various systems to work in multiplayer and single-player modes
        • Began adding controller support

        At the moment I have about 7 days off, just as a way to reward myself around my birthday! So I plan to be working on the game in my spare time, as well as trying to finish Zelda and giving myself some time to play Playunknown's Battlegrounds, which I've just bought! I plan to try to finish controller support and begin work on AI behavioural states this week (if I can find my damn wired Xbox 360 controllers...).

        Thanks for reading!

        Harrison Short

        Unnamed project has a name, v.0.1.0 is out now, and more...

        So, last night I quietly released the first "version" of my unnamed solo project. If you're on the GameJolt page for the game, then obviously you know how to find it! If you're reading this on my personal website however, you can check the project out here!

        Finally naming the game

        In the process of uploading the game to GameJolt, I decided I needed to finally attach a name to the project. An earlier poll asking what word people liked placed after "Puppy" found an overwhelming number vote for "Plunder." However, I thought "Puppy Plunder" was a strange name as the player isn't stealing puppies, they're a puppy who steals from other puppies. So, the game has now been named "Plunder Pups!"

        Plunder Pups, ver. 0.1.0

        This release features the following:

        • Basic menu with credits screen and basic quitting functionality
        • Standard Human vs AI vs AI vs AI game
        • Time limit of 2 minutes (will eventually be customizable)
        • Basic AI
        • Majority of game mechanics implemented

        The current state of Plunder Pups is obviously quite basic. There have been a few things I've noticed that need to be changed, ranging from the UI being clearly placeholder, to AI still being somewhat glitchy. On top of this, I've noticed a few things from playing an actual build of the game, rather than the game in Unity. For example, the UI hasn't been scaled to the screen resolution correctly, which is something I've completely overlooked, but which isn't really an issue at the moment. Some smaller issues will be fixed in the near future, and it's likely I'll upload a patch for the game.

        Progress on game jamming

        Tomorrow is going to be my first session of 12 hour game jamming! I'm unsure of whether I'll be working on my own new project, someone else's brand new vision, or an on-going game, but I'm excited to finally be doing some collaborative work this year! Expect a devlog/blog post of some sort soon after!

        Until next time...

        - Harrison Short

        Work, deadlines and possible promises to myself...

        Hello everyone who may be reading this!

        So we're almost at June and this blog has remained mostly neglected this entire time unfortunately! Work (as in, paid work) has mostly been the cause of this, as my job is somewhat physical, leading me to be tired as I come home with little motivation to write blog posts and work on game dev related things. On top of this, I've been trying to actively avoid becoming a hermit, so social activities have stifled creative time as well.

        On a positive note, this year I wanted to mainly do two things: save money for my trip to America next year, and learn more game development-related skills. While the second goal hasn't been overly successful thus far, the increased time working at my casual job has me well on my way to accomplishing that goal, so that keeps me in a good head-space. Not all is lost on learning new skills and developing games however! A few new developments as of late should propel me back into spending time building a portfolio and advancing my career.

        Game Jams

        While development of a fully fledged version of Bees Won't Exist broke down earlier this year, most of the folks I worked with on that game were keen to work together again in some format. What we've come up with is a way to cycle through various ideas and work in a fun, collaborative workspace. This will come in the form of 12 hour game jams. Essentially, we'll come together every couple of weeks to nut out some prototype for a game, building our portfolios and our skills in the process. Perhaps if the idea is good enough, we might pursue it further, but at this point in time, the main point is to, above all else, have fun, and learn new things.

        Project Deadlines

        Throughout this year, I've been working on a small personal project (which I've actually only just realized I haven't talked about ONCE on this blog). The currently unnamed project started at the end of February according the initial commit timestamp, but due to the aforementioned increased casual work, as well as my own programming inexperience, the project has gone on a lot longer than initially anticipated. For fear of this project becoming my own personal Alchemy Punch (ask @WraithDrof and me about that one on Twitter), I've decided to place some more concrete deadlines in place. Currently the game is in an "alpha" state (though if I were to be strict, it's probably a bit more primitive than alpha).

        End of May: An "Alpha" version of the game will be released on GameJolt (keep an eye out), with the "Conservative" AI state completed, mostly placeholder models and layout, a basic menu system, credits (note to self: work out copyright bullshit!!!)

        End of June: "Beta," including local multiplayer, the other AI states, improved models and layout of the level and a completed menu system

        End of July: The final game, with hopefully all polish and features complete

        Failing this, I will probably end up making periodic updates to the game until I'm satisfied with it, but it won't remain my primary project past July. If you're reading this just after I've posted it, I've put up a poll regarding the naming of this game, as before I can put it on GameJolt I figure I should confirm a name for the game. You can check that out here.


        I've been tossing up the idea of properly branding my "studio." While this isn't at the forefront of my current issues, it will probably play a part when I create GameJolt pages, so I'm thinking about it more and more, and it has kept me thinking about my creative pursuits.

        That's really all for now! If you'd like to see gifs of the game, you can take a look at my Twitter media, as it has all been posted there. Thank you for reading!

        - 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



        My trip down to GCAP

        My very short trip to Melbourne for GCAP was an eye-opening and inspiring experience. If you hadn’t already found out, my final year project game, Bees Won’t Exist, was selected as one of six games to be showcased at the GCAP 2016 Student Showcase. Being selected is excitement enough, but as this is my first published game, it was an honour to be in front of so many industry eyes as early into my game development career as this.

        I flew down the morning of the 31st (missing GCAP Loading, an event catered to students, which I now sort of regret) with my teammates Rory Dungan and David Upcher, and we met up in the CBD with Dylan Ford before heading to our accommodation. Upon getting settled, we discovered that Rory’s beautiful Dell monitor was not able to weather the flight down from Brisbane, and had cracked, not only damaging the screen, but also causing the display to glitch out.

        After a quick call to a computer rental shop that told us it was too late for us to rent a monitor, Dylan optimistically decided to send a tweet out into the world hoping to find someone local that might have a monitor to use before we headed out to try and find a store that could sell us a new monitor – and miraculously we got a response, almost immediately! Not only was it an answer to our prayers, but it came from within Melbourne’s famous Arcade, from Tin Man Studios.

        After a quick lunch, we headed down to The Arcade (a collaborative workspace in Melbourne with an impressive host of game dev studios) and met up with Neil Rennison who had replied to Dylan’s tweet. A bit of small talk lead to a longer conversation, and that lead to meeting a few more Tin Man devs, and then afterwards, we managed to score a bit of a tour through The Arcade. I’m not sure how open people are in the building, but I’ll consider the whole experience very unique. I could probably write a whole blog post on this tour and my thoughts, but maybe that’s for another day.

        After saying our thank yous and goodbyes (or more, “see you tomorrow’s”) to the various people in The Arcade, we returned to the apartment and prepared for a networking event at a bar beneath Federation Square. As someone that does have trouble speaking to people, I remained a little subdued at this event. As much as I want to get myself out there, it’s hard for me to approach people, and it’s just something that I’m going to have to get used to and get over. Despite my reservations, I did meet a few people that I’d love to stay in contact with, so the event was not a loss.


        We returned to the apartment and I attempted to get as much sleep as possible on the uncomfortable AirBNB bed.


        Trekking a short way to the Melbourne Convention and Exhibition Centre with computer and monitor in hands, we made our way to the location of GCAP. Upon arriving, we were directed to the area where the Student Showcase would be held, and to our surprise, the student games were the only games on show. We mostly went into GCAP blind and had no idea how it was set up, so this was a very welcome surprise as it meant that anyone who was itching to play a game of some sort was directed to our games.

        The response to our game was overwhelmingly positive and we also received a lot of feedback on how we could improve and fix certain aspects of the game. While we had many people from the networking event the previous night come around and play, we also had a heap of people who we hadn’t met prior to GCAP play the game, which was another good networking opportunity as people came by constantly throughout the day.

        Another great experience was meeting the other students who were presenting their games. In particular, I had a great time talking to Jamie Rollo, who’s been working on his stellar title Silver Grapple for about 4 years now (almost entirely on his own!), the Team Armadillo folks working on Baroviet and Brad Francis, who impressively produced everything for his short game A New Life for Jerry. I actually helped out Brad by offering my laptop for him to use for the day, as the laptop he was using to showcase unfortunately died during set up.

        Besides showing off our game in front of plenty of folks in the games industry, and meeting so many friendly people, the other great benefit of being at GCAP was the talks. I managed to see all the talks I wanted to see. The first of these was one titled “Let’s Make Unity Great Again.” This was a pretty good talk as I identified with a lot of issues that speaker Kieran Lord (of Cratesmith Games Assembly) raised, but I was also a little too inexperienced a coder to understand a lot of the content of his talk.

        Moving on, I next attended the “Future of Game Audio: So Bright, It Hz” panel with some immensely talented and storied game audio experts. This was a talk I was eagerly anticipating, and I found the advice from the likes of Mick Gordon, Sally-Anne Kellaway, Jeff Van Dyke and Jacek Tuschewski. In particular, I became almost enamoured by the way Mick Gordon spoke – it was inspiring to see someone so enthusiastic about not only what he does, but what the people around him do.

        Initially, my next talk was going to be one on mental health when working in the games industry, but I learned that Mick Gordon would be doing another (unrecorded) talk, so I decided to head over and attend this one instead. Again, this was another great talk that inspired me in various different ways. In particular, I loved hearing about Mick’s process as to how he comes up with not only music, but the true feeling and weight behind each track. It seems like every track that he composes genuinely has an entire thought process behind it.

        To cap off the day, I went to Akash Thakkar’s talk about the sound work he did for Hyper Light Drifter – which ironically I have not yet played. Akash’s talk was probably the most entertaining of the day and it really succeeded in not only making me want to play Hyper Light Drifter but also just do some sound designing for the hell of it! Sound design is something to appeals to me due to how fun I find it, but I think in the last year, because I’ve been constantly under the pump, I sort of forgot that. After the talk, I spoke to Akash briefly, saying that I’ll follow his advice of emailing him, as he loves to help new sound designers and composers (note to self: I should probably get on that…).

        Throughout my university tenure, I’ve always had moments of doom and gloom, wondering “what am I doing, this isn’t going to lead to anything, this is crazy, etc.” but after experiencing GCAP and how the industry truly is, those worries for the most part have left my mind. Having this experience so close to graduation was almost cathartic in a way, as if it was all meant to happen and I’m moving in the right direction. There’s always uncertainty in the industry and in everyone’s career’s, but I couldn’t be happier and more enthusiastic about where I am, how I got here and where I’m going.

        Harrison Short

        First Blog Post!

        Hey there! Welcome to my blog!

        So, it’s been pretty long overdue but I’ve finally put together my personal website. The main purpose of this website is to be an online portfolio that I can point peers, idols and potential employers to in the future. However, I want to run a development blog here as well, as I’ve always found that it can be quite useful to document thoughts and progress on projects.

        As you can probably tell from the various parts of my website, I’m a game developer with a keen interest in sound design and music composition. In 2016 I also improved my previously basic programming skills, so I’m fairly proficient with that side of game development now, and I’m pretty good at sound implementation (which I think goes a long way to being a full package indie sound developer), though I’m certainly looking to improve my skills at all times. So basically, expect to see programming and a lot of sound posts on here!

        That’s about it actually! I’m currently writing this on the plane trip back from Game Connect Asia Pacific (GCAP), but I plan to write up a bit of a separate blog post about my exciting experience there. (Well actually, I’m posting this quite a bit after the fact… It’s been a busy week…)

        Thank you for reading!

        - Harrison Short