Senior Production Blog Post #5

Senior Production

Senior Production Blog Post #5

It’s the final week of the project and that means time for a post mortem of the project. Overall the project went really well I think.  There were certainly many hiccups along the way, with some being handled better than others.  The work we did was really great and I think most of, if not all, of our team is happy with the end result we produced.  The biggest detractors from the project in my opinion were a lack of productively from team members and some disorganization from the leads.

There were many factors that contributed to the lack of productivity from the team.  Covid still raging on, isolated, and other classes from school to name a few.  This led to some of the level design, UI implementation, and weapon implementation getting a bit behind.  A major setback in the level design was level scale.  Our beginning levels were really off scale and certain members of the team weren’t really focused or participated very much.  This delayed the start level iterations for a couple of sprints.  Initially the level designers worked on the tutorial level for the game while figuring out the multiplayer level scale, however making the tutorial took more energy than initially thought, which meant work on the multiplier level scale ended up being delayed and/or worked on by people who had very little level design experience.

The second issue with the way the leads organized the project with some of the meetings.  This was their first time organizing and being leads.  Some of the meetings could have been organized better and some things started earlier.  QA was one of them.  We didn’t really get started on planning what we wanted from QA until part way through the project which showed some of the earliest data.  It also would have helped us scope what we wanted to implement each week and set deadlines for when things should be merged into our core develop branch.

For me personally I think I was a good collaborator and developer overall.  I think I should have fought some for more design work earlier on in the project, but was happy to help the programmers implement some weapon features and make good use of my second major in game programming.  I could have taken a bit more charge when I came to areas I thought were somewhat lacking such as the previous QA issues I mentioned earlier.  Talking with the leads and telling them what I think they could have been better was definitely something I can improve upon.

Senior Production Blog Post #4

Senior Production

Senior Production Blog Post #4

It is post alpha at the time of this blog post and I have started balancing the game.  I’ve put off finishing the final weapon for the game in order to help get the balancing process started.  I’ve organized a QA planning meeting for our QA lead, design leads, producers and I can start planning out QA sessions for the upcoming sprint.  I facilitate the meeting to see what we want to test for this upcoming sprint and who we need to talk to in order for the tests to run successfully.  I’ve overall been trying to help get the QA pipeline to run a smoother since my balancing data depends on having good, reliable testing data.  I also have plans to start notifying people in our Discord server to start more internally testing changes I’ve made.  Ideally once the dev tools get integrated into the game I should be able to do more live tweaks, which means I can gather a small internal testing group and change values while they test.

In addition to tweaking the weapon’s values I’ve also started working on the balance of levels and prepping a mock-up for the level we are currently developing.  When setting up the document I first took the level sketch that our lead artist made with the help of our level designers and traced over it in Adobe Illustrator.  After I traced the sketch I then created a set of symbols for key points of interest such as team spawn locations, weapon pickups, and repair kits.  After the symbols are set up then I can start placing them, which also brings me to my biggest impediment, map detail.

The map sketch is just a sketch so there isn’t a lot of detail.  There were large swaths of empty space that I don’t know about.  I made some assumptions with what would be placed there, but I also talked to one of the level designers to see if I could get some quick sketches so I could see where the spaces are headed towards.  Height is another issue with those white spaces too.  Are the buildings in those white spaces going to have the same height, creating a large level top?  If I go about it this particular way I am still iterating while still moving towards what the level designers had in mind.

Senior Production Blog Post #3

Senior Production

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.

Senior Production Blog Post #2

Senior Production

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.

Senior Production Blog Post #1

Senior Production

Cedric Brownewell

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.