1. Shardpunk
  2. News

Shardpunk News

Devlog #112: More colors, more variety

Before we get started, here's an invitation: I'm gonna be doing some live streaming on Tuesday, February the 1st:



I'll be covering all the changes I've implemented in Shardpunk in the last few monthts. Do jump in if you want to get some insight on this stuff, ask some questions or just hang out with a cool game developer ;)

Now, back to the devlog entry.

I've probably already mentioned that recently I'm spending some time adjusting the visuals of the game - and even though I am not done with this part, there's something I already want to share.

One of the issues I had with the game was that gifs/screenshots were often looking too similar.

Take a look at these two gifs:





They are representing different level types. The top one is located in the "industrial streets" level type, and the bottom one is located in the sewers.

Now, you can see that they are kinda different, but it's far from what could be achieved here.

The main problem here was that there were no "theme" colors assigned to each of the level types. As for now, there are the following level types in Shardpunk:

a) industrial streets,
b) sewers,
c) industrial buildings,
d) caves/mines.

By using different theme colors with every level type, we've achieved a nice variety. So:

Industrial streets are now warmer, with red bricks and yellow light sources:



Sewers have the greenish vibe going on:


Industrial buildings have a colder, more sterile look:
(how could she not land that shot?)

Caves have that blue glow from the crystal shards:


Combination of post-process effects and some fiddlling with lights and color palletes did the job. There will be still some adjustments being made, but in general I believe the level types have become visually distinct.

That's it for this entry. I hope you enjoyed it! And don't forget to check out the Discord server!

Take care, and we'll see each other on the stream!

Live Development of Turn-Based Tactical RPG Shardpunk: Verminfall

Join Slawek on Tuesday, 1 February, at 10 AM PST / 1 PM EST / 6 PM GMT / 7 PM CET to see him work on Shardpunk: Verminfall and share his design approach when it comes to making a turn-based tactical RPG.

The live stream will be available on Twitch, YouTube, and our Steam card.

Devlog #111 What if there is no Fusion Core? - alternate version

Howdy! In one of the previous devlog entries I was figuring out how to deal with a situation in which the player somehow ran out of Fusion Cores.

For those of you that don't know what Fusion Cores are, and how they are used in Shardpunk, here's a brief introduction:

Fusion Cores are battery-like items that look like a jar with a bolt of lightning inside. They are powerful energy sources that can be used in a few different ways.

First of all, you can use them to power up and open entrances to further levels, which allows you to finish the combat phase and advance to the shelter phase:



Secondly, you can use them as lightning bolt throwers during combat. Good AOE, always hits, ignores cover:



After the automatons have been added to the game, Fusion Cores can now also be used to "revive" your broken mechanical buddy:



You can find Fusion Cores on your journey, scattered on the map, or as part of the loot from dead enemies:



Now, let's focus on the first ability - opening up entrances to shelters. It is obvious that a player can run out of Fusion Cores, so a scenario in which there was no means of opening up the shelter had to be handled.

Initially, I decided on allowing the player to pick an alternate escape route from combat - one that would still allow them to finish a mission but would punish them by not making the shelter phase available afterward. That worked pretty well, but as the game progressed, the punishment became too big - as the shelter phase has evolved so that the player can upgrade their weapons during it - and weapon upgrades are important.





So, sometime after I introduced automatons, I've decided that the player will always be able to unlock a shelter. If they don't have a Fusion Core to spare, they can use the automaton to do so. An automaton is a prototype unit, holding a unique and powerful energy source - and so it can force the shelter door mechanism into an overloaded state, which, in the end, opens them up. The only downside of such a Fusion Core-free approach is that it takes more time to open such doors - there's basically a number of turns that need to pass before the bunker opens.



The support automaton is right about to electrify that entrance. But it won't do it now, as I don't have an animation ready for it yet.

This way of handling things - while maintaining a risk/reward approach - greatly simplified game rules when it comes to entering a shelter. I could assume that there will always be a "safe place resting" phase between missions. Which also allowed me to simplify parts of the UI.

Here's how the feeding phase UI looked like before this change:



It was basically pure UI, with no resting characters rendered in the background - and that was because I was using it also in scenarios when the player was not entering a shelter (which right now is not possible anymore). I could not simply state that in such situations the player would not have to consume food, as that would lead to an exploit - players would be intentionally skipping a shelter phase to avoid hunger damage/penalties.

In the new "shelter is always there" approach, I was able to embed the feeding UI into the shelter visuals. This is how it looks like right now.



I like these new mechanics - and the refreshed feeding phase UI - a lot. The idea that there is always a resting phase after tough combat is also comforting in a way. After all, we all like to have that "safe place" vibe from time to time, right?



Thanks for reading! Take care!

Devlog #110: Let's make it smoother!

Well, another year ends! And it's my first year as a full-time indie game developer. The feeling's awesome!

Now, there will be time for a yearly summary, but let's wait for the year to end first. And now, let me show you something else.

I was recently thinking about how to make the game visuals even more appealing. One of the ideas was to make sure that the animations are as smooth as possible.

Take a look at this animation:



In here, there are no transition animations between the crouching and standing stances, and no turn animations. Now, the lack of them does not break the game, but I believed that filling in these gaps might be worth the effort.

Here's a new approach, with the transition animations in place:



Feels smoother, doesn't it?

The other thing I've worked on was adding some emission map-based HDR bloom effects, based on this YouTube tutorial from Brackeys. It allowed me to add extensive glow on specific things, like this grenade explosion animation:



Now, these are just some of the things I've started to implement to up the visuals/feel of the game. This, combined with a pretty nice gameplay loop will result in a fantastic game!

In the meantime, I wish you all a Happy New Year! Take care!

Devlog #109: Key bindings

The last two weeks were a little bumpy due to hardware issues. Basically, my PC is dead for a week due to a faulty power supply and the incompetence of a shipping company to deliver the new one. I am still waiting for it to be delivered.

So, I am stuck working on my old laptop, which is not a developer-friendly situation. Still, I managed to get some work done - mostly technical one. To be more specific, I've added key bindings for mouse+keyboard control scheme.

First, I studied how the bindings are handled in similar games (think XCOM, Mutant Year Zero: Road to Eden, or Pathway) and then took the stuff that made the most sense to me.



Few notes here:

1. Camera movement is not rebindable, and stays at WASD/arrow keys
2. Bindings are not unique - so the same key can appear in more than one binding (example: speeding up enemy turn and displaying to hit preview both use the "alt" key, which is OK - as the player is never able to perform both actions at the same time). Technically, these actions could be defined under a single binding, but I don't feel it would be better.
3. The Main binding for the "Cancel/Pause" action cannot be cleared (XCOM 2 has the same approach). Otherwise, there might be a situation where the player has no possibility to pause the game and re-enter the bindings menu. Of course, I could add a physical UI "pause and enter the menu" button, but I don't want to make the UI more cluttered.

From other things, I have started working on tuning the visuals up more - for example, making more use of HDR and bloom:

An original image:


HDR, more colors:


Bloom effect:


I believe the visual changes are going in a good direction - do let me know what you think.

Take care, and don't forget about the Discord server!