CAGD 370 Postmortem

 Now that the fifth sprint is done and we have a finished build of our game, Figure Skating Flying Squirrel, it’s time to do a postmortem of the whole development process. First, I’ll talk about some challenges we faced during the development process, and then I’ll talk about how the final project turned out (it went great).

One challenge we faced during the start of development was breaking up tasks into sufficiently small pieces. For example, developing a level is a long process. Eventually I decided that the best way to do it would be to make separate cards for two drafts of the annotated map, a level blockout, a first draft, and final draft of each level. Throughout the development process we had some similar issues, but I definitely think this is just something that gets ironed out with experience, since we figured out what the expected steps are for certain tasks.

Another challenge I ran into during the fourth sprint was getting stuck on a card I couldn’t get to work. I looked through the unity scripting API and online for solutions, and nothing seemed to work. Eventually I figured out it was a conflict with someone else’s script—I assumed he would’ve told me if there was a conflict, and he assumed that I would’ve checked for any conflicts. In the end it was a funny misunderstanding, but I think going forward I learned that I should ask for help when I get stuck, and check with my team members if there could be a script conflict.

In the final sprint we realized we probably wouldn’t have time to include a final level, and had to decide to cut it. Throughout the development process, as the lead, I would have to make the call on whether or not to cut certain features. While this is just something that has to happen in every project, since at some point it has to be finished, I didn’t want to dismiss other people’s ideas. I solved this problem by trying to find ways to incorporate other people’s ideas by modifying them—for example, somebody suggested being able to upgrade the player with new abilities. I didn’t think this would work great for the design of the game, so I suggested keeping the idea of new abilities, but putting them in temporary power-ups instead of permanent upgrades. 

An early success of the project was getting the movement and physics working early. I really have to thank my programmer for this; but getting that working early on meant we could work on the levels and game interactions with much more confidence.

A later success was the design of our level objects. I wanted to add some intractable objects to the levels that made things more interesting. The design I’m most proud of are the bumpers—I realized that the biggest challenge to the player is the large turn radius and slow turn speed. I figured that bumpers that instantly cause the player to bounce one-hundred-eighty degrees would therefore be a meaningful addition that players want to go for. 

Another game object that had some thoughtful design was the branch wall. The player can smash through branch walls if they’re going fast enough. I wanted the players to be able to pick up on this, so first I made a model for them that communicates that they can be broken. I made them look really brittle, but I also gave them large gaps that the player can see through. If the player can see that there’s an area behind the wall, they’re more likely to realize that they have to break the wall to get in. For the implementation, I put a section in the tutorial level where the player starts going really fast, and put a branch wall at the end of it. I correctly reasoned that players would likely lose control and hit the wall, then realizing that they can smash right through.

One of the biggest successes of the project was the switch to ProBuilder for our level building. For our game especially, we needed a lot of slopes, ramps, and curves, which weren’t feasible with the unity primitives. Using the ProBuilder plugin, we were able to make levels that both played and looked way better.

What would I do differently on my next project? While we knew we wanted powerups and level objects, I think getting design documents for those sooner would’ve been beneficial. Additionally, I think more of a design document for how levels should be designed would be good—while we got things worked out, I think it was hard for me to communicate my vision for the level design until I made the tutorial level; making a design document with some general guidelines would’ve made that easier. I also would’ve liked to get the third level in if we had more time.

Overall, I’m really happy with how the project turned out. I think our strong core mechanics greatly contributed to a game that’s cohesively fun, and the powerups and level objects provide nice spins on the gameplay. The high score time and acorns give players some great incentives to go for, and playing it, it really feels fun to try to speed through the levels as fast as possible. The moveset combined with the varied levels means there’s a lot of tricks the player can pull off, and it makes the gameplay feel fun, rewarding, and flexible. 

CAGD 370 Blogpost 4

During the fourth sprint I got to work on building the tutorial level and coding the menus, while our programmer finished off the remaining features and our level designer got to work on the second level. The major features of the game really came together during this sprint, and all that we need for the game to be ready will be development of the later levels. Some smaller additions I made were the models for the checkpoint flags, snow shoes, and air rings, as well as adding a controls screen.

The pause menu gave me some trouble. Coding it in didn’t take too long, but for some reason the buttons wouldn’t respond to the mouse, and I couldn’t figure out why. I spent a lot of time looking up solutions and couldn’t find anything, and after systematically combing through the scene found that it had something to do with the camera. Eventually I discovered that there was a conflict with another script that disabled the mouse input, so after making the pause menu re-enable it, everything was good to go. Having a working pause menu and being able to easily navigate between the scenes and main menu felt like we had a real working game.

