Hook is the Hook - Dev Blog #1

What is this? Well Hook is the Hook, is the name of my final project for university. The team consists of me and another fellow game designer. At the moment, the project is halfway through development... well kinda. For uni, it's spread along the last two trimesters. Trimester one, is the development phase. Where we design, prototype and test the game to sort of flush out and get a greater understanding of what it is we're making. Then trimester two, is the production phase. This is where we start from scratch with what we now know, and well... create the game.

As of writing this first dev blog, I am in my first week of holidays, just finishing up on the development phase, and preparing for the production of the final game.

Okay... but what is the game? Our elevator pitch is this:

Hook is the Hook, is a sandbox arena brawler, where you use your grappling hook to take out enemies in stylish and unique ways for the audience.

Set in an alternate-history gladiator setting, you are thrown into various different arenas, with only your grappling hook (reasons why and story are still in the works). There will be waves of enemies and it's up to you to kill those enemies. You can grapple them, throw them into traps, throw objects like crates or rocks at them, etc. Yet your focus should be on the audience's excitement. You are there to impress a crowd. So when killing the enemies, you need to do so in both stylish and unique ways. If you grab an enemy mid air and throw them down into a spike pit, that's pretty cool. Yet if you keep doing the same thing with every enemy, then the crowd's gonna get kinda bored.

Before I go on, I need to explain that this blog is going to be mainly focused on what the game is. If you already know about the game, then this stuff isn't really going to be new.

The core mechanic of the game, or the hook, is the player's grappling hook. Like I mentioned above, they use this to defeat their enemies. Also, they can use it to move around and even do both at the same time if they want.

Although the GIFs to the left are quite old, they do represent the mechanic well.

Now let's look at some of the traps in the game. A few of them were implemented in the prototype, yet there are still quite a number that are in the design phase.

The fire trap. A four way flamethrower, which lights up both enemies and the player when they get in range.

On the left is a spinning blade. This will of course chop things that touch the blades. We're still deciding if we want to implement decapitation for enemies that get cut. On the right is the lion trap. If enemies get too close to the door, it will open up and a lion will pull them in. Not sure if we're going to have it so the lion can run around and cause chaos... but that would be cool.

These are two traps we're planning on adding in. Something we want to focus on with a number of traps, is player interaction. Have them control the function. On the left is a large spike wall that the player can pull down with their grappling hook, squashing any enemies under it. Then on the right is a large mirror that will focus the sun into a beam and burn any enemies that get in the 5m or so range. The player will be able to grapple onto it and rotate it around.

Okay, now enemies. At the moment we have four in mind. Each having their own approach to the player, means of attack and ideal ways the player can defeat them.

• Warrior: The most basic and common enemy found in the game. This is your average fighter with a sword, who will charge towards the player in an attempt to chop them up.
• Archer: A ranged enemy, who can shoot arrows at the player. They will try to maintain their distance.
• Heavy: The Warrior but with a shield. The player cannot grapple the shield and if they get too close, they will be barged and pushed backwards.
• Bomber: A ranged enemy who throws bombs. Right now in testing, this guy just seems to blow up all his friends when trying to get the player. So that will need to be tweaked.

So these enemies will be introduced over the course of the game, with each level having a unique combination of them. Oh that's right, I need to talk about the structure of levels.

At the moment, there are 10 levels. Each level has a unique set up of: platforms, traps, physics objects and enemies. New ones of each will be introduced and added in as the levels progress. For the player to pass a level, they need to meet the minimum audience excitement. I mentioned it briefly above, but you gain it by killing enemies in unique and stylish ways. If you do an interesting combo using multiple elements, that kill will reward you more audience excitement. Yet if you keep doing the same thing over and over again, you will only get around 20% of the original score. This is to deter a master strategy, and encourage exploration and experimentation.

Thanks for reading. Right now we're on holidays, so not much is going to be done. Yet when uni starts back up, I'll try and release one of these every week or so. Also, if you're interested in the development process, I've written a post mortem for the project so far.

Post Mortem - Hook is the Hook (Development)

Note: This project is only half way through development. There are two phases: development and production. Development is the design and prototyping phase, while production is producing the game to launch. This post mortem is for the development half of the project.

This trimester we designed and built a prototype for Hook is the Hook. Overall, the process went well. We achieved most of our objectives and the multiple playtests helped form the game into what it is now. Yet there were aspects of the development that we lacked in, or which gave us problems. The following post mortem will go over these issues, as well as what I think we done right.

Code Structure

Going into a large project like this, structuring the code so that it is efficient, expansive and integratable is very important. Many of my projects in the past have had no pre-defined code structure, which ends up causing the code base to get confusing, un-efficient and not that expandable. This is what we were doing with the prototype. We went in, writing code on the spot for what we needed at the time. There was no predefined structure or plan for what we were going to do. Even with only around a dozen scripts and two months of development, the code started to feel a bit overwhelming. It was evident that if we continued with the process of just writing what we need as we go, then many problems will come our way. If not now, then definitely in the future.

