Introduction

This week, the team began to get everything together for the final deliverable. Programmers worked on finishing up the minigame and the UI in the main game. Some of the changes involve getting the monthly panel to become more intuitive for the player and adding in instructions for the player on post-it notes. Artists worked on creating sprites for all characters and polishing employee sprites. Writers continued to work on the individual characters and wrote the tutorial for the beginning of the game.

Programming

Programming spent this week making UI improvements in the main game and bringing in art assets to unify the panels. Panels now have a corkboard background and instructions are on post-it notes. This board is supposed to represent the managerial board in the store and serve as a visual indicator that that is where the player can work on their business. The team wanted to make where exactly money was going a little more obvious to the player, so programmers changed the month panel slightly. The monthly finance report panel now iterates through each category of spending to show the player how their money is being utilized for the month. Additionally, there is another bar for the total earnings of the player, not just how much they made in that particular month. Lastly, programmers put in the animation for the delivery bike, where the employee who is tasked to delivery for the week is shown zooming by outside the store occasionally.

The board on which the weekly tasks are assigned on

MinigamE

In order to make the example game more in line with the team’s design for BizWorks, programmers had to simplify the game. First, they made the initial 10 by 10 grid into a 6 by 6 grid and altered the positions and sizes of item lists on the grid. This change allows the game to move along more quickly and is a bit more user friendly on a mobile screen. Furthermore, the game was adjusted to match the UI mockup the artists made last week. The title of the game – Bakery Match-3 – falls down and “Tap To Play” button blinks before the game starts. Then the game starts when the player clicks on the button. The game now lasts for 1 minute, as that is the time of the shifts in our main game. The score earned in the minigame was also programmed to be transferred to the main game as money earned. The only thing left is to implement the transition between the main game and the minigame.

Art

Artists focused this week on the characters in the game, as well as finishing up whatever UI elements were carried over from the previous week. The biggest thing added this week were the sprites for the delivery task. Originally, the team wanted the delivery bike to be leaving from the back alley to show employees running deliveries, but we decided that it wasn’t obvious enough. Therefore, the team moved the deliveries to the front of the store and created new character sprites for it. Additionally, we decided to give each employee a specialty, so artists created sprites to emphasize those specialties. In addition to finishing the sprites for all four of the employees, artists also created additional character sprites for customers so that there are people to populate the store other than the employees. Looking forward, artists just need to finish all the minigame assets and polish some of the UI elements.

Sprites of the employees if they are assigned to deliveries

Some of the bonus UI for employee tasks

Next Steps

Going into the final week, the team wants to finish up everything that is being worked. Essentially, the next week will be spent tweaking mechanics and polishing all the assets/features of the game. Writers will get in the three main employees’ arcs and the fourth, if possible. Additionally, artists will finish up making the assets for the minigame, mainly the game pieces. Otherwise, the team just needs to improve on existing mechanics for the final product.

Introduction

This week, the team continued working on changing the UI to make the game more cohesive and enjoyable for the player. Artists created mockups of the UI for both the minigame and the monthly panel and finished up making assets for it. Programmers have started implementing that UI and have also added a start and credits scene to the game. To make the monthly panel more complete, programmers have started to change how the UI is displayed and have added the tax and insurance payment options. Overall, the team worked on putting in the minigame and getting everything in the game to look good.

Programming

Programmers work partly on bug fixes this week and partly on adding some new components to the game. The biggest thing that was added was a start scene and a credits scene to the game. In doing so, we could make the game feel more completed in general. Furthermore, it also allowed us to check the automatic save/load functions that were coded into the game earlier in the semester. Other new things that were implemented were some of the UI elements in regards to the main store and the ingredients buying panel. Most of the bugs fixed this week were in regards to the dialogue. We fixed dialogue bugs that occurred during the resetting of dialogue flowcharts for each day and dialogue now progresses as expected. The last big thing that was worked on this year was implementing the tax and insurance payments based on the diagram that we decided on last week. Not only is there a minimum payment for the player now, but failure to pay carries over into subsequent months and the financial advisor gives a reminder to the player that they have to pay a week before the payment is due. In addition, we put in three missed payments as a lose condition. Moving forward, programmers want to finish up the UI and polish the monthly panel.

First pass at a startup screen for our game

Main screen after implementing some of the UI elements

Minigame

After finding the base project last week (Cake Mania), programmers found that the game had very low reusability. The whole game was made up of one script, which made it too difficult to analyze and modify the code to get what we wanted. Essentially, it was too hard coded to work with in the timeframe we had. Instead, programmers decided to go with another Match 3 game, which is an example project from a Lynda tutorial. Looking at the game and considering the target demographic of BizWorks, we decided to use the highest level out of the three levels in the example project. After going through the code, programmers spent the week reorganizing the UI assets to match our needs. For example, we took out the target score and remaining move elements and took out the replay and “Try Again” buttons, essentially simplifying the game to match the short minigame expectations of BizWorks. Moving forward, programmers want to finish modifying the minigame, add our own art assets, and then integrate the minigame into the main game. Below is a short playthrough of the project programmers are basing the minigame off of. 

