This week has definitely been productive for the game. That being said I ran into many interesting problems that slowed down my productivity and efficiency in getting a working shell of our game to be filled with juicy assets :P
Progress:
Since last time, I've added the following features
*Dynamic Track Width
As of now this feature isn't really being utilized, but it gives us more flexibility in our design if we need to ever expand beyond a track being three blocks wide
*Global Variable Class
This was something I wanted to make from the start and finally made! This static class allows the team to change similar numbers and change the feel of play (player speed, camera drag, track creation settings, etc.). This will allow the team to test many different circumstances and will come in handy for quick tweaking when it comes time for play-testing and awesomeness-making.
*Block Tunnel Ability
This feature was actually a glitch before it was...well....a feature. When the player would crash into a block that had multiple blocks behind it, they would boost through and create a very visually stunning effect. I showed the team this "bug" and I cleaned up the circumstances around its happening and made it into an ability for the game!
*Power Block
This feature was discussed and fleshed out in our last Wednesday night meeting. If a player hits a sequence of these special "Power Blocks" correctly, on the last sequence block they have two blocks appear from beneath them and have someone of a hit-buffer similar to when Mario gets a mushroom. While I have implemented the blocks logical code and conditional trees, I have yet to add the block-adding portion. I plan on doing this today, or at least in time for class tuesday so we can have working prototypes of all of our mechanics! :D
***PROGRAMMER GEEK OUT TALK START***
So in implementing the new types of blocks, I needed to assign characters in my file parsing system that would represent the other blocks (as of starting this process everything was just 0's and 1's). I chose "*" for the Block Tunnel cubes and "#" for the Power Blocks.
I first changed my Dictionary that holds all of the file-parsed track pieces in integer arrays to character arrays. This worked fine until the final element of the array would always be set to null. This was quite a comical error on my part, because I should have known sooner on (took me around 20 minutes to figure out) that the null character ('\0') was being tacked onto the end of my character array, as it always is. So for simplicity sake I thought "Why not just use strings so we can avoid this problem?"
This caused me three hours of confusion
I would test the values of my pieces and then decide what to do from there. My logic was as such
"If the element does NOT equal 0, then do one of the following:
- Create 1 Block above the track ("1")
- Create a Block Tunnel Piece ("*")
- Create a Power Block ("#")"
This seems like it would work right? Well everything was fine except none of the third elements were behaving correctly (The entire right side of the track would be empty).
So I decide to do some debugging: Inside of that test for != 0 I added an if-else structure for all of the potential circumstances (1, *, or #). At the end I added a final "else" that if triggered a print-value of the currently accessed element. This yielded odd results. The print statement ended up print "0", even though this should not have been possible seeing as that statement could not be reached if the value was "0". This caused so much confusion and running in circles that I thought Unity was pulling a Game-Maker and mishandling certain circumstances. But of course, I was wrong as usual- but it wasn't entirely my fault! The problem ended up being, or at least I believe right now, that there are hidden characters added on to each element that I was unable to see. Maybe this was a '\0', or maybe a '\t', who knows? Either way my solution was to go back to an int[] and make 2 = Block Tunnel and 3 = Power Block. I may go back to the char or string methods later, but this works for now considering we don't need the blocks to go any higher than 1 above the track in our level design.
I'm by no means a programming expert, so in the end it doesn't surprise me I had this problem- But the learning process excites me so I feel as if that time wasted was actually time well-spent. Never underestimate the learning potential of a good-bug. :D
So until then, chars/strings! I will conquer thee in the future!!!
***END PROGRAMMING GEEK OUT TALK***
2 Steps Forward, 1 Step Back
As most of you reading this should know, as the size of a project becomes larger and larger and your environment gains more responsibility in managing certain assets in a multitude of ways, unexpected problems arise. While they aren't large, they're just situations I need to sit down and iron out:
*Cube Recycling
The problem with my recycling system is somewhere in maintaining the cubes' collision detection state. There are some weird things that happen sometimes and I've sifted through the code briefly. I know the cause of the problem- I just need to find all of the holes and patch them up with the right code! As of now I'm back to Destroying/Creating cubes when necessary and the game state doesn't lag because of it. Hooray for simple game design!!! :D
*Collision Detection
Not necessarily a problem, I just need to go back and optimize how they're checked. Not only to I feel like my current methods are inefficient, but they need to be logically restructured as well. I just need to look more into simple, yet effective ways to test collisions than what I currently have
Looking Forward
Our game is coming along very well so far! We have prototypes of main mechanics, and are starting to work on the assets that add to the feel/style of our game! Nonetheless, we can't get cocky in our progress and need to continue to work at maximum efficiency so can have time to apply the layers of polish we oh-so desire to do!
We are also putting a hold on the checkpoint system for our game. We still want it in there, we just want to make sure that the rest of our game feels fun and fresh before we put the checkpoint system in. This decision came after discussing our ideas with Brian on Thursday, and realizing we need to design the checkpoints around the rest of our game instead of the game around our checkpoints!
Goals
By the beginning of October, I'm hoping to have the following progress made:
*Block Tunnel and Power Block mechanics in full, working condition
*Add more Global Variables to give the team more freedom to tweak from outside the code
*Have a spotlight that flickers and creates the film-reel effect we want
*Have temporary animations working as expected with the player cube and associated cubes
If I succed in implementing the previous, prioritized features I plan on working on the following as well:
*Optimize Collision Detection
*Optimize Cube Creation/Deletion/Recycling
*Create a game end-state
*Create a more visually stunning track creation system (more on this later ;D)
Another mouthful, another book written.
Hope those following found this intriguing :]
-Dave
No comments:
Post a Comment