Quick update for all you party people,
Mason has been focused on bug fixes this past week getting rid of a pesky visual bug that happened whenever the intern took damage. There was also a problem with how enemies handled creating remains after they were destroyed. We’re trying to clean up the enemy scripts as much as possible as we’ll be moving things around to accommodate the enemy behavior system. Which is shaping up to be a robust system
This week Peter was able to start diving into the enemy behavior system. It still isn’t functional in any demonstrable way, however Peter hopes soon it will be functional enough that Mason can start creating behaviors for it and we can really start running it through its paces. Peter is getting really excited about the possibilities for this system. A little too excited…
Gewargis kept chipping away at the dialogue system. He was able to incorporate sounds so the NPCs now have a voice while talking. It was a bit tricky getting it to sound correct. The key was to play the talk sound per character, which gives it a more human-like cadence. We’ll refine as we continue, but we’re happy with it right now.
Hey all. Just a quick update this week showing off some updates to the E-Tool. Are you tired of this happening:
Well now there’s a better way. It’s the E-Tool! The E-Tool uses video game age technology to damage enemies from afar. Check it out:
Just activate the E-tool and press the correct sequence to hack into the robotic enemies. Good work Intern!
Stay tuned for more updates!
This week was even more organization focused than last week. The team talked a lot about solving the problem of building unique and complex animators and animations over and over again in the object-creation-pipeline. Right now this is mostly Larry doing this, and it often takes longer to implement the art than it does for him to draw it. So Peter is building several tools described briefly below to mitigate the issues. This will allow more time to design and draw objects, and less time waiting for them to work in the game. Additionally, the reorganization for the project folder has begun, ultimately working us towards a much clearer view of our game as development shifts from prototyping to the main game.
As you may know, lately we’ve been putting together a scene that will serve as a playground for our testers. This meant moving around enemies into several different spaces to help find issues. One of the big things that we immediately noticed was that enemies that can fly become frustrating when they fly past walls and ceilings. What started as a frustrating limitation, though, is becoming an interesting opportunity to think about ways to improve on enemy behavior. The Bat Bot has been updated to stay within the bounds of any ceilings but another of our enemies, the Brain Bot, will be a much more interesting challenge. Without getting too into the specifics the solution for keeping the Brain Bot in bounds has the potential to branch out to future enemy types.
We have several scripts ready to go that would support building of the game itself over focusing on just a playground area. This set of levels is helpful in working out issues and ultimately refining the gameplay before being confident to dive into the gameplay of the story missions and other crafted areas. Fixing content in those special areas could have effects further down the gameplay chain, so a round of refinement in a more isolated environment is favorable to us. That said, some story mission levels have had their spaces mapped out already, and we’ll continue to do that just to save some time later when we start digging into the scripted content of those areas. A higher priority than those story mission levels however are the many spaces the Intern can visit before/during/after a mission (the non-randomized areas). Several of those levels have also had their spaces mapped out, but need to have content to support the gameplay — alas missing.
This week was a better week, giving us some extra time via a session mid-week to work out some issues with combat.
Coily was experiencing a strange bug where he would get caught in an animation loop. Since Coily’s behavior is heavily dependant on the animator, getting stuck in a loop there can put a kibosh on the whole behavior logic. What was particularly frustrating about the bug is that it seemed to appear from nowhere. The actual reason had to do with adding an activation trigger to Coily. The trigger was continuously invoking a method that changed an animator property. The problem was easy enough to fix and it taught me a valuable lesson about the Invoke method and how to best communicate with the animator.