Art

This week, art finished prototyping the UI for both the main game and the minigame. With both screens being diagrammed, artists moved on to create all the UI assets. Our client had wanted us to implement spreadsheets into the game so that the player could more accurately budget for what they need. We spent this week working on how we could do something similar and came up with a predictive function for the game. Artists made the assets for that feature this week. Other assets added were the minigame title image and the managerial board that buying the ingredients and managing the store takes place. In terms of character work, artists finished the icons, sprites, and full body art for the financial advisor and the fourth character, Miles. Looking forward, artists would like to animate the character sprites in the coming week and make other sprites for characters in the world. Most of the UI was completed this week and now the team just needs to put it in the game to replace the programmer art.

UI mockup for how we want the Match 3 game to look

UI mockup of how we want the monthly panel to look

The main logo for the minigame

Next Steps

Moving forward, programmers need to put in all the UI assets that artists have created and then tweak them as necessary. Furthermore, they need to finish remaking the monthly panel and add some animations into the game. Artists will be finishing the UI assets and then start on making the assets for the minigame. They’ll also be animating the characters and adding some more background characters to make the game world more robust. Writers need to finish up the three existing characters and write a tutorial for the game. Then, they’ll be moving on to the fourth character, who won’t come into the game unless they can be written in time. Overall, some of the features discussed last week may be cut, but the team is moving along smoothly in getting a better prototype together.

Introduction

After presenting our prototype last Friday, the team spent this week rescoping the project and worked on addressing the feedback we obtained from both the professors and our peers. Specifically, we realized there were a lot of features we needed to either cut or reshape, like our review system. Additionally, we decided to put the minigame at the forefront of our last few weeks of work, as opposed to the original plan of leaving it on the back burner. Combined with prioritizing UI and the feel of the game, we spent this week working on those two aspects and expect to finish implementing them in the coming week.

Prototype Feedback

Feedback for our prototype was mainly broken down into three chunks. As we expected, one of the big issues we were told was the visual and auditory components of the game. Playing the cammed demo, the auditory feedback UI that we had in the game was annoying and visually, it was still difficult to tell what was going on. Furthermore, there was not a lot of feedback of what was going on and it made the game boring. The team was told to consider putting in more sounds, like the sounds of the bakery, and visually showing customers come in and out in order to push the idea of a working bakery (and to make it more entertaining). Another large issue was that there is still nothing for the player to do during the shift. Therefore, we were told that we should probably prioritize the minigame in order to make the game more enjoyable. In terms of what kind of minigame would be doable in the timeframe, we were told that a Match 3 game may be the best bet. In general, it should be a type of game most people are familiar with and the experience should last about twenty to thirty seconds. The last big critique we got was the appearance and use of the monthly panel at the moment. The monthly panel does not give any warning about when payments are due and doesn’t give any information about the payments being made. Essentially, it’s forcing the player to do an action that may not be understood. The team was told to figure out how exactly the player would be forced to pay and what happens if they cannot make that payment and make that clear to the player.

Along with feedback from the instructors, the team also got feedback from our peers with different ideas for the game. Some of the things they were concerned about were how the financial literacy concepts were being taught and how the player interacted with the screen. Agreeing with the professors, they thought that the UI was a little bit awkward, with the auditory components being “alarming” and the lack of confirmation before the store shifted between the shifts and the break. Another thing they pointed out was the lack of tutorial within the first iteration of the day, stating that it was a bit confusing to follow without any additional instructions. In general, the comments pointed out that it was still unclear of what the player should do and the parts that we wanted the player to focus on (such as workstations) needed to stand out a bit more. However, they mostly agreed that the concepts behind the game were appealing, as well as the artwork, so the team just needs to tie everything together better.

Concept Rework

Taking into account the feedback from both the instructor and other members of the class and considering how much needs to be done in terms of debugging and tweaking existing aspects of the game, the team reworked the mechanics of the game a bit. One big thing that we changed was that we took away the unexpected events that we originally had planned to put in the game. This change is due to our time restraints and the changing priorities in our game, with the minigame now being at the top of the list. We want to use the minigame to emulate the player/owner “helping” various employees with their tasks. Therefore, if the game is expanded, each task could have its own minigame and the results of that minigame can be translated into bonuses for the player, whether it be money, ingredients, or reputation. We decided to also spend a lot of time reworking the UI instead of adding many more features to the game. For example, we had originally wanted customizable equipment and a storefront, but we decided that investing in better UI would make the player more attached to the game than some color options on equipment would. Also, to give the player more to do, we decided to create a trash collecting mechanism in the game. Player will need to pick up the trash as it builds up and if they do, they get some cash bonuses. Additionally, if they do not, their reputation and sales start to suffer. Regarding the review feedback system we had planned, we decided that we didn’t have the time to implement it, so we reshaped it to be a customer that comes in at the end of each week that the player has to click on before finishing the day. In this way, they are forced to see the feedback and how the store is doing.

