next »

[arvidsson]

HAKE IS CURRENTLY ON HOLD INDEFINITELY

hake is a 2d action platformer with procedurally generated levels and challenging gameplay where the player must master the grappling hook and shield in order to overcome obstacles and conquer foes

UPDATES

• Update 1: Introduction
• Update 2: The Grappling Hook
• Update 3: Prototype 1 done!
• Update 4: Level Generation using templates
• Update 5: Extrude Tool
• Update 6: Behavior Trees
• Update 7: Current Status
• Update 8: The Scrap Machine

HAKE IS CURRENTLY ON HOLD INDEFINITELY

[arvidsson]

Update 1: Introduction

We are two guys from Sweden who have been developing this game in our spare time for about two months. We have been talking about creating a game for more than two years now, and finally gotten far enough that the idea of finishing a game doesn’t seem as far fetched as it was two years ago (a combination of using the right tools and having realistic expectations was probably the most important ingredients for this to happen).

We have always loved the grappling hook game mechanic in platformers and wanted to combine this with procedurally generated levels making for, at least theoretically, endless replayability; and with that the idea for hake was born. We have more interesting game mechanics to introduce, evaluate and explore, but we want to keep the game fairly minimalistic. Fun and challenging gameplay is a given of course, but especially we strive to give the player the rewarding experience of mastering the “tactical agility” that is essential in order to beat the game. Not only must it be important to deftly navigate the enviroment but also how to tackle all the different situations that might occur. If we get it right and manage to achieve our vision of the game, all the puzzle pieces should allow for emergent gameplay where the player is rewarded for using imagination when it comes to tactical choices.

We are using Unity to develop this game, and pyxeledit and aseprite for creating the pixel art. We don’t have much experience in creating pixel art, so the graphics will most certainly change a lot during development (either from us getting better at it, or from hiring someone else to do it).

[CyberRascal]

Update 2: The Grappling Hook

When we started with the earliest prototype of hake we had two core mechanics we knew we wanted to include: the shield and the grappling hook. It offers a satisfying and agile way to navigate the game world, and combined with other game elements allows for a (hopefully!) varied game style with multiple approaches to obstacles and multiple tactical solutions to combat. As a bonus, our randomly generated levels can get away with certain sets of map chunks that would not be traversible without the hook.

Simple vector approximation

First starting out, we had no idea how to make this sort of thing in Unity. As usual, we started with google but found mostly some stuff using Configurable Joint in Unity, but if I remember correctly we found that it didn’t really match our needs (we probably wanted something simpler).

At that point some of the math from school started to slowly ooze into my mind, and we started prototyping using a simple vector approximation of the motion. Basically, we raycast and store the grappling hook anchor point, and in each frame use the perpendicular vector to the vector from the player position to the anchor point to calculate direction of movement.

Since this is a rough approximation using linear movement, there is a certain degree of drift every frame. This is corrected for by recording the original length of the hook and adjusting player position along the vector towards the grappling hook.


hake screenshot while grappling, showing relevant vectors

Having the direction of movement it is simple to use some acceleration value to modify speed each frame, to accomplish a pretty natural swinging motion. Basically this means we have a sort of system where energy is converted from kinetic energy to potential kinetic energy. We augmented this system with an “energy loss” were we subtract a bit of velocity each frame, to avoid endless swinging.

To calculate initial movement speed along the grappling vector, we use the magnitude of player velocity times the angle between the velocity and the grappling vector, which seems to work.

Each calculation involving velocity or acceleration uses delta time to allow for frame-independent movement.


hake screenshot showing maximum kinetic energy


hake screenshot showing maximum potential energy

Line segments
To give a nice feel to the game element, we needed to simulate wrap-around of the line around platforms. We achieve this by continually raycasting from player position to grappling anchor to see if the collision point has changed. If so, we push a new line segment onto a stack, and use that for all calculations. When the player swings back, we need to remove that line segment from the stack. We use the same raycast as previously, but using the previous segment as anchor, to figure out when we should remove the line segment. With little effort this method give a very lifelike feeling to the grappling hook.


hake screenshot showing multiple line segments

The future
We are quite satisfied with the feel of the grappling hook, but the game element is like a pole that attaches to where the player points - it might feel more natural if we could simulate a rope more closely. The naive approach from the top of our heads is to use the angle of player velocity to somehow determine when to “disengage” the grappling hook mechanic, allowing the player to freefall until the rope again reaches its initial length, but it seems finicky.