For the rest of the sprint I worked on the tutorial level. I built the whole thing from the ground up, completing the annotated map, blockout, and full working version of the level. Our programmer added in some code using surface normals to get the movement working on any surface, so I wanted to try something different for the tutorial level. Since we used ProBuilder in CAGD 270 to make levels, I thought it’d be worth experimenting with using it for this project. After testing it out with our movement system, ProBuilder worked great, and let me make much more intricate levels with curves and ramps that fit our game perfectly. 

After testing the level out myself, I made a few changes from the annotated map. Mainly, I removed the alternate routes in the opening area, since I think they would be too confusing for new players. I want it to be clear where to go next, and the current more linear design better shows the player what their goal is: gliding to the platform that’ll let them access the next section. This ensures that players learn to skate and glide before they continue. I added a few extra ramps, but they all direct the player to the goal. One of the extra ramps subtly pushes the players towards success, since if they skate up it to get the acorn, they’ll come down with extra speed that makes the first gliding section easier.

After the first checkpoint, there’s a long ramp and jump to prepare players for more of what the main levels are like, with long speedy down-ramps. This big jump can’t be completed by gliding right away, so players have to learn to start gliding at the apex of their jump. During the playtest we saw some players struggle at this section, but because there’s a checkpoint at the top, players were able to try until they got it without losing progress. I was happy that it successfully taught the players how to play the game. 

The last trick I added was the first breakable wall. Because players completing the jump have a lot of speed, it’s likely to be hard for them to slow down. I added a breakable wall at the end of this section so that players will crash into it and learn that these walls can be broken. In the playtest, I saw a lot of the design elements work perfectly, and all players were able to complete the level while learning how to play.

CAGD 370 Blogpost 3

 The third sprint was defined by our kinesthetic playtest, where we had other groups playtest the movement of our game in the first level. We learned some important things from the playtest. Skating worked really well, but gliding not so much. Because players were used to holding W to go forwards, as soon as they started gliding, they would nosedive. We decided to remove the S and W gliding controls for now because their gameplay use was limited and they felt confusing and unintuitive to players. The other major change to movement was that now gliding is limited to a timer, so players can’t glide over the full level.

During the sprint, the first thing I did was upload my model for the end of level flag. Now that the level flag was coded in, I could link all the levels up to the main menu. The main menu has buttons for each level so that the player can access whichever they want in any order. Next I started on the main menu stats. I got a scriptable object set up for the player data, which updates whenever the player completes a level. That way, the player’s time and acorns are recorded, and then compared to the record time / score, and then the menu can display the record time and score. With the acorns, this incentivizes players to try to collect them all, and with the time, it encourages players to compete to go as fast as possible.

Another major development I tried to get completed as soon as possible was making a design document for level objects. We decided that the next feature to add was intractable objects in the levels, so I designed the bumper, branch walls, black ice, and icicles. I wanted an object that changes the players movement, and eventually realized that the bumper would be huge for gameplay because it lets players easily 180, which is difficult with the skating controls. The branch walls are a simple barrier that players can break if they’re going fast enough, which serves as a different type of obstacle. Black ice is another unique obstacle type, as its much more slippery. Finally, icicles add another hazard in the air.

Finally, I decided to take on designing the tutorial level. Since the movement is the most important part, I wanted to design a gentle area that lets players get used to how movement feels. It opens on a frozen lake with a small ramp, an acorn, a wall barrier, and a small puddle of water, where players can get acquainted with the controls. From there there’s two different paths with a tiny gliding platforming section, rewarding some extra acorns and both leading to the first checkpoint. After the checkpoint is the first challenge, a short skate down a steep hill to prepare players for what the harder levels will be like. Its a straight shot with one gliding gap and one big turn. In the final area, players can experiment with a branch wall, avoid another water hazard, and learn to use a jump pack to reach the flag.

Overall I would consider the design mostly successful, but I feel like I could do better with more time. However, as the third sprint comes to an end, I know it’s important that the project gets completed by the deadline. I’ve started work on the blockout with proBuilder, and next up is to finish the tutorial level.

CAGD 370 Blogpost 2

Our team finished the second sprint, we have a lot of good progress but still have a ways to go before the prototype is complete. The good news is that all of the foundational elements are there and everything in the game works—at this point, we know that no matter what, we’ll have a functional playable prototype. Elements like skating, gliding, acorns, and the first level are all in the game. The next step is going to be looking at the game’s completeness, making sure there’s a good amount of other features. 

