GAZE OF THE ABYSS/RADICAL RAT RUMBLE

The Vampire Crew

So for this last blog post I'm going to talk about some a bit unconventional, which is team dynamic. Specifically, team dynamic at 3 am, which has been specifically dubbed the "Vampire Crew". This was essentially just another team member and I having our optimal work hours after midnight, and since we were the only ones awake during that time, we essentially got a much clearer communication since we were the only resource to ask about project going ons. While people might view this as less than ideal, the workflow was great as we were able to focus and get things done. Besides work meetings, I feel like this was the most productive time I've had, as its just people working, with nothing else going on at 3 am. The only other conversation that happened was a team member occasionally coming in and telling us to go to sleep, which was responded to with a resounding no. I feel like this was a good experience because not only was a lot of work done, there was clearer communication between the disciplines because of this. I felt like I understood the design of the aspect more, and I think they understood the programming a bit more. I guess the moral of the story is that the best workflows can happen in an unplanned, unconventional style, and that generic meetings can sometimes leave open gaps that can be filled in by other conventions.

Releasing the Game: Patching it all together

So this week was set out to be the "release" week, which meant patching the game all together, cleaning it up, and shipping it out. Since we can't pay the hefty licensing fees, we are releasing for free over an itch.io. We are also seeing if a donation button will be legal and if so what will be done with that. The only problem is there was quite a few patches in the game that needed fixing. The most glaring issue was the ending, which as I am typing is currently not finished. Hopefully it will be finished by the release date, because that would tie the game together well. We also need a few small things like menu improvements, a few quality of life changes, and possibly some lighting adjustments, depending on how it goes. Now, the only catch here is I put in a whopping 40 hours of non class time into the project this week, and technically more if you count prep time. And I want to clarify here that I gave myself this work, and it was not forced onto me. I could've easily done the minimum amount of work for this week, but I decided to "up the ante" to get the game into a truly finished state. And I am proud of it, and I'm looking forward to taking a week off after this and not working, so its all well and good in production land. But it feels good to "ship" the game soon, and to work on the next game that comes my way!

RPI GameFest

This weekend my team went to RPI's very own Gamefest to present our game, Gaze of the Abyss. While 7 people were slated to go, only 3 of us went because of forces outside of our control. The upside is we only needed 2 people to man the booth at one time, so the people who went switched off every hour and a half in order for everyone to get a break. The events leading up to RPI (The organization, planning and travelling) were less than ideal but nevertheless my team persevered and we eventually arrived, set up the booth, and demonstrated the game to what seemed like a couple hundred people. While there were some bugs present in the build, none of them were game-breaking and they were fixed that night when I got back. So that part I view as a big success. It seemed the attendees liked the game, and praised the concept as being innovative. From my experiences manning the booth, almost every person got through level 1, and then the general stopping point was somewhere in level 2. The average playtime was around 10 minutes, with some people going over and some people going under. I believe only 3 people actually played level 5, but most of them used the level select to get there. The experience of looking at other peoples games was also quite cool, as we were able to see games that were 2 months in development and other games that were 9 months in development. All in all the experience was an enjoyable one and I look forward to attending another GameFest sometime in the future, possibly with the Capstone game.

Programming Art

I'm going to be talking in this blog about something I don't talk about a lot in the world of programming: Art. Now for this game we had a bit of procedural animations. And I took up the job of doing this because I believed it would be a fun time. It was, but I also had to learn about how to animate first. My first task was putting some bones into a model.

So I had to boot up good old blender in order to properly do this. And since my experience with blender was near zero, it was an experience doing this. I looked up some tutorials and was able to place the armatures inside of the lamprey tail to get it to move properly.

This was effectively the result. You can move the tail around any which way you wanted, which allowed Unity to procedurally wave around the tail and do some things that look really good. The upside is any sort of mismatches that happened (there was a very small seam in the left) wouldn't be noticed as the lamprey would move fast and then kill you so you wouldn't get the time to notice a lot of it. This was the final product that went into the game:

All in all while it wasn't artist quality work I was very happy with it because I felt like I understood a lot about procedural animations which I didn't really have a lot of knowledge about beforehand.

Revisions and Revisions

