The Dev Log is a place where you can closely follow our development. Every time we add something awesome, we will post it here, so this is the best place to get started to get the latest insights into Roche Fusion.

Colour coding in Roche Fusion

by amul on

Roche Fusion is a fast game. A very fast game.

This makes it very important that the player always has as much of an overview about what is going on as possible. A big part of this is visual communication.

One important aspect of that is the colours we use for enemies, players, projectiles and even the game's backgrounds.

Player colours

The most obvious colour coding of the game is the colour of the two different players in Roche Fusion's co-op mode. When deciding on the player's colours, we know that they had to be easily distinguishable.

That is why we went for bright-blue/cyan for the first player, and yellow/orange for the second.

Image

This combination is also easily separable for most forms of colour-blindness, which we believe is an important consideration.

Note that the projectiles of the player's weapons - and this includes all of the powerups and other weapons available to the player throughout the game - are colour coded as well. This allows the players to tell apart the ships, even when not directly looking at them, since it increases the footprint of the player's colour on the screen.

Image

Even drones - little companion powerups the player can collect - shoot in the same colour.

Image

Note how the HUD of the two players follow the same colour scheme as well. This is important so each player knows instantly which side of the hud belongs to them, even if the ships may be on the opposite side of the screen.

Further, none of the enemies in Roche Fusion shoot cyan or yellow projectiles, which allows for a distinction in colour between friendly and harmful projectiles easily, even though their shape can sometimes look similar.

It is important to note that this does not hold for all forms of colour blindness however. Especially red enemy projectiles and yellow player projectiles might be difficult to tell apart with red-green blindness, which is the most common form of colour-blindness.

Given the limited range of colours available, we decided that this was a tradeoff we were willing to make however. Fortunately, colour is not the only way to tell projectiles apart: An even better and easier distinction is that the player's projectiles tend to fly upwards, while the enemies' projectiles tend to move down.

Enemy colours

As was mentioned in last week's post, enemies in Roche Fusion are colour coded by their behaviour, and also use different shapes to be easily distinguishable for colour-blind people.

Image

In addition, we use subtle colour coding for different enemy projectiles as well. This is not a necessity, since everything that needs to be communicated is done so by shape and behaviour, but it is a neat additional detail.

Image

Overall all enemy projectiles are in the range from red to purple and pink.

In detail, red projectiles (including lasers) are the simplest ones that deal simple direct damage when hitting the player.

Pink projectiles are bombs that explode after a short while, or when hitting the player. (Note how a particle effect in the screenshot above distinguishes between the slightly different bombs of spiders and squids.)

Lastly, darker, purple projectiles (not featured here) are fast and homing, and can deal significant damage depending on their size - though, overall size is a good estimator for a projectile's damage in Roche Fusion, even extending to the width of lasers.


I hope this has given you insight into how we use colours - and shapes - to help the player understand what is going on in a game of Roche Fusion.

Maybe you also found our considerations regarding colour-blindness interesting. I certainly enjoyed reading up on the topic at the time, and making decisions that allow colour-blind people to enjoy Roche Fusion, without having to make compromises in the game's graphical quality or colourful palette.


Enjoy the pixels!

Cheating Newton's Laws

by Tom on

An important feature of Roche Fusion is that enemies with the same colour follow similar behaviour. Each of the colours has a certain theme applied to it: the red enemies follow the so-called "Australia" team, modelled after different dangerous animals - snakes that only want a bit of love, and spitting spiders. Blue enemies - separated in two subgroups - are a bit more boring: the either fly in straight lines shooting pews, or follow arcs and fire lasers.

These themes are very important in a game that is procedurally generated like Roche Fusion. It is important that the player can recognise behaviour and know how to defend themselves against it. Even when variations in behaviour are introduced later in the game, the general drift of the enemies does not change, making it easy to anticipate on what they are doing.

The behaviour themes are extended into the boss fights. When a huge blue monstrosity approaches you, you can count on a whole lot of lasers (or pews, depending on the exact tint of blue) coming your way soon, and it doesn't take a lot of imagination to recognise the behaviour of the snake boss.