Some features that we are adding/cutting from our game and a more detailed timeline for the next two weeks

More detailed diagram of how loan, tax, and insurance payments work

Programming

Because the team reworked the minigame to be one of the highest priority features we want to have in the game, programming decided to split work between the minigame and the main game between the two programmers. For the main game, most of the work this week was focused on the UI. Programmers polished the UI to unify buttons, panels, etc. at least with programmer art until art assets are finished, in order to give the game a more cohesive and appealing feel. Some aspects of the lunch shift were also changed. Employees move to a lunch table during the shift and the shift is no longer timed. We made these changes based on the feedback received, where it doesn’t make sense for the lunch shift to be on a timer if the player is just having conversation with the employees. Now, afternoon shift only starts after the player has spoken to both employees. In this way, the player is forced to play through the financial literacy arcs to get through the game. Some feedback UI was updated as well. For example, UI feedback blinks only when an employee actually makes bread or sells bread now, as opposed to before when it blinked each time the energy bar decremented. Moving forward, the team wants to spend the next week completing the UI with the assets that artists create.

Minigame

This week, programmers started to research the types of minigames they could include to improve player experience. Originally, there was a debate between using a Match 3 game versus a Cooking Mama style game, the latter of which was attractive because it was relevant to how the business ran. However, after considering the options, a Match 3 game was chosen for a few reasons. First, it’s a more universal game type than a Cooking Mama style game, meaning that we would have to explain less to the player. Second, it’s easier to implement, as there are more open source projects to base the game code on, which was important to us given the time constraints we had in creating the minigame. Lastly, in terms of expanding the game in the future, a Match 3 game is more universally applicable than a Cooking Mama style game, especially if we cover more than just food-related businesses. Therefore, we went with a Match 3 game. Programmers were able to find an existing, fully-implemented Match 3 game in the Unity Asset Store called Cake Mania. The rest of the week was spent analysing the scripts to see how they could be modified to be incorporated into the game. Some of the things that need to be done to the game are making the grid smaller, making the time limit within the parameters of our game, and changing the art assets. Programmers have started to work on this and plan to continue doing so in coming week after figuring out the code. Below is a snippet of how the game looks having already started to tweak some aspects of it, like the board size. 

Art

Artists spent this week working on two major components. With most of the in-store assets completed, artists turned towards working on the UI and collaborating styles between the different artists on the team. For the character sprites, we decided to redo them so that they work better with the full-size character assets. Additionally, this week, artists put final touches on the financial advisor sprite. The latter half of the week was spent starting to map out the UI in the main game. In making the UI, artists wanted to make something that was easily interpreted. Therefore, we decided to add a large clock on the bottom left to tell the player what shift they were on. Additionally, we used bars on top to keep track of stock, money, and reputation. Artists drew out diagrams of the UI layout for the main game and started to create the assets for it. In the coming weeks, artists want to focus on animating the sprites and creating the UI elements for the minigame and the monthly panel.

Updated sprites for the three main employees and the financial advisor

The plans for how we want the UI of the main part of the game to look like

Next Steps

For programming, programmers want to finish integrating the minigame, as well as finish implementing the functions in the monthly panel, mainly the tax and insurance payments. Specifically, in the next week, programmers also want to implement a start screen and make sure the saving function works. Some of the pieces that are on the back burner are the customer reviews and the trash collection in the main screen. Artists want to focus on polishing the sprites and in the immediate week, will focus on adding in all the UI elements into the game. Furthermore, we plan to make the trash assets and the delivery sprites in the coming week. Writing would like to finish all scripts in the next two weeks, including adding the fourth character, so that their dialogues could be put into the game and tested. Ideally, the team would like to start playtesting two weeks before the final checkpoint.

Introduction

For the most part, this week was spent polishing the existing mechanics and assets for the in-class presentation on 4/6. In terms of main gameplay, we were able to completely finish the day cycle and have most of the week cycle finished as well, with the exception of some of the functionality of the weekly summary panel. Considering the team continued to have technical issues with the collaborative software, progress did not go as smoothly as we’d have liked. However, the game is in a good place where the only things that need to be adjusted in the main game mechanics are some of the UI and feedback elements and the visuals of the game.

Programming

