Malevolent Planet Unity2d Day1 To Day3 Public Fixed ›

This report outlines the development and release status of the Malevolent Planet 2D project, focusing on the public releases covering the narrative timeline from Day 1 to Day 3. Project Overview

Malevolent Planet 2D is an adult-oriented sci-fi adventure game developed in Unity. The project features a mix of exploration, dialogue-heavy narrative, and illustrated/animated scenes. Recent efforts have focused on "The Reassembly," a significant structural overhaul to consolidate the game's episodic content into a cohesive build. Public Release Content: Day 1 to Day 3

The public build covering the "Day 1 to Day 3" arc is a milestone release that allows non-patrons to experience the early-to-mid-game content, including major story beats and mechanical fixes.

Day 1 Content: Focuses on the initial crash-landing, exploration of the alien environment, and meeting the core crew members.

Day 2 Content: Includes the "Classroom" update, which introduced NPC interactions, 6 new scenes (5 illustrations, 1 animation), and a dedicated map for the academy/classroom setting.

Day 3 Content: Covers critical plot developments including "Day 3.1 G-test Gone Wrong" and "Day 3.3 Blackmail Letter Part 1". Technical Fixes and Optimizations

The "fixed" public builds specifically address stability and performance issues encountered in earlier episodic releases.

Critical Inventory Bugfix: A known source of soft-locks and crashes, the inventory system was overhauled and, in some versions, temporarily disabled to ensure game stability during the Day 3 narrative flow. malevolent planet unity2d day1 to day3 public fixed

Performance Optimizations: Integration of three new quality settings to support a wider range of hardware.

Memory Management: Significant changes to CPU usage and memory allocation to prevent "out of memory" errors during high-resolution scene transitions.

UI Enhancements: Added Quality of Life (QoL) features such as Auto Play, Skip, and Hide buttons for dialogue sequences. Feature Summary Update/Status Animation

1-2 new animations per major sub-day (e.g., G-test, Blackmail). Illustrations

HD resolution art enabled for all scenes in the April 2025 build. Maps Forest, Lakeshore, Classroom, and Simulation Room. Platforms Android, Windows, MacOS, and Web/Browser. Project Direction

The developer is currently shifting focus back toward the "main story plot," which involves repairing the ship to escape the planet, following a period of "lack of direction" where development focused heavily on side-content and open-world village elements. Malevolent Planet 2D - Day3.1 G-test Gone Wrong | Patreon

This essay assumes “Malevolent Planet” refers to a 2D game where the planet (or environment) actively works against the player (e.g., shifting gravity, hostile terrain, or a corrupted world core). This report outlines the development and release status

Day 3: Public Fixed Variables – Clarifying Intent

Goal: Final polish—add public and const or readonly where appropriate, and demonstrate a complete malevolent cycle (day/night hazard, ground corruption).

Key Concept – Distinguishing public from fixed:

  • public → Inspector exposure, runtime tuning.
  • fixed (as in FixedUpdate) → physics timing.
  • C# fixed keyword (rare) is unrelated; here we mean “fixed timestep.”

But a common confusion: a public fixed variable doesn’t exist in C# (you can’t declare public fixed int x; outside unsafe context). Instead, Day 3 clarifies that public variables are for designers, while FixedUpdate is for stability. Additionally, use const or static readonly for truly unchanging malevolent constants.

Final Script – Full Malevolent Planet System:

using UnityEngine;

public class MalevolentPlanetCore : MonoBehaviour
[Header("Gravity Tuning (Public)")]
public float gravityIncreasePerSecond = 0.3f;
public float maxGravity = 12f;


[Header("Hazard Spawning (Public)")]
public GameObject hazardPrefab;
public float spawnInterval = 2f;
public float spawnRadius = 5f;
[Header("Planet Corruption (Fixed Timestep)")]
private float gravityTimer;
private float spawnTimer;
// Private constants (not public, never change)
private const float BASE_GRAVITY = 2f;
private Rigidbody2D playerRb;
void Start()
playerRb = GameObject.FindGameObjectWithTag("Player").GetComponent<Rigidbody2D>();
    playerRb.gravityScale = BASE_GRAVITY;
    gravityTimer = 0f;
    spawnTimer = 0f;
void FixedUpdate()
// 1. Malevolent gravity increase (fixed timestep)
    gravityTimer += Time.fixedDeltaTime;
    if (gravityTimer >= 1f) // Once per second
if (playerRb.gravityScale < maxGravity)
            playerRb.gravityScale += gravityIncreasePerSecond;
        gravityTimer = 0f;
// 2. Spawn hazards (fixed interval)
    spawnTimer += Time.fixedDeltaTime;
    if (spawnTimer >= spawnInterval)
SpawnHazard();
        spawnTimer = 0f;
void SpawnHazard()
Vector2 spawnPos = (Vector2)transform.position + Random.insideUnitCircle * spawnRadius;
    Instantiate(hazardPrefab, spawnPos, Quaternion.identity);

Why this is the final form:

  • Public variables (gravityIncreasePerSecond, spawnInterval) allow level designers to adjust difficulty without touching code.
  • FixedUpdate guarantees that gravity steps and hazard spawns align with physics, preventing double-spawns or skipped gravity changes on laggy devices.
  • No misuse of fixed keyword – clarity of terminology.

Quick troubleshooting tips

  • Persistent NullReference: use defensive coding and log with context (which object, scene).
  • Physics jitter: ensure consistent FixedDeltaTime, move physics in FixedUpdate, avoid modifying Transform directly when using Rigidbody2D.
  • Audio not playing in build: check AudioMixer snapshots, address platform-only mute settings, confirm audio file compression and load type.
  • Large build size: atlas sprites, reduce unused assets, use addressables and sprite packing.

Proven Day 3 Survival Tactics

  1. Burn resources preemptively. The malevolent meter drops by 10 points if you destroy your own structures (sacrificing progress to calm the planet).
  2. Use the high ground – Unity 2D’s sorting layers now correctly handle elevation. The Lithovore cannot jump more than 8 units vertically.
  3. Craft at least 5 healing salves (herb + water + clay). The public fixed build ensures clay spawns near all water tiles on Day 3 morning.

Day 2: The Resource Corruption Glitch

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.

The Fix (Public Build v1.0.3):

  • Rewrote the item data persistence using JsonUtility instead of binary formatting.
  • Added a one-time migration script for existing save files (preserving player progress).
  • Fixed the OnTriggerEnter2D check so only crystals exposed to active malevolent fog turn corrupted.

Result: Players can now actually survive to Day 3 without cheating.

4. Day 3: The "Public Fixed" Phase – Serialization & Persistence

The phrase "Public Fixed" in the tutorial title usually implies a correction of common Unity serialization errors. This section covers the deepest technical hurdles in the series: Saving and Loading.

3.1 Decoupling Data from Logic

The tutorial introduces ScriptableObjects to define characters and events. The Architecture: Day 3: Public Fixed Variables – Clarifying Intent

  1. Data Container: A ScriptableObject holding Dialogue lines, sprites, and event flags.
  2. Logic Controller: A MonoBehaviour that reads the data and renders it to the UI.

Why this matters: This separation allows a developer to create 100 different planet exploration events without writing a single new line of C# code. The "Deep" realization here is that the code becomes an engine for reading data, rather than the game itself.

What Was Broken Before?

In the initial public release, Day 1 was either trivial or instantly fatal due to:

  • Random spawns of acid geysers within 5 units of the landing pod.
  • Oxygen recyclers requiring power cells that didn’t drop.