Dish Dash

Dish Dash is  a top-down 2D diner cooking game.

Players will complete as many customer orders to reach their score goal of $250. Players must view customer orders and then win a minigame every time they  want to acquire each item necessary. Gather all items to complete each order and make you way to the end goal amount. Be careful not to miss any order or you will lose progress. 

Team Roster and Roles

Hailey Rock - Game Artists/ Animator

Brissais Hidalgo - Programmer

Mikel Herrera - Programmer

Shonita Bangale - Programmer/Animator

Instructions:

-Use the W,A,S,D keys to move around

- Player Inventory is displayed in the top right corner

-Customers will spawn in randomly in bottom cafe area

- Approach customers to view their order

- Approach different stations and click on them with mouse to open and serve food

- When all order items are acquired, approach customer again and press SPACE key

What went right?

We are particularly proud of establishing and developing our inventory system to save customer order items. As complete beginners it is very difficult to turn some of concepts into fully developed ideas. Even with tutorials it is hard to take those building blocks and make them into your own idea without a full guide to follow. Given this difficulty we are very proud of being able to develop an inventory system that functions properly and is transferable to our customer orders as well. 

In addition we are proud of making our different parts work together as while we all had our own different portions to make it still provided challenges when combining our programs so we are very happy that we were able to make a coherent and fully functional game. The art and aesthetics for our game is also one of our highlights as the overall look to our game and the animations from our artist is one of its best features. 

What went wrong?

Some of the biggest issues we faced was with the order checking system and simply establishing the sprites correctly in our game. The order checking system was difficult to come up with as it required a lot of trial and error to find a method that would properly check the players inventory and still be linked to the customer orders. The inventory system proved a highly difficult system to set up as testing consistently revealed new errors or misaligned functions that would hinder gameplay more than they assisted. We overcame these problems by furthering our understanding of the applications of what we were trying to do as well of properly studying the tutorials outside our specific idea to best gasp how the teachings could be altered to our game's needs. In addition to the inventory system we faced challenges with keeping the sprites working properly. Changes in room size and altering the size and function of other sprites and animations led to misalignments in different images a lot of the time. Adding animations to the game's operations such as pouring and serving was also difficult as it required a lot of set up and proper management to ensure the right animations played without disrupting other sprites or rooms. However we overcame this issue by working as a team and meeting to discuss how our game was operating and take everyone's ideas of viewports, code and, animations to best fix each issue with a sprite.  In addition having some systems require changing rooms was the most difficult as most of our knowledge required the same instances to be use constantly so these changes in rooms meant we needed to learn a lot about how to save some information like customer orders or ensure some variables are maintained globally but not destructive to other functions. We overcame these issues by researching things like arrays and persistent objects and simply researching how games typically address changes in scenery or display easily. 

Changes that were made

Originally our plan was for customers to line up at a designated counter area where the player would accept their orders before proceeding to make them. This was changed to due the difficulty with spawning the customers in and establishing their movement. In addition the difficulty with establishing the order checking system made it harder to be able to ensure enough time to allow for the customers to move and align properly for a queue style set up. Another change made was the removal of some different minigame idea that would require players to manually cut a cake or serve ice cream for other parts of the stations. These were also remove and changed to the slider minigame as combining the functionality necessary for the original idea along with dynamic animations proved difficult to implement. 

What did we learn?

Overall we learned a lot about establishing interconnected systems of functions and the difficulty in make a game that includes changes in scenery and consistent generation. We learned a lot about game development and that even simple games and systems require extensive testing. Every additional component brought new issues or simply new ideas to fix and improve the overall experience.  Even with the work broken down there is a lot of time put into developing a game. We also learned a lot about information management and how games store and exchange information with other players or entities and how procedural generation can be very beneficial to a game but also very challenging. We learned the challenges of producing a project like a game even at small scale doesn't avoid challenges in learning to developed and design systems and make our idea into a functional component.  On a general basis we learned a lot about the importance of communication and simply working in a team no matter how small for a large scale project requires a lot of preparation and planning even for matters as simple  as meetings or information exchange. Our team learned a lot about game maker and how powerful a game engine it is capable of being as well as a great tool for learning game developers.