This week, programmers had some technical issues working with Git. For example, the scene was not being preserved between different branches, thus leading to a lot of headache every time the game was updated. Therefore, programmers switched to Unity collab for version control. Programming finished up the full game cycle including the day (week) cycle and the week (month) cycle. The end-of-month summary panel was completed aside from tax and insurance functionality. There is still some polishing that needs to be done to the cycle, such as adding more visual indicators that the shift times are different from lunch time. Additionally, some of the UI of the monthly panel will change, but functionally, most of the work is there. In terms of implementing dialogue and the written script, Lila and Sue’s first levels of dialogue were added during the lunch shift. Now, when the player taps on the respective sprites, they can choose how to advise the employee. Some art assets were also put into the game, like the character sprites in the back alley. Lastly, programmers implemented a simple camera pan to move between the main store and the back alley to differentiate shifts and to give a sense of continuity.

A screenshot of the task assignment screen

The first iteration of the monthly panel– the total income is on top, while the expenses are on the bottom

Art

Art focused this week on getting sprites finalized and creating some other assets for the weekly panel. The sprites for the first three employees were finished and put into the game, and the sprite for the fourth employee will follow. In the future, artists would also like to animate these sprites so that they are not just staying still as the day moves forward. Also, artists want to spend the next week tweaking the sprites so that there is a consistent style between different assets in the game. While a lot of work was put into the sprites this week, artists also started working on assets for the weekly panel and finished up polishing assets for both the store and the back alley. In the next few weeks, artists want to focus on finishing the UI assets for the weekly panel and start working on other assets to make the store more visually appealing.

In store sprites of the first three employees

The fourth employee for the game, Miles, an aspiring pastry chef

Prototype

Our prototype has the main game cycle fully functioning. Essentially, the player can now go through the whole main game, save two mechanics. Right now, because tax and insurance payments have not been implemented, the player is still missing part of the game. However, they are capable of running through the first few months and still paying off the loan. Furthermore, for two of the characters, the first level of conversation has been implemented, as well as some fluff interaction to make the employees more personable. The player can access these interactions in the lunch break area. In our prototype, we also included some UI elements that are not permanent, but get across the idea what we want the player to be aware of. For example, the bread and money assets are going to be polished in the upcoming weeks and made more appealing in general. Furthermore, right now, the text indicating what shift it currently is is unclear and not appealing, so we’ll also be fixing that in the future. Essentially, the goal with the prototype moving forward is to tweak a lot of the mechanics and make the game more visually appealing, including adding a start screen and narrative to fill in the gaps of the game. Additionally, there is not a lot for the player to do right now, so we’d like to make them more invested in the game through the use of minigames. The prototype is not as far along as we’d like, but the team thinks that the main mechanics have been put in fairly well.

Production Schedule

Taking into account how much we were able to accomplish for the prototype this week, we realized that we had to cut a few features of our game. Our timeline for the rest of the semester is as follows, although the feedback that we receive may change the schedule. Understanding that the minigame can become a project in it of itself, the minigame will be the first thing that will be cut from the game if we cannot stay on schedule.

Introduction

This week, programmers and artists focused on implementing some of the features we discussed in previous weeks. Due to some technical issues, we were not able to progress as much as we’d like on getting all the mechanics in. Thus, we will have to postpone the minigame creation until after the next checkpoint. Essentially, programmers focused on feedback UI in the game. They also started adding placeholder sound clips for the game, although the bugs associated with putting it in were not resolved this week. Artists, on the other hand, focused on redrawing the key assets in the store, as well as creating some assets for the feedback UI. Writing for the characters is going along smoothly and the team is talking about possibly adding more characters into the game.

Programming

This week, programming focused on improving the feedback UI for the player. However, a lot of the work had to be-implemented due to major merge conflicts with Git. Therefore, programmers could not put in everything they wanted to. Some mechanics implemented include the aforementioned sprite changes to the shelves. Bread on the shelves now visibly depletes as employees sell and increases as employees make more product, still in 25% increments. Some other feedback includes preliminary auditory feedback and visual in the form of employee energy bars. Right now, the bars are programmer art, so when artists finish making the assets for it, they will be replaced. Additionally, the auditory feedback will be accompanied by visual feedback in the coming week. Programmers fixed bugs regarding the employees’ energy bars and now the employee sprites themselves show up in the scene. For the prototype next week, programmers want to polish this feedback UI and fix any lingering bugs with the main components of the game before moving on to the minigame and some additional features.

Programming of the employee energy bars and the visual feedback

Art

Art worked on getting in all visual elements to facilitate playtesting and balancing, assisting the programmers with what they needed for the prototype. Prototype sprites for the employees (Lila, Bruno and Sue) and financial advisor were made. The team polished many current assets, like character icons and everything located in the main game hub. They also started adding assets for the clarity of the UI/UX, raising the quality of its graphic elements. For example, for feedback purposes, whenever bread gets made and bread gets sold, there will be a small “+1” pop up that gives visual confirmation that stock is changing (in case the player does not see it changing in the corners).

