This sprint went well, I completed all of the assigned cards, which was 12 points, and my honesty with the producer led to this and less confusion.
First I started this sprint by finishing the character I didn't complete last sprint, which was the new Alien NPC model. I finished the high poly, low poly, and two textures for this character. I'm happy how it turned out. This character didn't take as much time to complete since it was much more simple, and I had good concept art provided with it, so I didn't need to come up with any last minute ideas. The entire process was predictable and I always knew what I was doing and how much was left.
I'm happy with how this character turned out. I think it fits with our game's style very well and he looks very clean.
Something that went very well for this process was me learning a new technique for retopology. Retopology usually takes a very long time, but this time I used ZBrush's remesher tool and polygrouping for ID maps. This won't always work, and it requires some cleanup in Maya, however it streamlined a lot of the processes. This isn't always advisable for models with lots of animation work done on them, however our NPC's have simple animations associated with them and therefore this was fine. It saved a lot of time, despite a few hiccups here and there. With enough research and tutorials this new process was well worth the time taken aside to learn it as it has sped up my process lots. Before, I would have been more adamant to try something new as the amount of time to learn a new task can be intimidating midst the fast-moving nature of agile development. However, in this case, it paid off greatly, and I wish I had tried this sooner. The real mistake was not researching faster retopology methods, rather knowing about a faster method but being too scared to try it in a stressful and fast-paced environment. It would have paid off to try this much earlier, and would have sped up the process for my other NPC. In the future I plan to look into and at least try other methods of doing things more frequently. I used this class as a testing grounds for another project I'm working on for CAGD 330. This is another great strategy, where I can test something in a place where the stakes are less high. In this case, the team didn't mind too much about having perfect topology, but in my 330 project this was very important. Testing this technique here, to later be applied and built upon in 330 was a very smart decision.
I also had to go back and make some changes to our antagonist's texture. This was mainly my fault, I missed a few key details in the texture and received some notes after Sprint 5. However I got to this quickly and this allowed me to focus my attention on the new set of tasks I had, which was animations in-engine.
Animation in Unity isn't entirely new to me, however it was important I got off on the right foot familiarizing myself with our engine and how characters work. I did some research, got my repository and branch set up in our GitHub, and got away to working. I solved a good amount of animation issues with our player character. This is important as the player can have unpredictable inputs and movements, and its critical that the player has good feedback with their inputs for the game to be fun.
I solved lots of issues using animation masks. This cleaned up the animation controller, which previously was a huge spider web of animation states. Now the animations are split between things that the legs do, and things the arms do. I also managed to add animation controllers for our wolves.
Of course however, things did not go according to plan. There were some issues in these animation tasks, and unfortunately I'm not sure if they were my fault, even though I was the one who discovered them.
Firstly, what went well, is that our programmer, Colin, was very helpful in explaining how our character scripts worked so that I could use them. This streamlined my process and eliminated any issues or bugs that I created. It also helped me identify some of the critical issues our game had that stood in the way of animations.
Another thing I think I did well was fixing some of the issues in our game that made it impossible for our animations to look good. For example, the player could kick while they were moving, which gameplay-wise, makes sense, however our animations didn't reflect this. Our character didn't have a jump-kick, or some sort of animation that would have made this seem correct. Instead, our character lifted one foot. This meant that our player couldn't blend a kick with a walk animation, as it looked confusing, and the player couldn't kick instead of walking because this looked bad. I got permission from a responsive lead and programmer to stop the player for a certain amount of time when kicking so that this looked and felt natural. This was out of my comfort zone so I am happy I was able to fix this right when I cam up against it.
However, a few things went wrong. Firstly, I was blocked for a day, which was frustrating. This happened because a member forgot to upload some animations for our wolf. This is a mild inconvenience however it was strange that no one had noticed before. I didn't know I was blocked on this task until it was too late, and it cost me a day of work and moving my plans around to make sure I wasn't unproductive.
Next, I feel that some of our animations weren't fully planned out to reflect our gameplay. I had never faced this issue before, but had it been identified by our team earlier these issues may have been avoided. For example, our wolf does not have an attack, the player simply takes damage when they collide with the wolf. This is a fine system, and plays well when our game is grey boxed. However, now I need to play the animation after the player has already collided with the wolf. What is more, is that the wolf's attack animation is a lunge, meaning visually, the damage should be taken after the animation is played. What would have made more sense is a lunge that the wolf does, where an animation plays, and the player takes damage if that lunge connects with the player.
I didn't want to suggest this type of change this late in development, so instead I described the issue and suggested a solution. However, this fix unfortunately calls for a new animation, which is unfortunate. We identified this solution to take the least amount of work, which is necessary this late in development. In a way, I feel this was a success on my part since I communicated the issue so well, as well as came up with a fix that multiple people agreed was a good fix. However, I do think that if the designer communicated to the animator how the wolf's attack functioned better, this issue could have been avoided entirely. In that case, we would have an animation where the wolf simply bites, and this bite can be played after a collision. I do see how this can be confusing and hard to predict, but its a lesson learned from me, as making animations for a game can be harder than one thinks. Every animation must reflect the gameplay as explicitly as possible, otherwise those issues can cause for wasted work and time.
コメント