Half way done to final release
Hi and welcome to my first real DevLog on Itch.io!
In this DevLog I will have a very brief review of what happened after Beta Release. Then I will continue with thoughts about the changes that will come with the release 1.0. I will have a bit of Tech-Talk about a Bugfix and announce the release date (the planned version).
After the Beta-release of my first project build with Unity3D (why was I using 3D Engine to build a 2D game?) I still had to get used to this page and its mechanismn and where I can find what. But I could start collecting feedback right after, though it has not been easy starting from absolut zero.
The main issue is: What to change and what to leave between a Beta and the final release?
Changing too much could mean:
- A lot of Bugs might appear, because all the changes can also interact with another on scenes in the project that are not tested daily.
- 'After the newest feature is before the newest feature' - meaning: Never finish, always add another one.
- Delay of the release date again and again, losing trust of the followers.
- Changing the originally posted game to something completly different, losing the 'fans' (as if I had any right now) half way.
Changing too less could mean:
- Disappointment of any one waiting for the release: 'What? For that you really needed an extra release? Isn't it just like the Beta?
- Losing the opportunity to once again blow the horn for the game by showing new features and other accomplishments
After a few days of thinking things through, I decided for a mixed approach of features and graphical changes. That's because graphical changes on the one hand have a huge visibile impact while on the other hand do not really interfere with any of the code or game mechanics.
But why graphics?
Seeing how little feedback I got on my game on YT or roastmygame or here, people may feel somehow troubled writing anything. On the other hand the click-to-rate ratio was also low. When I was scrolling down the search results I realized, my thumbnail really stand out somehow: The magenta colors!
While it is definetly good to stick out it is also important to stick out positively. Sticking out because your game looks like that people might cringe would do some harm - except if it were ridiculously cringe. Then it could go viral but I do not see how and even less want BABU to be that bad. So I changed the default colors for all the blocks to a blue-ish look:
What Game Mechanics?
Just a bit: At least I can use the only user input I got and have people not play the last 5 levels again when they failed a mission but just the previous one. Especially since the first 3 or 4 levels are more like a tutorial than challenging.
From Bugfixes to more Game Mechanics?
For the last part I wanted to just do the remaining bug fixes. Just.
After the first small ones I came to one ugly, you can see in the Pre-Alpha demo video on YT I linked in my Beta-release post.
After a level win and following level change, the player was not positioned where he should be according to the leveldata script. Instead the player remained on the last position. This can either enable the player to strike a match-winning blow right at the start of the new level - or trap him in a bunch of blocks, waiting to be killed by alien turrets across the level.
Details: (just skip if you are not interested in game dev)
After hours of search-and-despair I could lock the bug to be origined in a strange combination of a function 'ResetPositionIfMovingIntoWall' and the way of Unity3D to handle the user-input in the fixed update. So if I was still pressing movement buttons when the game-win-screen popped up and the game was paused, it somehow collected and stored the last user input.
When the previous level had been removed after the game-win-screen and the new one has been loaded, the game was unpaused again. And just then the newly set position of the player was overwritten by the stored last input and the following reset of the player's position because he hit a wall last level.
Consequence:
I really had to implement a different system of collider and collider-as-a-trigger and therefore rewrote a bunch of code, causing a few other things to break. So I ran late but still hope that I can upload the
Release 1.0 Next Saturday, the 30th of May. (planned at least)
There is still another nasty bug to fix. It is less game-breaking but still bothers me and will occasionally irritate people playing.
Oh, and I still have to really build a switch for people to change between old and new graphics. There are always people who still like the old look. The new one is set to default tough.
See you next weekend!
Get BABU - Blow All Blocks Up
BABU - Blow All Blocks Up
Action arcade game in retro style
Status | Released |
Author | H.A.R.D.Games |
Genre | Action |
Tags | 2D, 8-Bit, one-hit-kill, Pixel Art, Retro, Short, Singleplayer, Space, turrets, Unity |
More posts
- BABU Version 1.1 UpdateJul 19, 2020
- BABU Release 1.0May 30, 2020
Comments
Log in with itch.io to leave a comment.
I played for some time, you can make something interesting from this concept. I think that the movement doesn't feel very good, especially when you hold two buttons, the character often moves straight and not diagonally. I guess it can be fixed by summing movement vectors or using some other code in movement. This situation usually happens when using if-else system. In my devlog you can find a comment in discussion about smooth movement. It's for Godot Engine, but maybe you can use that in Unity https://wans24.itch.io/pongus/devlog/139908/after-update-reflections-020
Also, the game lacks some impact, for example some satisfying particles when shooting and destroying blocks. Maybe, I would make shooting direction separate from movement direction. For example, movement is WASD and shooting is left/right arrows, because now it's not comfortable to aim.
And in a lot of cases you put a bomb near a big cluster of blocks, it blows everything up. After that it's easy to prevent aliens from building something, especially when you killed the builders, so the game becomes boring and you just wait for the timer to go off.
Thank you for playing and writing some feedback! :)
I can reproduce the problems with movement sometimes (using keyboard atm) but unfortunatly I am not using a if/else construct. Maybe a side effect from using the new input system… well, I will try to solve this problem.
Some temporary debris from the blocks… sounds good. Not sure if I can include it until the 30th but the next update will include it.
I do not understand the point of the timer to go off though… The timer just calculates the bonus points for clearing the stage. One always has to blow all block up or kill all of the workers. What did you mean exactly?
Maybe I should reduce the amount of bombs in the early levels. I will look into that as well. Again, thank you very much for your feedback.