It’s about a week until Greenlight and the game is really coming together.  Weapons are becoming more stable, we have better reference directions for levels and all around increased the quality of our production.  We did get some helpful advice from our production teachers about the scope of what we were trying to accomplish and upon reflection our leads thought we might be doing too much in such a short amount of time so we brought back the scope.  We had originally wanted two game modes, a regular deathmatch (possibly team deathmatch too) and a custom gamemode called Breakdown where instead of just trying to get as many kills as possible the player gains points by getting kills in unique ways.

This change has altered my work a little bit, but not too much.  With the reduced gamemode scope our programmers are working on making sure the networking and its related systems are up to date.  I took on the work of bug fixing the weapons we currently have.  It’s a job I’m happy doing since it lets me build my expertise in blueprinting.  Additionally bug fixing the weapons takes less pressure from the other programmers who already have a lot on their plates trying to get things ready for Greenlight.

The weapons are fine at the moment except for one, which is the Supercell (formerly the Derecho).  The Supercell currently has two core issues: the projectile damages the person who fired it and the movement is jerky.  The former problem is caused by something in the projectile code, however I have yet to verify this.  I have tasks set out for investigation of the problem and tasks for the actual solving of the problem.  I have it split up this way so that in case the problem isn’t easily solved.  The issue might not be what I thought it would be and if that’s the case then I have a task that doesn’t accurately cover what I am doing and spending more time on a task then predicated isn’t inherently bad, but does signal poor planning if extra time is significant.

The weapon projectile speed stuttering is most likely an issue with the server calculating the movement.  It will be a small tweak I imagine, but I have the same task structure as the damage bug just in case something goes awry during the bug fixing process.

Testing has started in earnest as well.  We had some good results so far with testing sessions, both external and internal.  I am trying to push for more data on the weapons such as their range, how often they are used, etc.  Our team has not yet had any formal meetings for QA, but after having a meeting with my design discipline advisor, he made it apparent that I need to be involved in the QA process.  I can’t just be there to get the data earlier I should be part of the process guiding how some of the questions should be shaped alongside our QA Lead.

It’s about four weeks into the project now and things have started to pick up in the project.  Balancing is still not on the forefront of my work, however I’ve still been able to help the team.  Since we don’t have quite enough data to effectively balance at this point I’ve had plenty of time to get familiar with the weapons code.  I’ve been implementing some of the weapons.  One feature our leads wanted to add were weapon alternate fires.  I was assigned to implement the alternate fire for both of the guns that were already created, the Volt45 and the Derecho.

Implementing those alternate fires was tricky in the beginning.  I had very little knowledge of how the Unreal Engine’s Blueprint system works so this was very enlightening.  Fortunately for me the weapon’s were set up in a C++ inheritance structure, a version of polymorphism I am very familiar with.  The hardest part of the process was becoming familiar with the Unreal syntax.  With time and effort I managed to get the two weapon’s alt fires to work properly.  In addition to learning how to code blueprints I was also introduced to code reviews.  Code reviews are something I had heard about in my periphery, but never got to experience until now.  I am going to try and do more in future to get better acquainted with the programmers on my team and to also help build up how code reviews should be done.

I was also assigned to fully implement a new weapon in the game.  The weapon is a sniper rifle-esque weapon that can attack from far away, but the fire rate is low.  I’m still in the process of putting it together, but it will be my first full implementation.  As previously mentioned I’m getting more used to blueprint coding I have not spent as much time exploring the inspector and other parts of getting the  weapon to appear in game.  I’ll need to apply a mesh and test to make sure all functions of the weapon work as indented.  I’ve made a note to set up a meeting with the design leads so I can show them the weapon.  If they don’t like something about the weapon I can make notes and readjust the weapon based on that feedback.

Testing has started which means things should start picking up for me in terms of balancing work.  We had a few bumps in the road with our networking, but they were quickly fixed after testing so the next QA session should prove more fruitful for balancing information.  We also have more levels being grey-boxed so I will be taking a look at them in the next sprint (or earlier if time permits).  Looking at the grey-boxed level should help me establish a better rapport with the level designers.  We will be working together very closely once balancing starts in earnest so becoming familiar with them will prove advantageous in making changes to levels or systems.

One last thing I worked on these past weeks was to help develop a new game mode.  It’s called Breakdown and is a take on traditional deathmatch.  Instead of score being entirely dependent on the number of kills.  In the Breakdown game mode, players are granted points based on how many kills they get, but are rewarded with points multiplier if they do cool things before, after or during the kill.  Some examples of cool things are kills in motion, successfully navigating the map without running into anything and multiple kills in a short time frame.  Testing should provide more ideas for cool actions to perform, but for now we think we have a solid start on the game mode.

Cedric Brownewell
2/6/2021

It has been about two weeks since the start of the semester and the project.  It has been great to get to know the team.  I was on-boarded to help with systems design and balancing the game.  Because of those reasons I was also put onto the backend team.  Our current team structure is divided into a front end and a backend team.  The backend team is in charge of things the player won’t directly be interacting with such as networking, developer tools, and mechanics, while the front end team will work on aspects such as level design, environment art and UI.

The backend team’s biggest project right now is getting networked play up and running.  While a great goal, this unfortunately means there isn’t much balancing work for me to do in the game’s build.  In order to be productive I have been trying to help the programmers on the backend team.  I offered because in addition to my Game Design degree I also am working towards a Game Programming degree.  Since in build balancing is feasible at this moment my role in the team is to help design the developer tools that I will be using to balance the build.  It’s a good job for me to have as it will help me familiarize myself with the tools I will be using in the future to gather data and make changes.

I have also been putting together a plan for when I can actually get into the build to start balancing it.  I’ve been keeping track of who I should be in contact when I start balancing the game.  Some of the areas I’ve identified so far are the weapons designers, level designers, and systems programmers.  The weapon designers and systems programmers would be needed in case a major change had to be made to a weapon. The changes that would require that level of collaboration would have to go beyond just simply adjusting the weapon’s values. Adjusting values such a damage and clip size is something I should be able to do with in the engine editor.  Level Designers would need to be brought into the loop incase of any tweaks in the weapons or game modes. These changes might change how the level needs to be laid out so they should be included in the process.

I expect to participate in QA for a majority of the project duration.  Having the results and making sure the tests collect good information makes my job easier and more efficient. Good data means clearer results and well informed decisions.  One of the tools the backend team wants to develop is an admin spectator tool so that developers can watch the games in action. It would be a useful tool to help supplement the other data we’ll be collecting with context to the decisions we see.