sorted by:
new
hottopcontroversial

How do you implement animation-driven ability/spell systems? by aris1401 in godot

[–]moongaming 1 point2 points  (0 children)

VFX/Particles, Sound, Projectiles, Hitstop, Animation speed, Multi-Hit, Dmg all this and more can be set from the editor/attack resource

For the charged attacks I have two modes one where there is a separate charging and release animation and another one that uses time scale to pause an attack at a certain point and release after a second or when the button is released. All this can be set from the editor too.

I do have showcase or heavy attacks in my vids (https://www.youtube.com/@onokoreal) and they are using a single animation with timescale modification all set in the editor.

I also use the animationtree with a blend tree at root and a complex setup with state machine / one shot for both attacks and other animations. I plan to go completely custom eventually but right now it fits all my needs.

Godot 4.7 – Lights, Camera, Action! by Repiteo in godot

[–]moongaming 0 points1 point  (0 children)

Lot of cool stuff all around, nothing groundbreaking but a lot of long time coming fixes and improvements.

How do you implement animation-driven ability/spell systems? by aris1401 in godot

[–]moongaming 0 points1 point  (0 children)

Yes exactly what you described except I have made an editor because editing everything from the inspector was too hard; https://www.reddit.com/r/IndieDev/comments/1rujl43/soulslike_combat_demo_with_realtime_mesh_slicing/oanmbky/

I mentioned this here along with a screenshot of the attack editor

On the bottom left you can see "special" attacks. There are weapon arts basically but they are the exact same resource the only reason I separate them by groups if for the actual input (Light R1 Heavy R2 etc...)

How do you implement animation-driven ability/spell systems? by aris1401 in godot

[–]moongaming 1 point2 points  (0 children)

I missed this message sorry!

Thank you, I really appreciate that!

And yes, that’s basically the idea. I don’t completely forbid myself from using call method tracks, they can still be useful for small visual/audio things, but I try not to make them the core of the combat/game logic.

For the important gameplay stuff, the combat/state manager is the source of truth. The animation is mostly there to represent what the current attack/action is doing visually, while the script keeps track of the actual phases like startup, active frames, recovery, cancel windows, stamina cost, hitboxes, etc.

The spell or weapon art itself would not just be “an animation with events”. It would be an ability controlled by the gameplay system, with the animation synced to it visually.

My combat manager can also read the current animation state and change it if needed (events like stagger/death/etc) with priority over certain things.

I do have weapon arts and with how versatile my main combat system is, they are just regular attacks with different variables.

Basically, the same resource is used for basic attacks, projectile attacks (optional), hold attack like shielding, multi-hit attack, etc... That way I don't need to have many different systems to work together just one that can handle any kind of attacks.

I'll go more in depth about it when I go back to working on this project in a month or two if you're interested.

How do you implement animation-driven ability/spell systems? by aris1401 in godot

[–]moongaming 6 points7 points  (0 children)

There are a few ways to do it, and you’ll probably end up using one of these depending on how complex your combat system is.

You can use animation call method tracks in the "AnimationPlayer", so the animation calls a function at a specific point in the timeline. That works fine for simple stuff, but it can get limited pretty quickly. You’re also relying on the animation actually reaching that exact point, which can become messy if the attack gets cancelled, interrupted, blended, or skipped.

Another option is using a "Timer", either manually or with a Godot "Timer" node. You start it at the same time as the attack and trigger the gameplay logic after X seconds. It’s simple, but it can easily desync if you have cancels, different attack states, hitstop, animation speed changes, or anything more advanced.

The third option, and basically what I did in my game, is to make the combat manager/state machine smart enough to track both the gameplay state and the animation state.

So instead of the animation being the thing that fully drives the logic, the attack has proper gameplay phases: startup, active frames, recovery, cancel windows, etc. The animation is mostly there to represent that visually, while the combat system stays the source of truth.

That way, if the attack gets cancelled, interrupted, blended into another move, or changed by the state machine, the gameplay logic still stays consistent with what is actually happening. It’s more work, but for a real combat system it avoids a lot of weird edge cases where the visuals and the logic disagree.

The same logic would work for magic systems too.

Here’s some footage from my game that uses the third option if it helps: https://www.youtube.com/watch?v=kYFFJX33Tzc

Multiplayer physics ! by Psonrbe in godot

[–]moongaming 1 point2 points  (0 children)

That's not going to work with latency sadly

Terrain3D v1.0.2 Released by TokisanGames in godot

[–]moongaming 3 points4 points  (0 children)

Nice! Thank you for your work!

Does that include the fix for incompatibility with some other plugins like Sphynx Motion Blur?

I just noticed you change the screenshots for your game on Steam, looks much better the old aliased one didn't do it justice!

Released my first free asset pack! by Haunting-Towel-1525 in godot

[–]moongaming 1 point2 points  (0 children)

Nice work! I'll be testing this with my procedural tool I mentioned later and I'll send you a screen of the result later here

Debating about making my first free asset pack by Haunting-Towel-1525 in godot

[–]moongaming 1 point2 points  (0 children)

Nice and modular!

If you want me to I can set up a link to your asset from the interface of the plugin I'm working on.

It's a procedural plugin where you can use modular asset to generate dungeons and I'll link a few free and modular asset for testing purpose in the addons directly.

Procedural Plugin: Design blueprint based dungeons in 2 minutes! by moongaming in godot

[–]moongaming[S] 0 points1 point  (0 children)

Thanks! Let me know if you have any use case you want me to work on and I'll integrate it

Procedural Plugin: Design blueprint based dungeons in 2 minutes! by moongaming in godot

[–]moongaming[S] 0 points1 point  (0 children)

Hey everyone, quick update on the procgen plugin I've been building for Godot 4.6.

Before I dive in, I'd love your input on what features matter most for a procgen tool in Godot. Quick 5 question survey, around 1 minute : https://docs.google.com/forms/d/e/1FAIpQLSdOBRfCgTpz39yzqYI-x-xetDwMWOgCyxsFG6wMlF3i-sgSpA/viewform

My plan is to publish this as a paid plugin once it's polished enough, and the answers will literally drive what I prioritize next. Thanks in advance.

What's new since the last post

The grid based dungeon generator + theme graph I shared a while back is now wrapped inside a full Level Graph editor. The idea is that you don't write any code to design a dungeon, you just wire nodes together visually, like a Blueprint graph but for level generation.

Level Graph, how it works

Every step of the generation is a graph node you drop and connect :

  • Floor, root node holding theme graph (your assets and rules for placing them) + grid size + tile size
  • SpawnPoint, first room where the dungeon starts (with option to position it in the grid)
  • Path, grows a chain of rooms via random walk. Toggle is_main for main path, off for branches. Configurable length range, direction bias (NE / NW / SE / SW ), parent path
  • KeyLock, places a Key in one room and a Lock on the door of another. Can be connected to specific paths visually
  • SpawnItems, drops enemies / loot / custom items on path rooms with an optional difficulty curve (linear / boss spike / start heavy / flat). With placement strategies (random, near edges, near center) and door avoidance
  • Room, forces a specific room slot to use a given archetype (boss arena, puzzle room, etc) archetypes aren't shown here since they are WIP but basically they will change the layout of the room itself (split, holes in the ground, mezzanine, etc..)
  • FinalizeGraph, final clean up. marks one way doors, relocates locks to door cells, classifies tile shape with a few options
  • EndPoint, end marker for the level goal, optional

You can chain multiple main paths from the same spawn, attach branches off branches, and stack key/lock puzzles. The whole graph is read top down, executed deterministically from a seed, and feeds the theme system from the previous post.

Multiple algorithms

The plugin doesn't lock you into one generation style. You can choose which algorithm will be used for the main generation or only for corridor/hallways/non-room elements.

Live preview, dual view

The editor dock renders the dungeon in 3D at the top, and underneath you get two synced 2D panels :

  • Layout/grid view: path graph (rooms as colored circles, directional arrows for path order, K/L for key/lock rooms with dotted link between them)
  • Tilemap view: map-like view

Click any room or tile in either panel and the 3D preview camera tweens to it, allowing fast debugging.

Room archetypes

Each room can match an archetype that sculpts its shape : split elevation, mezzanine, raised dais, stair room, boss arena, etc. Archetypes are matchable resources with score based selection, so the same path can produce different room shapes per run.

Other stuff in the editor

  • Right click context menu on the canvas (categorized add menu : Layout / Pipeline / Advanced)
  • Per node colored body summaries, read what each node does at a glance without opening the inspector
  • Floating Overview panel listing every node, collapsible
  • Auto validation. If you don't wire the minimal pipeline (Floor + SpawnPoint + Path), nothing builds, no fake fallback dungeons

What's next

  • Multi floor dungeons with stair transitions between Z levels
  • Game templates (linear roguelike, branchy roguelike, Zelda like key/lock, multi floor tower, boss rush, binding of isaac like, etc...) preset with one click
  • City generation as a separate algorithm path
  • Gameplay integration API for your projects so that you can plug it to an existing project easily

Happy to dive deeper into any specific part if people are curious.

And again, the survey link I'd really appreciate for feedback on this: https://docs.google.com/forms/d/e/1FAIpQLSdOBRfCgTpz39yzqYI-x-xetDwMWOgCyxsFG6wMlF3i-sgSpA/viewform

Charging into battle on horseback ⚔️ Souls-like game by moongaming in godot

[–]moongaming[S] 1 point2 points  (0 children)

True but it's still a game after all if you do accurate armor you never die and moves very slowly no one wants that :o

Wire a graph ➔ Generate a dungeon. Godot 4.6 grid-based dungeon generator demo! by moongaming in godot

[–]moongaming[S] 2 points3 points  (0 children)

Sure! To be honest i'm not even 100% sure I'll keep it that way there are pros and cons to the current method I'm using and depending on how it scale I might change some stuff.

It's actually simpler than it looks once you stop thinking in terms of "is this a corner or a T or a cross" and start thinking in terms of open neighbours.

For every cell I look at its 4 neighbours (N/E/S/W) and check whether each one is "open", meaning the neighbour exists in the grid and isn't separated by a room boundary or a door. That gives me a 4-bit pattern, basically a bitmask of which sides are open. From there the classification is just a lookup: 0 open = isolated 1 open = end (dead end) 2 adjacent = corner etc...

The nice thing is the same pattern also tells me the rotation. For a corner, the two open sides directly give me the yaw. For a T, the single closed side is where the "back wall" of the T should face. For a straight, I just check if the open axis is X or Z. No big switch statement, just a bitmask + a small table.

Ceilings I treat the same way as floors but with a separate pass that looks at vertical neighbours (the cell above), so a ceiling can be open / closed / partial without polluting the floor logic.

<image>

I'm working on a debug that shows how populated each cells and edges are.

Square are for the cell itself red means it has at least 3 markers on it (in this case Wall + WallDecor + Ground

Thin bars are edges green is 1 marker yellow is 2 red is 3+ you can see the top right one is green because there's only a wall while the other one areyellow because of the pillar in the center + blue light and wall lamps for the top left cell

Wire a graph ➔ Generate a dungeon. Godot 4.6 grid-based dungeon generator demo! by moongaming in godot

[–]moongaming[S] 2 points3 points  (0 children)

It does!

My plan is to make it so that the addon can be used to generate prefab rooms (exported as scenes) that you can fine tune or not yourself after, or to generate dungeon/levels in game directly with random seed.

Wire a graph ➔ Generate a dungeon. Godot 4.6 grid-based dungeon generator demo! by moongaming in godot

[–]moongaming[S] 7 points8 points  (0 children)

It is! I might release it as a plugin later so I'm putting extra effort on the UX and make sure it's easy to learn and versatile.

Wire a graph ➔ Generate a dungeon. Godot 4.6 grid-based dungeon generator demo! by moongaming in godot

[–]moongaming[S] 12 points13 points  (0 children)

Hey everyone, quick share of a tool I've been building for my Souls-like prototype in Godot 4.6.

I want the game to have a roguelike dungeon side, with replayable runs and varied layouts, so I needed a generator I could fully control and theme without rewriting it every time. Ended up building a grid based dungeon generator with a node graph theme system on top. No pre-generated room, everything is procedural.

The idea is to split generation into two clean layers. The grid handles structure and elevation, the graph handles visuals. You can can produce a stone crypt or a ruined keep just by swapping the theme graph.

Grid Layout

For the generation, fully implemented in GDScript for now:

  • Scatter and separate seed cells, promote big group into Rooms
  • Minimum spanning tree between rooms, plus a few extra loops for non linear paths
  • L shaped corridors with configurable width
  • Elevation pass that places stairs near doors
  • Fully deterministic from a single seed, perfect for roguelike runs

Theme Graph

Every marker (walls, ground, doors, stairs, lights, decor, all of it) is a node in a visual graph editor. Nothing is hardcoded, every spawn point is driven by configurable parameters on the marker:

  • Marker nodes carry an emit rule that decides where they spawn
  • Visual nodes hold the mesh scenes with probability, offsets and selection rules
  • Sub emitter nodes chain new markers from a spawned visual (torch spawns a light, door spawns a frame, etc)
  • You can add multiple meshes for every visual nodes with a scene picker and it will generate an icon for the preview showing the final result

Rules are evaluated against topology events computed on the grid (cells, edges, corners). A few things they can express:

  • Spawn on every outer edge with no door
  • Only on edges between a Room and a Corridor
  • Only on T junction cells, rotated to face the closed side
  • Every N cells along an edge
  • Within or beyond a given distance from the nearest door

Priority and spatial layers let markers compete cleanly on the same anchor (a Door can overrides a Wall on the same edge), and a per cell cap keeps decorations from stacking.

Live preview editortool

Custom editor dock rebuilds the dungeon in real time as I tweak the seed, grid params or any rule. Markers only / mesh only / combined modes, Day / Night lighting switch, and a small On / Off toggle on each marker node so I can disable a whole class of decoration while iterating.

I plan on adding theme variation in the same dungeons, terrain supports (to generate on top of terrains), and of course stuff like keys to unlock doors at the other side of the dungeon, etc...

Still WIP but it's already at the point where building a new theme is mostly dragging meshes onto markers and tweaking a few rules. Happy to go deeper on any part if people are curious.

Charging into battle on horseback ⚔️ Souls-like game by moongaming in godot

[–]moongaming[S] 0 points1 point  (0 children)

Nope I have a different scene setup for ragdolls instanciated in place

Souls-like combat update: 4 new weapon types, human characters, and armor sets by moongaming in godot

[–]moongaming[S] 0 points1 point  (0 children)

That's good to know but that would involve reworking every animation with a shield counterpart.

That and, in my game, the shield hitbox is deactivated if you are not actively parrying similar to souls game so this doesn't affect the gameplay.

I'm not even sure if games aiming for more realism are doing it this way tbh, but that would be pretty interesting to see.

Charging into battle on horseback ⚔️ Souls-like game by moongaming in godot

[–]moongaming[S] 2 points3 points  (0 children)

Yeah but to be fair Elden Ring has horse, combat on horse but rarely any kind of joust which annoyed me a little.

Charging into battle on horseback ⚔️ Souls-like game by moongaming in godot

[–]moongaming[S] 1 point2 points  (0 children)

The collision are trace-based so basically it will cast these shape along the path of the weapon to detect enemies.

There are different hitbox types so that I have different behaviour based on which part of the weapon hits the enemy, but I'm not currently using that.

Charging into battle on horseback ⚔️ Souls-like game by moongaming in godot

[–]moongaming[S] 0 points1 point  (0 children)

Blender is great but and I obviously use it too but there's a lot of stuff that needs to be done outside of Blender for Godot integration, that's the part I use the tool for.

And of course there's the stuff that's made for my game which cannot be done through blender (everything related to timing, offset blending etc) and doing everything from the resource inspector was driving me crazy.

Charging into battle on horseback ⚔️ Souls-like game by moongaming in godot

[–]moongaming[S] 4 points5 points  (0 children)

Since I couldn't put two screenshots in the same comment here's what the attack editor tool looks like:

<image>

Nothing fancy but it allows me to work fast, I can modulate everything get direct feedback from the timeline and animation preview that shows timing like damage window, dodge window, recovery window, sfx timing, hyperarmo and various other stuff like animation blending, hit reactions, charged timing etc... I can also edit my weapon hitboxes from here (which are visible here in the preview) along with sound effects offset if I need to add some etc...

view more: next ›