CAGD 470 - Sprint Blog 3

I am the designer of Group 1, the team making Vampiric Checkmate. So far, this sprint has been the most challenging one for a multitude of reasons. The work that we set out to complete during the Sprint Kickoff was as follows: Implement skills, implement items, implement the acquisition of said skills and items, test the level generation so that it was functional for the player to navigate, and have a workable prototype to give to people so that we could obtain playtests. Despite these goals being an extension of the past sprint goals, in which we were fairly successful at completing, we struggled to meet our deadline for these goals. 

Part of the issue that inhibited us from getting to a comfortable point with the development of our game was that the overall concept of the game contains a lot of different moving parts. By the very nature of the game, I knew this from the start. I wanted to include procedural generation in the level creation so that once it was complete, it had a ton of replayability value. In addition to that, I knew that having a skill selection feature common to most roguelike games would exponentially increase the amount of gameplay variability that any given player would experience. So, even though we did slow down in terms of pace from the previous two sprints, it was accounted for and was the reason why I wanted to tackle such major features before we hit the halfway point of the development cycle. 

UI flowchart I created for Heath, one of my programmers.

The other issue that I anticipated to a much lesser degree was that the communication among my team members was lacking. Putting a build together was a somewhat difficult ordeal because even though we had many individual parts developed and within the Unity project, we had yet to actually put any of it together and make it a singular cohesive product. This issue did not affect us for the entire sprint, though, and instead just caused a spike in stress towards the end of the sprint. 

This process has been measurably different from my previous experiences developing games. Having two programmers instead of one does not simply translate to having double the code production, though it does provide a nice boost. What I have realized from this past sprint was that instead of having a single programmer need to communicate with me about how development is going and showing what features do, I need both programmers to communicate with me alongside each other. This makes development more difficult than I thought it would, simply because I need to consider how much the two programmers are communicating and then consider how much easier or difficult it makes doing certain tasks such as creating a build.

Some examples of concept art made for Carl, my modeler.

The work that I completed this sprint was primarily focused on concept art, much like the previous sprints. This sprint was likely my least productive sprint as my work for other classes began to pick up simultaneously. The beginning of this next sprint will consist of me finishing the leftover concept art which I was assigned last sprint. Additionally, I am shifting my focus towards developing the UI. 

I initially tried to avoid programming altogether, simply because I was aware that my programming is far from my strong suit and it would be more efficient to allow one of my two programmers to handle that work. I changed my mind about this when I realized that both of my programmers already had their hands full trying to finish the two major features of the game. As far as programming goes, UI is on the easier end, will contribute directly to making the project feel more finished, and it allows me to alleviate some of the workload off of my programmers. 

More concept art, for sprites and models.