CAGD 470 - Sprint Blog 4
I am the designer of the game Vampiric Checkmate. This sprint, although we were able to complete a similar number of cards as we did in past sprints, it feels as if our progress slowed down due to a multitude of issues stemming from the complex nature of the game’s design. I personally was frustrated with myself because over the course of this sprint, I had many revelations about ways in which the core design of the game could have been improved, but I was unable to think of it prior to actually starting development.
The game was on the brink of needing to cut core features in order to create a reasonably complete product by the end of the seventh sprint. My programmer, Heath, had come into this sprint with a bug that did not allow him to properly scan generated maps to see if the player could make it to the end. However, just when Daniel and I were preparing to shift the focus and cut the feature of procedurally generated maps, Heath was able to fix the bug and move onto other programming challenges. I am very glad that he was able to figure out how to solve the issue, because when I designed this game, the procedurally generated rooms and levels sat at the very core of the design. Without having the levels be procedurally generated, the game would take on a much more uninteresting and lackluster experience.
The first half of the sprint was punctuated by our first electronic prototype. We were unable to get the generated levels functioning in time for that prototype, but we were still able to receive a lot of great feedback on the other features which needed to be fine tuned. For example, contrary to what I thought would happen, most players felt that they were given too much time to make moves. The intention of the in-game timer is to place an additional mental pressure on the player and encourage them to make more mistakes within their movement. However, because of the relaxed amount of time which the players were given, they rarely felt the effects of having a timer. This is an easy change that we plan on making, taking the timer from 10 seconds to 5 to 7 seconds long. The reason for such a drastic change is that I would much rather the players feel that the timer is too short and bump it up slightly than to only very incrementally decrease the timer over a longer period of time.
Another thing that I learned during the playtest which spurned my realization of the issue with the game design is that many players felt that the movement was too repetitive. Once the players understood the controls, they needed very little time to make their decisions and could spam the same movement over and over. I came up with an idea to add variety to the movement, which was essentially that the player would get a random movement “type” each turn, as if they were a piece in chess. One turn, they might be able to move like a knight piece, and another turn, they could move like a queen piece. However, that idea would considerably change the whole design of the game, and I decided against even trying to implement it because we were already halfway through the game’s production cycle by this point.
I recognized later in the sprint that although many players stated that the movement felt boring, it was not actually the cause, but a symptom of another issue which the game had. The timer did not apply enough pressure as mentioned, but the enemies were also lackluster. The player was able to see the entire level at once, which made anticipating the enemy’s movement very easy. I feel that if we are able to produce solutions to these much smaller problems, the effects will snowball and the game will feel much better to play as a result.
I spent the majority of the prior sprints focused on developing concept art for my teammates to work off of. However, this sprint, I shifted to creating the UI. Joseph, who is my other programmer, felt that he had too much to work on, handling both the player skills and items as well as the UI. So I decided to take over UI, because even though programming is far from my strong suit, it would allow us to produce better work much more efficiently if Joseph was able to focus purely on skills and items. I rewrote the main menu script almost completely because it was fairly barebones and referenced all of the UI game objects whenever something was changed. I made it more modular and then redid the basic visuals of the main menu so that they were closer to being in-line with how I envisioned the final product to be.
Comments
Post a Comment