The character design for the financial advisor

The visual feedback for when bread is produced and sold

Next Steps

Going into the next week, now that most of the main aspects are finished, we’d like to implement employee dialogue and polish the visual and auditory feedback in the prototype. Once all the back end work is completed, we want to start adjusting the numbers for minimum payments, costs of ingredients, and how much employees are making and selling. Therefore, all the mechanics that we’ve been working on will be visible, especially all the back end work that we just did not previously have the assets for.

Introduction

With the team’s spring break causing a slight lull in work, members mostly focused on polishing some of the assets in game and finishing the basics of the daily cycle. Programmers were able to get the dialogue system into the game, using placeholder dialogue while writers continue to write character arcs. Art also laid out new characters for the game and continued working on environmental assets. The goal for the next two weeks is to polish all of the in game assets and present a working prototype to the client, as well as get a preliminary version of the game up and running so that we can playtest with students on campus.

Programming

The skeleton of the daily cycle has been finished with programmer art and UI elements. For the purposes of playtesting and programming, each shift is thirty seconds in game time, which represents a week in the game. During the shift, depending on the tasks assigned to the employee, the bakery sells bread. There are a few mechanics built into the game regarding employee task delegation. For example, if there is no one assigned to run the cash register, there will be no product sold. Likewise, if there is no one assigned to make bread, stock will not be replenished. During the lunch shift, the player can tap on an employee, which triggers a dialogue. This dialogue can either be part of the employee’s character arc or just fluff interaction. Employee interaction is implemented using the Fungus plugin for Unity. Placeholder dialogue is currently being used but can be easily replaced with real dialogue once that is finished. The daily cycle will be polished in the upcoming week. Working with artists, programmers designed a weekly summary panel. The purpose of this weekly panel is to give a place for the player to pay loans, taxes, and insurance, as well as show the player how they have earned money and lost in expenses. The mechanics have been planned out and are in the process of being implemented.

An example of how dialogue choices will be given to the player

Art

Over the break, the artists worked to finalize the designs of the characters and further prototype the environment. For example, we wanted to add a back area to the store for the lunch break, in order to reinforce the idea that the lunch shift is different from the morning and afternoon shifts. The styles for the first 3 employees — Lila, Bruno and Sue — have been updated and are now more detailed to generate more player investment. When making these characters, we kept in mind how much diversity we could bring out in them and how we could get the students to identify with the characters. Therefore, we made the first three characters close to the target demographic in age and tried to give them relatable issues to work through, such as roommates, credit cards, and athletics. Visually, the characters are also diverse, as being able to make everyone feel included was a large goal of the artists. The artists also started planning a 4th employee and a financial advisor, which are at the stages of concept art.

Designs of the first three employees

The lunch and storefront areas have also also been outlined. As mentioned we wanted to add a back area to the store for the narrative portion of the game. The lunch area, which is essentially a back alley, connects to the back door of the main game hub, allowing for a smooth pan during gameplay, which programmers should be implementing in the next week. The lunch area’s purpose is primarily visual and is intended to evoke relaxation, as that is the designated time for when you can interact with the NPC employees in a more thorough manner. In order to leave this back section, the player has to interact with the employees. Additionally, in the back of the lunch area, there is a bike that will move in and out for employees who go out on deliveries. Artists are going to spend the next week polishing this area as well.

Initial sketch of the lunch area

Moving Forward

Keeping in mind the next checkpoint is in the next two weeks, the team is moving into making a fully playable prototype. Artists will move into finalizing design for the environment, as well as starting the process of animating the three to four employees. Programmers will start to create the weekly panel and focus on getting all the main mechanics in and working. In terms of writing characters, the goal is to have at least one fully written character for the prototype, although we’d like to try and have more than one for it done. Although we were supposed to have started implementing a minigame by this point, the team is focusing on getting the main mechanics that teach financial literacy in first, and then move to the minigame if we have time.  

Summary

This week, we focused on getting at least one iteration of a day in the game done to present as a working prototype. Also this is really late, sorry it’s completely my fault.

Programming

This week, programmers worked on getting the main game logic working with regards to buying ingredients, selling product, and assigning tasks to the employees. Unfortunately, programming wasn’t able to implement employee interaction and a lot of the logic isn’t obvious because of the lack of UI elements to represent it.

Art

Art worked on finalizing the design of the bakery, with the assumption that it would present most playable features within one screen. The game would function on the basis of diegetic UI: to assign an employee to sales, the player would have to click on the cash register. This sort of environmental interaction would increase player engagement.

Additionally, two new characters and the outside map had been created for the purpose of the prototype demo.

Prototype Build