In the content update - coming soon to Roche Fusion for free - a new epic boss will be introduced. The design of this purple epic boss was quite the challenge. The theme of the purple enemies consists of having a very militaristic nature (the formations) and being very physical in attacking the player. This behaviour can also be clearly spotted in the purple mini-boss.

Image

Adding a militaristic nature to a boss fight isn't difficult, since we can add a lot of support enemies. The epic boss is in fact the general of a large army of purple enemies, and - discontent with how his soldiers are not doing much harm to you - comes to fight you itself. It was however obvious that to keep the purple enemy theme going, we had to give the boss some form of physical attack.

This is where we ran into a problem: epic bosses are big... very big. We can't just take the dashing of the mini-boss and fit it to the epic boss. It would not look right due to its proportions, but furthermore, it would also not really work well for the gameplay, since it would become very difficult to dodge the boss.

The solution seems so obvious: just make the boss slower. And in fact, that is exactly what we did. We still had to give the boss the illusion of speed though, and that is where a new graphical trick comes in.

The trick is inspired by something that can be seen in (old) cartoons. Look at for example the following notorious fast runner:

Image

This example clearly shows a well-known technique for inducing speed: after images. Apparently the character moves so fast that we can see it multiple times. While mostly a stylistic effect, we felt that the effect would fit very well within Roche Fusion, so we went to work:
Image

The implementation of the effect is quite simple. When a dash like the one shown above is initiated, we start recording the position of the enemy every 0.1 second, so we can replay the movement of the boss by using the keyframes to interpolate the boss position. We could also have recorded the position every frame, but since Roche Fusion supports playing the game without an FPS cap, the amount of memory usage would be theoretically unbounded as well. The chosen time step turns out to give very smooth results by interpolating the actual positions between the steps.

Technical note 1: in this particular instance the boss always moves in a straight line, which makes a time step of 0.1 second sufficient. For movements that contain curves however, there would be very clear points in which the movement is not smooth. A solution would be to use smaller time steps, but this leads to a lot of precision on straight sections of the path. To solve this issue in Roche Fusion we use an adaptive sampling method that stores a point after a predefined time step, or if we detect that the angle between the current movement vector and the difference between the last two recorded points becomes larger than a given threshold.

To determine where the after images should be drawn, we replay the movement of the boss with a very small delay. The after image itself is achieved by redrawing the entire enemy with a higher so-called holoness factor (the replacement for fading using in Roche Fusion, for example when (re)spawning). The after images fade out when they are close to their original, to give the effect on overall slick look.

Technical note 2: in theory we could have simulated the movement of the phantoms separately in an identical manner as the original. The small discrepancies that would come from float rounding would not be noticeable, but if the boss movement would be influenced by external factors (e.g. pushing), the movement of the images would diverge, unless a list of external influences would be stored, which is impractical. Further, storing the position makes the code extendible to arbitrary movement behaviours.

The result is a very interesting looking illusion of speed, while giving us the freedom to tweak the actual speed of the boss to fit the gameplay. You will be able to take your chances against this boss very soon in the free content update coming to Roche Fusion. I am looking forward to hear what you think of it!

Dimension Drive - A graphical effect explained

by amul on

Howdy ho!

As you may have seen, we are currently running a crazy deal with the guys from 2Awesome Studios.

Their game Dimension Drive is currently on Kickstarter, and for just another 36 hours or so, you can get a copy of Roche Fusion for only €4, if you back their game!

You can read more about this sweet deal here:

https://www.kickstarter.com/projects/2a ... ts/1215430

Dimension Drive is a pretty cool and unique game.

That is why I turned its teleporting gameplay mechanic into an upgrade in Roche Fusion.

Today I want to go into some details on how I created the power up's visual effect. I hope I can give you some insight into the subtleties that are involved in something like this.

Before we start, here is what the finished effect looks like:

Image

Achieving an effect like this relies on a smart combination of different elements.

