SWM Devlog #1 : The new plan

November 5th, 2018, all posts

Hi everyone,

In this blog post I will tell you what happened in the development of Squarewave Maker over the last couple of weeks.

The new plan

After the kickstarter failure, that we will write about in a future Kickstarter post mortem, we had to changed a bit our plan and its timing. We had to figure out how to stay afloat and out how to pivot regarding the funding of Squarewave Maker, you know filling the fridge, paying the bills all that stuff.

It took us about a couple of weeks to find a new contract, but in early october we started to work as a part time contractor for our friend at Guard Crush Games. We‘re working with them doing ui, metagame and network related tasks. Great project and great people in there, follow them and go play their game now!

Regarding the development of Squarewave Maker our next goal is the playtest build. What we want to do is to get some fellow devs and other people we can physically meet here in Montreal to play the game.
After these playtest sessions will occurred and the related issues encountered will be fixed, we will be heading toward the closed alpha.

The playtest sessions will take place around january/february 2019 and the closed alpha will be available around june/july 2019. With a successful Kickstarter the closed alpha would have been available by the end of January 2019, meaning that in our new plan the closed alpha date is moved of 6 months. Not that bad after all.
This seems like a long time to wait but in the meantime we will write about our progress so you will be able to follow what’s going on with the game.
So now that the plan is exposed let’s go and see what we've been working on.

The road to the playtests

The playtest build will focus on the rhythmical performance part of the game and not the creation related activities. What we want to have for the playtest build is something like 15-20 levels where the player will get a glimpse/introduction of the performance gameplay of Squarewave Maker.
What we have in mind regarding the progression of those levels is something like a mix of the first levels of Super Meat Boy and exercises from an instrument method book. We’re really thinking of Squarewave Maker as being half a game and half a music instrument, that’s why we are going this way.
You can see below an extract of the first levels and the intent we have for each one.

We did that doc to get a better view of the pace we want to have for the playtest build. Everything in that spreadsheet is self explanatory except maybe for the last column. The estimate average replay count is a way for us to express the difficulty we want to have for each level.

Based on that doc we built a few levels, we played them and we came to the conclusion that we needed to add/improve some visual feedbacks. We worked first on the death fx of the character.
Until now the effect was quite simple and after having played the first level it was clear that the current fx was not informative enough. It was difficult to know exactly where you died, leaving a weird feeling of misunderstanding about what we did wrong during the play.
We ended up creating the following death fx that we are now very pleased with.

Having a colored blood splat is letting you know what trap or block you’ve hit and the lighted blood fit perfectly the global art style.

We did also a pass on the scoring feedback to show explicitly the gameplay elements that you're scoring. We still have to sync the animation to the global quantization of the song but we’ll do that in another sprint.

Another aspect of the game we were not sure about before building the playtest levels was about continuous control.
Until now we thought that pressing buttons will be enough to play the song as you play the game. It turns out that we were wrong.
Not being able to have gameplays build around using continuous input controls, such as the gamepad triggers, does not allow us to meaningfully link continuous audio parameters, like filter cutoff for example, to the gameplay.
We did not want to have the gamepad to be mandatory to play the game but without it we can’t fully exploit all the gameplay possibilities offered by the realtime audio synthesis in Squarewave Maker.
As a consequence we added the possibility to link continuous input controls to gameplay elements. These control are not linked to character movements like jumps or dashs because there is no meaningful way to connect them.
What we went for was to allow association of continuous control to level block parameters, like position offset and rotation and hence let the player influence dynamically the content of the level during its play.
Were are still working on this part and will be able to show you exactly what kind of level design we have in mind in a couple a weeks.

An improved QA worflow

By doing all the modifications regarding the continuous control we revealed the need of tools to smooth the production of the levels and the QA of the game.
Squarewave Maker is built around a custom game engine so everytime we add or tweak a new gameplay feature we have to modify underlying systems such the collision system or the character controller.
By doing so it is possible that we introduce regressions in some existing features. To alleviate the QA workload implied by these changes we decided to create an automatic testing system.
We had the following QA workflow in mind :

  • You play a level recording the player inputs and the resulting game trace (score, player position...)
  • You mark it has the reference one.
  • Everytime you add or change a gameplay feature, you run the autotest system on all test levels with their associated recorded reference inputs
  • You do the comparison between the reference trace and the newly optained trace.
  • The traces must be the same otherwise it means your modifications introduce a bug.

We first had to move to a fully deterministic game loop to be able to exactly replay each level run with only the inputs and no matter the frame rate or the sampling rate. To achieve this we had to move all our systems in a fixed update scheme and we used an audio clock to timestamp everything.
The auto test system is not finished yet but what we can now record and replay gameplay sessions.
What we still have to do is to automatically play a level, compare its resulting trace to a reference one and print the result in some report file.

One bonus side effect of the work we've done for our QA process is that the level replay system will be also available for the players in the game.

That's all for now folks and don't forget to let us know what you think on our Discord.