This of course happened due to our approach. In terms of code, we had a rough idea of what we needed to complete for the prototype, yet never had it planned out. Since the game is very sandbox focused, we’re giving the player a bunch of toys that all need to interact with one another - so using events is necessary. At the time of making the prototype, I only ever added in events when the code required it. Most notably, the grappling hook script. At the moment there are seven events running the code. These were added in over the course of the trimester rather than at the beginning, causing the script to be inefficient and confusing to look at. Also with no overall codebase structure, we didn’t implement any inheritance based classes. Which in a game like this with various types of enemies, traps and other objects, is something we need.

I’m already working on part of a solution for this problem. A tech spec. Laying out all the events we will need and data classes for those events. Along with this; the classes we will be creating, how they interact with others and what they will be inheriting, etc. This is and will be in future weeks, done by writing documentation, utilising mind maps and even perhaps drawing diagrams to illustrate the overall structure and visualise it easier. In doing it this way, we will have a solid understanding of what needs to be made and can even produce estimates of time and weighted importance for different parts. It won't be us just going into an empty project, making a player controller, grapple script, etc as we need it and ignoring all future problems.

Iteration

One thing I believe we done quite well, was iterating upon our design to make it much better than it originally was. At first, we had the idea for a metroidvania-collectathon game, similar to that of Banjo-Kazooie and the like. Upon pitching it though, we found that the scope was too large and most importantly - the game had no hook. What made it different from the inspiration? Not much really, apart from some mechanical changes and the level design. This prompted us to find a new game, with a hook this time. We landed on the keywords of “grappling hook” and “action”. Bouncing ideas between the two of us, we finally came to an action based, sandbox grapple hook brawler. From what we could find, there wasn’t anything similar to it and most importantly, it had a hook - literally.

Prompting us to find this new game was of course, the search for a core mechanic. Our original idea of a metroidvania-collectathon grew from us wanting to recreate an existing game, mixed in with some other elements. This caused the game to not really have an identity of its own, and just be labelled as “Banjo-Kazooie but shit”, as evident from the first pitch. We weren’t designing a core mechanic, we were designing around a core mechanic. From there, we scrapped the idea and designed a new game. Hook is the Hook, grew from finding a core mechanic and building outwards from there. We had a mind map filled with different game mechanics and genres, connecting to bubbles detailing how they could be used. These then helped us pin down the idea of “grappling hook”. From there, we thought of how this could be implemented. Through Discord, we iterated upon it, how it can interact with the environment, enemies, other objects, etc. The core design of the game was what we worked on first, not what we wanted it to look like, or what we wanted it to be similar to. Really the only thing we compared it to in those early days, was Spiderman - and that was just the concept of swinging and moving smoothly through the air. We only started to think of a theme and structure once the idea of a grappling hook was an agreeable core mechanic between the two of us.

This way of finding a hook and building off from it is something that I will definitely be using in the future. First, creating a mind map and filling it with all different game mechanics and genres that come to mind. Different systems from other games like: gravity manipulation, deck building or reverse tower defense. These can then be combined, torn apart and compared to one another to create a mechanic that is both expandable and unique. Normally with a grappling hook mechanic in games, it’s used only for traversal. In Hook is the Hook, it’s used for both movement and combat. Really, it’s the player’s only form of interaction with the world.

Marketing

Marketing is an aspect of this trimester which we pretty much done none of. We do have a Twitter account, yet the handle is of our initial name for the game (Grapple Gladiator), not Hook is the Hook. Originally, we planned to use the Twitter account to post updates on what’s been added, changed and just interesting GIFs that we believe could build up an audience. As after all, we’re building the game around the idea of these “cool moments” to share with friends and the internet. Yet none of that happened. We also had ideas for a potential YouTube channel, to showcase video updates and trailers for the game. This too fell flat.

The primary reason why I believe the marketing failed, was due to the lack of a marketing plan. We knew what we wanted to do, yet never had the push or foundation for doing so. We created a Twitter account, yet what do we post? And when? We were working on the project and it never came to our minds to share what we were doing on there. Really, it just became a thing we ticked off as having without putting much effort to maintain. Also the fact that we were just prototyping the game and not really having a direct goal of releasing anytime soon. I remember myself always thinking “oh, we’ll start marketing next trimester when we’re doing this for real”. Yet the main purpose of the Twitter account was to in-fact show the process from nothing to release.

In both next trimester and for future projects, a marketing plan will need to be made. A layout for what accounts will be made and the purpose for them. What sort of information are we going to share? In what format? Every week? Twice a week? It will outline a specific schedule for releasing content which like a work calendar, will hopefully encourage us to do it more. We can anticipate when we’re going to be releasing a GIF of gameplay, so we have it ready for the day and can share it on all the platforms we need to. For next trimester, I intend to have the following social media platforms: a Twitter account, to share GIFs of new features and interesting things that happen in the game. A YouTube channel to post weekly or monthly dev logs which will go over changes and additions to the game. Finally, a Reddit account, which can share posts from the Twitter and YouTube accounts to various different game dev related subreddits. This is an optimistic goal, which hopefully a marketing plan will help encourage us to achieve.