We start with just the player's ship. To give the player feedback on where he will teleport when using the power up (so that they do not accidentally end up inside a group of enemies), we draw an exact copy of the ship, stripped of its colour and slightly transparent.

Image

Once the player hits the button to activate the power up, we instantly switch the position of the player and the teleportation ghost image. This is important to allow for split second reactions.

To make the jump less jarring, we could fade between the player and the ghost graphics over a couple of frames.

However, this is not necessary in this case. At the same time of teleporting the player, we also create the different parts of the graphical effect which obfuscate the switch, especially in a fast game like Roche Fusion.

Image

The effect mainly consists of a few dozen particles and a shockwave sprite (strictly speaking: a procedurally textured shockwave quad) on each side.

The shockwave starts out very small and expands linearly, while the particles start all start in the position of the player and ghost image and then fly outwards, again linearly. The particle effect is simulated in three dimensions, to give the effect more depth.

Note how the effect around the player position is considerably brighter. This serves to draw the player's attention to their new location.

As the effect expands, another part of it becomes visible:

Image

To further highlight the player's new location, and to fit the effect in with Roche Fusion's high contrast art style, we use localised crepuscular rays - also commonly known as volumetric, or god rays.

The effect is only applied to the new location, making it stand out significantly, giving it a unique look.

The effect quickly reaches it's maximum intensity, and then shockwaves, particles and crepuscular rays fade away.

Image

Note how the new ghost is drawn with even less opacity at first. It fades back in after a short while, when the cooldown of the power up has elasped.
This serves as a visual queue for the state of the upgrade, preventing the player from having to look at their hud too often.

One last component of the effect are screenspace distortions.

Image

If you again look at the final result animation, note how both the ship and ghost image seem to slightly expand, contract and expand back to regular size in a pulsing motion at the beginning of the effect.

This effect could not be achieved by simple scaling the ship's sprites. Instead we use post processing to distort the rendered image in a circular wavy fashion around the ship and ghost.

The same and similar effects are used for many other effects in Roche Fusion, for example the black hole weapon, but also every single enemy explosion.

All in all, each of the different parts of the effect is critical in achieving the end result.

I hope I could show you how each adds a part to the whole, and how they work together to make this unique effect.

Make sure to check out the following video to see how the upgrade looks when used in gameplay!


Of course, in Roche Fusion this is merely a power-up the player can pick up every now and then. In Dimension Drive, teleporting is the gameplay mechanic that the entire game is build around.

If you are curious, make sure to check out the Dimension Drive Kickstarter, where - just for a few more hours - you can even get a copy of Roche Fusion -for yourself, or for a friend - for super cheap!

Enjoy the pixels!

Today: Update 1.1 play test stream

by amul on

Image

Hey folks!

Roche Fusion's first content update is getting closer and closer to completion.

At this point, with most of the content implemented, we need to do a lot of play-testing to make sure we get the balance of the new ships and upgrades as good as we can, and to make sure we find any bugs or glitches (programming is complicated!).

And of course, we want to polish all the new features, making sure they are as awesome and fun as possible!

Today I will do exactly this, live on stream!

If you like to take a look at some of the stuff to come, and maybe give some feedback, make sure to drop by my Twitch channel:

http://twitch.tv/amulware at 14:00 GMT

Hope to see you there!

How to design content in five simple steps

by Tom on

At the heart of much of the content of Roche Fusion stands the design. Ships, upgrades, enemies, and bosses all have to be designed before they can be put in the game. Especially since the gameplay in Roche Fusion is completely procedurally generated, a lot of thought has to go in the design of the single elements and the synergies between them to get a consistent and fun mix.

Today I will take a quick walk through the stages we go through from a design perspective. We don't follow a fixed design path for all content, since every bit of content is approached differently, and sometimes content is introduced to the game based on an epic idea of one of the team or community members. Still we can recognise a general path most designs follow before becoming a permanent part of Roche Fusion.

1. Determining the goals

The first step in designing a new piece of content is determining the goals. We often try to look for gaps in the content currently in the game and determine how these gaps could be filled.