During this sprint, I made design documents for the HUD and power-ups, so that my team can have a good idea of what we’re going to be designing. I also coded in the acorns, and gave them a model. The acorn collection is a dynamic system that counts how many acorns are in the level at the game’s start, so this way, the designers can add more acorns to the level without worrying about breaking the HUD. I also wanted the acorns to look nicer than just deleting on touch, so now they quickly shrink and move towards the player, to indicate picking up.

Hand in hand with collectibles, I also set up the rest of the HUD, which included the speedometer and the timer. For the speedometer, I grabbed the rigidbody of the player and used its velocity, then rounded it. For the timer, I tried a formula to round it to two decimal places, but then it would jitter back and forth since it would truncate whenever there was a trailing 0. Fortunately I found a truncation function in the ToString() method, and set it to always only display two decimal places. I also made a model for the jump pack power-up that our programmer implemented. I know that art should be minimized, but there’s going to be at least three power-ups, so I think it’s useful to the player to have a way to distinguish between them. The model is also pretty simple.

We faced a couple of challenges during the sprint, the first was that kickoff was a little trickier since we didn’t have class time to do it. We distributed some work out over the weekend, but reviewed it and modified it slightly in person, where it was easier to discuss. When it came to our cards, we were better about splitting things down from the start, however, this led to some redundant cards.

Another challenge was that our level designer was out sick for a few days towards the end of the sprint, but fortunately he pulled through and got a blockout of the first level completed. While we had six cards left at the end of the sprint, we completed over twenty. The work we didn’t get to was the level flag, the dash powerup, and the second level map.

Going forwards, the next area of focus is going to be adding intractable objects to the levels beyond the existing collectibles and hazards. Once they are designed, the programmer can implement them, and the level designer can put them in the levels. We also need a system to load into levels from the main menu, as well as tracking stats, and saving player data. Currently, there’s also a few more power-ups to be coded in. When those features are done, the levels can be completed, and the game will be ready!

 

CAGD 370 Blogpost 1

The biggest difference between this game design project and the previous ones I’ve completed in this and other CAGD classes is definitely the scope. Previous projects, such as paper prototype board games or individual digital levels, were a linear process that only took a few weeks at most. However, with the Game 2 project, we have to plan for a final product that will not be complete for two more months. This means that a lot of the first sprint was dedicated to things like level maps, paper prototypes, game design documents, and setting up unity and github. 

One of the unique challenges we faced in the first sprint was dividing tasks into small enough pieces. With programming it was pretty easy for us to identify everything that needs to be in the game, but for aspects like building the levels, it took some thinking to figure out how to break them down into short tasks. Eventually we got things right, and broke up the level building into stages with drafts and final versions for both the map and digital level. 

On the design side, we completed our treatment, paper prototype, and a level map for the first level. On the programming side, we completed almost all of the basic controls of the game, getting the movement and the ice skating physics working amazingly well.

The first task I had a large hand in was the game treatment. I wrote up what our group discussed and made the concept artwork for the game. Going into the project, the pitch gave us the idea of how the character should move, but we spent a while discussing how the rest of the game should be structured. One such element was the level design, which got clearer once we got some concept art.

There were a couple elements we compromised on, or somebody suggested it and then it was modified. For example, we discussed adding an upgrade system to the game. However, this might not fit the game too well since the levels have to be designed to precisely match the movement, and alterations in the player’s speed could make everything feel off. So we took that idea and tweaked it a little bit, agreeing on using power-ups instead. 

The largest task I took on during the first sprint was constructing the paper prototype. At first, we struggled to come up with good ways to translate our game into a paper format, since it’s a 3D platformer. Eventually we decided to just focus on the skating mechanics. I figured that the best way to do that would be a game about acceleration, so our paper prototype focused on accelerating and decelerating your x and y velocities to maneuver around an icy course. It translated perfectly, and all of our playtesters found that it represented the concept very well. 

We learned a few things from the paper prototype. It confirmed our hypothesis that maneuvering around a level on ice skates would be engaging for players. It also confirmed our hypothesis that acorns as bonus collectibles would be a good incentive for players. For the level design, we learned that since players will slide around, there should be some extra space on turns in case they slide too far. 

CAGD 270 3D Level 2 Feedback

For our second level using the 3D Gamekit, we were instructed to make a hard level with a medieval theme. I had several people playtest the level in class. 

