Ordering System Overview - UQcsse3200/2024-studio-3 GitHub Wiki
Table of Contents
Introduction
NOTE: Docket and ticket are used synonymously throughout this because I am unintelligent and old habits die hard
The ordering system involves getting an order from a customer, generating a docket which contains some sort of docket identification, customer identification, the food they ordered and the ingredients required to make it and having that docket displayed and able to be moved around the screen.
The docket line consists of two parts, a "primary" and "secondary" area. In the primary area, only one docket can be stored here at a time. The docket stored here will be enlarged so the player can more easily read it and so that they can organise themselves and focus on it. The secondary area contains all other dockets that they player currently has active. Dockets stored in the secondary area are not enlarged, so as to fit more on screen and so that the player's attention is better focused on their pinned docket.
In order to move dockets, the player will be able to drag and drop dockets from one area to another, or alternatively press left square bracket ( [ ) and right square bracket ( ] ) to quickly cycle through the docket line.
Coding
UML
The UML below details the relations between the different classes created to successfully implement the ordering system.
NOTE: updated with latest classes
Description
In order to display dockets on screen, in the class MainGameActions a new entity was created, and had the component MainGameTicketDisplay added to it. It was then immediately registered in the entity service. An event listener is then created, registering an event called "createOrder", which calls the method onCreateOrder(). This method then calls the addActors() method in the MainGameTicketDisplay component. The addActors() method then creates a new Table object, which contains all appropriate UI elements. The Table object is added to an array, alongside other important variables for updating the docket background and the docket contents.
Coding Choices
The Entity Component System was heavily utilised for both the front-end of the UI - i.e. the code responsible for showing the docket on screen - and the back end - e.g. registering and triggering events, updating graphics and labels. This is because making the required classes an extension of a Component allowed for it to be added to an Entity directly using the inbuilt Entity.addComponent() method, with said Entity then being registered to the EntityService, which handles the vast majority of complicated tasks such as rendering. To implement this in a way that adhered to design patterns, a class called UIFactory was implemented, which simply creates a new Entity and adds a new MainGameTicketDisplay component to it immediately, acting as an extremely simple factory design pattern.
Design
Introduction
Here's a mockup of questionable quality
Now here it is broken down a bit
1 - This is the main docket area. Only one docket can be pinned here, and it will (most likely) be the one the player is currently focusing on. When a docket is here, it is enlargened so that the player can more easily read it.
2 - This is the "docket line," where orders will go after the player takes them and if the primary spot is full. These dockets are of a smaller size, both so they're not as big of a focus for the player and so that we can fit more on screen
3 - This is the docket heading, which will help players better keep track of their dockets. Not fully vital and can be removed if need be to save space, but for now is worth consideration
4 - This is where which customer it will be for will be displayed. Ideally, for readability it would contain some sort of image for example a shrunk down sprite of the sprite of the customer who ordered it
5 - The food that the customer has asked for. Again, ideally, in future version it will use some sort of image or sprite as opposed to text for readability
6 - The ingredients to make the food that the customer asked for. The main way for players to learn the recipes for different food items. Again, ideally, in future version it will use some sort of image or sprite as opposed to text for readability
Design Justifications
Inspiration and Theory
The game as a whole was originally inspired by the Papa Louie franchise. The docket system especially was heavily inspired by the order dockets used in the series, as it is one of the most significant and recognisible features from the games. For the purposes of this game however, the dockets - and by extension, the orders themselves - have been simplified. While the dockets and orders in the Papa's series of games had features such as requiring a specific presentation or garnishes, the orders in this game have been heavily simplified due to the overall scope of the game and feasibility.
Order ticket from Papa's Pizzeria, displaying the order number, what the customer wanted on their order, how much they wanted and how they wanted their order presented and cooked.
Image retrieved from the Flipline Studios fandom wiki.
In terms of scope, while the Papa's game franchise was a large source of inspiration, the concept evolved and Overcooked became another heavy inspiration for the game, which has a greater focus on the chaos of physically moving a character and completing multiple simple orders in a game level that introduces new complications as time goes on. Since it was deemed that an Overcooked style game play loop would be more fun and challenging for players as opposed to a Papa's game play style, orders were simplified in order to better fit in with this vision for the game. With simpler orders, this meant that dockets could be simplified too, containing less information for the player to process. In terms of technical feasibility, having more complicated orders that are closer to what is present in the Papa's franchise would be infeasible, as it would be extremely difficult to develop this on the restricted time frame this project has, especially in conjunction with all other systems and game play features that need to be developed.
Level from Overcooked! which showcases the general layout of an Overcooked level with dockets present in the top left of the screen, showcasing how they are far more simplified and closer to the dockets used in this project.
Image retrieved from the Xbox webstore listing for Overcooked
Design Advantages
By having simplified orders and therefore simplified dockets, this presents multiple advantages for both the players and the development team. For players, the design of dockets primarily allows for better readability for a variety of reasons. First of all, since the orders and dockets are simplified, this means that they have less information that needs to be communicated. This, by extension, means that dockets can be smaller in size and therefore less intrusive for players, as they can still comfortably display all their required information in a smaller space. Furthermore, since they don't have as much content they need to display, this means that the dockets themselves will be less cluttered and can therefore more clearly show what information is required. For the development team, an overall simplified system means that the final vision for the game is overall far more reasonable and achievable, especially when considering the limited time frame given for this project.
As heavy inspiration was taken from the Papa's game series, the docket system heavily borrows elements from those games, mainly in terms of presentation. This is extremely advantageous, for reasons detailed in the sixth Nielsen Usability Heuristic, recognition rather than recall (Jakob Nielsen, 1994). As the Papa's games are extremely popular and well established, there is a high likelihood that a player has had experience with one, and therefore would inherently know how the system functions due to recognising its presentation. Furthermore, since the dockets resemble their real life counterparts, it helps completely new users learn and understand the game faster, as they would likely recognise the dockets based off of their presentation and using that pre-existing mental model, fill in the gaps and quickly understand what is being communicated to them and what they need to do.