The first week of this sprint we have not pushed that much code and made PRs since we were mostly in the planning stage of how we were going to implement the feature. In addition, we were waiting on another teams to fix issues with the game before starting the make PRs of new features since that is what we agreed on the week we started sprint 3. This is what we were working on:

Different ideas for implementation

1. I’m thinking of implementing different map layouts for each level using a switch case statement in the TerrainFactory class. The idea is to have the method take the level number as an argument, and based on that, the switch case would define the layout for each level.

2. I was also considering using separate class that inherits from a common Terrain interface or abstract class. Instead of a switch case in the TerrainFactory, I could create specific classes like Level1Terrain, Level2Terrain, etc., each with its own implementation of the generateLayout method. The TerrainFactory would then instantiate the appropriate class based on the level number.

3. One last idea was using a text file to handle map layouts, where each level's terrain is represented in a simple format, like a grid of characters. The tutor helped us come up with this idea. The TerrainFactory could read this file and interpret each symbol as a different terrain type—like # for walls, . for open space, or ~ for water. This approach would keep the game logic separate from the layout design, allowing me to edit or add new levels just by modifying the text file, without touching the code. It also gives me the flexibility to easily visualize and design levels by hand. Plus, parsing a text file is relatively straightforward, and the simplicity of the format would make it quick to load and manage within the game.

Different layouts implemented

It was decided that we would implement 5 stages of the game all with different map layouts. The idea is that as the stages progress, the difficulty of the game would increase. This implemented through the increased prevalence of different ingredients and stations requiring more complex recipes for the player to create.

Here you will see the stations and recipes required for each day. Further recipe information can be seen in the Ingredient Station wiki page. There will also be a description of the purpose of the day, and an image of the final map design of that day after it has been completed.

Day 1

This is the first day the player will play on, so is made to be as simple as possible so that the player can learn the basics of the game. Only one meal is required, and minimal stations are provided.

Stations required:

1. Cutting board
2. Tomato basket
3. Cucumber basket
4. Lettuce basket

Recipes:

1. Salad - cut up tomato, cucumber & lettuce

Evaluation

• Simplified map layout to accomodate newer players unfamiliar with how to play the game
• More open and free map design

Day 2

This day aims to up the ante by getting players to manage different types of dishes and making the ingredients for the right one.

Stations required:

1. Cutting board
2. Tomato basket
3. Cucumber basket
4. Lettuce basket
5. Banana basket
6. Strawberry basket

Recipes:

1. Salad - cut up tomato, cucumber & lettuce
2. Fruit salad - cut up banana & strawberry

Evaluation

• Still relatively simple and easy layout for new players
• Slight increase in difficulty with stations and ingredients more spread out from each other
• More stations and recipes

Day 3

This day builds off day 2 by getting the user to both juggle multiple dishes, while also learning the cooking mechanic.

Stations required:

1. Oven
2. Frying pan
3. Cutting board
4. Fridge
5. Tomato basket
6. Cucumber basket
7. Lettuce basket
8. Fire extinguisher

Recipes:

1. Salad - cut up tomato, cucumber, lettuce
2. SteakMeal - cut up tomato and cucumber, put cut up ingredients in oven. Beef on frying pan

Evaluation

• Oven and ingredient strategically placed as far as possible from each other
• Increased difficulty with more eccentric map layout

Day 4

Day four is introducing new meals and the blender which hasn't been introduced beforehand. This should be easier then day 3, but will help the player relax a bit before Day 5.

Stations required:

1. Blender (for acai bowl, not sure if required, could use cutting board instead)
2. Cutting board
3. Banana basket
4. Strawberry basket
5. Acai basket
6. Fridge - Chocolate

Recipes:

1. BananaSplit - cut up banana, strawberry and chocolate
2. AcaiBowl - cut up or blended up (?) acai and banana
3. FruitSalad - cut up banana and strawberry

Evaluation

• Cutting board placed as far as possible from ingredients as well as the servery position
• Increased difficulty do to longer travel time

Day 5

Day 5 aims to truely test the players skills they have gained through playing the game. In this day, every recipe and every station is present.

Stations required:

1. Oven
2. Frying pan
3. Cutting board
4. Fridge - Beef
5. Fridge - Chocolate
6. Tomato basket
7. Cucumber basket
8. Lettuce basket
9. Banana basket
10. Strawberry basket
11. Acai basket
12. Fire extinguisher

Recipes:

1. Salad - cut up tomato, cucumber & lettuce
2. SteakMeal - cut up tomato and cucumber in oven & cooked beef from frying pan
3. BananaSplit - cut up banana, strawberry and chocolate
4. AcaiBowl - cut or blended up (?) acai and banana
5. FruitSalad - cut up banana and strawberry

Evaluation

• Drastic increase in number of stations and ingredients
• Addition of more complex recipes
• Maze like path to servery to increase travel time and difficulty

Map text files

Initial implementation in sprint 3

We created a MapLayout file which loads in the text file in the load function. It is being called in ForestGameArea which takes in the level when being initialised to load in the right map. We also create a Map class in order to return the arrays when load is being called and the spawning happens in ForestGameArea. We also created 5 .txt files, one for each level there are located in images/map/....txt. The load function reads every line of the file and checks with if statements based on the letters to know what needs to be loaded. These are added to arrays which are then accessed in ForestGameArea and spawned. The map for each level is loaded through a text file formatted as follows: (note: the row that the object begins at corresponds to the row of the file where the text is written) Benches:

• Xab creates a horizontal bench beginning at column a that is b cells long
• Yab creates a vertical bench beginning at column a that is b cells long

Stations:

• all stations use the same code of Za1 where a is the column and Z is a letter from the following
• b: banana basket
• s: strawberry basket
• u: lettuce basket
• t: tomato basket
• c: cucumber basket
• a: acai basket
• E: stove
• O: oven
• B: beef fridge
• C: chocolate fridge
• G: cutting board
• N: bin
• S: submission window
• F: fire extinguisher

The first 4 lines of the file are ignored. Example: assets/images/map/map_one.txt

Hel
1
3
=
X08 Y07 Y97
S00
Y63 X13
O00
N61
X21 Y32 X70 G70 X50
000
X12 X44 t21 c51 u71

Changes that have been made during sprint 4

This is a UML diagram describing the structure of our code:

Some changes had to be made for MapLayout. The bench tiles were being spawned below the stations and hence were disrupting the functionality of the stations. This had to be fixed by optimising the case/if statement in our code as well as modifying each one of the text file to ensure a working design. This required some collaboration with the stations team in order to figure out the issue and debug it. Some issues were on our end and others were on theirs. Additionally, we had to change the MapLayout load function to optimise overall performance of the game. This was done in collaboration with team 2. We had to make sure that the entities were still spawning correctly after modifying this function. The helper functions were improved. We also had to tweak with the text files. The BenchGenerator class also had to be modified when optimising performance (done by team 2 who consulted us). This line of code was used (Changed by Alex from team 2): b.addComponent(new ColliderComponent() .setAsBoxAligned(new Vector2(1f, endY - startY + 1), PhysicsComponent.AlignX.LEFT, PhysicsComponent.AlignY.BOTTOM));

We made sure that this integrated well with the rest of our code. We also polished our classes, and deleted BenchLayout (unused) and unused functions. We also deleted the code in TerrainFactory which was there prior to MapLayout when trying to load in the levels in there. Finally, the map designs were modified to ensure that all elements are included. For example, here is level 5:

Improving the testing

In the MapLayoutTest class we have added some code that checks if the file loaded is read correctly. This is done by checking if the right functions are called using verify and spy as well as using the getters to see if the right level name is returned. We also checked if the different helper functions work properly by checking if the correct stations and bench tiles are created (to be spawned on the map). For the BenchGeneratorTest we simply made sure the benches were created properly by checking the array returned by the functions in that class.