Hey everyone, and welcome to (finally) another productive week of 'Just Survive: Arena' development blog. This week was a very good week for me. Not only did I manage to sort out the z-layering issue, but I also managed to add a few more aesthetic effects to the game level, as well as ironing out some kinks with the trap "formula".
So to start off, I FINALLY managed to sort out the Z-layering issue that I had last week (second times the charm). Without going in to too much detail or programmer speak, I basically failed to call the correct actors at the start of every update, leading to null objects. But, after a few hours to rigorous (and tedious) testing, I had managed to flesh the problems out and correct them. Bottom line is; it's working. Yay!

The next thing I had to correct was timing and spacing involved with each of the traps. Before it felt a little too fast and didn't really "ease" the player in to playing the game and understanding it. To fix it, I basically slowed down the timing of each trap trigger, and doing so made the game-play fell a lot more comfortable. Still, I would probably tweak this further down the track during Beta testing, but at the moment it's feeling pretty good.

Now the real fun part, I had enough time to implement some aesthetic changes / additions to the game level to make it a bit more "poppy" and animated. I added a bit more saturation to the game's background so it didn't feel washed out. I also added an animated crowd to the outside to make it feel more lively. I'll probably add a few more effects to the game-play later down the track such as streamers, or the crowd throwing rotten tomatoes. Let me know what you think!

Another really short development blog this week. Next week I'm hoping to not only finalise the power-ups/Pick-ups, but also implement the final scoring system after your character dies. Once that is done, I'll then focus on the main menu screen, the options page, and the credits screen. Yes! I can see the light at the end of the metaphorical tunnel!

Lets hope things stay on track this time!

Until next week,

​Thanks for reading!

Welcome back to another.... erm... well... I want to say "productive" week, but I don't think this one should classified as "productive". At most, maybe a "two steps forward, three steps back" week? Well, anyway. welcome back! What a frustrating week it has been. Let me start off by saying, I did do a lot of work, but inevitably scrapped it... Why? Well, Firstly, I started off by redesigning the background to become more of a "finger-obstructive-free" display. However, after a few variations of it, I decided to go back to the original design and just use a smaller joystick. Below is the various attempts.

Welcome back to another Juicy Beetle DevBlog! This week I worked heavily on the timing and trap mechanic functionality, as well as a rough draft of the intro for the player when they first enter the arena. 
Now, there isn't really much to show this week since it is a lot more involved with the programming side, but I do have a snippet of what the starting animations look like when the character enters the arena, as well as some trap sequences. I'm pretty happy with everything so far. For the intro, I'll probably add a few more icons to show the player what to do to start playing (similar to 'Flappy Bird'). After that, I'll probably implement a skip-able countdown as well for the player to prepare themselves a little more (see how we go).
The struggles I had this week was less about the animations for the player, and more about the logic behind the traps. When setting up the algorithms for the traps, I had to think of a few 'hidden' things. Firstly, will the traps overlap if the same trap sequence triggers twice? If so, how will that be portrayed? What about the spacing involved with the traps? Does the character have enough room to squeeze through the traps if they take up the screen?... Yea, so A few things I had to nut out first before plowing ahead, but I've managed to get through majority of these obstacles which is  good. I guess it will come down to testing as well, making sure that the game is still 'fun' and 'feels good' to player.  Another big hurdle I'm scared to test is the screen res from device to device. I know I planned this well in advanced, but I always have my doubts. I think there might be a few issues with the wall traps not matching the background's wall, but again, that will come a little later in development.

I've still yet to fix the bottom part of the arena so the player doesn't obstruct their view while playing, but that will also come a little later (possibly next week). I'm still going off my plan from last week (with a few tweaks here and there), so still on track which I'm happy about. But, besides that, I think that about sums it up.

Until next week,

​Thanks for reading!

Yet another exciting week down for the delicious DevBlog. This week was less creative, and more... theoretical. I've been analyzing the trap implementation quite a lot this week, and I believe I have come up with an interesting take on it. Before I get into that, let me breeze through what else I have done. Firstly, I've cleaned up some visual bugs related to the sludge, flames, and the electricity (based on my problems last week), so everything seems to be working a lot more efficiently now than before. Secondly, I've updated my GDD to reflect the updates within the game. I had also added the latest images to my GDD to keep it live, and on track.

Ok, so now the juicy stuff. So as I said before, I've managed to come up with a formula on what I need when implementing the trap mechanics. I wrote up exactly what I wanted as well as what considerations I needed to keep in mind for the play style of the game.
​

As you can see above, I broke down my idea into multiple sections: The difficulty of the traps (which ones are deemed easy to avoid verse which ones are more of a pain to deal with), the Algorithm in which these traps will function outsides the means of randomness, and Frequency (how often will each trap/algorithm appear). For this formula to work, I needed to somewhat think backwards. So instead of thinking about the score counter, I wanted to separate everything first into their categories (easy, medium, and hard). Then, I needed to decide arbitrary time ranges in which these easy, medium, and hard traps will occur (image below). Once I had figured out that, I then thought about the scoring system. The question I asked myself was "how long will it take for the player to get bored?". Generally, players judge a game within the 5 - 15 second window, so if the games was still quite boring after the 15 second mark, then I most likely would have lost my audience, so I needed to have the game's difficulty progress even before that. So I came up with this...

Now I know this is a lot to take in, and I agree, this could even backfire. But, I need to start somewhere right? And that is where testing comes in handy! Over the next few weeks, I'm hoping to get a better grasp on what needs to change in order for the pacing to feel comfortable. Hopefully this thought process will turn out quite well, but it's still only theoretical at this point.

Below is just a snippet of the game play at the moment with simple randomness.

Another thing I noticed through testing is that the controls on the screen definitely take up too much room. So to avoid this, I might even move the bottom arena wall up further, and shrink the joystick to fit within the boundaries to maximize real-estate. 

Next week I'm hoping to have the core game mechanics implemented and working, as well as the intro animation for the character sorted. See how we go!

Until next week,

Thanks for reading!