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.