CAGD 470 - Sprint Blog 2
I am the lead designer of Group 1, and the game we are making is Vampiric Checkmate (formerly Feeble Vampire). The process of working with an even ever so slightly larger group is interesting and new to me, because of how the allocation and distribution of work has gone. In my prior experience from 370 and 377, the smaller groups meant that I as a designer would usually be taking on multiple roles such as overall design, level design, modeling, and art/UI assets. However, due to my group having five people, I no longer have to worry about doing several things at once and spreading myself thin.
In fact, I now have the opposite problem–the larger group means that my team is able to complete a lot of work much more efficiently. My main role as of late has been expanding on the game’s ideas and trying to make sure that there is enough work for everyone so that the game is fully fleshed out by the time we reach Sprint 7.
Development has been progressing fairly well, with our momentum building from Sprint 1 and allowing us to complete a total of 65 cards during this sprint. The top priority for me during this sprint was making sure that most of the models which Carl would be making had art concepts to reference. I do not have to worry about level design that much, which was an intentional design choice by me.
When I was designing the game Dimensional Delivery for 377, I designed a puzzle based game in which the player must use portal and physics to solve puzzles. However, after playing my classmate’s game Break By Colors, I realized that my design lacked replayability and longevity for one simple reason–the levels were static and unchanging. Break By Colors had the advantage of being an endless runner with a randomly generated track, meaning that players were inclined to continue playing many times over. In comparison, a single level took an average of 3 hours for me to design, build, test, and iterate upon in order to implement it into the game–and that is assuming that players even found it fun.
When I was creating the design for this game, I decided that it would be much smarter for me to alleviate the stress of creating levels considering the small team size and create procedurally generated rooms which allows the player to have a fresh experience every time they play the game. As such, my only task each sprint as far as level design is concerned is to create different modular level “chunks” which add a lot more variety to every playthrough.
After I created more level chunks this sprint, my next job was to take those designs and turn them into scriptable objects. One of my programmers, Heath, created a grid system and a grid generation system that allows me to use scriptable objects to implement the level chunks which are then used to generate the levels. This process allows me to quickly take my level designs from concepts into actual testing.
Other than creating level chunks, I also created a lot of concept art for models as per Carl’s request. I created a couple of variants for the farmer enemy which the player will encounter in the levels, drew up simple designs of what the walls and boundaries are going to look like at each tier of the game, and drew a throne that is going to be placed in the final room of the game. I also made concept art for the sprites of the skills and items, throwing together quick sketches of what they should look like so that Daniel can create pixel art sprites of them.
This next sprint, I am going to be creating a lot more concept art for certain levels within the game, as well as building out the Game Design Document and adding more skills and items so that the game has a lot more variation in gameplay.
Comments
Post a Comment