Point and Click - architecture or not

Over the past three months, I've been stuck in what feels like a never-ending cycle of prototyping, trying to create an engine that is user-friendly for a game designer like me.

I've noticed that my way of thinking often differs from that of software engineers, despite having a SE degree and the ability to develop frontends, backends, and smart contracts. When I discuss problems with my friends, we approach them from quite different angles.

In most cases, I realize that my approach is not optimal, so I have to change my thinking and adopt a "proper" approach to find the best solution.

However, this time I wanted to build something that suited my needs. I wanted a simple way to convert my game system blueprint into actual code. This journey took me though three versions, although I wouldn't call them iterations since they were three distinct approaches built with the same tools.

In retrospect, it seems like these versions were more like regressions than progressions. I initially approached the project as a proper software engineer, focusing on architecture, optimization, and clean code. The first version had a well-structured architecture, with a database layer accessible through readers and writers. The backend aggregated information and created a state based on event-driven architecture, which was then presented to the frontend in a readable format.

It was a solid version, but it didn't suit my specific use case. I wanted to take a snapshot of the game state and display it without transforming the entire state into proper database entries just to maintain cleanliness. It was a version designed with software engineering principles in mind, but it wasn't user-friendly for game designers.

For the second version, I decided to eliminate the database layer and work directly with JSON. This made it easier to obtain a snapshot of the game state, but modifying it became a nightmare, especially with the limitations of node.js. I had to rely heavily on indexes, and any changes to one element of the game had to traverse the entire tree.

The third version is perhaps the strangest one. It doesn't have a backend at all. Instead, it follows an event-driven architecture approach using an events array on frontend. Each object on the screen uses its own "onDraw" function to set itself in the correct state based on the content of the event array. Is it optimal? Definitely not! However, it makes it incredibly easy to add scenes, objects, and interactions, as their states are influenced solely by the events. From an architectural perspective, it's just a huge set of objects with no connections between them. From an end-to-end testing standpoint, it's an even bigger problem because there's no true end-to-end flow—you either have an event to react to, or you don't. But as a game designer, I can take my objects and actions, align them, and get the game into the exact state I need.

Although I realize I might need to incorporate some backend functionality, as keeping the event history in the session is not the best idea.

But it worked and the game is playable. It also has some AI-generated art for now, so I just need to upload the rest 80 scenes with all the popups and items and actors in them to complete it. What can go wrong?