Does anyone have some tips regarding the above? Or any comments on better approaches to the grappling hook mechanic?

Thanks for reading!

[Superb Joe]

hake is not my favourite fish

[arvidsson]

Naming a game is always tricky business. Since we are such creative and imaginative individuals, we took the word for the main game mechanic in the game, "grappling hook", and translated it to Swedish, "änterhake"; and, here comes the real ingenious move on our part, we removed the "änter" part of the word and ended up with "hake": the Swedish word for hook. Genius.

That hake also is a certain kind of fish in English, we consider a bonus.

In other news, we are getting very near to release a playable prototype that actually seems fun to play!

[Silkworm]

So what's the catch? (I'm Swedish )
Seriously though, the swinging does look fun. It reminds me of worms, with the tiny sprites too. "Drawing" the shield seems pretty neat too.

[arvidsson]

Thanks!

Yeah, although we will certainly have to continuously adjust the grappling hook "feel" during the development of this game, it feels quite good right now. Very agile. Perhaps too agile when more enemies are thrown into the mix, we'll have to see about that.

It will be interesting to evaluate how well the manual drawing of the shield works when the player is in a tight spot. It could very well be that we need some shortcuts when there is too much action going on at once.

[icedvariables]

Procedurally generated platformer is a cool idea and that grappling hook looks like a lot of fun! Add a parachute and it'd be like a 2d just cause.

[arvidsson]

Update 3: Prototype 1 done!

First prototype build of our game is done and available for download at itch.io!

We have updated our first post as well with some new gameplay movies and screenshots. It would be ridiculously awesome if you guys would like to try it out and give us any feedback you can think of

We had an original scope for the first prototype which we actually managed to keep and we scared away the scope creep. The prototype was meant to test how fun the main game mechanics were, and it feels like we are on the right track. The enemies are rough in their design, and how the levels are populated is very random at this point. But it's starting to feel like a game proper and less of a grappling hook simulator.

Cheers!

[CyberRascal]

Procedurally generated platformer is a cool idea and that grappling hook looks like a lot of fun! Add a parachute and it'd be like a 2d just cause.

