CAGD 370 - Pre Production Design and Prototyping

Postmortem

    As the final sprint is here, this is a post mortem of the whole process of the development process within 370. A lot of things went right and a lot of things went wrong. Starting from the beginning, my team and I came to the decision to make my game, Skate and Scoot and for that reason I was the designer. I think we started off good and strong with making and working on the paper prototype. Another thing that went well was the AGILE Development pipeline. This pipeline helped me with organization and a glimpse into how the work within the industry takes place. The first things we started on regarding if the game is fun and to test out different mechanics we came up with for our digital prototype. This eventually evolved into the rule sheet and what little things are present within our game. One worry was that there would be no one to one with the paper prototype and the digital but we found out that there are certain things that could still be tested while on paper such as movement and more importantly, an early grinding. So we focused on the main things we wanted to test and structured our sprint 1 around this.

    Within the fourth sprint, a lot of things went right and one big thing went wrong. For the things that went right, a lot of additions and fixes and refinements were made in this sprint. Things such as a pedaling movement, a better grinding system, enemy and enemy combat, etc. This sprint was one where a lot of core mechanics got done. One thing that went wrong was that some of these things didn’t get finished in time for the playtest so a lot of them weren’t tested out by the playtesters, rather within ourselves. Another thing that went wrong that I can do better next time is to have a better made level to test out certain mechanics. While the mechanics were tested, the map could have been made better to accommodate the players. Certain things like the large map nature of it really made us go back to the drawing board for how to approach the level. 

This led to the making of the board game. We decided to make a rough game outline just to see how the players are going to traverse the level and how they might approach the grinding as well. During this, Veronica was starting on the digital prototype by getting a moving character within the game. This was all going well. The playtest yielded more results and information that we could apply to our digital prototype with certain foundations such as grinding.

    In the second sprint, things still went pretty well with some things that went wrong. With kickoff and having some things already done digitally from the last sprint, we were in a good place to start. The main focus was the grind mechanic for me. I decided to go with the method of having a bunch of points that the player just moves towards when they hit a trigger. I also had the idea to implement a quicktime event within the game. 

    One thing that went wrong in this sprint would be the development organization of our game. Using github, we made forks that didn’t pull from dev and that made it so a lot of our things were not connected properly and weren’t up to date in some branches. This was thankfully resolved but it was one hiccup that came up during development. 

    Moving on to the third sprint, most things went well but there were some things that went wrong, mostly in the playtest. We focufeefsed on the kinesthetic prototype and this involved me working on various different items. One thing that went wrong this sprint was that even though we did a fair amount of playtesting, there were some things that went under our radar and didn’t work during the playtest. More specifically, my quicktimes weren’t working and wouldn’t reset. One other thing that needed work was our burndown chart and where we were at with setting up the numbers and such. I think next time, we would playtest even more and try to get on top of the burndown chart early.

    Onto sprint 5, thankfully, a lot of things went right in this sprint. Some things that did go wrong are the wishes being cut and the quicktime system being cut. However, the things that went right I feel overshadowed the things that went wrong as we had a very good pedaling system, a good combat system, a good grinding system, UI, and many more things. This was a satisfying place for the team and I to stop and and say that we actually did make something cool.

Coming out of it, If I learned anything, its that I personally need to take more time to flesh out things within development and always be in some sort of communication with the team. Even though our communication was good, there were points where there was no talking and that would not happen the next time.

Sprint 4

For the fourth sprint, the main goal was to have some sort of a system prototype with various components of our game working in tandem with each other. This now meant that our prototype needed to have movement refined a little more along with different aspects of our game such as level and enemies in a better condition than before. So, my team and I worked on having a more cleaned and polished movement, UI, grind rail, level, and enemies

I worked on implementing a new system for the rail grind as it wasn’t as smooth or as functional as we wanted it to be. I did some research and looked into the Spline package that’s in the Unity Package manager. This allowed me to make a new rail system that is developer friendly as well as engaging for the player to encounter in the level. This new system was miles better than the old one with how it plays in game as you are not arbitrarily moving along some predetermined points within the game but instead have geometry that you’re stuck to and actually grinding on. It also allowed me to make the rail grind a tool for my partners to make. They can also go in and add rails where they see fit.

Another aspect of the game I worked on was the main level. I made the decision that maybe we should switch to a tutorial screen with the info rather than having the tutorial embedded within the level. So, I made the first scene to hold the information that people would need to know about the game and then moved on to the main level. I wanted to give the feeling of being in a large highschool that has different paths that people can go on with the main level. After playtesting, we saw that players actually didn’t like the large aspect of the level and preferred having a smaller level. This aspect will be discussed again with my team as we made changes on our movement, especially its speed, so to counteract that we need to figure out how big to make the level.

As I was working on the grind rail, I also needed to connect our new movement we created with the grind rail and detect when were skating or not. This wasn’t so hard but took talking with Connor and Veronica as they worked on the movement scripts. One issue that arose was that our character would sink into the rail. We then figured out the different rigid body attributes were changed and that makes the character sink. I then fixed the problem and the rail grind worked. I also made the rail jump equal to the spacebar and not to mess with the regular jumping.

 

On playtest day, it was really helpful to know what specific components needed to be ironed out even further. Unfortunately, the playtest didn’t involve the new movement but we will be holding our own playtests for the new movement with other students before the final playtest. The playtest still helped us figure out what specific things needed ironing out such as enemy strafing, map size, level design, and other things that we will implement. Thankfully, A lot of these things are changes that we can add and the state of our game looks like it is in a very healthy state. Its in a place where now were adding the final finishing touches on stuff so that we can playtest earlier to get a sense of what absolutely final things we may need to fix and add on.

Sprint 3

For the third sprint, one of the main goals we had to accomplish was getting a kinesthetic prototype working. This just meant that we needed to have a prototype to test out the movement mechanic we have and how it works in tandem with our camera.  With some of the core systems worked on in sprint 2, we had to work a little more to get some of our basics done in time for the prototype. Some of the things we wanted to have for the prototype and subsequent playtest was movement, UI, grind rail, a basic level, enemies, doors, death, and QuickTime events. These aspects make up the core of the game so getting them ready was the main goal for our sprint.

I focused on the grind rail, UI, doors, and QuickTime events. I added on to the original grind rail I had that I made during sprint 2 and worked on getting a better QuickTime event working for the player in order for the player to stay on the rail. This involved a countdown using UI elements to have the player essentially have about 10 seconds to be able to hit Q to stay on. Next, I implemented a very basic door system. This just consisted of a collider and a button that once pushed, made the door disappear. I also implemented multiple grind rails in my test level to even see if the method I made can handle multiple grind rails. Thankfully, after adjusting a little bit of code, it did work with multiple different rails throughout the level.

One thing we had to work on for our organization and backend was a Burndown chart. This chart was a visual tool to show us and other people how far along our project is and to project the future scope for our project. It uses math and calculates a line graph detailing how your current progress is going and how the future progress might look like, depending on the current progress. I made the burndown chart as I had experience with making excel charts in the past and I could customize and automate it so any of my partners could go in there and edit and the chart and it would automatically update and calculate based on the numbers added or taken away.

I also worked on the actual tutorial level for the playtest in order for players to get the system one by one and know how to play the game gradually rather than give all the information all at once. This meant that we worked together to figure out what’s the best way for information to be presented to the player and how the level should start out. We decided that having text on screen and long hallways are actually a good idea for the tutorial level because the player really doesn’t know anything so to have these large patches for players to experiment and figure out stuff was crucial. We essentially led them from a long hallway with the basics of movement to the actual level in which we had enemies and parkour for the player to engage in. After doing the parkour, the player is then introduced to the first grind rail and the rest of the level is an extension of our aspects.

 

In our playtest, we found that players found our game to be easy but also fun. They found the parkour of the level to not really fit the skateboard theme but could see where we were going with the idea. Some of the controls were sensitive and needed to be adjusted. Players wanted a little bit of a better checkpoint system. The quick time event system was intriguing to play testers but they asked for improvements.

Sprint 2

