Week 16 - pressure's on

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!