Anyways, we did make progress since the last blog post. All issues from the problem list have been solved, except for the following:
- Disconnecting from an unresponsive server takes too long
- Gravity toggle stops the player's momentum from their own movement (but not momentum from pushes and abilities)
- HUD will occasionally stutter in it's display.
- We know where the error is happening for this, but not how to fix it. It's a weird issue with Unity's OnGUI system.
When fixing the grounding issue, we had tried several methods of seeing if the player was on the ground. The first method was simply using the collider to determine if we were colliding with objects below a certain point on the collider. This was effective until we altered the shape of platforms to include a subtle slope. The collider doesn't nicely slide down this slope while moving, and will quickly alter between the touching and not-touching states when moving down. We tried to fix this by introducing a delay after the collider left the object, and if it didn't come back into collision within that time, it would actually be considered off the ground. However doing that caused another issue, the player's jump counter is reset while the player is on the ground, and about 10% of jumps would not register as properly off the ground, essentially giving them another free jump. Extending this to catch this odd case would have gotten even more complicated, so we went back to the drawing board for detecting groundedness. We created a class, called Groundable, whose job it was to determine if the object was on the ground. This class simply fires a raycast a very short distance below it's parent object, checking to see if it hit anything (other than the object itself). This method solved all of the problems described above, and is actually portable enough that we could apply it to other things, such as crates if we needed to check their groundedness.
Beta 1
The Beta 1 test went very well! Our group of users were thorough in testing all the pieces of functionality for any bugs and such issues. We received positive opinions about the game, but nothing really constructive in that regard, probably due to the younger age of the test group this time. However, we did glean some interesting pieces of information from watching them play:- Inexperienced users would control the character with the arrow keys, making all the ability controls unreachable
- We are going to disable the arrow keys, as it only creates bad habits, and there is no way to map all the functionality of the game to keys around the arrow keys on the keyboard
- Ability keys at QERF was not intuitive
- We are going to also map the abilities to 1234 as alternatives to the QERF
- The blink ability made the player virtually unkillable if used correctly
- It was way too easy to just blink up into the air, back to safety
- Players could blink out of the map, killing themselves on accident
- Aiming the cone ability was difficult for inexperienced users
- Users complained about not being able to see the edge of map, where they will die.
- This could be solved by adding a colored plane to the edge of the map, however we don't know if this will actually be visible and distinguishable due to it effecting all directions. It may be simpler to just leave things the way they are
Scholar's Day
We prepared a poster for BVU's Scholar's Day. We will be 'presenting' the poster while other students, faculty members and such look at the work students have been doing for the year. It's some very cool stuff, and a great opportunity for us to tell the world what is going on with this crazy project. Here's a copy of our poster, for those interested:
We're doomed.
So we reviewed the original schedule for Dias, that was created way back last semester:
According to this schedule, we should be much further in our project. Namely, we should have all abilities implemented, breaking and moving platforms, a platform generation system, and a respawning system. We can safely say our goals got a bit lofty toward the end of this schedule, and we did a poor job of predicting how long it would take to solve certain issues (not to mention we added animation, which isn't even on this schedule...) and how full our schedules would be.
The first decision we made regarding this schedule, and the end-of-semester deadline that is swiftly approaching is to cancel the Beta 2 Test. We won't be able to implement any sweeping changes to the game and be able to test them by the time that the end of the year arrives, so we simply plan to move ahead with any changes and not have another large test.
We realize that there in insufficient time to complete even a fraction of these items before the semester is over, so we are going to focus on 1 or 2 items and try to complete them by the time the semester ends. The items that are the most appealing are:
- Add missing abilities
- Complete work on character weight
This has been a very constructive semester, and looking at this schedule really nails home how important it is to take into account problems that are going to occur during development when picking deadlines. We should have added sufficient padding around certain items in the original schedule, and been less eager to squeeze even more features in. The ability implementations is still surprising with how long each of them took. We easily could have spent an entire week on certain abilities, let alone 2 weeks for all 12. This is a really important concept that will definitely be taken away from this project as a whole.