In constructing the level, I utilized the theme by building a castle with battlements at the top. I wanted to make use of the 3D environment by designing a level with three separate levels: the first floor, the basement, and the second floor. I start players outside the castle so they can get a view of its size from the outside before they enter into a courtyard. The courtyard has a few enemies, two closed doors to the right wing, an open door to the left wing, and a giant gate to the palace inside. The goal of the level is to open the giant gate.

While the level doesn’t follow a straight path, players do have to take a specific route. I tried to make this route feel natural by having locked doors and collapsed stairs as barriers. First, the player goes into the left wing and platforms across some acid. They use a switch to open a door to a gated area of the outside garden, where they then touch a crystal. Upon activation, the floor drops under the player, sending them into the basement. This is meant to catch the player off-guard, but it’s just a friendly trap since it is the intended route. 

In the basement players have to cross a large acid pit across platforms that sink into it. They then have to cross some moving platforms to reach a switch that lowers a door up above, which then blocks the player from the way they came. After climbing some stairs, players can use a crystal switch to open another door, and then go back out into the courtyard. Now that the doors to the right wing are open, they can enter, and jump up the broken stairs to access the second floor. Up top, players cross battlements with enemies and moving platforms. Finally the player reaches a crystal switch that opens the giant gate, ending the level. 

The level is fairly complicated, however, none of the playtesters got lost. The only section anyone got confused about was entering the right wing from the courtyard, so I could maybe add a glowing crystal to indicate what new area has opened up. No players got significantly stuck on any section, although some had trouble with the acid pit in the basement. I actually found that section frustrating, so I would like to add more platforms and alternate routes in it, such as rising platforms that move on the opposite cycle to the sinking ones, meaning there’s always an available path for the player.

Everyone liked re-entering the courtyard and getting to see the upper floor of the castle. Everyone really liked the platforming throughout the level. I think that players had a good sense of exploration as the wove throughout the structure.

For the second version of the level, firstly I’d like to advance on the theming by adding more castle features, like spires, crenellations, or buttresses. I would like to make the courtyard area a little more challenging by adding some more structures to it as well. I would like to refine the basement area and part of the upper floor. If time permits, I might experiment with getting some textures in the level as well.

CAGD 270 3D Level Feedback

 For the version two of my 3D game level, I had an in-class playtest to have a couple people try it out. Compared to the first version I added some more rooms to the end, and improved some existing rooms with more hazards and checkpoints. For instance, there’s acid in several rooms now, and some more platforming in the room that introduces enemies. This also opened up the first room a little bit more. 

Everyone liked the platforming a lot. Nobody got lost or confused on where to go, and everyone had an easy time figuring out what to do. Some people experienced some light and simple challenges with the platforming, but everyone seemed to find this enjoyable, and it was never to a degree that was frustrating. 

Many players made quick work of the first few rooms, possibly seeming bored. Most of them had to re-do a couple jumps on the last few rooms, and faced some minor challenges with the enemies. Everyone completed the level quickly, but about half of that time was spent in the tutorial sections. That’s the major reason I think a few more challenge rooms at the end would be a major improvement.

In terms of improvements, I think the level should be a bit longer. It advances the mechanics at a good steady pace. The last few rooms are when things start to get interesting, when players have to clear out enemies in a room whilst they take on its platforming challenges. Extending that out further with new rooms would be an improvement.

Additionally, sections such as the acid pit in the first room that preview the upcoming area with the moving platforms or the upper window that lets players look back on where they came succeed in giving the level a sense of cohesiveness. They work to create an environment that feels interconnected. I think expanding the level would benefit from this: using height variations and acid pits to let the player see the connections between the level’s challenges. 

Certain rooms could also be expanded to aesthetically make it feel more open. Primarily I’m thinking of the first room with the moving platform and the first room with a switch. Having some more height variation in these rooms would help make the level feel more like a real environment. If future versions introduce something like collectibles, I think levels would benefit greatly from being more open.

The last room that has some platforming and several enemies to me scratches the surface of the design starting to get more interesting and dynamic. 

Overall things went very well. There were no major errors or glitches, and nobody had difficulty or got stuck anywhere in the level (since it’s supposed to be easy). For this type of game I really want to emphasize exploration, so I think having bigger areas with more nonlinearity would benefit it a lot. More deliberate structures could be an improvement as well. I like the contrast when the player goes indoors towards the end of the level.

For the next 3D level we design, I’m definitely going to have a combination of outdoor and indoor challenges with a focus on interesting and intuitive platforming. A couple flavor elements in the environment would also be a good way to encourage players to explore. I definitely want to experiment more with activatable objects and switches.