Thanks! We are hoping to make a lot of exciting improvements for the next playable build, one of which is the ability to find and equip items, which provide some form of (massive) benefit. Parachute is not at all a bad idea for such an item (and a 2d just cause wouldn't be too bad to end up with..).

[arvidsson]

Update 4: Level Generation using templates

When looking at how to actually create levels procedurally we had many ideas for more or less advanced techniques. But as we wanted to also achieve progress quickly, we got quite intrigued by the techniques used by Spelunky, especially of the idea to create templates and thus combine procedural generation with pre-designed components. This, in our minds, would make for the best end result, where the levels would enable new experiences every playthrough but where the design of the levels still would indicate a certain intent with the design and also decrease the possibility of weird combinations which a human designer would avoid. So, that’s what we decided on. A level in hake would consist of chunks. And a chunk would have a certain template type which would ultimately decide what that specific chunk would look like, how it should be populated and how it would correlate to other chunks.

Quick Iteration

In order to be able to iterate quickly on chunk template designs, to fix broken stuff or improve because of a lack of challenge for example, we needed some kind of tool, some kind of chunk template editor. And aside from finetuning mechanics in the game, it will be the templates that will require the most time, but they also bring most bang for the buck as well since we wanted an easy way to edit them and create more, each template adding to a more varied and hopefully better experience for the player.

Tools are often fun to make yourself, depending on the scope of course. We will touch upon this in another update. The first thought was to make an editor on our own using C++ or maybe Python, or perhaps trying to use another tile editor. We eventually ended up using Pyxel Edit, the tool we had been using to create the actual tileset.

The Template Tileset

By creating a new tileset, a specific one for templates, where each tile had a specific meaning, we could easily create and edit chunk templates and also get a visual indication of what the template would look like and how it would probably work inside the game. We kept it simple, so that we only had to define where we wanted solid wall tiles to begin with and then added concepts such as probabilistic tiles of both walls and spikes. The level generation code would then interpret this, and assign the correct tile ids (so corner tiles would look like corner tiles etc), placing decoration, determining if wall and spike tiles should be generated and so on until we had a proper chunk generated that fit well with other chunks depending on the layout of the entire level of course.

An example chunk template:


Part of a generated level:


Further improvements

Right now we are quite happy with this format. Whenever we need more functionality, it’s quite easy to define a new tile type and create the logic for it in code, as long as we don’t make too much spaghetti code of the level generation code. Right now we don’t have any drastic changes in mind, but it would be nice to be able to define where spikes could appear, and if they don’t it should be filled with regular dirt tiles. As well as adding new forms of static obstacles of course.

For even quicker iteration and easier playtesting, it would be even better to be able to edit the chunks in-game, so things that doesn't work can be removed right there and then. But right now we have other stuff to focus on, so that will go on the nice-to-have pile for now.

Thanks for reading!

[arvidsson]

Update 5: Extrude Tool

Sometimes it's actually fun to build small tools if they aid your work process. They also bring a little bit of respite from the main project when motivation drops, even though you should never rely only on motivation to begin with. Anyway, we had a problem with rendering our tilemap as tears and lines were showing especially when scrolling around the tilemap. One solution was to extrude each tile in our tileset so that the outermost pixel was doubled. But instead of pixeling our tileset this way, since it would become rather tedious as soon as you wanted to change or expand the tileset, we decided to create a tool.

Well, first we did some research and tried to find something that could solve this and was easy to use. We couldn't find anything good though, either it didn't work as we wanted or it was part of some software solution that required quite a hefty investment and we only wanted this small feature.

So, we decided to create a small tool using C++. It's available on github (https://github.com/arvidsson/extrude) if anyone is interested.

In sum, creating small tools is fun!

[arvidsson]

Update 6: Behavior Trees

We have a lot of work ahead of us when it comes to the enemies and their AI, but I think we are on the right track. We’re using behavior trees to define each enemy types’ behavior using small, clearly defined, actions - the atoms, or rather the leafs, of the behavior tree. The idea for using behavior trees have been in our minds ever since we read this article how the developers of Project Zomboid made great use of that technique. I wrote a C++ library (which can be found on github) some time ago, and when it was time to start working on the enemy AI we basically converted this library to C# and made some tweaks to better fit Unity. Then, we quite rapidly could construct our first enemy using a recipe such as this:

var sequence = new Sequence(new List<Behavior> {
    new SetPlayerAsTarget(gameObject, blackboard),
    new IsTargetWithinRadius(gameObject, blackboard, 10f),
    new IsTargetInLineOfSight(gameObject, blackboard),
    new ShootBurstAtTarget(gameObject, blackboard, new BulletFactory(), 3, 10, 1f),
    new Wait(gameObject, blackboard, 60)
});

and it worked! And we could reuse action nodes for other enemy types quite easily, and code reuse holds a special place in our heart of course

If you want to try out our behavior tree controlled enemies yourself, the prototype demo can be found here.

[arvidsson]

Update 7: Current Status

We are hard at work trying to develop all the features we have envisioned for the first alpha of the game. Sometimes the road isn't that straight forward though, and we have been tinkering both with movement and input controls for the player as well as other game mechanics, especially the different "resources" of the game - player energy/health, ammo and scrap (the currency of the game you could say). The tinkering has also led to us thinking more of the story of the game, what kind of narrative we are after, even though it won't be a very story-driven game.

We have developed a few more weapons and items as well, and an inventory system. The next couple of updates will probably be focused on these things. And as soon as we have a bit more progress we will release another prototype version.

Cheers!

[arvidsson]

Update 8: The Scrap Machine



In this gif, the player is harvesting an old relic of technology past in order to get metal scrap. Both the graphics for the machine and the scraps are pretty crude still. The scrap is the currency of the game. You need scrap in order to build better weapons, items and ammo. So, finding these machines are pretty crucial for survival and gives the player a reason to explore the level rather than scurry directly towards the exit. The enemies also drop scrap, if they are of the robotic kind. Organic enemies do not drop scrap. The scrap is also important for the end goal, so the player must always think twice before spending scrap on stuff.

[tankorsmash]

Is there going to be some sort of action required when you're scrapping stuff, or will it be purely clicking and holding? Given that it takes a bunch of seconds there, you might want to think about spicing it up a bit. Maybe this is a high level deconstruct and normally it only takes a second, who knows.