Technical Insights from My Indie Game Development Journey

Magic Tower Game is a minimalist RPG. Despite its simplicity, it covers a wide range of systems, making it a great entry-level project. Here are some handy plugins and tools I used in my mota24 project.

LDtk

LDtk (Level Designer Toolkit) is a modern 2D level editor developed by the creators of Dead Cells. It’s a fast, free, open-source tool designed specifically for game developers. Compared to Unity’s built-in Tilemap, LDtk is more user-friendly and can also be used to configure level events.

While you can add custom fields to Entities in LDtk to configure data and logic, I personally recommend using LDtk as a simple level editor and handling logic and data outside of LDtk. This is because it can get awkward when dealing with areas LDtk isn’t strong in.

I won’t go into the basic Tilemap editing for terrain and blocking in Magic Tower. Instead, I’ll focus on how I use LDtk’s Entities for monsters and the princess.

In the image below, you can see that all monsters are individual Entities. Each monster has two fields: MonsterId, which links to the configuration table, and AnimFrames, which indicates the number of animation frames. Unity’s importer uses this frame count to read the corresponding Sprite from the atlas and generate frame animations.

For Entities that are reused a lot in levels, like monsters and items, I only configure the ID in LDtk. When importing into Unity, the corresponding script is automatically bound, and data like monster attributes are configured via Excel, linked by ID.

However, there are many NPCs in Magic Tower. NPCs are unique, each with their own dialogue and logic, and are linked to other Entities in the level.

As shown in the image, the princess has three fields: Script, which corresponds to the Unity script name (bound via reflection), TargetStair, which links to a staircase (this staircase needs to appear after talking to the princess), and AnimFrames, which indicates the number of animation frames.

LDtk to Unity supports Custom Post Processing. In the post-processing, I bind the corresponding script based on the Entity’s properties. Different scripts read the Entity’s fields as needed.

The advantage of this approach is that I don’t manually modify the content imported from LDtk. All changes are done in the post-processing script. This way, after modifying the level content in LDtk, I can switch back to Unity, wait for the import to finish, and run the game directly without extra handling, reducing operational errors.

Luban

Luban is a powerful and easy-to-use game configuration solution designed to handle complex configuration workflows in game projects. It supports various file types (like Excel, JSON, XML) and export formats (like binary, JSON, XML), and is compatible with major programming languages (like C#, Java, Go, C++). Luban offers rich data validation features and excellent cross-platform capabilities, supporting Unity, Unreal, Cocos2d-x, Godot, and more. It also has a clear and elegant generation pipeline design, making it easy for developers to customize and extend.

Over the years, I’ve tried many different data configuration solutions and hit many pitfalls. Now, I only use plain text formats (like JSON) or Excel. I don’t recommend using visual configuration methods like ScriptableObject, writing your own Editor windows, or similar plugins.

The main reasons I chose Luban are its support for complex types (lists, classes), data validation, enums, and code generation.

As shown in the image, this is the bean table for mota24 (think of it as an object-oriented class definition). After exporting the table, corresponding C# code is generated, which is very handy and ensures consistency between the configuration table and the code.

This is the enum definition table.

This is the item table, showing how complex types are configured. It might look confusing at first, but it’s actually very intuitive once you get used to it.

Luban offers various ways to configure complex types, so you can choose based on your preference: Luban documentation.

Drawbacks of Luban The main drawback of Luban is its steep learning curve. The documentation is clearly written by programmers, full of technical theory, which can be tough for non-technical folks. I hope the official team can improve the documentation, add more example projects, and streamline the usage process.

Yarn Spinner

Yarn Spinner is a friendly dialogue writing tool designed for game developers. It allows writers to create interactive dialogues in a screenplay-like format and seamlessly integrate them into games. Yarn Spinner offers rich features, including dialogue display, player choice options, and commands to affect events in the game scene. It is compatible with major game engines like Unity and Unreal, greatly simplifying the development of dialogue systems.

For dialogue configuration, I hold the same view as for data configuration: it’s best to use plain text. This is much more convenient than visual dialogue configuration tools. Visual tools usually represent dialogues with nodes and connections, which look intuitive but often can’t perfectly meet the needs when the configuration demand grows. For example, features like regex-based text search and replace, multi-line editing, and multi-language support. Text-based configuration doesn’t have these issues; as long as you’re familiar with an IDE, you can efficiently handle text, saving the learning cost of tools (the more features a visual editor has, the higher the learning cost). Of course, this is just my personal recommendation; everyone should choose based on their habits.

Magic Tower’s dialogue requirements are not simple. The image below shows the dialogue of the mysterious old man on the 15th floor, involving condition checks, dialogue branches, reading and writing game data, and calling game functions.

Yarn Spinner’s advantage is that writing dialogue is like writing a novel. You don’t need to frequently use the mouse; you can just write text line by line. VSCode has a plugin that can validate syntax and check the use of custom functions exported by scripts, so you don’t have to worry about making mistakes.

Conclusion

These three tools are all new to me, so my usage might not be very professional. If you have better suggestions, feel free to share. These tools have been a great help for this project. If I had chosen to make the tools myself, the mota24 project would probably have been hard to complete within a month.

These tools also meet my criteria for good tools: text-based (LDtk is entirely JSON-based, so you can theoretically edit its JSON files directly), not tightly coupled with the engine, adaptable to different engines, or usable with self-developed engines.