# PPA Coursework 3 - Teyvat Ecosystem

**Authors**

###### Kaushik Chinta - 20029311
###### Aaron Patrick Monte - 20059926

## Project Information

This project is a simulator of the world of Teyvat, based on the game Genshin Impact by MiHoYo: https://en.wikipedia.org/wiki/Genshin_Impact

The project simulates different organisms and their behaviour. Organisms in this project include: Slimes, Boars, Wolves, Hilichurls and Humans. The values of the organisms can be found in the `Portfolio` class and has been adjusted to maintain a relatively stable population under clear weather conditions. In a normal long simulation, the wolves die out at ~1200 steps and the Hilichurls die out at ~700 steps because they can not compete with humans who eat their prey.

To start this application, create an instance of class `Simulator` and call either its `simulate()` method, `runLongSimulation()` method or their overloaded variants. Running the `startInfection()` method will start an infection but this will only be visible on the next step.

## Functionality

The simulation consists of five organisms, of which three are predators and two are prey. Plants are assumed to be always available.

The prey consist of:
- Slimes
- Boars

The predators are:
- Hilichurls - which eat slimes.
- Wolves - which eat boars.
- Humans - which eat both slimes and boars.

<div style="page-break-after: always;"></div>

**Class Diagram**


**Food Chain**


All organisms can eat, give birth and fall asleep as well as be infected and spread their infection.

Some organisms have varying behaviour, depending on the weather. This is explained further in the challenge tasks section of this document.

## Completed tasks

All the base tasks have been successfully completed.

We also implemented different weather types which cause some of the organism's behaviour to vary as well as infections that can spread between different organisms. We then modified the GUI so that we can add an extra 2 labels displaying the current weather and whether an infection has occurred yet or not.

<div style="page-break-after: always;"></div>

### Base Tasks

- We have five different species which are: Slimes, Boars, Hilichurls, Wolves and Humans.
- Humans compete for their food with Hilichurls and Wolves. It is interesting to note that because of this competition, Hilichurls and Wolves eventually go extinct after a certain number of steps.
- All organisms have a boolean `isFemale` attribute, in other words, its sex. We then modified the `canBreed()` method so that for an organism to be able to give birth, the organism has to:
- be of the right age
- be female
- be adjacent to a male organism of the same type
- not infected by the disease
- The field contains an `isDay` attribute which determines whether or not the field is in day time or night time. Organisms will become inactive during the night but they will still age. We switch between day and night every two steps (the default value for `DAY_NIGHT_CYCLE`) by using the `toggleDay()` method from the `Simulator` class when the total steps modulo divided by the `DAY_NIGHT_CYCLE` constant equals 0.

### Challenge tasks

- The different weathers of Teyvat are kept in an enumerated data type. Then we added overloaded versions of the `simulate()` and `runLongSimulation()` methods which take in a string to allow the user to make use of this weather system. Depending on this string, we choose a corresponding state in the `Weather` enumeration and assign it to `weather` attribute in the `Field` class. We then make a use of this attribute to implement changes in some of the organism's behaviour. By default the weather is clear and has no effects on organism behaviour. Currently we have 3 different weather effects which are as follows:
- When the weather is snowy, slimes will be unable to move.
- When the weather is rainy, slimes will move twice per step.
- When the weather is sunny, predators have a chance of becoming hungrier.
- To implement diseases, we added a boolean attribute called `isInfected` in the `Organism` class. We then used this to determine whether the mark drawn from the `SimulatorView` should be of their own respective class colours or red (if they are infected). This means that all infected organisms will show up as a red square regardless of their type. We then used a few more variables in the `Field` class to store the duration and the spread rate of the disease. In the current implementation only one infection can be simulated per field. Finally in the `Organism` class we made the disease kill the organism when the `activationTime` reaches 0. This activation time is initialised to the disease's `duration` and is decremented every step. We also made it so that organisms with the disease will try to infect their adjacent neighbours. In our implementation we made it so that organisms that are infected also cannot breed.
- The base program used AWT and Swing to create its graphical user interface. To modify the interface to display the field's current weather and whether or not the infection has started, we created two new `JLabels`: `weatherLabel` and `infectionLabel`. The base program's interface uses a `BorderLayout`, where all but the `EAST` direction of the interface are occupied. Therefore, we had to wrap these labels with a parent node. We chose to use a `JPanel` for this. We then modified the enumerated type for the `weather` to take in an associated string in its constructor. We then override the `toString()` method in the `Whether` enumeration so that it could easily be appended to the label.

## Code limitations

At the beginning of the project there was a lot of duplicated code that could be shared, however each class had its own constants. To enable more code sharing we added a `Portfolio` class which in conjunction with the `Entry` class enables the sharing of the constants. This is done by using a `HashMap` that makes use of the class names for the keys. However, one main issue that we came across while refactoring the code was that there had to be a direct call to the current class' constructor in the `giveBirth()` method. For example, the `Slime` class had to call the `Slime`'s constructor whereas the `Boar` class had to call its own constructor. We could not find a solution to this problem and therefore we had no choice but to override the `giveBirth()` method in every sub class.