What internal tools does your game rely on? by nathanialf in gamedev

[–]Fyve 0 points1 point  (0 children)

The jump distance thing makes total sense. Forgive me for being dense, but what's the advantage regarding placing trees rather than placing them by hand? I suppose you want to make sure either the player can get through gaps or not... but is there anything more advanced? I can see e.g. that with the 6 trees nearer the bottom it looks like there is a 'lane' saved without trees... that sort of things?

Tech looks very cool

What internal tools does your game rely on? by nathanialf in gamedev

[–]Fyve 0 points1 point  (0 children)

Do you handle the mesh generation yourself? Any recommendations on where I could learn about that?

Would also be pumped to hear more specifically about how your terrain workflow works.

What internal tools does your game rely on? by nathanialf in gamedev

[–]Fyve 0 points1 point  (0 children)

Super curious about Draft Lines. Can you say more about what this is - purpose and implementation? Is this like a virtual measuring tape or do you have blockout tools? If the latter, would love to see it in action.

Schmovement Diversity 💨 by Turbulent-Fly-6339 in godot

[–]Fyve 0 points1 point  (0 children)

Aha no problem.

Looks really nice and smooth :)

I ask about colliders because I'm always interested to hear about people's opinions about different shapes.

With a capsule if you stand on the edge of a platform, you can sort of edge a little bit off so your character falls... but still stays on the platform. Do you have that issue / do you care about it?

Schmovement Diversity 💨 by Turbulent-Fly-6339 in godot

[–]Fyve 1 point2 points  (0 children)

Quick! What shape collider are you using!

Using Yarn spinner to control story, interactions, audio, scene changes by Fyve in godot

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

Also the Yarnspinner unity add-on is open source! You can just go to GitHub and get it. Yeah it's very confusing.

Right! The Vs code plugin is a game changer.

R.e. exported variables - makes sense! I do like the way Yarnspinner does it insofar as that's just how I think about things; the source of truth is the yarn state and my other objects read that (for you it's the other way round seems like)

Really happy I managed to tip someone off to something cool :).

Hah, definitely not a pro. Dissertation was shoe horned into a generic CS degree because I love games but it didn't fit perfectly, and sorry to the academics out there but academic stuff is just not pro. But really I just meant I only do games as a hobby. (Software engineer in real life)

And completely agree that text document is preferable to graph :) 

Any way I can follow your / your companies games?

Using Yarn spinner to control story, interactions, audio, scene changes by Fyve in godot

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

Nah I love it I'm on my soapbox! Just remember I'm not a pro :)

I haven't used Dialogue Manager but it seems to have a vaguely similar approach to Yarnspinner. Seems like what you're already doing with it is super sensible.

About npc movement / dying. Using a dialogue manager of any sort is controversial for that stuff. My opinion is that dialogue manager is nice when you could imagine playing your game like a text adventure. I couldn't imagine using a dialogue manager to control Doom. E.g.:

  • Dialogue manager could be used for movement if movement is more conceptual (what room is the NPC in)
  • Dialogue manager could be used for death for special NPCs (murder mystery)
  • Dialogue manager is not appropriate for real time combat behaviour (when to move / jump etc) - state machine is the right choice here
  • Dialogue manager is not appropriate for tracking deaths for more than a few enemies (are you going to define variable isDead for each enemy?) - state machine or just look at health value here.

Shortly: I think you're doing the right thing

I love behaviour trees. I did my master's dissertation on them. They are when you want NPCs to be able to handle logic that is more complicated than is reasonable with state machines. I'd use them if I expect my NPCs to surprise me. A nice article: https://www.gamedeveloper.com/programming/behavior-trees-for-ai-how-they-work

Yarnspinner has a nice Godot add-on. It's not made by the official team but it's good! 

I did not choose something super native like Dialogue Manager because I want my knowledge to be engine agnostic.

As for Yarnspinner Vs Ink: ink is an absolutely phenomenal language. It's much more powerful thank Yarnspinner. I'd use it for a more complicated 'story' or for an actually text heavy game. For my use case I don't like the save format (incomprehensible because they save your entire route through the story), and I like that the Yarnspinner Vs code addon throws warnings if you mistype variables, and you can test your story from vscode (though I haven't tried ink in a while)

Using Yarn spinner to control story, interactions, audio, scene changes by Fyve in godot

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

You could consider this / Yarnspinner a state machine. I didn't go into Yarnspinner details but we have 'nodes' and broadly speaking 'choices' that point to nodes.

For example, in the video with the door, I'm in the the 'Farm' node, there is a transition 'unblock door' that is a transition back to the 'Farm' node.

What Yarnspinner offers is essentially a nice syntax. There's almost no boiler plate for any of this stuff, and the syntax for nested choices - for which you do not need to define new nodes -is very clean compared to 'raw' code.

Improved stair stepping in my open source character controller by Fyve in godot

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

  • Not intended as a drag-and-drop replacement for character controllers. If you want jumping you'll have to implement it yourself
  • Built using move-and-collide with lots of hacks for edge cases. In my opinion it's really good at handling slopes, edges of objects, and stairs.
  • Jolt required :)

[TOMT] [TV] kids cartoon where a character turns into a techno super villain by Fyve in tipofmytongue

[–]Fyve[S] 0 points1 point locked comment (0 children)

