Whew. What a ride it’s been!

It’s been almost three years since I first started work on this game, the idea remaining throughout and barely anything changing through gameplay, although the visual presentation has changed a lot since the initial concepts:

I am so proud of where this thing had become over the years, so I suppose before I start working on the feedback I have recently obtained I should write a short but also long post about my experiences while developing the game.

Starts

The first thing I had started to work on was the paddle and the ball. The game was designed with speed from the beginning but with the limitation of the paddle speed being restricted by the concept known in the final as “transmission”. Things went very smooth in general at this stage, but things quickly started going a bit down as I was working on the ball interactions with the bricks. I was (and am still) using Unity’s built-in collision and Rigidbody2D system. The original collider was a circle, and depending on how the ball collided with a 90 degree angle, it’d produce a possibly unintended bounce.

This is something I wanted to avoid immediately.

It was at this stage that I had given myself the task to avoid as much as possible interactions like… these:

(Source: Hyperballoid)

See, this particular example is a mistake, but there are games that also feature elements that have 45 degree slopes and such. These elements may produce bounces that are not intuitive and I wanted to avoid that because the game was focused on speed and predictability of movement (for the most part, not everything is perfect, but I’d think I got it right given witness reports of how it feels).

So, I’d say I spent a good chunk of the time getting the first interactions with the bricks and a high speed ball to work. Unity’s system as I was using it consisted of a KINEMATIC game object, so its positioning was entirely determined by me, as I want to eventually be able to make the game replayable (The powerup randomizer is also a specific Random implementation and not Unity random!)

Powers

It was mostly decent, so I began working on the powerups. Naturally, as per the concept, the first thing I started working on was the Unstoppable powerup. Things went very fast from there onwards and I stopped at a point would be good for Nano’s release. Honestly? I’d say the biggest hiccups at this stage were unique per powerup and specific problems were tackled with big success. Big ones I can think of is how at ball respawn your Magnet usage would go down by one, or Railgun (originally called Laser) being stopped by the powerup items themselves, ahaha.

At this point I was laying out the bricks and powerups manually in the Unity editor, but I figured that was not going to be friendly if I wanted the game to be accessible and for people to make their own stages.

TROWEL MOMENT

So what I did was start a parallel project: the level editor. But the game wasn’t even MATURE yet, let alone have a GUI (the icons for the HUD were just text!), so I wasn’t about to make a full fledged editor within the game’s engine. Besides, I wanted to be able to update the editor separately from the game, and ALSO I wanted to begin learning MonoGame. (Oh boy. You can see where this is going.)

So, I started work on what is currently known as Trowel. Its name and logo are literally based on Valve’s Hammer editor LOL

It’s currently not public and I plan to allowing supporters to use it for a period prior to release, so be sure I will eventually be releasing, but IMO it’s “pre-Nano” on its own right, still. I think I am gonna release it by Lite, which may allow stage loading.

This is how Trowel looks currently, but it was considerably more barebones at the stage of development I am talking on. I had no experience with MonoGame before (but am a very seasoned C# developer) and it is more of a hands-on framework compared to Unity so GUI and all that stuff had to be made by myself. Thanks a lot to rds for developing Myra, which is the GUI framework I use for Trowel.

Much of the time was spent into making that the level creation experience for myself was decent so I could prototype things, so progress in the game stopped for a good while.

It led to some funny statements from me such as these:

(Wondering what the accurate Mario twitter account would think about this Mario.)

When I implemented powerup chances in Trowel, it’s when things started picking up in parallel between the game and the editor (By now, I had already managed to make the game import Trowel exports.) (Yes. No icons. I added them later.)

The Nitty Gritty

After this, it was refining the HUD and even more time spent into fixing the interactions with the ball and the bricks. A LOT of time was spent on that last one and if I had made a commit for every attempt it’d easily cover 50% of the commits for 2022 and 2023.

Heads up for anybody making something like this: When using Kinematic rigidbodies (Dynamic is not really the best idea for this), make sure to calculate the closest position to the bouncing element in the ball’s path, so if it’s going way too fast you can tell the engine to snap to it and not overshoot.

At this point the ball even changed to a notched rectangle collider instead of ball to keep my desire of readable bounces.

Pre-Nano testing

There were SO many issues with overshooting and collision shenanigans in the first pre-nano builds…

but after a lot of work, I finally fixed em, and I think they’re even replay friendly given I make a good format for it.

Many people have reported it feels solid, so that’s a good step in the right direction for me.

Alongside that, which was minor in relation because I worked less harshly on it were some extra interactions of the actual game engine itself, such as game over reasons, HUD and GUI adjustments, icons, SFX (o göde) and music (OH NO I AM STILL TERRIBLE AT MUSIC)

————

hey fun fact, the INF-PWR track was made by a friend, whom I asked for the track ABOUT THE TIME I STARTED DEVELOPING THE ENGINE. So it was kind of crazy to me to message them when I released Nano like this:

————

After that, I began working on stages that actually would be compliant with the design guidelines that hugged the gameplay loop tightly. Just one, at first, because I really wanted to release this demo. That stage is Nano-0. It’s structured and looks like you’re going through a house’s rooms. (pay attention to the powerup that may sometimes come up when you break the base of the bathroom and draw your own conclusions.)

————

another fun fact: whenever I’m angry at something I often say “I’m going to demolish a house”, so when I made this stage a friend just said this:

and i promptly proceeded to Lose My Sides

————

Now?

I was extremely excited to release the demo, it was going to be the first game I release to a broad audience. My prior game projects up to this point were extremely amateurish things, projects that were too big for me to bite into and birthday gift games I made for friends (that in retrospective I now have little idea if they even appreciated…)

I am not kidding I was shaking when I was pressing the button I just posted that EVERYWHERE. And it was good.

I got a lot of useful feedback to implement and I want to improve the game in the future! But now that the demo is out, I am mostly going to focus on the smaller fixes until I can set aside some time to work towards the Lite release or further Nano revisions.

The near future?

I am going to update Nano’s builds soon. There were some readability issues I must address and I am going to fix them ASAP so the demo can be more enjoyable.

Also adding a god darn exit button to the desktop build LOL

Thanks for playing, btw.