Goal: Establish core planetary hostility—e.g., gradual gravity increase or periodic ground shakes.
Key Concept – public variables:
By declaring variables as public, they appear in the Unity Inspector. This allows designers to tweak values without recompiling scripts. For a malevolent planet, hostility must be adjustable: too weak feels passive; too strong feels unfair.
Example Script – PlanetMalice.cs (Day 1):
using UnityEngine;public class PlanetMalice : MonoBehaviour public float gravityIncreasePerSecond = 0.5f; public float maxGravity = 15f; public float shakeIntensity = 0.2f; public float shakeInterval = 3f;
private Rigidbody2D playerRb; private float originalGravity; private float shakeTimer; void Start() playerRb = GameObject.FindGameObjectWithTag("Player").GetComponent<Rigidbody2D>(); originalGravity = playerRb.gravityScale; shakeTimer = shakeInterval; void Update() // Increase gravity over time (malevolent pressure) if (playerRb.gravityScale < maxGravity) playerRb.gravityScale += gravityIncreasePerSecond * Time.deltaTime; // Periodic shake shakeTimer -= Time.deltaTime; if (shakeTimer <= 0f) ShakePlanet(); shakeTimer = shakeInterval; void ShakePlanet() // Apply random offset to planet sprite or camera transform.position = (Vector2)transform.position + Random.insideUnitCircle * shakeIntensity;
Why public matters here:
On Day 1, the developer can adjust gravityIncreasePerSecond from 0.5 to 0.2 (easier) or 1.0 (nightmare mode) directly in the Inspector. shakeIntensity and shakeInterval are also exposed. Without public, these values would be hardcoded, requiring script recompilation for every balance test.
Limitation discovered: Using Update() for gravity changes ties hostility to frame rate. On a fast PC, gravity increases more frequently per second? No—Time.deltaTime corrects for that. But a bigger issue: physics interactions (jumping, sliding) become inconsistent if gravity changes mid-physics step. This leads to Day 2.
Day 3 is where the malevolent planet distinguishes casual survivors from veterans. In the day1 to day3 public fixed build, Day 3 includes a scripted “Planetary Wrath” mini-boss: The Lithovore. malevolent planet unity2d day1 to day3 public fixed
The public shader used _Time incorrectly, causing a flicker on Day 3.
Solution: In your MalevolentGlow.shader, replace all _Time.y with frac(_Time.y) to prevent overflow.
A. Day/night cycle stops
if (timeOfDay >= 1f && currentDay == 1)
currentDay = 2;
timeOfDay = 0f; // Reset after day change
B. Enemies not spawning on Day 2
if (enemySpawner == null)
enemySpawner = FindObjectOfType<EnemySpawner>();
A. Boss doesn't appear
if (currentDay == 3 && !bossSpawned)
SpawnBoss();
bossSpawned = true;
B. Game doesn't end after Day 3
Here is the exact fix deployed by the community patch group. If you are reading this, you no longer have to scrap your project.
The Problem:
By in-game Day 2, players need to gather stabilized crystals to craft protective wards. But a logic error in the Inventory2D system was marking all crystals as corrupted on pickup. This made progression impossible unless you restarted.
Worse, the public bug reports showed the issue was 100% reproducible on Linux builds but rare on Windows. Classic cross-platform serialization bug. Goal: Establish core planetary hostility—e
The Fix (Public Build v1.0.3):
Result: Players can now actually survive to Day 3 without cheating.