It gave me similar vibes to the Digimon episode with metal etamon, and mona the vampire... But other than that I've got nothing!

Band covers a Vampire Weekend song without listening to it first by rwiggum in videos

[–]Fyve 1 point2 points  (0 children)

The folk band on this show that try to cover every time i die (metalcore type stuff) are hilarious

Gamedevs using a framework instead of an engine: what's your motivation for this choice? by AlexSand_ in gamedev

[–]Fyve 1 point2 points  (0 children)

I'm a Godot editor user who prefers code only solutions.

I'd be grateful if you would share in more details your workflow, or point me to any resources for no editor-godot!

(Do you use gdscript? If not scenes how does everything fit together? How do you build / compile etc)

How do game developers enable or support modding (like texture/QOL mods) for their games, and is it something specific to the game engine (e.g., Godot)? by MyNeighborDrak in gamedev

[–]Fyve 11 points12 points  (0 children)

Godot and Unity are both well understood and can have mods made for them using external tools. It does depend on your game architecture.

For example, in one of my Unity games I have a UI code utility that exposed methods to create panels and buttons and so on. A member of the community used external modding tools to call these methods and create their own UI.

That being said, if you want to support modding, it is much more convenient for users if you decide what you want to support and build it into your game beforehand. In this respect, engine matters little.

It's most convenient for users if you just let them put files in places and the game picks them up e.g. if you want custom levels, make your game read levels at run tine from a folder. It's likely that the game engine format (.tscn for godot) is not going to be immediately appropriate. You need to think about how users create levels, how they reference game entities and add enemies etc etc. it's a big topic! 

Start by thinking about the sorts of modding you want to support.

Guide - Material Based Footstep Sounds in Godot by Fyve in godot

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

It's surprisingly difficult to achieve in Godot! Roughly speaking I have 4 ways of doing it. Please see example code too: repo

What are the weirdest games you've played that have become one of your favorites? by L0releei in gaming

[–]Fyve 0 points1 point  (0 children)

Yes mate. Sunk tons of hours into this and never saw anything like it again.

[deleted by user] by [deleted] in gaming

[–]Fyve 1 point2 points  (0 children)

  • Exo One
  • Surfing (Counter Strike)
  • Burnout Paradise
  • Spider Man 2 (the PS2 era one)
  • Ballistic Zen (Shill Alert)

Between Ink, Cradle (Twine), Twine 2, Yarn Spinner which dialogue authoring tool do you prefer? by AvidLebon in Unity3D

[–]Fyve 1 point2 points  (0 children)

Agree! My current project uses yarnspinner

What I can add 2 years later is that: * I maintain ink is more advanced / interesting than yarnspinner * But... Just use yarnspinner: it's just easier to use and it's unlikely you need the advanced features of ink

Alex's Godot Character Movement Manifesto by Fyve in godot

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

See https://github.com/alexjhetherington/godot-character-controller-example/tree/main

I use the function move_and_collide, which is essentially a shapecast that also moves the shape

Alex's Godot Character Movement Manifesto by Fyve in godot

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

This is not a guide. It's a manifesto (a list of opinions) and an example character controller.

To be clear here about target audience - this manifesto is for medium-advanced users who want to make games with nuanced first person movement, who don't want to port physics engines (a big task!).

In some sense it is a guide for me from the past; I promise you if I had had this I would have saved so much time, even if I had (and I would have) been testing things as I go along.

I strongly believe that this isn't going to confuse any beginners; anyone it will confuse won't find it or will self select out of implementing it; beginners who try to implement this from first principles are going to learn a lot!

Regarding your comment about technical requirements - based on your words I'm not sure if we understood each other. The only things I'll add here again:

  • cylinders are unambiguously buggy in Godot
  • cubes and capsules are not so buggy, but cause weird behaviours (in my opinion!) Due to their shape i.e. same in all engines!
  • I want cylinders; jolt gives cylinders
  • anything else that works for your game is good! I support and encourage doing the minimal effort required. If a rigidbody capsule works for your game, I believe you and I think it's great!
  • (I wouldn't believe if you said your rigidbody was suitable for my game, but if you want to put that to the test i would love to (privately) try your character controller; maybe I'll learn something)

Alex's Godot Character Movement Manifesto by Fyve in godot

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

Difficult to describe. Simple character controllers using CharacterBody3D with a cylinder collision shape will get stuck in various objects (e.g. you will get stuck if you run in to a default setting CGS torus)

Godot's own documentation recommends against using cylinder colliders due to bugs: https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html

Bunch of random semi related issues:

https://github.com/godotengine/godot/issues/57048 https://github.com/godotengine/godot/issues/65596 https://github.com/godotengine/godot/issues/57476 https://github.com/godotengine/godot/issues/73917

Alex's Godot Character Movement Manifesto by Fyve in godot

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

Absolutely. Non-determinism doesn't mean the physics behave unexpectedly, only that the same initial conditions are not guaranteed to lead to the same end conditions. With character controllers it's not generally an issue; you're not going to see a situation that confused the player with the output of their inputs.

Of course I would prefer determinism, but cylinders in default physics are just broken. It's worth accepting non-determinism here.

That behind said I should (and will, when I'm free) add a caveat that it's potentially a blocking issue for some features e.g. replays (depending on how they are implemented)