MizGodotTools is a personal Godot code library, published as a toolkit

One developer's working code, released early

The repository describes itself plainly, a collection of code and tools the author uses in a lot of his games, released under the MIT licence with an invitation to use it in your own games. That framing is worth holding on to, because it tells you what kind of artifact this is. It is not a framework with a maintainer answering issues, and it is not a plugin with a versioned API. It is the accumulated scaffolding of one developer, published so that other people can start from it, and the reason it is worth reading is that the code has been shaped by being used in shipping games rather than by being designed in the abstract. The name in the repository, MizGodotTools, and the icon file in the tree, `mistools_icon.png`, carry the same prefix, so the project is a personal toolkit with a name rather than a generic collection. The primary language is recorded as GDScript, and the repository includes a `project.godot` file at the root, so it opens as a Godot project rather than as a folder of loose scripts.

Group names are a contract between the pieces

The first convention the README states is a set of group names, and it is the mechanism that lets the code find the objects it needs. The group `serializable` is for objects that are saved and loaded, so the save system knows which nodes in a scene have to be written to disk and restored. The group `instanced` is for objects that are instanced and need to be cleared on scene changes, which is the mechanism for a spawner, a projectile or a temporary effect that must not survive a level transition. The group `player` is for the player character. Three names, and every script in the collection depends on them, which means the first thing you do with this repository is copy the naming into your project rather than to use it as a drop in. It is also the thing most likely to irritate you if you have your own conventions, because a system that looks for a node in the group `player` will not find it in a group you named `PlayerNode`. The cost of adopting it is small and the cost of not adopting it is that the scripts have to be edited one by one.

The physics layer numbering is fixed and shared

The second convention is the physics layer numbering, and the README lists it exactly. Layer 1 is environment, layer 2 is characters, layer 4 is hitboxes, and layer 8 is items. The numbering is not consecutive, and that is the point, because it leaves room to insert a layer later without renumbering everything above it. It also encodes a small bit of scene design in the numbers themselves, since the hitbox layer is separated from the character layer, which is what lets a bullet detect a player without the player detecting the bullet, and an item layer separate from both. If you are coming from a project where everything is on the default layer, the difference will be visible immediately in how much you have to think about what can hit what. As with the group names, the numbers are only a convention, and the code in the collection assumes them, so adopting them is close to mandatory rather than optional.

Three global managers carry the state

The globals section names three, and they tell you the scope of the collection. `SaveManager` handles persistence, which is the piece most projects write first and get wrong, since saving a scene means deciding what to write, where to write it, and how to restore it without duplicating objects that already exist. `LevelManager` handles level transitions, which in a 2D game usually means scene loading, a transition effect, and knowing which level the player is in so a continue button can work. `AchievementManager` handles achievements, which is a system most hobby projects do not have and that becomes useful the moment the game has a progression loop. In the tree these appear as `globals/` alongside a top level `achievements_manager.gd` with its resource UID file. The naming convention of singleton globals is standard Godot practice, and the choice to make these three the backbone of the toolkit tells you the author's games are 2D games with progression, which matches the example scenes in the next section.

The example scenes are the documentation

The README's second half is a list of example scenes, each with a link to a short video, and the list is a better feature index than any prose would be. There is a drop shadows scene, `drop_shadows_examples.tscn`, and a pseudo 3D with drop shadows scene, `pseudo_3d_objects_examples.tscn`, which is a technique for making 2D sprites look like they sit in a 3D space. There is an IK and procedural animations scene, `ik_examples.tscn`, covering inverse kinematics and procedurally generated movement. There is a weapons, bullet and blood effects scene with a health manager, `weapon_damage_and_blood_examples.tscn`, which is a combat slice. There is an NPC vision scene, `npc_vision_example.tscn`, and a top down movement system, `top_down_player_example_scene.tscn`. Then the systems, with `save_load_scene_1.tscn` and `save_load_scene_2.tscn` for the save system, three test level scenes, a settings menu with key rebinding and UI sound effects, and an inventory and items scene. Each one is a self contained demonstration you can open and run, which is the format Godot developers expect from each other.

The tree shows the scope of the collection

The top level listing gives the inventory of what is in the box, and the directory names are a good summary of the systems on offer. There is `input/` for the input handling, which is where the key rebinding in the settings scene lives, and `localization/` for translations, which matters for a collection meant to be reused across projects with different languages. There is `menus/` for the user interface, `items/` and `inventory/` for the item and inventory system, `effects/` for the visual effects, `characters_utility/` for the shared character code, and `sfx_utility/` for the sound effect handling. At the root there is `achievements_manager.gd`, a `default_bus_layout.tres` resource, and the Godot project file. The audio bus layout is worth a second look, because the README names the three buses the collection expects, Master, Music and Sfx, and the `.tres` file in the tree is what defines them. That is the third convention, and like the other two it is a small decision that has to be shared across every scene, which is exactly the kind of thing a shared toolkit exists to standardise.

Licence, releases and how to use it honestly

The README is explicit that the collection is under the MIT licence and that you are free to use it in your own games, and the repository carries the LICENSE file at the root. Beyond that there is no packaging story. There are no GitHub releases, so there is no version to pin, and the last push to the repository was on 2026-07-20, which is recent enough to say the code is alive and old enough that a project starting today would want to read it rather than trust it. The absence of releases is normal for this kind of repository, since the intended use is copying the files into your project and then owning them, and the version that matters is the one in your own repository afterwards. The practical route is to open the project, run the example scenes to see which parts you need, copy those directories into your own project, adopt the three conventions deliberately, and delete the rest. What you get then is code you own, which is both the appeal and the maintenance cost.

Editorial conclusion

MizGodotTools suits a Godot developer starting a new project who wants a working save system, a level manager, an inventory and a set of scene conventions instead of writing them from scratch, and it suits a developer who prefers to read someone else's working code than to design the same patterns again. It is a poor fit if you need a maintained library, because there are no releases and the last push to the repository was on 2026-07-20, and it is a poor fit if you want a plug and drop package, since the code is written to sit inside a project with a particular group layout and a particular physics layer numbering. Before you take it, check three things: that you are willing to adopt the conventions as they are, since the group names, the layer numbers and the audio buses are what make the pieces fit together, which Godot version you are on, since the project file and the resource UID files in the tree point at a recent Godot, and the licences, where the repository is MIT and says so plainly in the README.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Miziziziz/MizGodotTools on GitHub
4. README