For the second sprint, we had to focus on working on our digital prototype and make our core aspects of our game. Thankfully, we started some aspects of our digital prototype during sprint 1. One main aspect would be the movement for our prototype. This meant we did not need to start from scratch or spend as much time on movement as it would have hindered development time, we could get started on other things almost right away. This involved working with my team to break down our backlog and determine what are the core things we need to have done within this sprint. After breaking down our backlog and seeing what the main components are, we got started.

            My main job this sprint was to work on the grind mechanic for the game. This involved figuring out different ways to approach the aspect of grinding. As this was a prototype, we needed to show off the mechanic without putting all the bells and whistles on it yet. This meant getting a pretty good interpretation for the grind mechanic. I figured there were two different ways for us to approach the mechanic. One involved setting up a lot of points on the rail and the player just moving from point to point. The other method would involve making hit boxes on the rails and have the player constantly checking the hitbox and going along it. I wanted to implement a QuickTime event also so the method that I went with also needed to work in tandem with the QuickTime event to stay on and to switch rails.

            I decided to work on the first method with all the points as I saw that as the easier path to take. I approached this after doing some research about the TransformTowards command within unity. This allowed me to make a simple script where when a trigger is hit, the player starts moving toward empty game objects within the game. I then attached these points onto the rails present within the game. This allowed the player to “grind” the rail by moving along the rail.

A big problem arose when we came into class one time and found out that our unity file was disorganized and messed up. In our unity file, we have the main branch, followed by our dev branch. Through our dev branch, we create different subbranches to work on our individual pieces of code and implement the things we need to work on. After that, we then push our work onto the dev which means dev would hold all the current work we all have. However, when we came in on a Thursday, we noticed some of our branches were disorganized. Some branches were a piece of main and one of our groupmates worked on the dev branch itself. 

It was a good thing we caught this early in the sprint as this would have presented a large issue later as a lot of our work would have been lost all over the place. I initially lost my first update and work that I did for the point method regarding the grinding. Thankfully, it did not take me too long to remake the work and move on to the next thing.

After remaking where I was, I had to clean up and make the actual grinding for the grind rail cleaner and make it seem like the player jumped onto the grind rail. I wanted to add on more but I had a lot of other homework and projects with other classes and couldn’t get around to add on a lot more with it.

Sprint 1

This semester, for the class of 370, I am the designer of the game Skate and Scoot. For sprint 1, I was in charge of essentially creating the documentation, ideas, checking other peoples work, collaborating, and so on and so forth. A lot of my work during this sprint was more focused on documentation and working on the paper prototype.

I first came up with and pitched the idea for Skate and Scoot before the sprint kickoff. After forming a group, we brainstormed a lot on what the game needs to have and what should look like at the end. It was my job to be at the forefront of these discussions and pitch many of ideas that will or won’t be in the game. This was done under the umbrella of a development process known as AGILE Development. This was a new development style that I hadn’t engaged in regarding game development, but I was sort of familiar with using the Trello board and the idea of designating tasks.

We then started on the paper prototype as that was the big objective/ mark of sprint one being completed. This was where I collaborated a lot with my producer, Conner, on what the paper prototype needs so that we can see if the game is fun and to test out different mechanics we came up with for our digital prototype. We decided that we should get started with the rule sheet first and have a basic idea on how to approach this. We would meet up in calls outside of class to first make a skeleton of the rule sheet with different aspects that would make up the paper prototype. After we got a rough sketch, we then clarified and cleaned up a lot of our rule sheet so that there were clear rules and procedures.

However, while we were making the rule sheet, we realized a lot of different mechanics and rules and things that happen in the game don’t translate very well over to the paper prototype. This caused an issue in that we had to essentially rethink our rule sheet and the actual parts that we want to test and get feedback on. Instead of making the whole game in a disorganized paper prototype, we instead focused on the main foundations to test out, which were grinding, combat, the actual platforming, puzzle solving, and score. Now with these limits, we could make a paper prototype that tests these things that can be transferred into the digital prototype rather than making two separate and distinct games.

 

With this new foundation, we started to also work on the game boards of our game. Conner and I both worked together as the level designer to figure out how we would want to approach the levels and islands within the game. We would make a rough outline on how the level should look and I would go into Photoshop and work on making the gameboard itself. I would reconvene with Conner to discuss and break down the level if we needed to get the best possible level and its corresponding spaces.

All while working on this, I as the designer had to sign things off and I was doing that regarding the digital prototype that Veronica was working on. She needed to verify the movement mechanic she created, and I signed off because it was a great starting point for us to build upon. 

After a quick playtest with Conner, we went into the public playtest with other students. This playtest was very helpful as it helped us see how players felt regarding these main foundations of our game. If the grinding or the traversing sucked, then this would reflect on our digital prototype that the way we are approaching this method sucks, regardless of the difference between paper and digital. This also allowed us after to see how we can actually transfer and transform the things we learned from the playtest and its mechanics to the digital prototype.