Now, before I start, I want to say that I'm not complaining about re-visioning. It is a very important part of programming. Instead, I'll be talking about one object that has undergone multiple revisions in the game: The angler fish. Now, this has undergone 3 big revisions, and multiple smaller revisions.

The first revisions is where the angler fish would attack the player until the player dies. If it doesn't see the player, it will just follow some waypoints. It was quite annoying, and was changed up in the next week. I went back into the revision history to grab a snippet of the code at the time:

Not very sophisticated, but it was a rough draft (Most functions not shown).

The second revision of the script was where it would then back up after hitting the player, then proceed to attack again. As before, it would follow the waypoint system if it couldn't find the player. This system hit a few bugs, where it would frequently back up through a wall/move through a wall. The bugs were fixed, and this system survived the longest of the three. Eventually, after about a month of being on the table, it was changed because it was still very annoying. Here is the revision at the time:

The complexity is increasing, and with it, the quality. However, there was still a few things that could be done.

The third revision (the one currently on) is the most well recieved out of all of them (I would hope). Essentially it doesn't home into the player it gets the position it found them initially at and targets that. After that, it stays still for a few seconds before continuing on the waypoint path again. This is simpler than the second, more complex from the first, and is liked because it doesn't home in, so it gives the player time to escape. This underwent a few revisions at first where it would wind up, then attack, and we settled on the cooldown after attack. This has also gotten a few bugs, such as the anglerfish sometimes staying on cooldown permanently, but the bugs were fixed. Here is a screenshot of the newest revision:

It might seem more complex, but that is mostly due to the stun mechanic also added, which stuns the anglerfish if it is hit with a flare.

In conclusion, this is basically how revisions can help your game overcome various problems, even if the code "works as intended" at the beginning.

Milestones and Releases

So up until now its just been about sprints. What can you get done in a week? What can you get done next week? And so on and so forth. But with Production II its been stepped up to full release. When does polish come in? When do we stop prototyping and start producing a finished product? When do we put the alpha and beta stages, and what will be on them? Will we try to go to festivals and conventions? Will we put it on Steam? If so will it cost money? There were a lot of questions that came up and we still don't have answers to some of them. But this is the first real time we have had to answer these questions. And sorry in advance for the lack of pictures here, this is mostly just a discussion based blog post and doesn't really have to do with the game per say and more of a conceptual thing.

So with the remaining weeks we allotted three school weeks for alpha, three school weeks for beta, and then the release at the end of the school year, which would be two school weeks. We are planning to attend GameFest, although we have not signed up for it yet.

The alpha build will be systems complete, meaning that all the systems will be done by that point. Since this is the first milestone, it was building up the game into a full proof of concept state, with a few levels inside so you can essentially play a demo.

The beta build will be feature complete, meaning that the game will be playable start to finish with no blocking bugs. During this milestones we will focus on implementing the systems, adding a bit of polish and catching bugs.

The polish build will be essentially the finished game. No bugs detected, game is fully fleshed out and playable, final art assets are in, etc. This time would be spent fixing any bugs left, polishing the game further, and preparing to present the game.

I look forward to carrying to the game to its full release, and to the whole one person out there viewing these blogs, I hope you are too.

3D AI Programming

After the first week of integration the designers provided the other programmers and I with a systems list. This is basically of the systems that would need to be in the game by the alpha build. We divided up the systems so I choose doors and the lamprey AI for the first week of systems programming fun time. Now Unity has a built in navmesh so it should be simple right? Wrong. The navmesh only works when you need to move across the ground. However, since this is underwater, they need to swim in all directions. So it was time to apply what I learned in AI programming and so my pathfinding.

This is a demo scene that I've been working in for the last couple of weeks. I added a waypoint system since navmesh in all directions would be much more time consuming then we need it to be. So the lamprey basically find the proper path to the player from whatever waypoint the lamprey is closest to. Since this is meant to kill the player quickly it needed to be fast and efficient. The only gotcha is that the waypoints need to see each point on the map so you can accurately pathfind. To resolve this I made a 100% professional diagram to show where to place the waypoints:

Essentially you need to place waypoints at all the corridors, doors, behind any obstacle that blocks view and at the center of every room. This insures that each position is viewed and the player could always be found. There is still some suspect testing to be done but I have yet to find an edge case.