Let's look at a few examples: the fatboss that will be introduced in the next update for example has as goal to provide the game with a boss fitting with the theme of blue enemies; the green enemies were introduced in the game to generate a group of enemies that could cause the player to consider not firing at everything at the same time; the Arrow was introduced to create a ship that forces the player to fly more in the top half of the screen to actually kill enemies.

Most content in Roche Fusion is designed around a set of goals. Sometimes the goals can be really loose, if we for example just want a new ship or upgrade and can't find any content gaps they have to fill.

Some goals can also be very generic. For most upgrades for example we want to design them in such a way that they synergise well with one or more other upgrades. This makes the game more interesting, as there is more depth to choosing more upgrades.

2. Exploring mechanics

When we know where we want the content the go, we have to look for ways to get it there. We have several large documents filled with interesting ideas we can pull ideas from, but sometimes we need to think of new ad hoc solutions to fit better with the goals.

This stage of the process is the most creative of all, as we have to come up with interesting mechanics that feel new and refreshing that fit within a certain set of restrictions. While this can be a lot of fun to do, it is also one of the most challenging parts of developing content for Roche Fusion.

3. Create a consistent whole

From the previous step we often get a decently long list of mechanics we can use. Just throwing these mechanics in a huge mixing bowl and implementing them does not always great good content though, so that's why the next step is looking at the mechanics and try and find a way of combining them in an interesting way. For upgrades there is often a single mechanic, but ships and bosses often have several mechanics that need some work to be put together.

If often happens that we have to scrap mechanics, and it can also happen that we need to revisit the mechanics and add some more ideas to link mechanics together. In rare occasions we have to go back to the drawing board and come up with an entirely different combination of mechanics.

In additional to making sure the design is internally consistent, we also have to look at the design in the bigger picture of Roche Fusion. The design might clash with another piece of content, or make old content obsolete. With Roche Fusion growing bigger and thus also more complicated all the time, it is really important to get a good feel of the game and stay aware of the features the existing content has to offer.

4. The two I's: implement and iterate

After we have decided on the design of the content, we start implementing it. We often start out with a rough framework and then work our way through the details. Once we have implemented an MVP (minimal viable product), we immediately start testing. Sometimes we find that a mechanic doesn't work as well as we wanted, or that some mechanics interfere with each other. In that case we revisit the design, make some changes and go from there. Sometimes we have to go back further, and we might be set back to as far as step 2.

For more complicated designs, several iterations are usually required to get a piece of content we are happy with. Green enemies for example went through three major redesigns across a full year of development, while the blue enemies have barely changed since their original implementation.

5. Polishing, playtesting and balancing

Whenever we are happy with the complete package, we start polishing it. At this stage, we often add the content to the main game already, so we can test it a lot along with the existing content of Roche Fusion. During this stage, we often make small improvements to the graphics, and make sure everything feels fluent and smooth. We consider it very important that every piece of content feels as complete and polished as possible.

This is also the part where the sound effects - and sometimes final graphics - come in.

Of course the new content also has to be balanced to fit with the rest of the content. This comes down to tweaking a lot of parameters to make sure the upgrade is similarly destructive as other upgrades or enemies are as lethal as you would expect them to be in the stage of the game they appear.

Having a basis of content to work from makes it difficult to anticipate how new content fits in, but it also sets a baseline for balance. Being the first ship of the game, the description of the Beard is very accurate in that most of the other ships have been balanced around the Beard. The difficulty level has been established over months of extensive beta testing, which makes it relatively easier to fit in new content with the rest in content updates.

Livestream

If you are interested in how we approach this final stage of the design process, you can tune in for a live playtesting session on Saturday April 25 at 16pm CEST over at http://twitch.tv/tomrijnbeek. I will be playing the game for several hours, testing all the content we have been working on for the first free update during the past couple of months, so this is a great moment to check out what we have in store for you. Of course there will also be ample opportunity to ask questions about our design process, the game, or anything else you would be interested in (my favourite colour is lawn green by the way, so there is no need to ask that any more), or leave behind your feedback based on what you are seeing.

