Interactive Display Production 3

As I typically do after working on a project I would like to do a postmortem about Micro Quest to look at what went well and what could have gone better. As far as the team goes, there were not any major issues. There were a few instances where work could have done to a slightly higher standard, such as unclean code or overly high poly counts, but those are minor issues and not unexpected at this level. One of the major issues we had from the start was poor organization. There were several attempts throughout at maintaining a trello board for tasks but team members would often stop using this after a week or so. This made it much harder to review and manage tasks for the team. Additionally this led to some wasted or poorly prioritized work. Along with the organization issues, communication was never quite as good as it should have been. There were frequently times were I was unsure of what certain team members were doing. Going with that, our stand ups and checkouts were never quite ...

After adding in the grass barriers to the game last week we immediately ran into performance issues and saw our framerate drop from consistently over 80 fps to roughly 3 fps. This is obviously a huge issue that we needed to resolve otherwise the game would be unplayable. I spent part of the weekend looking into various ways to help deal with this issue, such as occlusion and draw distances. Unity automatically does some occlusion so I focused more on the draw distances. Mitch and I fired up the build today to try and work through the current issues. While implementing the new draw distances we ran into some issues which I will get into in a moment. To do draw distances we used unity's built in layer culling distances. By doing this we could set the grass to a much lower draw distance while still allowing the play set and other set pieces to be very visible even from a distance. This worked quite well and helped bump the framerate back above 60 fps. As for the issues we encounte...

When Connery, Mitch, and I worked on the ant last week one of the issues that remained was with the implementation of the object pooler. The way it was set up before the ants currently in the scene were also in the pool. So when a new ant was needed it may not be able to due to the number currently active. This is fine except for the fact that it will simply check the next ant in the pool instead of seeing if any are available. So even if the max number of ants isn't spawned, the pooler may not spawn an ant when it is supposed to. We recoded the object pooler to keep two separate lists, one of ants in the scene and one of the available ants in the pool. This way when it tries to spawn a new ant it simply checks the list of available ants. This provided the desired behavior and the code is much cleaner now as well. After refing the object pooler we further tested the game, combat in particular. As we tested we made a lot of small adjustments to the ant, such as move speed an...

For the past few weeks several of our programmers have been working on pieces of the state machine for the ant's AI. When we tried to pull the various scripts together we ran into some problems with them. Mitch, Connery, and I spent much of this week fixing them as a result. One of the issues when looking at the state machine scripts was that many of them were not written particularly cleanly and there was quite a bit of bad practice going on in regards to where certain objects were being referenced and found, as well as certain code being looped and repeated unnecessarily. One of the biggest things we did to fix this was ensuring the state machine as a whole retrieved any necessary objects one time then provided those references to the various states as necessary. There were a lot of issues with the transitions between states as well. There were quite a few times when an ant would just cycle between two states every other frame, which resulted in some rather odd behavior. This...

I recently have been working on a couple of the states for the ant state machine as well as the new ant animator controller. For the state machine I've been writing up the attack and death states. For attacking the ant has a small delay after which if the player is still nearby they will take damage. I decided to do attacks this way rather than with collision detection due to the fact that we already have a lot of different scripts utilizing triggers and colliders, so I was unsure of how they would interact with additional colliders for attacks. Also I was unsure of how effective the ant's attack would be if it was tied to the collider on its leg based on the attack animation. The death state was simple enough. Upon entering the death state a timer starts along with the death animation. Then after a set amount of time the ant object will destroy itself (or despawn once the pooler is integrated). Along with that the ant is not allowed to transition out of the death state at al...