Arnulf against everyone!

Dev diaries
1

Hello everyone!
I don’t speak English, sorry :sweat_smile:

I decided to start a development diary for the game “Arnulf vs Everyone!” (a Brotato clone).
As the saying goes: “Better late than never” .

image
image807×587 43.8 KB

It all started with an idea: together with members of the chat Defolder, we wanted to make a game in one month. Some people joined us from other chats related to game development, directly or indirectly. The talk about why we didn’t make it and why we’re still working on it I’ll leave for another time and another post.

Today I decided to analyze the entire structure of the project and proceed in a way that won’t slow down progress or make me try to overreach. And just now I realized that I never looked at how the architecture is structured in “Brotato” or similar clones, and that seems like a mistake. At first, I tried using approaches that were most familiar to me, since I learned through examples by britzl https://britzl.github.io/publicexamples/. Later on, from talking in chats with more experienced developers, I understood that many use the ECS approach to make games. I tried to dive into that approach, but since I’m still a beginner, it was tough for me. Wiping away a Defold-tear, I listened to my peers and decided to keep working the way I understand and can handle.

In this post, I’ll try to describe the architectural approach used in this game. Maybe it’ll help other beginners who can use this diary as a guide to building a project in Defold later on.

About the chosen architectural approach

Yesterday I came across two discussion threads on the official Defold website:
https://forum.defold.com/t/what-kind-of-architecture-is-used-to-handle-the-game-logic/26537/4
https://forum.defold.com/t/game-architecture-in-defold/18404

These threads discuss recommended architectural solutions for developing games in Defold.

I decided that I will use an event-driven architecture with centralized state management, since that’s the approach I understand the best for now.

Event-Driven Architecture. This is an approach to handling game logic where components (scripts) react to events and messages, rather than relying on a strict hierarchy or data flow (like in ECS).

I will stick to two main principles:

Message Passing as the basis of communication:
Defold is designed with event-driven architecture in mind, using asynchronous message passing between objects. This ensures loose coupling between components.

Centralized data management:
Keep all game data in one place and think about how data transformations affect the current state of the game.

Example project file structure:

game_project/
├── main/
│   ├── main.collection (bootstrap)
│   └── main.script (scene manager)
├── assets/
│   ├── images/
│   ├── sounds/
│   ├── fonts/
│   └── atlases/
├── scenes/
│   ├── menu/
│   │   ├── menu.collection
│   │   └── menu.script
│   ├── god_selection/
│   │   ├── god_select.collection
│   │   └── god_select.script
│   ├── game/
│   │   ├── game.collection
│   │   └── game.script
│   ├── shop/
│   │   ├── shop.collection
│   │   └── shop.script
│   └── death/
│       ├── death.collection
│       └── death.script
├── entities/
│   ├── player/
│   │   ├── player.go
│   │   └── player.script
│   └── enemies/
│       ├── enemy1.go
│       ├── enemy2.go
│       └── enemy_controller.script
├── modules/
│   ├── game_data.lua
│   ├── god_stats.lua
│   ├── wave_manager.lua
│   └── scene_manager.lua
└── gui/
    ├── pause_menu.gui
    ├── hud.gui
    └── skill_upgrade.gui

I will use Collection Proxy for scene management, since Collection Proxy allows dynamically loading and unloading game “worlds”. I’ll use them for:

  • Scene transitions (menu → god selection → gameplay).
  • Death and shop screens (most likely, SHOP and Death will be implemented with GUI).

Core of the game:

  1. Scene Manager (main.script):
    A central controller for handling transitions between scenes, responsible for loading/unloading them.

  2. Data Modules:

  • game_data.lua – centralized storage of game state.
  • god_stats.lua – stats of patron gods.
    There will likely be separate modules for entities.

  1. Enemy Spawner:
    Spawning enemies using factories.
    Enemy behavior system:
    Each enemy gets a base script with common behavior (but how better to implement specific behaviors for different enemies without OOP?).

  2. Wave Manager:
    wave_manager.lua will manage battle waves (rounds).

Next development steps

  1. Create the basic folder structure.
  2. Implement Scene Manager with Collection Proxy.
  3. Add basic data modules.
  4. Create a simple gameplay scene with a player.
  5. Add Factory for enemies.
  6. Implement Wave Manager.
  7. Gradually add GUI scenes.
  8. Prepare a tool for testers and game designers to balance the game without my direct involvement.

That’s all for now!
Even though I’m still a beginner, I believe this post might help another beginner just like me!

12 Likes