This update introduced the core logic systems that make stories interactive. Variables, conditions, and triggers were added to the backend and integrated into the editor. These systems define how a story reacts to player input and internal changes during play.

Variables can now store values that persist throughout a story. They can be numeric, boolean, or text based. Conditions read these values and determine what parts of a story are shown or hidden. Triggers are used to start events when specific requirements are met. Together they form the base for dynamic behavior inside stories.

I also added the first version of the event system. Events are containers that hold one or more actions. Each event can be executed once or multiple times depending on its settings. This structure will later handle most of the logic inside a story, such as updating variables, changing scenes, or unlocking achievements.

Dialogue branching was added to the editor as well. Dialogue lines can now include conditions, which means responses or actions can depend on previous choices. Scene elements were also introduced as part of this update. These elements will later define what objects exist inside a scene and what can interact with them.

With these systems in place, a story can now track states, react to player input, and change its flow during play. This forms the technical foundation for all later features such as items and complex event chains.

After the account system was working, I started building the structure for stories. Each story can now contain chapters and scenes. The goal was to prepare the data model that will later be used by the editor and the player. I focused on creating and organizing stories in a way that can be expanded later without breaking existing data.

I also began working on the media system. Uploading and managing images will be required for almost everything in the app. The first version linked uploaded files directly to a user. Each element that used a file referenced it from there. It worked, but it was not ideal for shared projects.

I replaced this approach with a new one where media belongs to a story. That makes collaboration easier and keeps everything contained inside the project. Each story now has its own media space, and all files used by that story are stored there.

The first version of the editor interface is now functional. Stories, chapters, and scenes can be created and organized directly in the browser. It is still very bare bones, but it works and provides a clear view of how the editor will grow from here.

I started with the backend. The goal was to make sure the basics worked before touching anything else. I built the API and the user system first. That included authentication and account handling. I wanted it to be simple and secure from the beginning, without dealing with password resets or verification emails.

I connected everything to OAuth so users could sign in with existing accounts. Google, Twitch, Steam, and Discord were the main targets. I had to ditch Apple for now, because they require an existing website. It worked well enough, and I decided to drop traditional email registration entirely. This should keep maintenance low and reduce spam or duplicate accounts. It also makes abuse a little harder since each login is verified externally.

Next I plan to start building the editor interface. The idea is to create a place where stories can be written, organized, and tested later on. For now, that means defining how a story will be structured in the database. Chapters, scenes, dialogues, and media connections will all come later. The next steps are to design a clean editor layout and connect it with the backend so stories can eventually be created and stored.