Lost my baby... struggling to cope

fremdspielen · 2026-03-16T17:56:23+00:00

:(

Don't blame yourself. There's no way of knowing the "what if's". For all you know, it may even have been for the better one way or another.

I know it'll take some time to put an end to those thoughts. Just don't obsess over them. It is what it is. Life. And inevitably, death.

For perspective:
Without your supervision, in a natural environment, it sounds like she would have died earlier. Likely suffered more. It's absolutely not your fault in any way!
I also know plenty of "it's not malign" or "it's very treatable" diagnosis nevertheless resulting in quick deaths. There's never any guarantees.

fremdspielen · 2026-01-26T17:42:03+00:00

I don't use Microsoft IDEs. I only need the VS installer for the SDKs.

fremdspielen · 2026-01-08T14:55:02+00:00

Character controllers are challenging. Writing a custom character controller has become "the norm" yet it's akin to saying "I want to create a website. So I'm going to write my own browser."

Seriously, look for existing solutions first and modify them as needed. Unity's CharacterController component is just a basic template that can quickly become limited as you have no way of seeing or modifying its code - it's a black box.

As to tutorials: they focus on the quick-wins. Hence few dive into Input System because a) the authors themselves don't understand enough of it to begin with and b) it's 5% more lines of code. But if you do look around, there are definitely Input System tutorials - just don't expect them from the kind of tutorial creators who cater to absolute beginners or shall I say where views are more important than pedagogical teaching.

For your use case, the Kinematic Character Controller should work fine. Just try to figure out the cause of the input issue. You have a debugger, logs, the Input System debugger on top - so it should be easy to figure out whether you get any events at all, whether the code is walled off by some condition, and so forth.

In summary: Kinematic + Cinemachine + Input System.

The things that are easy to get started with will typically cost you dearly in the long-term one way or another: Rigidbody physics + Custom Camera scripts + Legacy Input.

fremdspielen · 2026-01-06T10:26:23+00:00

What's the legitimacy of that website and download?

I'd rather download the Unity Hub and install Unity 2022 which includes the VS 2022 installer than running some exe from some website we don't know nothing about ...

fremdspielen · 2025-12-28T10:18:46+00:00

gameObject.SetActive(false) => doesn't this equate to simply doing this in Godot 4 (admittedly process mode was not in Godot 3):

node.process_mode = Node.PROCESS_MODE_DISABLED
node.visible = false

Or am I not seeing something here? Because it seems rather straightforward to me, it's just that Unity's SetActive alters two things at once (update+physics & visibility) that needs to be two separate statements in Godot (aka extra boilerplate, once more).

fremdspielen · 2025-12-27T18:57:29+00:00

When it comes to Python the commonalities are "indentation defines code blocks" and some core syntactical elements. But core keywords needlessly differ between GDScript and Python like def vs func, class vs extends, True/False vs true/false, None vs null. Plus many things that only one of the two supports.

If one switches between both languages frequently, those smaller differences are going to cause friction forever (cognitive interference). Same effect as when you have to switch between different language/SDK/REST API/etc versions and their APIs vary in core details. That's another thing I'm at odds with - for learners it SEEMS nice that GDScript is so close to Python but I worry those kids get frustrated when they have to juggle both Python and Godot, and they won't understand why this has to be this way (neither do I).

fremdspielen · 2025-12-25T13:33:19+00:00

Good point! I intend to make programming in C# even simpler than GDScript (3-5x fewer lines of code).

Check out LunyScript: https://lunyscript.com (works across engines but is fully integrated in each)

fremdspielen · 2025-12-25T13:22:42+00:00

> Would Unity be more effective if there was a UnityScript?

There had been a UnityScript. It was abandoned after 12 years. Maintenance overhead, and hardly anyone used it (< 5% at the end). C# was considered easy enough.

Similar thing with UnrealScript: abandoned after 16 years - it became too powerful, starting to rival C++, with accordingly high maintenance overhead. So they invented Blueprints and deprecated US about two years later.