Team Integration - Midmordems

After midmordems I was tasked with joining a different team. This game is called "Gaze of the Abyss" an atmospheric horror game about exploring an underwater ship and finding out what happened to it, and the monsters that lay beneath. Here was a demo reel made beforehand (I had not part in making this demo reel, I am just showing it to give a context of the game):

Now this game already had two programmers, but they felt I could offer a new perspective on the game with a new programmer on board. I compliment them on readily adapting to five new team members, including myself, and we were quick to get on to the project. We added new animations and blend trees, new mechanics such as a key/door mechanic, and are currently making a new AI system into the game. The biggest obstacle we faced was using Mercurial with 10 team members. While the programmers and designers were the main ones to commit to it, that still posed a problem we had not yet come across. It mostly seemed that the commits were either not syncing or we were updating the same parts at different times. While this is still an ongoing issue, we have resolved a bit of it with conventions and branches. In order to get presentations right, we have cross checked a closed branch to make sure it works properly the first time. While it is not nearly as complex as industry trees, ours is shaping up to something like this on the right ------->

But I am excited to see what this game can do and look forward to bringing it through to the finals

Combining Genres

For Sprint 3 my team went with a platformer/fighting game. Now this may sound daunting for a two week long project, but it was actually quite doable with enough determination and teamwork. There was a few different problems that faced the game in the beginning. First of all, Rewired, a Unity plugin, refused to recognize multiple controllers. We eventually found a solution of plugging in one controller, starting the game, then plugging in another controller. We also used a character controller to start with, which posed a unique set of problems of not appearing to be "natural" combat. This was the result of the first week:

It worked for what is was. The main problem was there was no incentive for platforming. The main health mechanic was essentially just sonic rings that would take the form of cheese in that they spring out in when you get hit. The problem is that everyone would just fight in a closed area as that was where all the cheese was. There was no incentive to retreat or to platform. So it was back to the drawing board for the second week. The structure of the cheese was changed so that it would find a random platform, so that players would have an incentive to actually move around. This revolutionized the game, and made players move around and fight a lot more dynamically. The map was also shortened so it was more action along with the platforming. This way the cheese wouldn't fly a football field away and players would spend 20 seconds getting back into the action. We also added in animations (courtesy of mixamo) and a character select screen for scalability.

So after the second week the game was actually working well. It had animations, a good level, a combat system that felt fluid, a movement system that felt better, as it used a rigidbody system instead of Character Controller, and a reason to platform. Would this project make it through mid-mordems? Find out in the next dev blog!

3D with Sprites and Taking Risks

So for Sprint 2 my team came up with a 3D base building type game but the players and enemies were sprites on top of a 3D world. This is most prominently seen in Don't Starve, where the player moves around a 3D landscape but with a 2D environment. This was a little different as only the environment was 3D as well, and it was in a more blocky fashion, similar to Minecraft. The trick to get this little camera angle is to actually just skew the 2D sprites 45 degrees in order to make it look like they are on the blocks.

^This is the view from the editor. As you can see the camera and everything is just slightly skewed to create depth to the sprite. The problem with this however is it created a few tricky issues. Players often felt a lack of depth on which exact tile the player was on, since it was grid based movement to emphasize a more blocky feel. While the code itself worked in theory players thought that it was always off by a smidge because the actual position was the sprite center. This was fixed by simply applying the pivot to the sprite, but it was still an interesting issue that came from this concept.

Another issue that arose from the game was the building of a base. Despite the other issue of the player not appearing to be in the correct place, it involved a base detection script in which if you built three walls in a box it would detect that ground as a base and enemies wouldn't need to go into it. A problem quickly arose in that detecting three walls in a box formation wasn't as easy as it sounds, and involved a lot of raycasting and position checking. This could sometimes lead to issues like this one, where the base would detect incorrectly:

While I had eventually figured out a solution, it took multiple hours to really get the base building right, and when I did manage to fix it, the game never went forward since there was a lot of risks taken in the game and it was felt that it was too many to polish up in a week and a half to present. While I feel like this definitely had potential as a cool atmospheric game, I agree with the teams decision that it had too many variables and risks to fill out to give it a good enough chance. But I did learn a lot about risk taking and different camera structures and game types, so it was a successful experience for me.