What happens after

The final step often takes until the update is actually released. At that point a lot of different people get access to the content we have created. Our players often find different ways of consuming the content, or even behaviour that we had not anticipated. We always keep a close eye on videos and forum posts to check out what people think of the new content and how they are using it.

During the beta stage of this game we worked closely together with our beta players. Due to our short release cycle we were able to quickly make changes to the content. Since the game is now released, it is more difficult to make large changes to existing content. If we feel something doesn't work or is imbalanced, we have to consider carefully if and how we want to change it, since it could have large repercussions throughout the whole game, and eventually affect the overall game balance. This is why we have to assume the content immutable after we have released it, unless we notice major design flaws.


I hope you found it interesting to learn about our design process and the challenges we face along the road to developing new content. As always, if you have any questions or comments about what you read, don't hesitate to leave behind a comment or get in contact with us in some other way.

Birth of a Monster - Taiko drum effect chain

by amul on

This week we have something slightly different and very special for you.

We asked one of our composers, Thijs Kammer, to write a music-related post.
Below, he goessuper in-depth on how he created a specific sound sample for one of Roche Fusion's boss-fight themes.

I hope you enjoy the read, and listening to the samples!


"Birth of a Monster" is one of the tracks used for the big boss fights in Roche Fusion and has a dark, brutal and epic atmosphere.


Example 0 - Birth of a Monster

The composition is based on an ostinato bass motif and a repetitive pattern played by the taiko drums. The taiko drums are heavily processed to enforce the dark and threatening feel of the boss fight. Big reverbs are used to create the epicness. Let's take a look at the effects applied to them!


Taiko drums unprocessed

The taiko drums samples had a lot of typical concert hall reverb on them.
This particular concert hall reverb wasn't going to work in the context of the track, neither I wanted to process the sounds heavily with the reverb on them. So I decided to get rid of the original reverb as much as possible.


Example 1 - Taiko drums, unprocessed


Getting rid of the original reverb

To get rid of the tail of the reverb sound I tried to isolate the beater sound with Logic's gate. Since the taiko sounds were very dynamic I wasn't able to set the gate right. Some reverb tails were passing the gate and with more rigorous settings the sound of the beater started to disappear.

Image
Logic gate to catch the beater.


Example 2 - Taiko drums, with the (mild) gate on

In example 2 you can clearly hear the reverb tails slipping through the gate.

I decided to smooth out the dynamics of the taiko drums with Logic's compressor to have a clearer beater sound with less dynamics, example 3.
With the compressor on, the gate was better able to pick up the exact peaks in the taiko drums so that only the beater sound could pass the gate and the tail was silenced. After experimenting I found the settings that worked best.

When comparing the taiko with and without the compression you hear a big difference in character.

Image
The compression helped the gate to focus on the transients.


Example 3 - Taiko drums, compression only

Notice that the compressor has a long attack time of 32 ms and a long release time of 780 ms to emphasize the sound of the beater.

It's interesting that in this case both effects need to be applied in a mutual way to get the intended result.


Example 4 - Taiko drums, compression and the gate on


Fatten up the sound - adding a Decapitator and a bitcrusher.

To fatten up the sound and make it a bit grittier Soundtoys’ Decapitator and Logic's bitcrusher were applied. They both made the taiko drums sound more aggressive. Also it made the taiko drums sound less natural so that it matched better with the other synthetic sounds.

Image
ThumpyBumpy was this preset called...I might have tweaked it a bit.


Example 5 - Taiko drums, the decapitator added

Notice how the low mids sounds much thicker with the decapitator on.

Image
The bitcrusher is set very gentle.


Example 6 - Taiko drums, Decapitator and bitcrusher on.

With the bitcrusher on, you hear a crispy fire-like sound in the tail of the beats.


Sidechain compression, a high pass filter and some eq