The working prototype that we created allowed players to go through the first shift of a day. On the first screen, players would choose two of three employees to work for the day. After that, they would choose what tasks the employees would be doing for that shift, such as taking orders or making bread. When each employee has been set up, the screen transitions to the store screen where a timer starts to count down to the end of the shift. On that screen, players can also click on the door to receive deliveries and when they do so, they lose money as they buy more supplies. While the prototype has a few bugs and does not necessarily reflect the timeline we want the game to have yet, it shows that the features we want to implement in the game are possible. Playing the game on a phone, the team realized that the placement of some of the UI elements was strange and that some of the art assets needed to be polished. Furthermore,

The diegetic UI was found to be too confusing.

Introduction

Following the presentation of our prototype last Friday, we received feedback that made us reconsider what features we wanted to include in the game, as well as how we’d introduce feedback to the player in the game. Taking into account that information, the team sat down and reevaluated all aspects of the game, determining what needed to cut out or changed in order to have a good final product at the end of the semester. For the remainder of the week, we continued finishing the main mechanics of the game.

Prototype Feedback

After showing our prototype in class, we were given some feedback on the features of the game and how understandable it was. First, the diegetic UI was found to be too confusing. Our prototype had the door and map as diegetic UI in the game. However, everything surrounding these elements are non-diegetic UI, which makes it confusing for the player. Second, the team was asked what function the map was serving, as opposed to just a list menu of what financial institutions the player could go to. Considering the same information can be portrayed in a simpler way, the map can be discarded as an element if there is not enough time to complete it. Other feedback given was that the indicators in the game may not be as obvious to the player as we intended. For example, would they see the number of stock decreasing and the amount of money increasing and associate that with product being sold. Lastly, we were given suggestions on how to increase the financial planning component of the game through advanced notice of deliveries (similar to real life businesses) and showing the decisions that led to certain outcomes in the storyline (which could also increase replayability).

Concept Rework

Taking into account the feedback that we got on the prototype, the team sat down and rescoped the project, figuring out the features that needed to be eliminated or changed. First, we really wanted to figure out the exact playtime of the game. The client has indicated that he would like either something that ran alongside school curriculum or something that tested knowledge at the end of a course, so we had worked keeping both options in mind. However, we decided that we wanted to make the game very similar to a 30-day challenge kind of game. Ideally, the game could be played in 2-3 20-30 minute game sessions in class, so that it could be again, either a supplement to lessons or as a final class activity. In line with this 30-day challenge, the events such as tax collection and salary payment will be on a weekly cycle. Because we thought it would be too much to have the player pay a large lump sum every few days, we decided that deliveries and employee salaries would be staggered weekly. In addition to those payments, the player will pay taxes twice in the experience, once at the 15 day mark and once at the end of the 30 days.

The structure of each day will be similar to what we were programming in the past. There will be a morning shift, a lunch break, and an afternoon shift. Each one of these states will be one minute in game time. Employees will be assigned to tasks at the beginning of each shift and the financial literacy story arcs will be explored during the lunch break. Within a day, we wanted to include different types of feedback for the player, taking the suggestions made during our presentation to heart. We decided to add a few main types of feedback. First, as stock diminishes, the sprites of the product being sold will decrease in 25% intervals. Second, if the employees have nothing to do, they will be shown doing nothing, hopefully indicating that the player needs to assign them to a new task. There will also be notifications about low stock on product or ingredients. Lastly, a new feedback mechanism the team wants to add is a reviews system, like what you would see on Yelp or TripAdvisor for a business. As the bakery’s reputation changes, there will be reviews added to the screen. These reviews can be positive or negative and also point to some problems of the shop, like low stock.

With the problems we had in the previous weeks, our rescoping of the game also forced us to reconsider the features we want in the game. We decided to cut a few things we originally had in the game, keeping in mind that there were some core mechanics needed for the game to work and everything else was appreciated, but not necessary. While upgradable equipment helped the player deal with money management, budgeting is covered in other aspects of the game. Some other features the team decided to cut include two other shops, taking out additional loans, and selling the business. Even though we are cutting a lot of features that would make the gameplay more interesting, we plan to shift the concepts taught through those features into other mechanics of the game. For the most part, we want to showcase the concepts in more character storylines and will be increasing the number of characters from 4-5 to 6-7. Hopefully, by doing so, the game is kept robust and interesting.

Rework of the different mechanics of BizWorks

Programming

Programmers spent this week finishing the day and adding some smaller UI elements for the player to better understand the game. Players can now assign employees to tasks in order for the day to start. The UI in the corner also tracks how much product is available to be sold. Programmers also finished the ingredients panel and it now now includes a small inventory panel to indicate how much of each ingredient the player has. While the numbers are still subject to change after playtesting, everything works. We also started to put in reputation, which will help determine how much the store sells and just give feedback to the player. It will be used in conjunction with the reviews that we are writing. The money increments based on the store’s reputation to represent items being sold at some frequency, which again increases as the store’s reputation increases. Programmers are largely making good time with the main mechanics and expect to go into polishing going into the break.

