This is the development blog (or devblog) of PunchButton Studios.
This is where we post our, almost kinda maybe weekly development updates about the things we add and update in our game Counterspell!
COUNTERSPELL: DEV UPDATE - 35 | Abilities: ‘Cyclogenesis’
Introduction:
Eileen’s unique character ability is ‘Cyclogenesis’, which allows the last cast Spell to be suspended in mid-air for as long as the Ability button is held. Regular Spells cast through suspended ones are sped up dramatically.
Bloodlust Gauge:
Maximum : 60
Divisions : 2
Application:
Cyclogenesis is especially strong for players who are good at reading their opponent’s movements, using suspension to lay traps or set up areas of denial.
Similar to Pestis’s Swarm Control, this Ability allows the user to self-Counter in a pinch. Be careful, however, as opponents can likewise take advantage of the suspended Spell.
Spell cooldown is cut off as the Ability is activated, making it possible to suspend and then cast a Spell in rapid succession for unpredictable high-speed shots.
A more advanced technique is to use the suspension property to bait a Barrier attempt and then punish it within the same shot.
Cyclogenesis is an excellent choice for players who like to remain unpredictable and play mind games with their opponent. As suspension requires the holding of a button, some executional dexterity and multitasking is required for optimal results.
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
And subscribe to our YouTube channel for the newest footage!
https://www.youtube.com/channel/UCyw9YzmZVZspWMWA8_JaeNA
Introduction:
Nitires's unique character ability is 'Warp', which instantly teleports it to its last fired Spell.
Bloodlust Gauge:
Maximum : 80
Divisions : 2
Application:
An unassuming yet versatile ability, Warp can be used for offense, defense and mobility. Provided Nitires has a Spell out, teleportation allows for virtually unmatched flexibility in stage traversal. The act of teleportation instantly cancels any current action, which means a faulty Barrier attempt can be salvaged by quickly moving out of harm's way.
Alternatively, it is possible to bait an opponent into Deflecting a Spell, only to teleport to it and punish the recovery of the failed attempt.
Warp can also be combined with a Killdash to devastating results.
The Warp ability is a great options for players looking for more freeform movement and additional mind-games to subject their opponents to.
Warp does demand keen awareness of Spells as it is entirely possible to teleport into chasms and hazards, with unfortunate results for the user.
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
And subscribe to our YouTube channel for the latest footage!
https://www.youtube.com/channel/UCyw9YzmZVZspWMWA8_JaeNA
COUNTERSPELL: DEV UPDATE - 33 | Abilities: ‘Swarm Control’
Introduction:
Pestis' unique character ability is ‘Swarm Control’, which recalls the last cast Spell to the current location.
Bloodlust Gauge:
Maximum : 75
Divisions : 3
Application:
The ability's most apparent application is to salvage a missed shot and hit an opponent on the rebound. Because the Spell can even be recalled while off-screen, opponents would do well to maintain awareness of any Pestis with Bloodlust to spare. The character can store up to three Ability activations at a time, which allows tricky and elaborate manipulation of a single Spell.
As a more advanced technique, Swarm Control also has great synergy with the core Counter mechanic, as players can fire, recall and quickly
Counter their own Spell in one swift motion to instantly gain Armor and access to a Killdash. Naturally, the usual risk applies as inaccurate timing will result in self-afflicted harm at the cost of precious Bloodlust.
Between Swarm Control's straightforward application and low Bloodlust cost, Pestis is a character well suited for novice players while maintaining enough flexibility to satiate more advanced players. Pestis is the unadulterated manifestation of Counterspell's "easy to pick up, hard to master" design mantra.
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
And subscribe to our YouTube channel for the latest footage!
https://www.youtube.com/channel/UCyw9YzmZVZspWMWA8_JaeNA
COUNTERSPELL: DEV UPDATE - 32 | The ‘BLOODLUST’ System
Introduction:
‘Bloodlust’ is Counterspell’s new resource system, through which players can access a character’s unique ability. This post will detail the design of the mechanic and elaborate on how it influences the way the entire game is played.
Conception:
Throughout development we have gone to great lengths to aesthetically diversify Counterspell’s cast of characters: they all have their own unique models, animations, sigils, projectiles, impact effects and kill sequences. Beyond this, however, all characters played absolutely identical. This was a deliberate design decision to give every player the exact same tools and through it a level playing field, in keeping with our “easy to pick up“ design goal. As development went on, however, the game felt like something was lacking in the competitive department and was suffering from passive, overly defensive playstyles being a viable way to play - which was not how we intended the game to flow.
Resource Management:
A resource system allows us to penalize undesirable player behaviour and reward the behaviour we intend for the game. Locking special abilities behind a finite resource that has to be built up and maintained also enables us to make the actual abilities pretty strong and significant because they won’t be available all the time. In turn, strong abilities also present an incentive for the player to indeed engage in this suggested style of play. An obvious danger to this design concept is, of course, the possibility to restrict a player too much and homogenize player expression in the process.
The table below shows the different criteria for gaining or losing bloodlust.
Bloodlust increases gradually as players find themselves in eachother’s vicinity, whereas standing still or turtling away from the action for too long will see the resource gradually decay. Further bonuses are earned by narrowingly avoiding and countering projectiles, killing other players and interacting with hazards on the stage. These all encourage risky and aggressive playstyles, which keeps the matches fast and vicious. Notably, a slight penatly to bloodlust occurs when a block attempt does not find a projectile to counter or deflect. This is to discourage wanton, pre-emptive blocking, which slows down the game. Though as a natural result, having the right read is now more satisfying.
Because of these criteria, more players on the stage equals more means of building bloodlust. The rate at which bloodlust builds increases automatically with the amount of players. This ensures it will not build too slowly in, for example, 1v1 situations.
The Gauge:
With a new resource system we would of course need a means to communicate the gain and loss of said resource to the players. We designed two meters for this: one beneath the actual character models and one in the life/score counters in the corners of the screen.
As you can see, the gauge can be broken up in multiple stocks. This, in combination with a maximum amount, gives us access to another attribute which we can use to balance and diversify the different abilities. For example, we can design relatively powerful abilities that take a while to unlock, or more modest abilities that can be used more often.
In this instance, the ability is available at 40 bloodlust, but up to two uses can be stored at 80.
Next time we’ll take a closer look at the actual abilities and what they offer to the gameplay.
To stay up to date with our latest news, follow us on Twitter!
@punchbuttonstudios_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
Introduction: This is a step-by-step breakdown of one of our character’s projectile impacts, shown below. The focus lies predominantly on the actual shader construction, which is a prerequisite component for the complete, more elaborate effect. When attempting to recreate anything shown here, try to experiment with changing these variables and observe the effects of said changes – it can be very beneficial to the learning process.
Difficulty: Advanced
Subjects: Alpha Masks, Blending, Sheet Animation, UV Manipulation (Rotation, Flowmaps)
Prerequisites: Elementary understanding of Shader Forge (or similar node-based shader editors) and its terminology. Many elements build upon the previous breakdowns, so it is highly recommended to (re)visit these before attempting to follow this particular breakdown.
1.) The Cloud
This effect consists of a gas-like cloud and splitting bacteria within it. First we will construct the gas, which should be a straightforward process if familiar with the Eileen and Sneglii Projectile Breakdowns. We have two textures with their alpha channels properly set up and simply combine them through a Blend Node. A multiplication would also work, but a Hard Light blend gives the images a little more contrast. Experiment with different blend modes to discover different results. Also, don’t forget to add either texture’s alpha outputs to one another.
Next up is once again adding flowmap distortion to the UVs of these two textures. The setup below should look familiar by now, but there are some slight alterations in comparison to the setups we’ve seen earlier. We’ve added UV rotation to the actual flowmap itself and adjusted the time-driven sine by remapping its values.
When fed to the textures, this creates a sort of pulsating effect. As this exact same flowmap texture is used for the Eileen Projectile, this is a good example to showcase how you can have drastically different results with the same flowmap depending on the processes it is subjected to.
2.) The Bacteria
Now, it’s time to add the dividing bacteria by way of an animation sheet. For those who are unfamiliar with the concept, an animation sheet is a single texture that holds multiple animation frames. The individual frames are laid out in a grid, which consists of vertical columns (Y) and horizontal rows (X).
We have the right asset, but now we need to build a system to allow the shader to understands how to read this particular texture. A good way to go about this is to compile a list of parameters you suspect the system will need in order to properly process an animation sheet.
> Total number of animation cells
> Number of rows
> Number of cells per row
> Number of columns
> Number of cells per column
> Read only a single cell at a time
> Read order:
1. Start top-left
2. Move right across the row
3. At the end of row, move down to the next row and start in the first column
4. Repeat 1. through 3.
5. When at the last column of the last row, return to 1.
We will now jump ahead to the finished system and the results it produces, and then work backwards to demonstrate how exactly it works. It may seem complicated at first glance, but the network mainly consists of simple calculus operations.
The main input source of the system is the very versatile Vector 4 Node. We’ll be using this node to feed the system information about the grid we’ve established before: X for the rows and Y for the columns, which in this case are both 5. We can use the surplus property Z to dictate the speed of the animation, which for now we’ll keep at 1.
From here we’ll move on to the Time Node, which should be familiar to those who’ve seen previous breakdowns. This node produces a sine wave by default, which results in smooth ease-in and ease-out effects. For this animation sheet, however, we want to have completely linear movement.
Out of focus and shaky. It’s actually a pretty cool effect, just not what we want right now.
To stabilize the movement use the Frac operation to convert the Time Node’s sine wave to a sawtooth.
As you can see, the output now describes a linear ramp with an instantaneous drop. Almost perfect for scrolling across an animation sheet.
Considering we want to cover the entire sheet in one second (or to whatever you set the time to), it is necessary to multiply the sawtooth with the total number of cells, which we can derive from the multiplication of the number of rows (X) and columns (Y) – data stored in the aforementioned Vector 4.
To make sure the system only takes whole cells we have to round all decimals in the output up or down to their nearest integers. Conveniently, the appropriately named Round Node does just that. A nice diagnostics tool to test your network is to use a value Slider instead of the Time Node. You can easily track the values that flow through the nodes at any time and observe that the Round Node produces the results we are looking for. Alternatively, if anything in your shader seems to produce inadequate results, you can use this method to troubleshoot problem areas.
The sawtooth after rounding.
The next step is to define the rows and columns as well as the movement through them.
Starting off with the rows, we want to divide the rounded output with X (which is the amount of rows, as specific in the Vector 4). To prevent the shader from showing half frames we want to make sure that the output after division is rounded down. For this we will use the Floor node, which will result in the graph below.
When testing the network with the diagnostics as detailed earlier, you can see the numbers in action.
Now that the rows are defined, it is time to move on to the columns. To achieve this, we’ll be using Fmod. Like Divide, this node requires two inputs. The image below demonstrates the effects of Fmod within the current shader network.
The long string of numbers represents the entire grid. This string is divided by X (which is 5; the number of rows). This leaves 5 sequences of five, representing the 5 columns on each row.
To steer the horizontal and vertical movement over the grid we simply have to divide by X and Y, respectively. Notice how the division for the verticality outputs 0.2 at the start of the sequence. This means movement starts on the lower side of the Y axis, which is undesirable. As we’ve established in the read order, every sequence ought to start at the top row. To correct this we can use One Minus. This node has made an appearance in an earlier breakdown <link> to invert a Fresnel effect. What it actually does is take the value 1 and subtract its input. Logically, with an input of 0.2 this results in 1 – 0.2 = 0.8, which is the top of the grid. Make sure to append both paths and you’ve got the read order all set up.
Almost there, but we still need to make some adjustments to the UVs. By default, UV coordinates encompass the entire texture, but we want to essentially single out 1/25th of this texture at a time. Take both X and Y from the Vector 4 and Append them and use its output to Divide the UV coordinates.
Finally, add the read order to the UVs and connect it to the animation sheet texture.
3.) Combine
Merging the separate networks together should be relatively straightforward, as the required techniques have been elaborated upon at length in previous shader breakdowns.
Add colour to the animation sheet and use blending to add it to the emission. Be sure to join all alpha channels together.
Extend the flowmap-distorted UVs to the tiling network.
The final results.
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
Introduction: This is a step-by-step breakdown of one of our character’s projectile impacts, shown below. This is a follow-up to the Eileen Projectile Shader breakdown, where we elaborated on the projectile itself.
Although this particular breakdown deals with some (basic) scripting, it is tailored primarily to (VFX) artists. The goal is to show ways to manipulate specific shader properties through said coding to create the desired effect.
When attempting to recreate anything shown here, try to experiment with changing variables and observing the effects of said changes – it can be very beneficial to the learning process.
Difficulty: Novice
Subjects: Access & manipulate shader properties, Access & manipulate variables in other components, Animation curves, time.deltatime, C# basics
Prerequisites: Elementary understanding of Shader Forge (or similar node-based shader editors) and its terminology. As this breakdown builds upon a previous breakdown, it is highly recommended to (re)visit it before attempting to follow this particular breakdown.
Basic understanding of the Unity engine and its interface.This breakdown assumes you are familiar with particular terms such as editor, inspector, hierarchy, gameobject and component.
1.) Shader Forge Preparation
To achieve this impact effect we first need a shader to work with. We’ll be using the previously created projectile shader as a base, and apply the required adjustments from there.
An important aspect of this step is to acknowledge Property nodes in Shader Forge and how they are different from regular nodes. Property nodes are recognized by their green frames, whereas regular nodes are grey.
These are variables that show up in the inspector when you open a material with this shader applied to it.
When hovering over or clicking on these nodes within Shader Forge, you will see an “internal name“ pop up, which corresponds with the name you’ve given to the node. This name - easily recognized due to the prefixed underscore - is very important, as this is what will be referenced and manipulated in the script later.
With that knowledge at our disposal we can start building the required functionality into the shader. The original projectile shader had built-in UV-based rotation. Considering we want to govern rotation by the way of script for the impact effect, we have to take out this UV rotation first.
Next up is a system that allows us to control the size of the hole in the middle of the disc. We will achieve this by creating a second alpha texture to complement the texture we’ve established in the earlier breakdown.
We essentially want to be able to blend these two different alphas in varying increments. For this we will use the versatile Lerp Node. Lerp takes three inputs: A, B, and T. In our case, we will equate the original alpha texture to A and the new one - with the bigger hole - to B. Input T will be the blending agent. For our current objective, a simple value slider - ranging from 0 to 1 - will suffice.
0 = A, 1 = B
Now all we need is an extension to the system to be able to fade out the entire texture. Naturally, we’ll use Lerp once more. This time we take the output of our previous Lerp for A and a plain value of 0 for B. Alternatively, you could remap the alpha values of either texture from 0 > 1 to 0 > 0 to produce the same effect.
The shader is now all set, with the properties _HoleSizer and _MainFade at our disposal.
2.) Unity Preparation
First off, we’ll have to get all the easy stuff out of the way. Create a new empty gameobject, and call it something like “EileenImpact”. Now, add a mesh filter and mesh renderer component to it. Place the disc model from the earlier breakdown in the mesh container, and a material containing the shader in material0 of the mesh renderer. The projectile should be visible now. Finally, we can add a new script component, make sure it’s a C# script, and call it “EileenImpact”.
Double-click the name of your script in the inspector or the asset folder to open it. You should be greeted with the following text:
This might not make a lot of sense by itself, which is why I’ve numbered the different parts of the script:
1.) These are used to access classes in different namespaces. Ignore them for now.
2.) This is the name of the script itself. All of our coding will be done between these curly brackets.
3.) Functions, or voids, are used to tell the game which code to run when. For example, all the code you put in void Start() is only called once, before anything else, on the first frame that the script is active. This makes it ideal for initialisation.
4.) Update(), on the other hand, is called every single frame. Depending on how fast your computer is, this could be dozens to hundreds of times per second.
That’s all you really need to know to write the script. So, let’s start programming!
3.) Changing Transparency
Our first goal is to make our object transparent. To do this, we’ll have to manipulate the “MainFade” property we added during step 1. This means we’ll have to “talk” to the gameobject’s material, which is, in turn, stored in the mesh renderer component of our gameobject.
We only want to change the properties of THIS object’s material, not EVERY instance of this material.
First order of business is to give this material a name within our script, so we can talk to it more easily. Add the following line above the start void:
Now we have to tell our script which material we’re referring to by “myMaterial”. We do this by using the method “GetComponent”. This method will search our gameobject and look for a specific component, in this case the mesh renderer. To get the material within the mesh renderer, add a dot, followed by “material”. We only need to find it once, so we should put this line of code in our Start() function:
We’re finally ready to set the “MainFade” property of our material to any value we want. The way to do this is by using a method called “SetFloat()”. Between the parentheses, you’ll need to type the name of the float you want to change (in this case: “_MainFade”), followed by a comma, followed by its new value (1, which means fully transparent):
Run the game to see if this works. If you did everything right, the projectile should be fully transparent in play mode, but colorful outside of it.
It works!
4.) Fading Transparency
Of course, we don’t want our little vortex to “jump” from opaque to fully transparent within a single frame. Rather, we want it to fade out smoothly, over time. That’s what we’re going to add now. Often, the most intuitive way to do fades and transitions is by using animation curves. So let’s add one to our script. Above the start function, add:
But why is this animation curve public instead of private, like our material? Good question. It’s so we can actually change the animation curve in the inspector! That’s right, let’s head back to the inspector, and there should be a little grey rectangle in your script component. Click it, and you’ll open a dedicated curve editor:
A familiar sight for most game artists.
Although it’s nice to play around with, our animation curve doesn’t really do anything right now. We want the transparency of our gameobject to change over time. This means the y-axis of the curve should correspond with the value of the “MainFade” property, and the x-axis to the time (in seconds) since our gameobject’s creation.
If implemented correctly, this point on the curve should mean: "After 0.5 seconds, the value of mainfade is 0.5".
So let’s add a timer! Like before, we start off by giving this variable a name, “timer” in this case. Above the Start() function, add:
We’ll also have to make sure that our timer always starts counting from 0. In the Start() function, type:
Now we have a float that sets itself to 0 when it’s created, but it doesn’t measure time yet. To get it do this, we’ll have to make use of “Time.deltatime”, which measures the time (in seconds) that has passed since the last frame. This means that if we increase the value of our timer variable by Time.deltatime every frame, we’ll have an accurate measurement of time:
Make sure you put this line at the very top of the Update fuction; counting should happen before anything time-based.
Now that our timer works, we can link the animation curve to it. Go to the line of code in the update function, and change the “1” into “mainFadeCurve.Evaluate(timer)”:
This line of code means something like: “Set the value of “MainFade” to the y-axis value of “mainFadeCurve” at the current point in time”. So this works now. Try playing around with the animation curve from the curve editor, to see what looks best.
The result of the default curve from 0 to 1, in 0.5 seconds.
5.) Fading Hole Size
It’s time to add another effect: the expansion of the hole in the middle of the vortex. This step is almost identical to the last step. Again, we start by creating an animation curve:
And again, we’ve got to link this curve to the timer like so:
And we’re done!
The result of a quickly accelerating curve from 0 to 1, in 0.5 seconds.
6.) Fading Object Size
One of the things that makes the impact effect exciting, is the fact that it expands while it’s disappearing. This makes it look like the vortex is made up of some kind of gas, or plasma, which is being dispersed. Let’s add this feature to our script! You know the drill by now, just add another animation curve to the top of the class:
To change the size of our gameobject, we’ll have to talk to its Transform component. This is where all the values concerning the position, rotation and scale of a gameobject are stored. Unlike other components in Unity, we don’t have to use GetComponent to access our transform. The property of the transform that we need to change its size is called “localScale”. So, if we’d treat this property the same way as in the previous steps, we’d end up with:
...but this doesn’t work.
That’s because localScale is not a float, but a vector3, which is a variable that actually contains 3 different values! They’re always between parentheses, and separated by commas. The first value is the x scale, the second value the y scale and the last value is the z scale of the object.
This means that localScale expects that we give it a vector3 to work with, instead of a float. In C#, this means creating a “new” vector3 every frame. We then have to fill all 3 values of newScale with the y-axis value of our curve:
So the above line of code means: the value of localScale.x, localScale.y and localScale.z is the current y value of scaleCurve.
OPTIONAL: We can abbreviate this code to make it less ugly/messy, by typing it like this:
The result:
The result of an exponential-style curve from 1 to 1.5, in 0.5 seconds.
Feel free to try different kinds of curves this time. Making the projectile shrink instead of grow might look good, too!
7.) Fading Object Rotation Speed
For the final effect, we need to spin the disc. The fact that the rotation slows down over time really sells the idea that the disc is dissipating its energy. Here we go again!Blah blah, add a curve:
I'll just assume you know where to put this by now.
As I’ve explained in the previous step, the data concerning rotation is stored in the transform. Transform contains a method called “Rotate”, which kind of explains itself. Like localScale, Rotate wants us to feed it a vector3. Since we only want to rotate our object along its y-axis, we just have to fill in the second value of the vector3:
Pay attention! This spinCurve is the first one that needs a high y value to be noticeable. It’s probably best to start with a value of 30:
Right click a key, then click "edit key" to type in values. Will save you a lot of trouble!
The final result, after some tweaking:
That’s it, folks! I hope you learned something, be sure to leave some constructive criticism if you didn’t. Talk to you later, bye!!!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
Introduction: This is a step-by-step breakdown of one of our character’s projectiles, shown below. The focus lies predominantly on the actual shader construction, not so much individual variables such as specific images and values. When attempting to recreate anything shown here, try to experiment with changing these variables and observe the effects of said changes – it can be very beneficial to the learning process.
Difficulty: Intermediate
Subjects: Fresnel, Light Dispersion, Refraction, Screen-Space Effects, UV Manipulation (Panning, Flowmaps)
Prerequisites: Elementary understanding of Shader Forge (or similar node-based shader editors) and its terminology. Some elements build upon the previous breakdown, so be sure to (re)visit it if necessary.
1.) The Bubble
Sneglii’s right arm is based on that of the pistol shrimp; a creature capable of using its oversized claw to propel “bubble bullets” at potential prey. As such, this projectile will have the characteristics of a bubble: a transparent surface that refracts shapes behind it. As this is Counterspell, the projectile also requires a clear colour indication. To start, we’ll set up a simple bubble using a Fresnel effect to also outfit it with a distinguishable colour. A default sphere will work fine to preview this shader while you work on it.
For reasons stated in the previous breakdown, we will use the Unlit shader again.
Use the Fresnel Node, multiply it with a colour of choice and then plug it into the emission. Adjusting values for the Fresnel’s exponent controls the thickness of the rim; high values for a thin rim, lower values for something more broad.
We got the colour system in place, but it’s anything but transparent. This is easily fixed by using the Fresnel for opacity.
2.) Refraction
Refraction is an operation that distorts the pixels behind the object as you look through it. The particulars of this distortion can be managed by using a normal map.
Considering this distortion is achieved by offsetting UVs, the effect expects the red and green channels associated with UV operations. Extract these channels from the RGB normal map texture by using a Component Mask. Use a Remap Node to tweak the intensity as desired.
To get some movement in the newly created refraction, we’ll pan the UVs of the normal map texture. Having values in both U (horizontal) and V (vertical) will get you a nice diagonal scroll.
In order to make the object look more like a liquid, we’ll conjure another flowmap. The setup is similar to that of the Eileen Projectile, bar one addition; whereas the animation in the distortion there was driven by the rotation of the UVs, here we will actually animate the flowmap itself as well. To achieve this, create a sine with the Time Node and multiply it with the conventional flowmap setup. Finally add the output to the already panning UVs.
It’s starting to look like a bubble now, but there’s another element that can be added to make it a tad more interesting to look at.
3.) Light Dispersion
Dispersion occurs when white light is separated and “split” into different wavelengths. This concept is often demonstrated with the use of a prism, or commonly observed as a natural phenomenon in the form of a rainbow.
Knowing how this effect occurs in the real world, it is now possible to figure out how to simulate a recreation in the shader; we basically need to offset the colours that we see through the projectile. To achieve this, we need to extract the colours that are present in your scene. Conveniently enough, Shader Forge has a Scene Color Node for that. The extraction of the scene colours effectively simulates transparency, so we no longer need to have the Fresnel generating opacity.
Unfortunately this has created a new problem. As you might be able to notice, the projectile’s colour is significantly lighter. This is because the Fresnel is now blended with the scene colour data behind it. This means that the colour will be different depending on its background, causing potential inconsistencies in projectile colours. This is highly undesirable in Counterspell, as this may have a negative impact on readability. To correct newly surfaced problem we can use the Fresnel that we have as a mask of sorts to tell the shader to only take the scene colour where the Fresnel doesn’t cover the background.
A good method to achieve this is by inverting the Fresnel using the One Minus Node, and subsequently multiply the scene colour with it.
In order to offset the different “wavelengths” we need to split the RGB channels of the extracted scene colour, so we can adjust these individually.
With that out of the way, we can start building a system to actually perform the offset. The core of this system is the Screen Position Node, which we use to shift UVs in screen-space. When adding a value to either the U or the V we can ultimately offset colour channels vertically or horizontally. In order to offset to both left and right with the same value we add a Negate Node. You can see the setup in action below.
Now all there’s left to do is hooking up the offset system to the separated scene colour channels.
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
Introduction: This is a step-by-step breakdown of one of our character’s projectiles, shown below. The focus lies predominantly on the actual shader construction, not so much individual variables such as specific images and values. When attempting to recreate anything shown here, try to experiment with changing these variables and observe the effects of said changes – it can be very beneficial to the learning process.
Difficulty: Novice
Subjects: Alpha Masks, UV Manipulation (Rotation, Flowmaps)
Prerequisites: Elementary understanding of Shader Forge (or similar node-based shader editors) and its terminology, capable of image creation, basic knowledge of 3D modelling and UV unwrapping.
1.) Initial Maps
To start off we’ll need a texture map for some colour differentiation and an alpha map to use as a transparency mask. It is possible to use two separate maps for this, but here we’ll use an image format that supports its own alpha channel – in this case Targa. This method is generally favourable because this way there’s only one texture file to bother with. This being said, needs may vary on a per-project basis.
Texture and alpha.
Considering we’re creating a spinning, buzz saw-like object, make sure you have a disc-shaped model to put the shader on early for proper reviewing in Shader Forge.
2.) Basic Setup
We really want this projectile to light up by itself and not really have it affected by external lights and shadows being cast over it. In order to achieve this goal we’ll have to start off with a Unlit shader.
Characters in Counterspell come in a variety of selectable colours; therefore, we need a variable in the shader that allows us to assign these to the projectile. This process is relatively straightforward: multiply the texture with a colour of choice, and multiply that with a value for delicate fine-tuning of the emission (“glow”). You may be able to reach satisfactory results with just the raw colour, but Counterspell deals with varying bloom levels in specific scenes, so a value property is very useful.
Instead of multiplying the colour with the texture, try out different blend modes and see the results they produce.
Now it’s time to hook up the texture’s alpha channel to the opacity. It already starts to look a lot like the projectile we’re looking for, but it doesn’t animate yet.
Remember that the alpha map is already in the alpha channel of this texture. Setups with a separate alpha map would need an additional Texture Node.
3.) Rotation
Although it’s possible to physically animate rotation for the actual model the shader is applied to, doing so within the shader itself is less of a hassle and leaves you with more control. We’ll do this by manipulating the UVs on the model, so make sure the UVs on the model are laid out properly for the best results.
Nice and centered.
For the actual rotation, we’ll simply use a Rotator Node as shown below. Connect a Time Node to the Angle of the Rotator Node to simulate continuous spinning. Subsequently add a value to the Speed to control how fast it spins. Alternatively, you can multiply the time with a value and connect that to the Angle to produce the same result. This is a demonstration of how there are often multiple ways to achieve the same result. Experiment with these options to find out what works best for you or your project.
The negative value produces a clockwise rotation, whereas a positive value will create a counter-clockwise rotation.
4.) Flowmap
The shader is starting to look about done at this point, but there’s one more element to add to spice things up a little. If you’re unfamiliar with flowmaps, I suggest you read up on blog post 15. We want to use a flowmap to distort the UVs. Start off with isolating the red and green channels of the the flowmap texture by using a Component Mask Node. Next, add the output of that to the already rotating UVs. You’ll end up with a network as shown below.
The image below previews what the projectile looks like now. It surely looks “interesting”, but not necessarily what we’re looking for. This effect is caused because the flowmap-generated distortion is too strong, and as such the UVs are pushed out of their initial UV space.
To remedy this problem, it is possible to Remap the values of the flowmap to make it more subtle. Multiply the remapped output with a tenth value for even more control.
It could use some more tweaking of values, but this is the gist of it.
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
It has been quite a while since the last time we posted a development update. About 9 months in fact. The reason for this is that we were busy trying to finish our studies. A few of us succeeded, a few of us didn’t. During this period, development on Counterspell was close to completely halted.
But now, we’re back.
At the moment, we are focusing all of our efforts on finishing Counterspell and getting it ready for release. This means that we will mostly be working on finishing off features, fixing bugs and polishing everything that is already in the game.
For me, this meant implementing UI. Lots and lots of UI. Is this a very long and tedious process which will eventually lead to me longing for the sweet embrace of death? Most definitely.
The first UI system I implemented since our last post, is the UI for the Foundry. This system took quite a lot of time to design and even more to implement, due to the complexity of the Foundry and the difficulty of presenting that in a usable fashion.
I’ll go more in-depth into how this system is designed and set up in a later post, as I have recently learned that some more fixing and implementing is required...
Something I worked on recently, is a feature that was very much needed in Counterspell. A settings menu!
Though the systems that run in the background and actually do stuff are fairly old, the settings didn’t actually work properly until they were set up neatly in the UI system you see here. It’s not finished yet, I still need to set up the UI for changing key-bindings and it might be handy to have a button that reverts everything to its default settings. But it works, and more importantly, it actually looks good!
This week, my focus will be on implementing singleplayer challenges into Counterspell. This is the only thing that we’re adding to the game in this final spurt that wasn’t already in there. But more on that next week.
FX CO-OP - Ernst & Joey | Subtly Polishing Stages
The visuals of most stages aren’t quite ready for launch yet, so this week Joey and I took it upon ourselves to update them.
First up was Open Sea. One of the big problems with this stage was the lighting. It didn’t look like the action was taking place during the night-time, despite the skybox clearly featuring a full (blood)moon.
Old
To address this, we darkened both the water reflections and the main light source, trying to find a sweet spot where the stage looks dark enough but still visually interesting. We also changed the colour of the light source to a much cooler shade of purple.
New
Another problem with Open Sea had to do with layers in the composition. Close to the camera, there’s a lot of activity; ocean waves, spinning rotors, splashes of water and so on. All this movement makes the second layer, the skybox, look awfully lifeless and fake. What we needed was a third layer in between the two, to help them blend together. We added two groups of slow-moving clouds in the distance, which both scroll at different speeds. This helps a lot, but we might need to change the texture of the clouds to something that more closely resembles the ones on the skybox itself.
Next up was Moonlight Temple, which also received some overhauls. We changed the lighting to better match the skybox, which made everything just a bit shinier. We also added a particle system not unlike the one featured on Orbital Mining, to keep the amount of foreground activity somewhat consistent between stages. The result:
Although we’re by no means done (the bloom on Orbital Mining is still a bit too much, and our skyboxes still look like cubed piles of misery), this week we’ve gotten a lot closer to our visual goals.
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
This week, Joey and I finally got round to making a unique gibbing effect for Pestis' projectile, which consists of a swarm of overly aggressive insects. We wanted to somehow create the illusion that the bugs actually eat their prey after they tear it apart. My idea was to reuse or virus impact shader, which dissolves textures into nothingness. I figured that if we'd stick a couple of bones through some dissolving limbs with a lot of bugs flying around it, it'd look pretty convincing. Joey 3D-modeled realistic looking human bones, and we tried my idea.
After a lot of testing and tweaking it looked pretty good, but it was still lacking something. But then Joey thought of a brilliant way to make the effect look more convincing. Realistically, a giblet wouldn't be laying completely still on the ground while 30+ bugs are viciously gnawing away on it. The insects would probably pull it all over the place. I made a script that simulated just that and after two days of work, the effect finally felt complete. Here is the final result:
LEAD PROGRAMMER - Jeroen | Drawing the Lines
Okay, small post from me this time. Most work I’ve done past two weeks consists out of cleaning up things I’ve made for the new Foundry looks and works and, frankly, it’s not all that interesting - unless you’re amazed at things like automatically scrolling scrollbars. Other things I’ve done are mostly still work-in-progress (yes, I have works-in-progress in a work-in-progress). Although there is one major-ish thing I can show off.
What is new this time - and frankly a thing that should’ve been there since a long time - is the lines for the waypoints and targets. Of course, the waypoint system always had lines connecting the dots, and therefore kind of showing the path. Kind of. But with the addition of numbers and moving arrows (via a simple shader I made) it is now actually clear what the start of the route is, what the end of the route is. Overall this makes it easier to configure things such as the button’s start and end positions for i.e. the laser turret.
Woosh! I wonder what this turret’s path is…
The waypoint arrows still need a little bit of tweaking due to a bug in Unity’s line system, but it’s not a lot of work.
Additionally, as you can see in the image, the same kind of arrow (although a little altered in its looks) is present for the target system. These, unlike the waypoint arrows, are always visible. Fancy, huh?
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
LEAD DEVELOPER - Bas | Counterspell Rising: Revampgeance
I’ve spent the last weeks trying to rebuild, rewrite and reorganize all the systems involved in choosing the gamemodes, stages and characters at the start of a match. If everything goes well, I should be done very soon. which is nice.
This is what the screen currently looks like backstage. (This is fine)
Every little bit of this mess animates in a particular way, functions in another way and interacts with all the other pieces in another different way. Fun!
As a little preview of how it all will function: this is how the menus transition to one-another.
It’s so pretty and swooshie!
I’m thinking about giving a short tutorial on how some of the interesting quirks the UI system in Unity has and how to work efficiently with them, but that really depends on how much time I have and how much content I have for the next post.
LEAD PROGRAMMER - Jeroen | Coloring the Right Speed
So in the past few days I decided to break a foot. On the positive side, I can always work from home, and so I did. In fact, I’ve mostly been spending my time working on the level editor, adding in improved versions of functions.
The first thing I’ve improved is the way you adjust the lighting color in the level editor. Previously you had 4 different sliders, three for the RGB-values and one for the intensity of the light. One thing that’s most definitely more intuitive for this is a color picker - and so I made one. It was a bit of a hassle to get working, but I did it! The input is HSV (hue, saturation and value), and gets converted to the RGB system that Unity (and most other programs) use.
Now pick a nice color for that stage!
Next up, I’ve improved the camera panning controls even more! Previously you’d either had a slow speed when panning fully zoomed out or super speed when fully zoomed in. Now, I’ve set up the system to adjust the speed depending on how far you’re zoomed in. This means you now pan the camera faster the further you’re zoomed out, allowing for more precision when zoomed in.
See?
I’ve reworked some other things, but nothing noteworthy as of now. Hopefully I’ll have more next week!
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
After finishing up a character it is sometimes nice to have a breather with some “lighter” work. Since Bas has been reworking the UI and menu systems we needed various new menu assets. This was also a great time to give said menus more visual uniformity by correcting some aesthetic incongruities. Early Counterspell menu items had a grimy, very weathered metal look, but this shifted to cleaner stone-like qualities with the character select screen. The changes are very apparent in the Game Mode Select screen in particular.
The old Game Mode Select screen.
Assets for the new Game Mode Select screen.
The new Game Mode Select screen also had to accommodate for more game modes and a list for player-created variants on said game modes.
The different icons for all current main game modes.
The Stage Select interface was needlessly elaborate and had to accommodate more for user-generated content, as well as a different way to show which hazards were present on the currently selected stage.
Different hazard icons. The greys and blues are in line with the color scheme of the standard Foundry tileset.
The one thing we really like and therefore maintain in the reworked Stage Select screen are the stage holograms. In order to elevate its presence I’ve made a model for the actual hologram device.
Spin me right round.
LEAD PROGRAMMER - Jeroen | Rebuilding the Builder
In the past two weeks I’ve been working on a few features and an overhaul. One of these features I don’t quite want to talk about yet. It’s a feature that’s important for the final release, but it’s not quite done yet, and I’ll talk more about it once I’ve gotten the time to focus on it. The other feature is less impressive: The audio options menu. You can set the SFX volume, BGM volume and master volume of the game here. Nothing big.
Now, let us talk about this big overhaul. A while back I wrote about how I redid the Game Ruleset menu. The way it was set up was… Disappointing to say the least. But besides that, there was something bigger. Something else that was all set up to fit the basic needs. The Foundry: our level editor.
The Foundry was initially set up to work functionally, but it has never been final (and still isn’t yet). It always had a few simple keybinds for a few functions - even though the structure was all set up to work way more dynamically. As of right now, my task is to make use of that, and make the Foundry (finally) user-friendly!
Being a bit messy at first, I’ve begun to clean up the Foundry’s code, separating a whole controller system off of the main system - which allowed me to bring in some tweaks regarding camera control and the likes. Selecting “tiles” has become much easier using a menu and I’ve added in a few options for Ernst to add in effects when tiles are removed.
We now have effects AND better camera movement!
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
FX Co-op - Joey & Ernst | Bolasting appeal
(We’re very sorry)
This week, Joey and I teamed up to finally give poor Fuller his own projectile impact effect. We started by trying to envision what would happen when Fuller's projectile, which consists of two intertwined rotating “plasma bolas(es)”, were to hit an opponent. We theorized that the bolas would ensare the victim, temporarily stunning it. After wrapping around the poor soul a few times, the plasma bolases would meet and explode violently as a result. This would of course cause the victim's limbs to fly in all directions. Such is the nature of Counterspell, after all.
Fuller's plasma bolas.
Fuller's impact effect would be Counterspell's most ambitious death effect yet, being the first to have multiple stages and require it's own unique animations. At first we tried to make the bolas meet in the middle by scaling Fuller's projectile effect, but that didn't look very convincing. So Joey had to open up Maya and create the wrapping effect from scratch, while I was providing him with a constant barrage of suggestions from the sideline. This is what we ended up with:
Finally we meet.
After that it was time for me to create new scripts for the bolas themselves, and to add a lot of new functions to our giblet script. Until now it didn't support delayed effects, and a lot of extra code had to be added to make everything sync up perfectly. We also thought it'd be cool if the bolas would take their victim for a little ride in the direction they're flying, so we added that in. The “wrapping” stage of the effect was now done.
“pls halp”
The final thing that we needed to add was an effect that visualized the violent release of the energy that occurs when the plasma bolas meet. I thought that death effect already looked pretty good without an explosion, and that any further additions should have to be subtle. Joey, on the other hand, wanted a lot of smoke, a pillar of fire and a laser shooting at the sky. We started with the fire. I didn't particularly like the way it looked, but joey was adamant that we should only dismiss it if it didn't look good in combination with the laser. One laser effect later and it was clear that the effects didn't really blend together all that well. We decided to remove the fire, and both really liked how spectacular it looked. Very violent and over the top.
The finished effect.
Looking at it now though, I think it might be a little bit too much in comparison to Counterpell's other gib effects. A game with four Fuller's playing at once would probably be too much of a seizure-inducing experience. We'll have to look at that in the future.
LEAD DEVELOPER - Bas | Rebuilding, Reworking and Revamping
When we first started with the development blog I was working on the new character select scene and systems. Right now, a little more than one year after we started our devblog I’m once again changing not only the character select, but all menu screens in Counterspell. My plan is to unite the the custom game screen, the level select and finally the character select into one scene. I’m doing this to improve the flow between the scenes you encounter before starting your game by removing unnecessary loading screens and creating a more consistent style for the different screens.
The character select screen as it’s currently set up.
As you may imagine, this is going to take quite a bit of work, both on my part and Joey’s as he’ll be reworking the art for the custom game and level select scenes. Right now I’m busy setting up the things required for the character select to work. This means setting everything in the correct places, setting it up so the system will be able to work and then animating everything to make sure it feels nice.
What I’ll probably be doing is first setting up the different assets required for each screen and then reworking the scripts used in each system, starting from scratch with the current scripts as reference. It’ll probably be more work trying to alter the current scripts as pretty much nothing will be the same as in the current scene.
As I said, a lot of work...
Other than that, this week I had to fix a bug that caused the game to shut down when you tried to play it in a build. It did not show up in the editor in any way, so I had to re-build the game every time I wanted to test it. It wasn’t a very pleasant experience.
Especially because it turned out that I had forgotten to put -1 next to a value I was looking for in an array and it wasn’t showing up as an error because it was inside a try{} catch{} where the catch shuts down the game and creates an error log file, but doesn’t notify me that it has…
Oh how I love game development sometimes.
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
Our newest character, Sneglii, has many wiggly bits. Chiefly the tentacles on the face and wormlike protrusions on the back. Although comparable with Cosmosis’ tentacles, these details wouldn’t need the same amount of control. Rigging Sneglii’s ‘noodly’ bits the same way would be ineffective and a general waste of time, but the effectiveness of these elements would be severely diminished without animation. Thankfully, there’s a perfectly fine solution to the particular problem: ‘Blendshapes’.
Often used in facial expression animations, Blendshapes allow you to create one or multiple modified instances of a subject and subsequently use animation in order to blend the original subject towards or away from said instances. Below is an example of this method being applied to the tentacles.
First, you need your original model.
Then you need to create modified instances of that same model. These will function as different states you can have your original model blend with. Logically, with more states comes more controls, but in my case I felt three was enough.
I have applied the same process to the spindly objects on the back of the character. Below is an example of the Blendshapes working in tandem with the rest of the animations, which are powered by a more conventional bones system.
LEAD PROGRAMMER - Jeroen | Saving Nitires
So this week I’ve been working on two things, of which one is related to the other. They’re both things that already were in the game, but could be done better, or were just done badly in the first place.
First of all, the player traits system has been redone. The whole way its menu works is now a lot better, making the best use of Unity’s UI system as I’m able to. This way it’s a lot less of a hassle to make new additions or to adjust the UI’s graphical appearance. In addition, there has been a major change the way the rulesets function. Previously, you’d adjust the traits depending on which player you were (player 1, player 2, player 3, player 4…). This has now been redone so that it doesn’t depend on which player you are, but which character you are. This means Eileen could be fast but have higher cooldowns, Cosmosis could fire bullets more frequently, but is slower and Fuller could shoot out 8 bullets in different directions instead of getting armor when parrying a bullet.
Everything here is or may be subject to change
Besides that, I’ve also reworked the “Saving & Loading” dialog. When Bas made this, you had two different UIs for saving and loading, depending on which of the two you did. The code that’d save/load the specific data (foundry stage, player trait ruleset…) was also present in this system. The way I’ve redone it, it consists out of a single UI that can be repurposed for almost anything. When called, the UI can be set to either loading or saving, and can even be set to allow navigation through multiple directories. Though navigation may initially not be used in Counterspell, it may in future projects using this system. If the file to load/save has been selected, the system will return the file’s path to the caller, which can then use that to save/load that specific file.
The looks of the file data can easily be adjusted to fit the kind of file you’re saving/loading.
Anyway, that’s been most of my work for this week, next week there’ll be more waiting for you people, so stay tuned!
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
Considering the previous character was probably the most human looking character for the game thus far, it felt like a good time to delve into the odd and peculiar again. When going for this particular brand of design and finding yourself in need of inspiration or reference, you cannot really go wrong with deep-sea creatures. And maybe some insects. Insects can get funky. I wanted this character to be strange and decidedly un-human, but also pretty – maybe even flamboyant – to look at.
Eventually, my reference sheet looked something like this:
For Counterspell, characters will need to fly or hover. This is where the silk moths come in, with very discernible wing shapes that will give the character a recognizable silhouette. The tube-like protrusions of nudibranchs – or sea slugs – are also ideal elements to create a unique contour, as well as effective pieces of geometry to add player colors to.
On a quest to make a less-than-threatening looking combatant for once in order to give Nitires some competition, I originally tried to shape the head like that of a silk moth, but with the cuttlefish’s tentacles attached to the face. However, it started to look more like an aardvark in the blockout due to the moth antennae being easily perceived as ears. I decided to keep going with that because aardvarks are ‘totes adorbs’. It’s one of those happy accidents that just work out.
The pistol shrimp’s massive claw is perfect as the source of the character’s projectile. It also allows for a certain degree of asymmetry, a concept that will make this character stand out from the established cast even more.
Hammer cocked.
Boom.
Butterfly (or some moth) wings have patterns that look like a predator’s gaze to ward against threats. I wanted to take this nifty piece of evolution and use it as a reference to another character within the game. Whose ‘face’ are these wings trying to mimic?
LEAD SOUND DESIGNER - Ernst | Kill Me
One of the most important things to finish before our next big milestone build are our gib and projectile effects. We've been using placeholders for far too long. This week, I made a new explosion effect for the latest character
we've added, Ignis. Notice the little heat distortion effect going on.
New splosion means new giblets, and so far I've made flaming gibbing effects for four of our characters, next week I'll finish the rest of them. They look a little something like this:
See you guys next week.
LEAD DEVELOPER - Bas | Reporting Carnage
It’s already been 2 whole weeks since we showcased Counterspell at Firstlook, yet we’re still working on fixing and implementing things we noticed or thought of while we were there. It’s quite the list so I’m going to try and narrow down the things I’ve changed into a few overarching subjects.
Let’s start off with one of the more mayor fixes, the rebalancing of Juggernaut mode. Fixing this mode required us to first overhaul the indicator system.
In the new indicator, a few different things are indicated. When a player has acquired armor, a bar indicating how much time they have left appears.
Once this bar is empty, the player will lose their armor.
When the juggernaut loses their armor, the bar indicates when they’ll regain it.
The top part of the indicator shows which player is playing as this character. This will be integrated with one of our new systems where players can select their own profiles to play with. When a player selects a profile, their name will be displayed above their indicator. As such, a profile name can only be a maximum of 3 characters long.
The player profiles don’t really do a lot yet, but eventually all sorts of things will be recorded into the database for users to review or gloat over.
Continuing with the Juggernaut mode, you can now select in you ruleset if you want the Juggernaut to be selected automatically at the start of a match, or grant it to the player that gets first blood.
Another thing we decided to add was a speed multiplier to countered projectiles. Now when a projectile is countered, a multiplier is added to the speed, meaning that the old projectile tennis duels have gotten a lot more interesting. Because of this new variable you can also set it so that projectiles will slow down when they get countered.
As Firstlook has passed I’m also starting work on some big overhauls. The first thing I started overhauling is the “post game content advisory update” or carnage report. It was originally designed to allow for more than four players, but that unfortunately was a feature we didn’t have the time to implement. The post game report is now way more streamlined, snappy and feels way better.
Now, it displays very clearly which player has won and why, while also rubbing it in the losers’ faces that they lost. After that, it displays the basic stats in a very clear and simple view.
It’s still very much work in progress, for example: I didn’t get the feel right yet and have to experiment a little bit more. But that’s for after I’ve finished all the things still on the list.
ARTIST - Jaden | Chibi-spell 2: Chibi Boogaloo
Before Firstlook I showed some sketches of some of characters in their chibi form. Now that Firstlook is over I’ll share the final 6 designs and some progress shots of how they were made. Of course the 2 final characters still need to be added once those characters themselves have been finished.
Now, to quickly walk through the steps.
I usually begin with making some rough thumbnails for the character I want to draw, I try multiple poses and the ones that are liked most by the team are chosen to be finished, these 6 were picked.
I continue by adding a little bit more detail, turning the small thumbnails into sketches I can work with onto the next step.
Cleaning it up just a little and adding some more things as guidelines for myself, the reason the two other characters are not there is because they are more robotic so I use a line tool to add most of those parts, which isn’t a super good representation for this step since besides some tweaking I work with those lines for the finished lineart.
Making the actual lineart is the next step, and this usually takes me the longest time out of the whole process.
Colouring is pretty straightforward and simple, I make a base colour layer and make sure that I colour everything I want to colour in something like green (usually using a red background to see if I coloured everything). I then mask all the other colours to that base layer. If the lineart is clean enough this doesn’t take too long, since I am able to select all the separate parts with a tool like that magic wand in photoshop.
This time around I decided to add some effects before doing other things, but I also sometimes do this as one of the last things.
To finish it I first shade, then I add some colour overlays and final effects. Some final tweaks and touch ups that I forgot earlier in the process and then call it a day.
During Firstlook we handed out these stickers and a poster with all the designs. This poster shared the background with the flyer I made to promote our game as well this is how they looked:
“This is a good quote” - Bas Klein
Please note that we’re currently reconsidering that Q4 release.
Besides promotional material I also have another thing to show, some work in progress of two skyboxes. A sun rise and a blood moon, of course they need some final tweaks, but here is a preview of how they look so far:
LEAD PROGRAMMER - Jeroen | Profiling the Players
Being past the Firstlook deadline, and having showcased our game, we’ve found a lot of issues that needed fixing. Amongst these were both some minor and major bugs, like the portal hazard not working properly or players still having invincibility after shooting a fireball. Most of these have now been fixed, and the game works better than ever before! But this doesn’t mean it’s done quite yet.
For one, we thought giving custom profiles to players would be a nice addition. Players would be able to create a profile with their name, which they could use to store personal game-related data on, such as who their favourite character is, their highscore, win/lose ratio… The system for this is quite simple: in the DataManager - a script for general purposes that stays consistent throughout almost the entire game and its menus - there would be a list of “profiles”. Each profile would store the data said before, and the version of the game they were last loaded on, so the game knows when to back them up. The DataManager also knows which player (player 1, 2, 3, 4) is assigned to which profile, and a piece of code that can be called directly returns the right player’s profile when asked for. This way the system can be easily used in other pieces of code.
Secondly, there was a bug in which players could leave a custom-created stage, by going into the corners of a tile and “wriggling” their way out. The way players moved was still an old (and honestly badly programmed) system from 2-3 years ago in which players would have their position changed directly. And as it turns out, Unity’s physics system - on which our colliders rely - doesn’t handle that very well when diagonal movement is involved. The way I’ve solved this is by moving the players using their physics component and adding velocity to it. By making sure they have no friction they won’t get stuck on walls when moving diagonally against them, and by giving them a huge “mass”, they won’t be given any velocity by bullets and the like either, without being unable to collide with walls. And after that, this bug has finally been fixed.
Also I’ve finished work on the Foundry’s logic components. These contain “machines” that allow for constant button signals, “AND-gates” and “XOR-gates”, even delayed signals. By the end of a “process” they can be put into a “state change detector” to properly activate or deactivate a hazard. Additionally, there’s the HUB-object that allows a single input to be split-up into four.
Besides regular stages, you can now make contraptions.
Thanks for being interested in our game and its development!
Check out Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
The newest addition to the playable roster of characters has propelled her way into the fray.
She doesn’t have a name yet but is certainly ready for action.
The silhouette of this character is primarily defined by the large hands, ponytail and – to a variable extent, depending on different angles – a triad of propellers. During the animation process, I’ve used these defining features to increase readability of character actions. I made sure that all these prominent elements behave distinctly during these core actions.
While idle, hands are outstretched, propellers rotate continuously and the ponytail sways from side to side.
When firing, hands are stretched to the front and together, some propellers stop during recovery and the ponytail now moves up vertically before falling down. Firing is in ways a direct opposite of idling and the animation reflects that.
When blocking, hands are brought to the front and together, all propellers stop during recovery and the ponytail now moves vertically. It has the same departures from the idle animation as the firing animation for the same reasons. Overall, however, the blocking animation has more of a snap to it and puts the character in a more defensive stance by pulling up the knees and bending the arms with the elbows out, describing a perimeter of sorts while the big hands protect the front.
When all is blown up and done, it’s time for some acrobatics. She’s really excited to be in the game.
Next week I’ll be working on some overall polish for various facets of the game.
LEAD DEVELOPER - Bas | Workspace Requirements
This week we finally got our own office in the HKU building we study at. We’ve been trying to get a room to work in for about as long as we’ve been working on Counterspell, but the time has finally come.
It’s quite a big office.
I’ve got a lot planned for this office. When we get our new batch of Counterspell posters for this year’s Firstlook Festival, they will hang all over the place. Same goes for the stickers. I’ve already moved a lot of our event stuff to the office to set up a playtesting space. Because now we have a room, we’re going to be playtesting a LOT more! Right now we’re busy preparing the game for Firstlook, but the week after next week we’ll be spending the entire week playtesting so we know everything works perfectly at the Festival!
If you’re in the area and interested in volunteering to help us make Counterspell better by playing it, send an email to [email protected]!
Note that if you’re not invited:
It scares the artists.
With Firstlook getting closer and closer all of my other tasks revolve around implementing and fixing bugs. So I don’t really have a lot of interesting things to write about that. Just look at the stuff the others wrote and imagine a note saying “I put that stuff into the main build - Bas” next to it.
Although there are a lot of interesting new implementations coming up! Joey has finished work on the sixth character and I’ll be implementing her into the game next week. Ernst has been working on a new gib system of which a lot should be implemented next week and I can barely keep track of all the stuff Jeroen throws my way.
Other than that, I’ll probably be doing some producer-y related stuff next week like ordering the stuff we’ll be giving away at Firstlook and checking/updating all the content on our website, Steam page and social media pages. Oh joy!
ARTIST - Jaden | Chibi-spell
Guess it is time I start talking about my work as well, instead of only working behind the scenes. So let’s start off with some new promotional art I have been working on this week.
One of the things I worked on this week are stickers of chibi-fied versions of the characters from Counterspell. We picked the designs we wanted and I moved on to the sketch phase, then I added some more details to these sketches (shown below) while also correcting any errors, before finally moving on to lineart, colouring, shading and effects.
Look at the cute little ones.
I’ll give more info about the process I went through making these next week. The first print of the finished stickers will be given out at the Firstlook Festival event on October 7th to 9th in the Netherlands.
LEAD PROGRAMMER - Jeroen | Bugfixes and Firing Arcs
My task has slowly become to look around for bugs to fix, systems to optimize and to help with other things. Naturally, there are always some features that are missing that I can work on. Most of the remaining features are things I plan working on after FirstLook Festival, so that I can work without accidentally breaking the game 2 days before our deadline. Nonetheless I’ve worked on some features last week.
First of all, under design of the others, I’ve reworked the way the game decides where you shoot at. Initially, you’d shoot where your character was looking at. This would mean that if you’d shoot while your character was still turning around, it could shoot into a way different angle than you might have intended to shoot at. Now, the character will shoot directly into the direction you’re pointing your gamepad stick at - or your keyboard keys, if you prefer those.
If you’d point left, then right and shoot, you’d initially shoot into the direction of the red arrow. In the new system, you’ll shoot into the direction of the black arrow.
I’ve additionally made it so that your character keeps turning towards the angle you’ve last pointed at. The character will also snap to the direction you shoot in, if you’ve pressed the shoot button.
Secondly, I’ve worked on controls customization. Honestly, it’s a thing most games have and should have. It does nothing more but set the variables for what keys or buttons to use in the custom Input Manager to the one you’ve selected. It took a while to get it working for the keyboard keys since Unity has no proper support for systems like these, but I managed to make it work.
The system initially was a bit “double”, since it both checked for the last key in Unity’s input “string” and for an OnGUI “event”. One would only show alphanumeric keys, and the other only shows special keys, such at “left control” or “right alt”. Then I came across an issue: it would not register numpad keys. In the end, I made it check through all keys, besides mouse-clicks and gamepad buttons (why are these even considered “keys”?). It feels bad, and probably is, but for now it’s the only way I know how to deal with it, and it frustrates me.
Hoping Unity will add in the option for in-game controls customization, I’ll just have to deal with it this way. But that also concludes my part for this week, next week… We’ll be at FirstLook Festival, so I’ll (perhaps) see you there!
Thanks for being interested in our game and its development!
Vote for Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
The team is nearing completion of the first three additional level editor themes. Aside from the Classic blue theme, we have the green Ancient, orange Diesel and purple Eldritch tilesets in order to shake it up in the visual department. Below are some examples of what different hazards look like. We should be seeing these in action on full-fledged stages within the next couple of weeks.
The mystical Ancient mirror hazard opens and closes.
The mechanical Diesel turret hazard activates and deactivates.
The fleshy Eldritch turret hazard… wakes up and goes to sleep, I suppose?
The Eldritch button morphs and churns as it’s activated.
In addition I’ve also cooked up a new countdown shutter that bridges the end of character selection and the start of a match. It looks a little barren now, but should appear pretty snazzy once implemented with all the right parts in place.
This week I’ve actually spent most of my time working on a new character. More on that next week when I finish up.
LEAD SOUND DESIGNER - Ernst | Dashing FX
Hey readers! During the past week I've been doing a lot of boring stuff, mainly updating old particle effects and improving old sound effects, such as Cosmosis' shoot and hitsounds. Sadly, there's not really anything interesting I can show you right now, except for one little particle effect that I'd consider a major improvement.
As you can see, I've finally replaced the old dash effect that Bas slapped together two years ago. The old effect wasn't bad (which is why it's been with us for all this time), but I'd consider the new effect to be more in line with the visual style of Counterspell.
LEAD DEVELOPER - Bas | Work harder!
Well, it has been quite some time since our last post and quite a lot has happened. For example, Counterspell got greenlit! Check it out: https://steamcommunity.com/sharedfiles/filedetails/?id=643651505.
In other news, school has started again, but this time it isn't a barrier for development as we're allowed to finish Counterspell as a school assignment. As such we've made an incredible amount of progress in just one week of full-time work.
For example, last week I worked on a new game mode: Juggernaut. Though it still needs some testing, right now it all works so I'm quite pleased with myself.
The Juggernaut mode in Counterspell is very similar to other games, as the goal is to become the Juggernaut by killing the current Juggernaut and then getting a target amount of kills as the Juggernaut.
The Juggernaut receives a buff in the form of a regenerating armor hit. This Juggernaut armor functions the same as normal armor as it will be used up on a killdash or upon getting hit. The difference is that it regenerates after 5 seconds.
As such, it is recommended to stay at a moderate distance away from the Juggernaut as they will have the ability to instantly kill you if you get too close.
Though to nerf this a little bit, the Juggernaut can only dash half the normal distance.
Another thing I worked on was implementing the new control system with Jeroen. The new system uses XInput, which allows us to set up an in-game menu for tweaking controls and to also finally have controller shake!
Controller shake adds a lot of nice feedback for the player. In the past there were people that didn't notice when they died (Counterspell can get quite hectic at times) but now when you die, you'll know.
One final feature I worked on this week is the playlist mode. As we'll be showcasing at Firstlook Festival once again, we decided that it would be useful if we could set up a playlist of levels and modes for the players to go through.
Other than that I spent a lot of time implementing and bugfixing. There's only one known bug left and for us, that's quite the accomplishment!
Next week I’ll be spending most of my time testing and fixing any bugs that may pop up. If all goes smoothly, I might be able to start work on revamping the menus. I’m planning on combining the game-mode select, level select and character select into one scene. The problem is that that would take quite a lot of time to make, so I’ll probably wait until after Firstlook.
LEAD PROGRAMMER - Jeroen | Countertheme
In the past week work has resumed, and I’ve started by taking a look at the gameplay ruleset options first. Some options were still missing since, when I started, I had a lack of knowledge on how to make them work. Others broke over the course of time since they might’ve used code that has now been altered.
In any case, I’ve now made those missing things work. Things like vampirism and the counter bonus (by default the armor you’d get) are now adjustable. Additionally, you can adjust the player traits of the player that is currently in the lead. The player that is in the lead varies per gamemode. In “Last Mage Standing” that’d be the player with the most remaining lives, yet in “King of the Hill” this would be the player with the least time remaining until victory - it really doesn’t need any explanation. In any case, you can now have the winning player burst out a ring of bullets while firing them at the speed of 1 bullet every 3 seconds while dashing around with insta-kill dashes. It’s fantastic!
Bursts can be a counter bonus with deadly consequences when mirrors are involved!
Secondly I started implementing the foundry themes Joey has made. The system required an adjustment on the already-existing foundry asset system. The current selected theme is stored as a number (0 for default, 1 for ancient, 2 for diesel…) and each asset allows for additional “prefabs” (pre-existing objects, used to spawn in multiple copies of). The first prefab is that of the default theme and needs to be present in order to work. Then the second is for the second theme, third for the third theme… It’s quite simple! If a theme has been selected where the asset doesn’t have a prefab for, it takes the default prefab. This saves both a lot of effort and space! It’s a small adjustment with huge results.
In fact, these are the results. Some things might still be subject to change, however.
Anyway, that’s it for my part this week! There’s still some stuff to work on, but you’ll hear about that next time. See you then!
Thanks for being interested in our game and its development!
Vote for Counterspell on Greenlight!
https://steamcommunity.com/sharedfiles/filedetails/?id=643651505
To stay up to date with our latest news, follow us on Twitter!
@PunchButton_DEV
You can also like us on Facebook!
https://www.facebook.com/punchbuttonstudios
