What it is and why
Egmatic is a modern editor and toolset for making your own 2D games. It is written in C# and built on two cross-platform frameworks: Avalonia for the interface, MonoGame for the engine.
Why
Visual editors on the market fall into two camps.
The first camp is tools locked to one genre. They do their one thing well and nothing beyond it. You want a platformer? Sorry, this one only makes role-playing games. Or only adventure games. The genre decides everything: which objects you can create, which properties they have, which logic is available.
The second camp is general-purpose engines. Powerful and flexible, but they often require programming skills, or a long study of a complex interface. The distance from "I want to make a game" to "something is running on my screen" is measured in months.
Egmatic sits between the two. It is a visual editor with no genre lock and no programming requirement, a tool where an idea reaches a working prototype in weeks, not months.
How it works
Egmatic has no predefined object types. There is no built-in "hero", "enemy" or "item". The starting point is an empty object, and it becomes anything you need through behaviors.
Want a character? Add the sprite, physics and jumping behaviors. Want a collectible coin? Sprite and collision shape. Same mechanism, different set.
Where do behaviors come from? From extensions. An extension is an add-on that brings its own object types, behaviors, conditions and actions for the visual script.
The editor itself does not know what the properties mean, what "mass" or "health" is. It displays them by the schema from the extension: a number becomes a numeric field, a color becomes a color picker, an object reference becomes a dropdown list. The meaning of a property appears only when the game runs.
RPG mechanics, for example, are not part of the editor. They are a separate extension. You install only what your genre needs.
Game logic is defined in event sheets. An event sheet is a visual script with simple if/then/else rules. You write no code, and you still get nesting, loops and for-each iteration.
More on how it works in the next post.
What already works
The project stands on a modern base: .NET 9, a cross-platform interface on Avalonia, a game engine on MonoGame.
Working today:
- Object system. Creating objects, attaching behaviors, setting properties.
- Extension system. The extension manifest, the catalog of types, registration of behaviors with their property schemas.
- Scene editor. Layers, object placement, tile maps.
- Event sheets. Rules with conditions and actions, nesting, and/or/not logic, rule kinds (repeat, while, for each, else).
- Animation editor. Animation definitions, frames, playback.
- Extension editor. Creating and setting up extensions, behaviors, property schemas.
- Camera. A composite behavior with smooth follow, auto-panning and bounds.
The editor and the engine are two parts of one product. The editor creates the data, the engine runs it. Between them sits a shared foundation: expression evaluation, error handling, data contracts. Because of that, engine messages and errors from a test run land right in the editor, ready for further analysis.
Where it's going
The nearest steps are to finish the basic set of editors:
- Camera. Integration into the editor.
- Variables and sounds. Finishing the basic editors.
- Tile drawing. Brush, fill, erase.
- Physics and collisions. Built-in behaviors.
After that, the goal is to build the shortest possible path from a finished project to a published game. The market has many tools that help you make a game, and few that help you release one. The distance from the first working prototype to a published game with first players and first metrics is measured not in hours but in months of manual setup.
Egmatic is meant to shorten that path:
- Publish-ready templates. Not demos: complete starting points with build profiles already connected.
- Step-by-step export. One flow from project to a finished game for the platform you need.
- A checklist before publishing. No step gets skipped on the way out.
- Analytics and feedback. After release, the developer sees what is happening with the game.
The strategic goal is an ecosystem of extensions where genre mechanics are built by the community. Role-playing games, platformers, puzzles, visual novels, strategies: each genre as a separate extension, installed in one click.
Why Boosty
This is where I keep an open development diary: the process, architecture decisions, early builds. Things that will not make it into the public channels. The paid tiers get the raw material: GIFs straight from development, early builds.
Boosty is not only a diary for me. Every paying subscriber is proof that the product is needed. Likes, follows and stars are interest. A paying subscriber is a decision. They took out the card, typed in the details, pressed the button. That is a different kind of signal.
For a project at an early stage this is the most valuable evidence there is: people pay for a tool that is not publicly available yet. Subscribers see the product before anyone else and influence what it becomes.
If the idea of an approachable 2D tool that is not locked to a genre speaks to you, welcome.
egm
gamedev
indie games
game engine
no-code
2d
devlog