Screen capture of employee task delegation

Art

Art spent this week finishing the assets for the store and polishing the existing assets. Working together with writers, they outlined all the employees for the game and will start on concept art for them. Art also spent this week making some UI assets that programmers requested. The goal is to add small details that make the experience enjoyable for the player, such as sounds and visuals that show the player is making money. Art discussed using the appearance of the store for feedback as well. For example, we are going to have the stock in the display cases disappear as the number of pieces of bread left goes down. Artists created the aforementioned assets and are starting to work on other feedback assets in the coming weeks. Furthermore, while the team will keep using bread for the moment, artists discussed making the product sold at the store some kind of fad dessert, partly in response to feedback received at our presentation. There have been no final decisions made on that, but ideas on the table are things like unicorn bread or sweet pierogies. In the coming weeks, artists will be focusing more on characters and UI, as the store design is pretty much final. 

The progression of how the bread shelf asset changes as stock decreases.

Writing

After rethinking the concept of the game, writers focused this week on the review system that will be used as feedback for the player. We decided that there would be three kinds of reviews– negative reviews, filler reviews, and positive reviews. Negative reviews would present themselves when the player has made mistakes with running the business. For example, if the player runs out of stock during a shift or has employees that are being negative because of personal issues, it will be reflected in the reviews. Filler reviews are reviews that are there to give some character to the review feature, but don’t really imply anything positive or negative about the experience in the way the other reviews do. Examples of this would be just a number of stars or statements like “Good food.” Positive reviews affirm that the player has made the right decisions. For example, a review stating that “The staff was helpful and really nice. You can tell they’re really enjoying their jobs! I got a baguette and not only was it tasty, it was also fresh out of the oven.” Hopefully, these reviews serve as something fun for the players to read, as well as give positive or negative feedback as needed for the game.

Working review database for the in-game review system

Summary

This week, the team continued developing the core mechanics of the game. Like last week, we’re still struggling with balancing the concepts the client wants to teach and what we think makes a game appealing to those in our target demographic. To help solve this problem, this week, we gathered information from our target demographic and from an expert in educational games. We hope to use this information to make any changes needed to our core mechanics in the coming week.

Programming

Programmers finalized the game’s main cycle, which now includes a day and night portion as well as lunchtime. Taking into account the feedback from different experts, we determined this would be the best way to make time pass in the game. Tasks will be assigned to employees now rather than the player. Programmers also made more progress on the store interior scene, although it is still mostly programmer art. Tapping on on the door marked “Delivery” now triggers a pop-up panel that details an ingredients list that is programmatically generated. We are working to have a similar mechanic for the store employees. Much of the programming work will be dealing with UI in Unity, as programmers decided that loading a new scene for each menu will be too time consuming. Below is how we envision the game cycle to function:

How we expect the game cycle to play out in a given day

Art

This week, artists continued working on the in store assets and started on employee assets. One of the main struggles that the artists have had this week is getting all the assets needed for the game in the small space that we have. Since the game is being developed for a mobile platform, there is already a limited amount of space for the player to interact with. Specifically, we’re trying to incorporate the sitting area and cooking area on the same screen, but the limited amount of space available is making it seem a bit cluttered. In order to get around this problem, artists have considered creating a scroll screen, but are hoping to keep the player on one screen. Artists have also worked on the menu and map assets for the player to do different tasks on.  

PlaytestinG

Along with last week’s paper playtesting, this week, the team was able to go to an event at the Carnegie Science Center. There, we were able to distribute a survey for students in our target demographic about the way they approach video games and what they thought about our ideas thus far. While we did not get as many people to fill out the survey as we had wanted, there was enough information to obtain an answer to some questions we had about the appearance of the game.

The survey was organized into three sections. In the first, players were asked some demographic questions, including their age and what kind of movies and books they consume. We wanted to make sure that we were getting responses from a wide range of people. In the second section of the survey, we asked more specifically for the respondent’s video game preferences for the same reason. The third section of the survey dealt specifically with BizWorks and some of the concerns we had discussing the game with our client. We wanted to make sure that the art assets and existing UI we had made sense. We also wanted to address the question of whether we should make a more realistic game or a more fantasy game, so we presented responders with more fantastical themes, like steampunk and magic fantasy and asked them if they preferred those themes over the realistic concept art that we have. Lastly, we wanted to know what aspects of a game make it fun for the players.

