bad-chilli-peppers

team-09

gameplay direct link

Story Cutscenes

The story idea was generated by all members of our team. Rough sketches were generated, and then final drawings were done by a member of our team. We used the FreeType text library to integrate our story scenes. The total number of scenes or 9 (4 with images and text, 5 with just text)

Game Balance

The game levels were generated by members of our team, and excessively tested to ensure that each game was playable. We had peers play test our game to ensure each level was playable and enjoyable, but also had componenets of difficulty. This included balancing number of enemies, number of ingredients, game timer and obstacle placement.

Basic Asset Integration

We created assets and integrated them into the game. All of our assets are interactable, they are either the player/enemy component or the ingredient component.

3D Dynamic Lighting

Player is the light source Uses normal maps to calculate light intensity based on direction Different normal maps per block allows for different lighting conditions for different levels. Enemies and ingredients are only visible if within a certain radius of the player or of any fire blocks No lighting effects are visible if limited visibility is disabled

Camera Interpolation

Camera keeps player in center of screen (majority of the time) Camera does not go past map boundaries Results in player not in center of screen when player is close to map boundary

Audio

Implemented background music for main screen, tutorial, playing screen and story screen. Implemented sound effects for entity interactions including player-enemy collisions and player-ingredient collisions. Sound effects for player death and level pass

Sprite Creation

We used generative AI for inspiration of our enemy sprite visuals. Rather than generating designs, we provided descriptions of gameplay mechanics and thematic scenery, then asked for creative ideas. For example, we described an enemy’s capabilities along with the theme of our game being chilli peppers, burning, fire, smoke etc., and were inspired to draw our own enemy sprites. The assets generated using generative AI are the meals in each recipe card (Salad, Pasta, Fruit Salad, Steak, Sundae, Cake). However, each recipe card was put together by members of our team.

Additionally, the following assets were all generated by members of our team:

• Ingredient Textures
• Story Cut Scenes
• Enemy Bounce
• Enemy Lava
• Enemy Tornado
• Player

Publically accessed textures

The following textures were sourced from open-source libraries or publicly available resources. The background texture sprites were from: -RottingPixels, -Uma Alma (Dungeon Kingdom Essentials), -FOX (Cave Tileset), -Kenney Urban Pack (City floor texture), -Polar_34 (City block texture) -O_LOBSTER (Garden level textures) The fire sprites were from: devkidd

Required Elements: Key-frame/State Interpolation

State interpolation was implemented in two areas: player movement and the powerup fragment shader.

Player Movement

• The position of the player is linearly interpolated between grid cells to achieve smooth grid-based movement.
• This is done by computing the start and end vec2 positions when the player presses a direction key, and interpolating between them using a standard lerp function defined in common.hpp.

Details

• The player has four states:
  • IDLE, where input is processed and lerp endpoints are set up.
  • TRANSITION_TO_CELL, where which performs the lerp based on the elapsed time.
  • DEAD, where input is no longer processed and the game over delay is in process
  • OUT_OF_TIME, where input is no longer processed and the game over delay is in process
  • WIN, where input is no longer processed and the game win delay is in process
• After every cell movement, the player state is set from TRANSITION_TO_CELL to IDLE regardless of player input, to set up the new endpoints.
• An inverse lerp function is used to compute the t-value given new endpoints, for smoother movement.
• A lerp computation is also performed once in the IDLE state if the movement key was not released, to get rid of the discontinuity that would occur otherwise.

Powerup

• Uses the GLSL mix function to blend between two colours based on a weight value between [0, 1], with a cosine-based t-value for ease-in/out transitions.
• The mix function uses the formula a(1-t) + bt which represents a linear interpolation where the function smoothly converts between value a and b as time t goes from [0,1]
• Each vertex is given a colour and the vertex colour will smoothly mix between vertColor.yzx and vertColor.xyz while time t oscillates between [0, 1].

Advanced Features

Particle System (Instanced Rendering)

• Implemented a particle system using a ParticleSpawner component that can be attached to any entity.
  • The particle spawner is responsible for handling the rate at which particles spawn and the position of the particles.
• The spawning logic is contained within the particle_system module.
  • The system handles the creation of particles along with random velocity, lifetime.
  • The system also handles the updating of particles by updating their position, scale, angle, along with the velocity based on a fixed acceleration.
• Rendering is handled by the ‘InstanceRequest` resource.
  • The system is set up to use a single Instance Request per texture for efficiency. This would mean all ParticleSpawner components will be rendered using the same InstanceRequest. (a particle entity is located in the header file of the particle_system module)
  • The resource allows choosing any texture to be used for the particle. The particle system defaults to the smoke texture for our use case.
  • The resource also allows passing a list of InstanceItems which contains the all the positions, scales, and angles of the particles.
• Instance Rendering occurs in the render_system module.
  • Initialization is handled per texture with an initial capacity of twice the maximum amount of particles that can be spawned.
  • The rendering step first converts each InstanceItem into a InstanceVertex which is then passed to the GPU for rendering.
  • The rendering step then loads the texture and renders all the particles in a single draw call.
• The ParticleSpawner component is used in the world_system module to create a smoke particle system for any fire once it is extinguished.
  • The system creates a SmokeBlock component and attaches it to a new entity with a duration.
  • The ParticleSpawner component is then attached to the entity to create the smoke particles.
  • The ParticleSpawner component is then removed after the duration has passed.

A* Pathfinding (Advanced AI)

• Implemented A* pathfinding as the slime enemy (purple slime). - If there exists a path to player, use A* search to follow the path. If no path exists to the player (blocked by fire etc.,) stay in place and wait. - The code for A* algorithm can be found in the ai_system.cpp file.