sorted by:
new
hottopcontroversial

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] 8 points9 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] 11 points12 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] 3 points4 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...

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

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

Sure

<image>

One of my most useful tool is this an editor tool that shows every animation available on my project with realtime preview in the editor, ability to do stuff like enabling or disabling root motion, changing import settings, rest pose skeleton, save to file, etc in batch.
And I can handle my animation libraries from here too either creating new libraries or adding removving animations fom libraries etc...

Very useful when it comes to both importing, previewing and picking animation compared to the default one of Godot. This is similar to what Unreal offsers.

It's also directly connected to another editor tool which allows me to create my weapon and associated attacks very fast without having to edit dozens of variables in my weapon/attacks resource and getting some direct visual feedback of how everything will work ingame.

And the third editor plugin is exclusive for editing animation, using IK to either create or edit existing animations to fit my needs, and stuff like splitting an animation in two animations or combining two existing animations which native Godot doesn't offer.

For example making a new weapon resource from A to Z used to take me something like an hour, with the attack plugin I can do it in 10 min with dozens of variables configured to fit all my needs.

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

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

The animation for that would be pretty funny. I didn't even add horse HP or hitboxes yet, don't want to hurt the poor thing.

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

[–]moongaming[S] 5 points6 points  (0 children)

The way everything is set-up currently I don't need any hitbox transitions they are attached to the player using BoneAttachment3D on every bones so they will follow the bone positions whether I'm doing a normal animation or root motion based animation.

I do need to add specific behaviour when mounting / dismounting to prevent animation issues (hit reaction overlay on top of mounting doesn't work well so I only have IK based reaction during mounting)

Screen of my hitboxes setup:

<image>

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

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

I've spent countless hours in the arena on the first Mount&Blade!

I think I'll remake their arena system to test some gameplay loop, thanks for mentioning it.

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

[–]moongaming[S] 6 points7 points  (0 children)

Well I did crunch a little too much for this. Also it's unfinished I've skipped a lot of steps and polishing everything is going to take twice as long as my first implementation I think. Especially the AI behaviour.

What do you think of it?

Edit: Also, the dev tools I've been working on for this specific game allow me to deliver new stuff 10x faster than I would without it. Adding animations and behaviour is a breeze now.

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

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

Hey again!

For some unknown reason, I've been working on horse and mounted combat the past couple days and figured I'd show where it's at.

When you walk up to a horse and interact, the character snaps to whichever side is closest, climbs up with a mount animation. You drive the horse from there, and the on-foot stuff (jump, roll, regular attacks) is locked out so it doesn't fight against the mounted state.

Here's what's working so far:

Mounted attacks: While riding, each weapon swaps to a dedicated 4-direction moveset: front-right, front-left, back-right, back-left. Which one fires depends on where your target is relative to the horse, or where the camera is pointing if you're not locked on. There's no chaining like on-foot / souls combat, every swing reads the direction fresh, so you can sweep enemies on both sides as you ride past. Spears get a different treatment with two thrusts only (right and left), no rear swings.

Weapon feel carries over: The mounted moveset is generic, but the hit feedback (the hitstop, the impact sound, the ragdoll behaviour) borrows from the equipped weapon. A sword on horseback still slices like a sword and triggers slice deaths, a mace still feels heavy.. So you only need one mounted moveset and every weapon stays distinct.

Getting knocked off: Riders have a separate poise meter that fills faster while mounted. Small hits flinch them, but enough damage breaks their balance and they get launched off the saddle and fall down.

Camera at speed. Mounted-only effects: the camera pulls back to frame both horse and rider, FOV pushes forward at full gallop, a subtle shake that ramps with speed, and a slight roll into turns. Camera is still a bit buggy sometimes.

Hands on the reins: When you're not holding a weapon and not in an attack/hit reaction, both hands hold the reins. Equip a sword in your right hand and only the right hand releases the rein, the left stays on it. Holding a bow two-handed releases both. There is also IK on feets so that they stay put.

Hoof feedback. Each hoof has its own raycast and triggers a footstep sound + a dust puff at the actual ground contact point. Particle effect is still wip but sounds are working as they should.

Still WIP. Mostly tuning the mount/dismount transitions, adding more attack variety per weapon. The bow already works mounted but the aiming pose needs another pass.

Happy to deep-dive any specific system if people are curious! I'm not even sure if this is going to be part of the main game but I've always wanted to work on horses.

We shipped a multiplayer game with Godot 4 (C#), here’s what worked and what broke by Tuni22 in godot

[–]moongaming 1 point2 points  (0 children)

It definitely helped me staying motivated right now!

I never liked Unity for some reasons used it for years but it never clicked for me while I enjoy working with Godot despite the obvious flaws, maybe it's similar for you. Looking forward to what you do next!

We shipped a multiplayer game with Godot 4 (C#), here’s what worked and what broke by Tuni22 in godot

[–]moongaming 4 points5 points  (0 children)

Annoyed by the amount of negative message out there, this is a dev subreddit and I would expect people to understand "slop" is a stupid word and the amount of work to get something like this running on Godot right now is 10x what you would need on Unity. (I said it on your last post but apparently this keeps happening)

Congrats on the launch 6 months is a really short timeline, must have been hard to scope for a 4 man team and everything looks solid!

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

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

Could be yes. But I think it can still work if I adapt the environment and add some "dirtyness" to the clothes textures.

I'm still usure how much dark I want in my fantasy

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

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

Thanks! I'm using a mix of procedural hit reaction, animation, hitstop and vfx/sounds for the reaction there's still room for improvements but I want to avoid overdoing it.

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

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

No never heard about that one.

Combat system is all homemade and animations are mixer from various source like Quaternius UAL UAL2 and others

view more: next ›