Fledgling Videogame Developer

My previous Unity3D post was demonstrating my trials with scriptable render pipeline and shader graphs. Now I have gone one step further and combined these techniques with one of my previously released game. "Ball Twister" was originally released about an year ago. I did not advertise it too much because of boring outlook and bit simple gameplay. However, now I have found this game perfect for testing scriptable render pipeline and shader graphs in real 3D environment. Attached video shows how different new version of Ball Twister looks compared to the original one. Original version (on left) is using standard Unity render pipeline and shaders. Enhanced version (on right) is using LWRP (or URP) and shader graphs. In enhanced version, rolling checker board texture, swirling sky and obstacle materials are all using shader graphs to create a sense of movement just by tweaking textures. Basically, only objects that are really moved are black obstacles and coins. Everyth...

I've been bit busy with my daily work for last couple of weeks, so gamedev activities have got less attention than normally. But still there has been some progress since my last update. My original plan was to finish and release "Dualball" flash game in the end of September, but now it seems to take some more time. Game itself is in pretty good shape: the mechanics works, there are no detected major flaws currently, and 75% of planned levels are ready and tested quite well.  We have done thorough testing ourselves and a number of serious bugs have been found and corrected during the process. Gameplay tests have been run on both computer and touch-screen tablet to get some extra coverage. It has been interesting to see that some bugs are not easily visible on both platforms: E.g. "ball ground check" routine worked fine on computer, but on tablet there were strange malfunction with it. So I strongly recommend you to test your games on multiple platforms in...

No matter how simple your game is, or how well you plan it. In any case it is 110% sure that there are several bugs included in your masterpiece. And fledgling game developer surely has more bugs than the experienced ones. :) Here are my thoughts of this matter. Major and/or often occurring bugs are usually very easy to detect, and they are relatively easy to find from your code. You just need to find (or know) where certain functionality is located in your code and check the difference between desired and existing operation. Fixing the bug might not be so straightforward, but at least you know fairly well where the fault is. But then there can be very nasty bugs that occur rarely or even randomly. Sometimes it is very hard to understand if some behavior is really a bug, if it can't be easily reproduced. And locating these bugs from your code is very difficult if you don't have clear idea where to look for them. Luckily here are some ways to ease up bug hunting. I am us...

Ok. After lots of debugging, fixing, and other hassling we finally got Turbomole Trial Run flash game reproduction published at Newgrounds. Although to-do list was quite short for the day (only 3 items left), it took surprising amount of time to sort everything without breaking anything. The judgement phase was passed quite fast, and during the first 7 hours there were over 300 views. Average rating is currently around 3/5 stars (about the level I was originally expecting). Gameplay seems to be working and major flaws have not been found (yet). Also the level design is quite ok at least from our own perspective. It seems that sounds share opinions, but the current solution is about as good I was able to arrange within this schedule. For background music I was using "Fun in a Bottle" downloaded from Kevin McLeod's " Royalty Free Music " pages. All sound effects were created using the laptop microphone and Audacity software, so there might be some strange ...