City Feature Placement and Addition

Introduction & Motivation

Prior to this sprint, the game was all business: everything was added to the game strictly with a purpose, with little regard to the player experience. This sprint, in an attempt to embody Juicy Game Design, we tasked ourselves with sprucing up the city with fun cosmetic elements. These elements, or "city features" as we call them, add no depth to gameplay, but provide a visual indication of life within the city.

City Features

The city features are designed to spawn randomly throughout the city, but are aligned to buildings to continue the sense of structure that has already been created within the city. This hopefully continues the existing balance between variability between playthroughs, whilst retaining a core structure to the game that is easily recognisable.

Water feature

The water feature was designed to befit the dignity of such a storied city, and follows the colour aesthetic and stone design of other prominent Atlantean buildings

Lamps

To fit the medieval aesthetic, glowing lamps have been added to the feature repertoire, in an attempt to provides some brightness in the gloom

Bushes

To add some lighter greenery to the city, Bushes also spawn intermittently beside buildings

Island tiles

Similarly, the island was deemed too bland, as it was a never-ending stretch of the same sand tile. Our solution to this was to randomly spawn island tiles with different textures - some with a shell and some with a starfish. This added some life to the island, and made it feel less bleak and uninhabited.

Before the change

After the change

Adding a feature

To add a new feature to the game, the following steps must be adhered to

1. Add a feature entity creation function to CityFeatureFactory.java
2. Edit the spawnFeatures() function in AtlantisGameArea.java with the following changes:

• Set the numFeatures variable to be 1 greater than it was previously
• Edit the switch statement within the main loop to set your new feature e.g If the switch statement looked like this...

                switch (currentFeature % numFeatures) {
                    case 0:
                        //Place a water feature
                        feature = CityFeatureFactory.createWaterFeature();
                        break;
                    default:
                        //Place a lamp
                        feature = CityFeatureFactory.createLamp();
                }

edit it to ...

                switch (currentFeature % numFeatures) {
                    case 0:
                        //Place a water feature
                        feature = CityFeatureFactory.createWaterFeature();
                        break;
                    case 1:
                        //Place my new cool feature
                        feature = CityFeatureFactory.createMyNewFeature();
                        break;
                    default:
                        //Place a lamp
                        feature = CityFeatureFactory.createLamp();
                }

Testing

The testing plan to ensure the robust implementation of the aforementioned features was predominantly experimental, as unit tests were not considered a necessary approach given the way placement was implemented.

As feature placement was done relative to buildings, it was assumed that the unit tests verifying the placement of buildings also covered features. This is because each feature is placed a small, fixed tile offset (in the x direction) from each building (with the exception of the final buildings in each row). This functionality is easily verifiable by eye, and guarantees that each feature will be placed within city bounds and will not intersect with another building, as buildings have a mandatory minimum offset in the x direction.

As such, over repeated game loading, it was simple to determine that each feature did indeed spawn at its correct position relative to its building, and no features spawned in the final row - indicating that each feature had a valid position. It is noted that this approach is largely unscalable, and vulnerable to changes such as the reduction of the offset between city buildings in BuildingGenerator. If future sprints were possible, this approach would be incorporated into BuildingGenerator, to ensure it would always have a valid spawn point relative to other buildings.

Finally, the "bonus" island tile textures were also easy to test by sight, as the distribution they are spawned at is easily viewable.