A side chain compressor activated by the kick was added to carve out a bit of space (for the kick's attack). The compressor was working with a gain reduction of 2 db. After experimentation a release time of 460 ms gave the best results. Obvious that's a very long release time in this case but I guess it had to do with other settings of the compressor that made it necessary.

A Softube's Passive Eq was used for a small bump at 390 hz to emphasize the body of the taiko drums. In the mix I wanted to leave the low end for the bass and kick so I decided to add a high pass filter at 120 hz.
Normally I put this filter earlier in the chain but in this case I wanted to make sure that the decapitator and bitcrusher worked on the full spectrum of the sound instead of a smaller part.

Image
The Passive Eq is used to emphasize the body of the taiko drums


Example 7 - Taiko drums, with side cain compression and the Passive Eq on

Notice that the eq decisions were made later on in the mixing process in the full context of the mix and with all the effects on. By itself I like the taiko better with a lot of bass on them!


Ringshifter - defining the sound

The ringshifter of Logic was used to get the defining out-of-space sound from the taiko drums, the "breathing" noises of the ringshifter also enforce the feeling of a big monster nearby. I love that sound!

Image
The most significant effect in the chain is the ringshifter


Example 8 - Taiko drums, ringshifter applied

Taming the low frequencies

A side-effect of the ringshifter was that it made new sub frequencies.
To make sure those weren't overloading the low end, a new high pass filter was applied at 49 hz. To tame some more peaks of the lows the multipressor of Logic was applied.

Image
Logic's Multipressor is taming the lows, the two high bands were bypassed


The topping: some reverb and final effect automation

The signal was send to a reverb channel with Logic's space designer with the warm vocal hall-preset, also some more eq to cut away more lows.
This added back the tail to the sound which was lost in the first steps of our processing.

Image
Logic's Space Designer was used to make the epic reverb sound!

After applying all the effects I used automation to change the sonic character of the taiko drums during the song. The wet/dry signal of the ringshifter is automated, as are the frequencies of the high and low pass filters. Both effects generate momentum and excitement in the track and steer the attention of the listener to certain points in the song.

Image
The effect-automation creates momentum.

In this example you can hear the ringshifter gradually increasing


Example 9 - Taiko drums with reverb and automation on wet/dry signal ringshifter

Image
Overview of the effect chain


Adding it all up

You might have the impression that all the effects were applied successively in the order of this article. That is not truth. During the production and mixing process I often experimented with different kinds of effects and the order of them. Especially in a situation like this in which new sounds are being explored
I like to compare different option.

Adding up all the effects together made a big impact on the sonic character of the taiko drums. With so many effects on one channel it can be difficult to keep the overview. In this case all the effects had a clear reason to be placed in the signal chain so there's no reason to be scared about that!
I hoped you liked this article, and if you're interested in more please let me know.

Thijs

Player directed development live stream #2

by amul on

Two weeks ago we had an exciting development live stream where we created an update completely designed by one of our players.

We had a lot of fun fiddling with the gameplay and the graphical details and the result will be included in our first content update.

Tomorrow, we are going to do the same thing, with a different player!

I hope you will drop by as well, to just check out how we work on Roche Fusion, or to participate by giving suggestions or askign questions.

I always enjoy having a chat about almost any kind of game development topic! ;)

The event will start tomorrow, 14:00 GMT at http://twitch.tv/amulware

Hope to see you there!

Graph violence

by Tom on

In my previous dev log I talked about the graph structure we use to model enemy behaviours. This week I will look at a single enemy, and show how we go from a design to a usable model.

Introduction


The enemy in question is a new boss for the upcoming free content update. The boss goes by the name Project Fatboss and was designed to add a boss that thematically fits with the very popular (*cough*) blue pew drones.

Image

The boss was implemented with the use of a design documents. Design documents describe the behaviour and mechanics of an enemy in plain text and images. For the purpose of this devlog I have made the design document for Project Fatboss available for download below:

Below I will discuss how I went from this design document to the final design. There are some small changes in the final boss design, which I will not discuss here. Also note that I implemented this boss mainly on stream. Sadly Twitch does not store videos long enough, so they are no longer watchable, but if you are interested how we tackle these problems, feel free to tune in to our livestreams - http://twitch.tv/amulware (selected Wednesdays) and http://twitch.tv/tomrijnbeek (most Saturdays, including tomorrow!) - where we will be open to ask any questions you might have and often take feedback from the chat.

The guns


When reading through the design, there is one thing that immediately comes to my attention: the guns. The behaviour of the guns stands is entirely independent from the rest of the behaviour. The design also contains the suggestion to make the large guns destroyable separately. These mechanics almost make the guns separate enemies.

The advantage of separating the gun behaviour is that I can completely ignore them in the main behaviour controller of the boss, making it simpler and easier to maintain. That is why I made the decision to go through with this and create separate enemies for the guns.

The behaviour of the guns can easily be implemented in a single class, so the behaviour graph of the guns consist of a single node controlling the direction and shooting of the gun. The gun is attached to a bone in the animation skeleton of the boss, so the position of the gun can be easily fixed.

Furthermore, the two different types of gun share the exact same behaviour. The only difference is the parameters that should be used for rotating the gun. Our behaviour system allows us to define additional parameters for the behaviour of an enemy, which means we use the same graph, but the nodes can access the parameter and have slightly different behaviour that way.

Movement


The next step in the process was to actually make the boss do something itself. For now we will forget about what exactly we want the boss to do and focus on the movement on the boss.

The boss has two different states: it can be in the middle or it can be on either of the two sides. There is not really any difference between the boss being on the left or on the right, as we can just mirror the behaviour if necessary.

To transition between these states, the boss needs to move from one place to another. During this transition no other behaviour is happening, so the movement should also be a state in the behaviour of the boss.

If we combine all this, we get a relatively simple behaviour graph:

Image

DoSomething()


Since we now have a general graph structure to work with, we can start filling in the blanks. In this case it's the "do something" parts. We don't want to boss to move all the time, so we usually want to do more than one thing before moving again. That means that we have to replace the "do something" nodes by more than one node. We also don't want the boss to perform the same sequence of actions all the time, so we can't just make a sequentual graph. Instead we will make something like this:
Image

Remark: only the center "do something" has been filled in to keep the image readable; the side one can be handled in completely the same way.

So... this looks quite a bit more complicated than the things we have seen so far. Let's take a look at what we have:

We still recognise the basic structure from before: the move nodes and the intermediate behaviours. After each move node, the enemy moves to do something else. After doing something else, the enemy moves again. Instead of a single node that represents the doing something we now have multiple nodes that represent different behaviours. All these behaviours are fully connected, so the boss can switch between these behaviours randomly. At a certain condition, the behaviour transitions into the move node, and the same pattern repeats.

If you remember from last time, outgoing arcs for a node are built from a condition and a new node. That is however not entirely sufficient for what we want to do here. We have a shared condition, but we want to select a different node randomly. If we were to just add multiple arcs with the same condition, we would always choose the same one, so we need to slightly change how it works.

This exact problem actually caused me to make a small change in the implementation. Instead of giving the arc a condition and a node, the arcs gives a condition and a function that returns a node. In other words, it only decides on the outgoing node at the point the arc is being traversed. In our case, the arc is given a list of nodes to choose one from randomly.

The implementation therefore does not look exactly like the graph shown above, but the structure is still clearly recognisable. Below is an image that shows the difference between the graph structure and the implementation visually.

Image

Conclusion


There is a lot more to actually make the boss work, and many design elements from the document we haven't talked about. However, I hope that I have made clear how we approach going from a design to a model of the enemy, which we can then implement fairly easily.

The concepts I discussed were actually first introduced for this boss, but have already been used elsewhere (follow us on Twitter - @amulware and @tomrijnbeek if you want to know more). As always, if you have any questions, please leave a comment and I will get back to you.

Have you been living under a rock and missed some of our older posts? Luckily you can still read all of them on our forums. This is also the place to discuss them.