Home Page
Welcome to our homepage for UnderCooked!
This website is a showcase of our frantic cooking game, UnderCooked! (Inspired by OverCooked, UnderCooked is a project from students at the University of York.)
All the contents for this website are on this page, the navigation bar in the header will take you to a specified heading on this page.
Download UnderCooked!
https://github.com/undercooked-team/UnderCooked/releases/tag/game
Our GitHub Repository
Below is a link to the GitHub Repository we’ve been developing our game in:
The Team
Details for all the team members can be found here:
- Fin Cochrane - ftc505@york.ac.uk
- Sehran Ahmed - rsa533@york.ac.uk
- Sam Davis - sd1598@york.ac.uk
- Hamza Salman - hs1955@york.ac.uk
- Owen Thomas - obt503@york.ac.uk
- Zhenyi Xu - zx1090@york.ac.uk
Requirements:
Architecture:
Below are UML images showcasing our development process for the Final Architecture Design (for Assessment 1). You can also find all the images here:
Google Drive: https://drive.google.com/drive/folders/1KE2M_o6zdMu1JZjFEnv3oIxf5IxwgiiC
GitHub: https://github.com/undercooked-team/UnderCooked/tree/main/ENG1/SUBMITTABLES/Architecture
Use-case Diagram:
The below summarises the general outcome of this project:
RDD Table:
We initially designed a Responsibility-Driven Design Table (RDD) out of our requirements:
Using the RDD above, we made our Initial UML Diagram.
Initial UML Diagram:
Over time, we expanded upon the Initial UML diagram, making changes where necessary:
Addition 1: Game
We quickly realised how limited our initial UML was surrounding the gameMaster:
- Boot is responsible for initialising the game.
- GameSprites is responsible for holding multiple sprites to render.
- gameMaster branched off into 2 classes:
- ScreenController is responsible for switching between the main, pause, instructions, credits, gameplay-screen and game-over screen.
- GameScreen is the gameplay-screen. It contiains various methods and attributes to allow for gameplay, including mapHelper related methods.
Addition 2: Food
- FoodStack is responsible for holding a stack of in-game cooking ingredients. The chef class will use this object to hold food items.
- FoodItem contains information about how to render each ingredient.
- Recipe contains each recipe and how each one is made. We learnt that to consrtuct salad and burgers, the cook must hold a certain FoodStack. Thus, certain - FoodStacks correlate to certain recipes. Recipe holds a dict which translates a String recipeName to Array
listOfFoodStacks which are all the foodStacks which correlate to recipe recipeName.
Addition 3: Cooks
- Chef was renamed to Cook.
- Collidable branched into the GameEntity class, which was used as a base class for any item that could exist as an object with a physical position in the game-world. We learnt that classes Cook and Customer can use the same code in GameEntity.
- We made CookInteractor because this object is solely responsible for letting a cook interact with other objects. Any other object within the CookInteractor Rectangle, is an object that the Cook and interact with.
Addition 4: Interactions
These classes were not present in our initial UML in any form. This class is an information class:
- Interactions contained a dict, which accepted an ingredient (foodID), and a station (stationID), and outputted a processed ingredient (foodID). This information doesn’t exclusively fit into Food, or Station, so it became a class of its own. This class also contains User-related interactions with the game-world, and would monitor which keys the player was pressing.
- InputKey is a helper class of Interactions, aiding with the mapping of keyboard keys being pressed, to controls and output in the game.
Addition 5: Stations
- CookInteractable allowed a station to become interactable with the cook.
- We quickly realised that we would need more stations to allow the player to have greater ability to manipulate the stack of items that they will hold. For example, if the player accidentally collects 1 too many items, they need to be able to bin the top item (BinStation). Or if the player needs to swap items with the other cook, they need to be able to place their FoodStack down (CounterStation).
Addition 6: Customers
These classes were also not present in our initial UML, and we realised this a while ago too, that we need customers to allow for the gameplay specified in the User Requirements. However, this was also the last thing we added since all the other classes above can be tested with each other without needing customers.
- Customer is similar to Cook, in that it holds cruical information about the customer, like the recipe/request they want.
- CustomerController is a new class dedicated to controlling the flow of customers into the restaurant.
Addition 7: Helper
- Hud is a superclass which easily allows for the addition of information on the screen during gameplay.
- GameHud displays the number of customers remaining, as well as a time taken to complete the task.
- InstructionHud displays the controls during gameplay, so the player always has a guide to tell them what to do next.
- None of the other Helper classes were orignally added into the initial UML, as none of them directly correlated to a user requirement. Rather, these classes were gradually added throughout development to allow for other classes to function properly, letting the other classes complete their assigned user requirement.
- Constants simply contained some global values.
Method Selection and Planning
Method Selection and Planning Google Doc
Method Selection and Planning PDF
Risk Assessment and Mitigation
Risk Assessment and Mitigation Google Doc
Risk Assessment and Mitigation PDF