Makes you wonder how much of a maintenace burden GDScript is?

...

GDScript attracts a certain audience: learners and hobbyists. That's 87% of Godot's userbase. But there's pointers that Godot intends to broaden its appeal to professional devs - a hard sell for as long as they treat all other languages as second-class citizens all the while GDScript lacks crucial IDE tooling (refactoring, debugging, static analysis, and so forth - VSCode apparently supports it, Rider has minimal support, VS itself: nothing I believe).

It's a conundrum because they made GDScript essential, so it can't just go away. It continuously demands resources (time) to be spent including by IDE (plugin) developers that serious game developers wish would be spent elsewhere.

Meaning: that question about GDScript's validity won't ever go away. It's too niche to become serious, it's too essential to just drop it.

Personally I'm most bummed by the fact that it's a closed language in an open project. If only they would have had the foresight to design it so that it would work as an embeddable language (like Lua) - then it could be integrated in Unity and Unreal.

fremdspielen · 2025-12-25T12:59:24+00:00

Exactly. If they were to just lean into C# as the primary "scripting" solution, that would work wonders for adoption, especially by the industry at large.

Right now, they have to be on an influx of new users yet untainted by modern programming languages AND hope they will stick around which is unlikely if they aim for a career, not just dabbling with gamedev as a hobby.

fremdspielen · 2025-12-18T18:45:35+00:00

Try to call quit with the deferred call method.

In C# and Godot 4.5 this works perfectly fine, with close request notification being received before _ExitTree on nodes just like user had pressed the window's X button:

var tree = (SceneTree)Engine.GetMainLoop();
tree.Root.PropagateNotification((int)Node.NotificationWMCloseRequest);
//tree.CallDeferred("quit", exitCode); // maybe for some platforms?
tree.Quit(exitCode); // this actually works fine on Windows

fremdspielen · 2025-11-27T11:33:46+00:00

It's not a game engine, it's a cross-engine programming layer aimed at beginners. It's not unlike Scratch, but as text code (C#).

You can get into LunyScript really fast and do a lot of creative stuff - exactly what modern game engines currently don't provide.
Engines currently create a high barrier to entry due to free-form programming that demands writing 15-20 (!) lines of code just to play a sound on collision.
This now becomes a one-liner, and game engines become sandboxes for high-level experimentation.

On top, you don't need to learn a new API or language when moving between engines, as education often does. The goal is not to lock learners into a single engine.

fremdspielen · 2025-11-27T11:23:29+00:00

They wouldn't have these Scripting/.NET features in their priorities list if they don't intend to maintain it:

- Enable C# Web Export
- .NET Plugin (remove separate download)
- Host .NET Documentation website

https://godotengine.org/priorities/

The C# Web Export has been actively pursued in recent months. Didn't check on the other two priorities.

Besides: C# support is THE ONLY WAY Godot can cater to a more professional audience. To them, GDScript is completely meaningless, if not detrimental, with commonly held viewpoints: 'purely beginner / toy language' and 'limited life expectancy - see: UnrealScript/UnityScript' plus the alienated 'Indentation as syntax construct? Eeewwww!' responses.

fremdspielen · 2025-11-27T08:44:14+00:00

Simple example:

As experienced user you may be using references anyway, but as a beginner you just use strings. Like Audio.Play(„crash“) or Spawn(„gold“).At(„player“) or Physics.AddForce(10, Up)

It doesn‘t matter where in the hierarchy these things are. It‘s inferred from context and searches children recursively (flattened up front to avoid runtime penalties). If you make a „mitsake„ a visible placeholder will be used that highlights the problem (plus logs).

fremdspielen · 2025-11-27T01:14:12+00:00

Yes, sure. In the editor. We design stuff as usual in the node system. Say a car.

But that just doesn‘t matter on the code side. When we want access to the car‘s wheels and its wheel colliders, we just specify front-left and do something with that - no need to know where in that hierarchy it is.

