I Changed My Core Mechanic (and no one will notice) - Nectar Devlog 11

Nerd Chomp
29 Jan 202410:14
EducationalLearning
32 Likes 10 Comments

TLDRThe developer Chris explains how he overhauled the core nectar mechanic in his puzzle platformer game. Previously, the nectar system was messy and difficult to manage, with collision spheres and material parameters that often conflicted. Chris separated the collision and visual aspects, created a nectar manager to dynamically assign slots, and streamlined updating only active slots. The new system is more flexible, allowing easy nectar instance creation without multiple child actors. This will save significant time as Chris continues developing his sunflower protagonist game.

Takeaways
  • 😀 The nectar mechanic was one of the first things added to the game, but was set up poorly originally
  • 👾 The old nectar system had two components - a functional collision-based part and a visual material-based part
  • 🌱 The visual part used sphere masks to control material properties inside the nectar radius
  • 🐝 Storing nectar data in the material parameter collection caused issues with nectar instances overriding each other
  • 🍯 Creating multiple child actors with different parameter names worked but was cumbersome to manage
  • 🎮 The new system separates the collision sphere into its own actor that can be spawned/destroyed as needed
  • 💡 A nectar manager blueprint sequentially assigns nectar instances to parameter collection slots
  • 🌈 Unused collection slots are kept at default values rather than being updated unnecessarily each frame
  • 👍 The new system allows flexibility without needing multiple child actors for each nectar type
  • 🔜 Additional improvements to the system are possible if more collection slots are needed
Q & A

  • What was the core mechanic in the game that was changed?

    -The core mechanic that was changed was the nectar system. This controls the ability to grow and shrink plants to solve puzzles in the game.

  • What were the two main parts of the old nectar system?

    -The two main parts were: 1) The functional part with collision spheres to activate plant growth/shrinking. 2) The visual part using sphere masks to control plant transparency/coloring.

  • What issue occurred when multiple nectar actors tried to update the material parameter collection?

    -They would override each other's data since they were saving to the same slots. So only one sphere mask would be visible at a time as they overwrote each other.

  • How was the issue of multiple nectar actors initially solved?

    -Multiple child actor blueprints were created with different default naming for the material parameters. This allowed them to save to different slots without overriding.

  • What were some problems with having multiple child actor blueprints for each nectar type?

    -It was cumbersome to manage manually. Also duplicating the same child actor would still cause overriding issues, so levels had to be designed carefully around this limitation.

  • What are two changes made in the new nectar system?

    -1) The collision spheres were separated into their own actor and spawned/destroyed as needed. 2) A nectar manager was created to automatically assign material parameter indexes and update them.

  • How does the nectar manager assign indexes to new nectar instances?

    -It searches through a boolean array marking used slots. It assigns the new nectar to the first unused index, incrementing dynamically as new instances are spawned.

  • How does destroying nectar actors work with the new manager system?

    -The manager unassigns the index and resets the location/radius values. This leaves gaps in the index array that get reused efficiently later.

  • How is unnecessary processing of inactive nectar data avoided?

    -The manager tracks the highest index in use and only updates indexes less than or equal to that value each frame. Inactive ones remain unchanged.

  • What flexibility does the new system provide compared to the old one?

    -Many instances can be handled dynamically without needing multiple pre-defined child actor blueprints. Level design is also easier without override limitations.

Outlines
00:00
🎮 How the core nectar game mechanic worked originally and its issues

The paragraph explains the original nectar mechanic in the game. It had a functional part to grow/shrink plants using collision spheres and a visual part to show the nectar sphere using a mask. Issues were overriding data between spheres and difficulty managing multiple child actors for different nectar types.

05:01
👾 New nectar mechanic system to allow flexibility and optimization

The paragraph describes the new nectar system. Separated collision from visuals, made a general material parameter for nectar, and created a nectar manager to automatically assign sphere indexes and optimize updates. Demonstrates the manager working to assign and free up nectar sphere slots.

Mindmap
Keywords
💡core mechanic
The core mechanic refers to the main gameplay element that the player interacts with in the game. In this case, it is the nectar system which allows the player to grow plants and solve puzzles. The developer changed how this core mechanic works by separating the collision sphere from the nectar actors and introducing a nectar manager system to handle assigning nectar instances.
💡collision sphere
The collision spheres are invisible spheres around the nectar which grow/shrink plants when they overlap. They were originally part of each nectar actor but are now separate actors that get spawned only when needed. This helped solve issues with unintended nectar activation.
💡material parameter collection
This allows communication of sphere mask data like location and radius from blueprints to materials. The developer stores this data in array indexes which get assigned dynamically by the nectar manager.
💡sphere mask
The sphere mask controls visual aspects like transparency and shading within its radius. It requires location and radius data from the material parameter collection. Originally each nectar type had its own mask but now there are generic masks handled by the manager.
💡nectar manager
This new blueprint system manages nectar instances by assigning them array indexes and updating the locations/radii in the material collection. It eliminates the need for multiple child actors and allows flexibility in spawning nectar.
💡array
The manager stores nectar data in arrays which get updated each frame. By tracking the max index in use, it limits updates only to occupied slots to optimize performance.
💡radius
The radius determines the area affected by the collision sphere and visual sphere mask. The manager blueprint stores and updates these radii for all active nectar instances.
💡location
The location tracks the position of each nectar instance, allowing the collision and visual elements to follow the nectar actor correctly. This location data gets saved and updated in the manager's arrays.
💡overlap events
These allow detecting when the nectar collision sphere overlaps with other actors like plants, triggering functionality like scaling plants when they interact with nectar.
💡child actors
Originally, the developer created separate child actor blueprints for each nectar type to avoid overriding in the material collection. The new system eliminates this need for multiple child actors.
Highlights

The study proposes a new theoretical framework for analyzing social media discourse during crisis events.

The methods involve collecting a large dataset of tweets during Hurricane Sandy and applying natural language processing techniques.

Key findings show that social media facilitated rapid information diffusion and helped coordinate disaster response.

The results highlight the importance of social media for building situational awareness during crises.

The paper provides novel insights into how microblogging platforms like Twitter are used for sharing critical information in times of emergency.

The research has significant implications for crisis communication and emergency management practices using social media.

The study analyzes the content and themes of tweets during the crisis to understand information sharing patterns.

The authors identify key topical categories like reporting damage and outages, coordinating relief efforts, sharing news, and expressing emotions.

The research methodology provides a useful framework for studying social media crisis communication at large scale.

The findings reveal how Twitter facilitated the rapid spread of situational updates during the storm's impact and aftermath.

The paper makes an important contribution to crisis informatics theory and social media analytics methods.

The results have practical implications for emergency services agencies aiming to leverage social media for disaster operations.

The authors provide quantitative evidence about how Twitter supported information diffusion and collective sense-making during the hurricane.

The study offers new insights into user behavior and community interaction on social media during crisis events.

The findings reveal the interplay between social media discourse and on-the-ground disaster response activities.

Transcripts

Browse More Related Video

I Paid Fiverr Game Developers to Make the Same Game

Trying To Act Normal for 30 Years | Living With Autism | Full Documentary

How to Improve at Crosswords - 29 July 2021 New York Times Crossword

Can You Develop Games as a Hobby After Work?

Adding New Weapons to my Game!

My 10 YEAR Indie Game Development Journey

Rate This

5.0 / 5 (0 votes)

Thanks for rating: