Hello there! This is the first installment of production blogs for the development of Perry’s Pies. My name is Brad Farris, and I am the producer for Perry’s Pies. This team consists of 11-to-13 developers. We have 2 Programmers, 4 designated 3D Artists, one 2D/3D Artist, 2 Level Designers, and 2 Animators (for this and the following sprint). The design and vision of our game comes from my game designer, Abbey Mendoza, whose designer blog is located here (add link).

In Perry’s Pies, the player will have to outsmart and avoid the original owner of a haunted bakery, Perry, by using items that distract him in order to find the 3 spectral keys across all the floors of the bakery, and escape with his Famous Pie tin. Each level will get progressively harder as Perry gets more and more aggressive and angry that the player took his pie tin.

3D/2D Art

For the dedicated modelers, Kaeli, Carl, Angel, and Ana, our minimum goal was to get Perry and the player’s hands modeled. Additionally, we wanted to get some of the main assets that would be included in levels/gameplay made. We got the distraction items, referred to as attractions/deterrents, modeled as well as the keys that the player is looking for, chains for the exit door, and some modular pieces so that we can begin putting together the scene as level design progresses. The 2D artist, Koda, worked on developing concept art for the first two levels, as well as Perry.

Angel

Kaeli

Carl

Ana

Koda

Programming

With our two programmers, Alex and Joseph, I decided to have Alex focus solely on Perry and his functionality/interactions. He suggested that we approach Perry, and how he moves around the level, in a way that implements state machines. We went through the different states that Perry would be in and he got to work on establishing the framework. He worked on creating a flowchart for the state machine that visually described the way that the state machine worked and has continually been working on making sure that things are optimized and compatible with the work that is being done by Joseph.

Alex has had more successful implementations than broken, however, he has had a few pitfalls. One of these was having too many functions implemented through one script. This was a contributor to the cause of a bug where Perry would begin pursuing the player, but then he would continue to move forward in a straight line and not stop once the player exited the radius. That is an example of one of the more obvious bugs that was helped in part by decoupling the functions that were all in one script.

Joseph has been working on the implementation of functionality involving the player and levels. This includes the Player Controller, Perry activation, key interactions, inventory systems, level changing systems, and more. Throughout the process of implementing all of these things, I have made sure that I check with both Alexa and Joseph to ensure that we address anything that needs to be avoided, or implemented in a certain way or with certain conditions.

Overall, this method of communication between programmers has been effective. We have recently come across an issue with the implementation of the level changing system, which is a UI-based elevator, that has encouraged us to reevaluate how we are scripting. The issue was that when the player would switch between floors, there would be times where the button for the elevator would get destroyed. We discovered that this was only happening when switching from the first floor to a different floor and then back to the first floor. When you did this, after going back to the first floor, the button would be destroyed. So, when you select the level after that, it took you to that level, but it soft locked the whole game afterwards.

We established that at least part of the issue was that some objects that were supposed to be assigned, through the inspector, had been missed and were not assigned. This wasn’t the whole issue, but it was what prompted us to try to do as much in-script game object assigning as we can, compared to assigning through the inspector.

Alex

Joseph

Level Design

Level designers, Bill and Andy, have done an awesome job. It has been very difficult for me when it comes to giving them a solid direction, especially during this first sprint. With level assets not being made yet, there wasn’t a dilemma of what to do. What I start with was doing Annotated maps for their assigned levels. This was adjusted shortly afterwards, as I decided that it would be more efficient to have them work fully on one level and After they finished the annotated map of each of their first levels, they got designer critiques and adjusted their annotated maps. After doing a second iteration, I had them do a block out in Maya.

After they blocked out their first levels, we still had a good chunk of the sprint left. I decided to do some research on ways that I could find more work for them to do on the levels before assets were ready to be put into the scenes. I consulted with the teacher of level design for our CAGD program at Chico State and decided that doing some documentation of the level before continuing would be a good way to make sure they still had work.

I came to realize, this was kind of counterintuitive. Having them do the documentation after they had already made the block outs was not an ideal use of time. Although, it was helpful in understanding the level designer’s idea of the level and what how they wanted the flow to go.

Bill

Andy

Animation

This sprint, we had two animators, Gavin and Samuel. Since they are the only two designated animators in the class, they will be rotating between groups. While they are with us, our goal is to have Perry and the player’s hands rigged and animated. Since the player’s hands were completed before the sprint ended, the hands were the priority to have rigged and animated while we were waiting on Perry. Samuel worked on getting the hands rigged, while Gavin spent time collecting real life references for the run, throw, and grab animations.

Gavin

Samuel

Production

The very beginning of this sprint was rocky. Misunderstanding/miscommunication resulted in me not having a backlog compiled for the first day. I had written user stories in my notes, but there were two problems. Assigning user stories from a note document is very difficult to keep organized and be efficient with; and I did not have enough user stories made to have an effective kick off with 12 people (we did not have Samuel on the first day).

Although the sprint was initially a rough start, this sprint was extremely productive. We completed a total 99 points and had an ideal velocity of 217 and an actual velocity of 154. I learned a lot during this sprint, and I am excited to see how the following sprint goes and the lessons/information that I learn.