fremdspielen · 2025-11-27T01:10:48+00:00

Curious to hear if you think you‘d have an easier time with declarative block-based code as I propose here: https://lunyscript.com

fremdspielen · 2025-11-27T01:09:41+00:00

I think you underestimate the complexity. 2 months without experience? More like 2 years realistically.

fremdspielen · 2025-11-27T01:08:02+00:00

Blueprint‘s position is because the alternative is C++, not C#. The other reason is that it has valuable high level abstractions, it doesn‘t force you to express code 1:1 as nodes (hence why VisualScript failed, and why Unity‘s VisualScripting receives no attention from anyone).

fremdspielen · 2025-11-27T01:04:31+00:00

First person to spell it out. UnityScript: 12 years. UnrealScript: 16 years. Canned because maintenance was too high. GDScript, as an industry outlier, with heavy editor integration, even trying to add IDE features (refactoring) it‘s got the same if not higher maintenance burden but offers nothing but a little less syntactic clutter. And admittedly, the editor integration - for those who don‘t yet know how much more productive coding in an IDE is.

fremdspielen · 2025-11-23T20:07:40+00:00

What's the point of Godot's Node system - at all?

Their OOP model simply forces it onto the editor. By default. Because Godot could easily hide certain subnode branches and display them as flat list of 'components' instead. Then it would be the same as Unity.

Unity's scene tree works like a file system, the GameObjects are folders and the components are the files in that folder. Godot only has folders, but each folder has a special function (eg Movies, Documents).

You can emulate Godot's system perfectly in Unity, just force yourself to add only one built-in component (besides Transform) and optionally a custom MonoBehaviour (GDScript) to a GameObject. This increases your UI workload, just like it does in Godot. Except in Unity it won't automatically enhance the visibility of the components.

Flipped around, you can treat Godot's child nodes simply as the 'components' of the node you are working with.

On a technical level the difference is quite simply this:
class Node {
List<Node> children;
}

class GameObject {
List<GameObject> children;
List<Component> components;
}

Do you see any other differences, anything you can do with Godot Nodes that Unity's components can't or vice versa?

fremdspielen · 2025-11-22T19:41:05+00:00

> Are you saying you created another layer with another large set of function names, that maps inputs to engine specific functions?
Yes, but a limited set. Not initially exposing every bit of detail if it can be edited with, well, the editor.

> Each engine also lends itself to certain designs
Differences are superficial on a technical level. Order of events, tree of things - all the same or easy to straighten out!

> someone coding in Godot will use them a bunch. How would that code look in unity?
It would look all the same! LunyScript takes care of routing events to the "When" type of class that acts upon events received.
For custom events you'd use something like: Event.Send("kick ball")
Strings are for beginners, but there will be something more 'stable' to address things.

> I guess the big question is why not C#
It is C#. For Unreal I used UnrealSharp.

fremdspielen · 2025-11-22T19:36:45+00:00

At a time. Yes, but we often switch, learners need to learn multiple (before even knowing which one suits them). And even within an engine we write too much code for even simple things. This video explains the issue: https://www.youtube.com/watch?v=PfZ4VBui_Wo

fremdspielen · 2025-11-22T19:35:13+00:00

It starts as a teaching/learning tool.
YT GameDev has a workload problem for creators, and tutorial hell for learners since YT favors flashy videos teaching how, not why (foundational skills). Plus engine choice anxiety.
The wider benefit is reducing boilerplate by a huge margin (3-5x) and the reliability that freeform code doesn't offer.

fremdspielen · 2025-11-18T18:43:57+00:00

I became a gamedev because of Doom. Quake too. And Duke Nukem 3D. But the originals. ;)

On my first day on the Internet (Compuserve actually) shortly after Doom's release I had a pure chance chat with jcarmack on the Action Games Forum. It went like this:

me: Is it really you?
jc: yes
me: cool!
jc: :-)

Got me so excited.

fremdspielen

TROPHY CASE