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
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
â Live Streamingâ Interactive Chatâ Private Showsâ HD Quality
Anya is LIVE right now
FREE
Free to watch ⢠No registration required ⢠HD streaming
COUNTERSPELL: DEV UPDATE - 34 | Abilities:Â âWarpâ
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
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
â Live Streamingâ Interactive Chatâ Private Showsâ HD Quality
Anya is LIVE right now
FREE
Free to watch ⢠No registration required ⢠HD streaming
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
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
â Live Streamingâ Interactive Chatâ Private Showsâ HD Quality
Anya is LIVE right now
FREE
Free to watch ⢠No registration required ⢠HD streaming
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
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
â Live Streamingâ Interactive Chatâ Private Showsâ HD Quality
Anya is LIVE right now
FREE
Free to watch ⢠No registration required ⢠HD streaming
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