With all our respondents coming from an engineering fair, we had anticipated the data being extremely skewed, but there was a wide range of interests within the respondents. In general, most of the respondents were interested in action/adventure media, including video games. Half of the respondents reported playing games for over ten hours a week, while half played significantly less. Regarding our questions, we found that most of the respondents would be interested in a fantasy or steampunk style game, but didn’t necessarily prefer it over the existing style we have been using. Therefore, we decided to keep continuing with the art style that we have been using. While we got valuable information from the playtesting, we only got six respondents, so ideally, we’ll get more information in the future from the target demographic when we have a working prototype.

Research

This week, we were also able to speak to Erik Harpstead, a professor at CMU that specializes in educational games. We explained the mechanics of our game, as well as some of our concerns and how we planned to implement the different financial literacy concepts that we wanted to teach. His feedback came in the form of a few large points. He suggested that we take everything we wanted to implement and only include about half of them, with his reasoning being that we should try to make the game as simple as possible so that the players could process it more easily. He also suggested that we don’t have a hard end goal for the game and instead allow the player to choose when to restart the game. After speaking with him, the team decided to change a few aspects of our game. First, players will have the option to sell their business after a set amount of time, but will not need to. Instead, they can keep playing the game. However, no new interactions will be introduced, so ideally, the players will eventually want to restart the game on their own. Second, we changed the structure of the day so that it has a morning and evening shift, with a break in the middle of the day for employee interaction. Lastly, we’ll be trying to make all the calculations involved in the game to be as simple as possible, to make the game not overwhelming for the player.

Introduction

This week, our team continued to develop the concept of the game, focusing specifically on the tone we wanted the game to have and balancing entertainment and education. We ran our initial concepts through with some playtesters to make sure we were on the right track and started programming the progression of the day. We also continued developing the art assets for the store and starting drafting an outdoor map for where the financial institutions would be.

Playtesting

While we didn’t have access to many people in our target demographic, the team wanted to test the ideas that we developed for the game on a group of people to make sure that we are on the right track. Therefore, we created some paper mockups of how the game would run, with employee interaction and the basic store screen to show to some freshmen at CMU, who were the closest people we could get to the target demographic.  We sat down with each playtester for 10-15 minutes and ran them through the game, explaining how the different mechanics would work in the final product. We also gave an example of what kind of employee interactions there could be using the employee Lila, who we designed. After we walked the playtesters through the experience, we asked for verbal feedback and administered a post-experience survey that they had to fill out, essentially asking how clear the game was in meeting its financial literacy goals.

Sitting with freshmen playtesters on Tuesday

The feedback received from the paper playtesting was positive, for the most part. Most of the playtesters said that they understood how the game was going to run and thought that the game would be enjoyable. One of the biggest problems we had last week was finding out if we wanted to make the game more realistic or fantastical. The paper prototype we showed took a more realistic approach, which seemed to be received well, although two playtesters said that they’d prefer something more high fantasy. However, in general, there doesn’t seem to be a large problem with the approach we are taking. Additionally, the team was concerned that the game would not be fun, especially given the topics that it is trying to teach. Playtesters told us that the idea of including minigames to make the game more engaging and using storylines to present the financial problems was a good way to make the game interesting, but not boring. Some playtesters also gave feedback about the UI elements and said they weren’t intuitive, since they asked us to explain some of them, so we’ll be changing some of the graphics to make them easier to understand. Overall, the playtesting session gave us a lot of good information.

Game images used for paper playtesting

Game images used for paper playtesting

Programming

Most of this week was spent setting up the project on GitHub and getting the preliminary classes set up in Unity. Earlier in the week, programmers ran into a little trouble getting the GitHub project set up. Therefore, the first few days of the week were dedicated towards trying to get it running on every team member’s machine. Afterwards, programmers spent the rest of the week focused on getting all the classes set up and started programming some of the UI elements of the game. The two main goals of this week was to start running the game through a day iteration of the game and working on money decrementation as well as supply incrementation based on deliveries. Both were started and are expected to be completed by the next week.

Art

For the first few days of this week, artists focused on making the art assets for the playtesting event that we held on Tuesday. They worked on some separate buttons assets and put together screenshots of the game screen. Not much was polished on the store layout, but after showing the store to playtesters, they gave our artists some ideas on what to add. We’ve decided to add a display case that can show stock diminishing, as a way to help players understand that they may need to stock up on ingredients. We also decided to add more appliances to the store, likely with simple animations, to show the store running during the day. Artists also started creating the assets for the delivery menu.

Inside of the store

Art for the menu buttons. From the top right, clockwise as follow: pause, balance sheet, menu

Next Steps

In the coming weeks, we want to continue implementing the main mechanics of the game. While we appreciated the playtesting we were able to do, we have an additionally opportunity to playtest some more with students actually in our target demographic. Therefore, we will be issuing a survey to them to collect more information on what makes a successful financial literacy game. We’ll also continue working on the script and art to bring the narrative aspect of the game to life.