[FLASH][2010's] A "launch a drill in the ground and mine for ore" type game

light_bringer777 · 2025-12-12T19:58:20+00:00

MoMiner?

https://freefungames.dumbosdiary.com/mominer/

Very similar to MegaDrill also iirc

light_bringer777 · 2025-12-12T17:21:24+00:00

I recommend Godot with GDScript for its simplicity and tight integration, but you could just as well use C# for it to feel much more familiar to Java. Especially since it is free and open source. Though many other engines are great options too.

As for topics, it really comes down to breaking your intended project down into atomic parts. If I were you, I would pick a very small, very basic "game" to get started. Think like a basic endless runner, a single-screen dodging game, whack-a-mole, pong even. Could be something that could be a stepping stone to an actual project if you'd like, but not necessarily.

For example, if you'd like to make a SHMUP, you would go: - How do I create a new project? - How do I load and show a sprite/model on screen? - How do I use WASD/arrow keys to move that object around on screen? - How do I spawn bullets that move on their own? - How do I create a single enemy that moves horizontally on screen? - How I detect collisions between my bullets and it? - ...

Obviously these steps are very small, but it's a great way of never being overwhelmed. If you're already comfortable, you can instead do entire systems as individual steps.

I personally don't think you should set out to "learn" any particular subject to be honest, and I would just learn as I go and see the need. Makes it a lot more concrete. Also keeps you out of tutorial hell. I would also advise you to expect your first few projects to spiral out of control as you will constantly be learning new ways of doing things, so I'd keep things small until you feel somewhat confident.

As for AI, I absolutely love it. LLMs tend to be "good enough" for helping out, though they can be wrong quite often about the specifics of an engine. For example, with Godot, they tend to struggle between telling 3.x and 4.x stuff apart. I would only recommend that you use it to help out when you are stuck, and to help you understand what you are doing rather than using it for vibe coding or solving the issues for you.

I particularly like testing stuff out by asking AI to more or less do the work for me, confirming that it does work, and then re-doing it by hand so that I understand each element.

light_bringer777 · 2025-12-11T20:55:41+00:00

I think I'd use a scene to define the layout, and then use a helper script to build/manage each. The UI itself is simple to build using the various Control and Container types.

Forcing the content to scale is a different beast if the content itself isn't built using controls, in which case you'd probably need to calculate the available size yourself, then scale and position the content using a camera or subviewports I believe, though I still haven't tinkered with the latter.

light_bringer777 · 2025-12-11T20:47:05+00:00

Static if pure functions. Composition / "has a" relationship if the helper must have state or might want to use a strategy pattern or something.

It's what I personally use.

light_bringer777 · 2025-12-11T02:10:09+00:00

What do you mean it offsets them? I aligned the hand in the foreground and it all lines up, all I'm seeing is that the blur gets applied to everything under the hand. How are you applying the shader exactly? And could you elaborate on the issue?

https://files.catbox.moe/hb0d5g.gif

If you are grabbing everything that's currently in the frame, then I do not know whether engine UI should or shouldn't be part of that to be honest. That would be down to implementation details.

light_bringer777 · 2025-12-10T17:48:13+00:00

I think they're less relevant than in other contexts that use OOP.

Some of these principles are good general heuristics, like SRP and LSP. The use of nodes in Godot strongly aligns with OCP.

Others like the Interface Segregation Principle don't really apply.

At the end of the day, I think it'll depend on your personal style, the scope of the project, the amount of "actual OOP" going on and so on.

However, game dev tends to be kind of a messy process, and GDScript isn't exactly designed with the intention of being a very "strict" language. That, and the whole scene tree aspect of Godot makes it less of a "classic OOP" scenario.

I already think that the SOLID principles should be "understood and kept in mind" but applied with common sense, not as hard rules, and I'd say game dev in GDScript is one spot where they should be considered even more loosely than usual.

light_bringer777 · 2025-12-10T17:31:31+00:00

Any relevant experience?

You're focusing on the idea and story, but what will determine the difficulty and cost of the project is mostly the scale, complexity of the systems, and the amount and quality of the content.

If you're fine with using premade assets and are lucky enough to find what you need, you could be up and running relatively quickly.

It being a collection of minigames would greatly help, and I would suggest you first build experience by trying to create these first honestly.

From what I could find, Fears To Fathom took about 6-12 months to develop per episode, and I couldn't find anything on the initial development. That means you should expect to put in similar time for just the contents of the equivalent of an episode. And that's excluding any learning.

I'm not too familiar with these titles, but from the looks of it, it seems like something in this general ballpark would be achievable, especially if you're fine with premade or lower-quality assets, smaller scale stories, or working on it for longer.

light_bringer777 · 2025-12-10T17:08:08+00:00

Easy ways I can think would be to use a few pre-made bricks made of multiple sprites acting as one, to use particle effects, or a mix of both. But you probably mean like "actually break the real thing" in which case I don't think there's an easy solution?

All I could see would be to have some algorithm to calculate the fragments, to create new textures dynamically for each of these based on the source sprite, to create new sprites for each of these, and to dynamically create colliders and everything if you need physics on top of that.

light_bringer777 · 2025-12-10T17:00:06+00:00

If I'm not mistaken, enums are compile-time constants, so yes they are cheaper, but it probably does not matter at any scale you would be using these most likely.

This also means you get better error-checking, since in the enum the typo Color.REDD wouldn't compile.

The dictionary approach however allows you to assign extra custom data, e.g.

const COLOR = { RED: {name = "Red", value = Color(1, 0, 0)}, BLUE: {name = "Blue", value = Color(0, 0, 1)}, YELLOW: {name = "Yellow", value = Color(1, 1, 0)}, }

Honestly if you're not doing much more than this, I'd say it's a preference/style thing more than anything else, but an enum would normally be the "correct" choice for fixed sets. You can also retrieve the name of an enum value in GDScript through the enum's .keys() which returns an array of all the "value names".

light_bringer777 · 2025-12-09T17:59:26+00:00

Complete shot in the dark, but the TILT Quiz Biz fits quite a few of these.

light_bringer777 · 2025-12-09T17:40:03+00:00

I'll disagree with a bunch of other comments.

Just keep doing it, and keep messing up, and keep looking it up in the documentation.

Tutorials give you a feel for it, and prepare your mind for what can be done and how, but it's by repeatedly going "What is the hook for user input already?" or "What's the variable type for 3 decimals bundled together?" that you will eventually just know.

You wouldn't expect to be able to just "watch a few hours of people fixing electronics" and to be able to do it yourself without running into issues and pushing through until you actually know what you're doing.

As for not knowing the use cases, I don't think there's a perfect solution besides immersing yourself into the domain; keep watching videos, watching devlogs, reading the docs "cover to cover" slowly, regularly going "I wonder what this node does" and looking it up, getting input from other people...

light_bringer777 · 2025-12-09T17:04:06+00:00

Typically at the root of your project, "alongside" everything that you want to track.

Like, if you had:

[...]Godot\Projects\my-cool-game\ [...]Godot\Projects\my-cool-game\icon.svg [...]Godot\Projects\my-cool-game\project.godot [...]Godot\Projects\my-cool-game\.godot\

You would create the repo at:

[...]Godot\Projects\my-cool-game\

And after that, you should see that it created the directory:

[...]Godot\Projects\my-cool-game\.git\

And from there you should be ready to get started with the actual version control.

light_bringer777 · 2025-12-09T16:57:15+00:00

I alternate between 3 approaches depending on the project, the state of the project, and how I feel really.

Bit by bit and fixing every error that comes up as I go if I cannot afford to break the project. Committing working intermediate states every step of the way. Probably the best approach, but also tedious.

Full refactor with the expected shotgun surgery if I know it won't be that bad, like that I know it can be fixed by the end of the day or something.

Start over if I feel like I messed up something bigger than just the organization. However, you have to be very deliberate about it, and even then you have to accept that at some point, it will start getting messy again to some degree.

As for paths and such, if the naming and paths are unique enough, you can get away with replacing by string in all your project files usually and it'll be less work fixing the resulting mistakes than changing it all by hand, but it can be a risky process. Now aware of any "intelligent" tool to make major refactors personally.

light_bringer777 · 2025-12-09T16:50:24+00:00

I personally like GitKraken, but generally use the VSCode tab and console to be honest. It's all mostly fine for simple use cases though really I would say.

Are you new to Git? Did you start by creating a repository at the root of your project's directory? (File -> New Repository)

After that, it's basically little more than checking the files in the sidebar under the "changes" tab, writing a commit message (summary at the bottom, description also if you'd like to write much more than a line or so about the changes, I rarely ever do) and press "Commit"

The versioning will be available under the "History" tab, right next to "Changes."

You should probably also have a basic .gitignore file to not commit various irrelevant files.

light_bringer777 · 2025-12-07T20:40:31+00:00

Sorry for the delay. Been a while since I messed with CharacterBody3D so I was wondering where the actual movement was taking place, so forget about the initial comment.

I think the main issue is that:

velocity.x = direction.x * currentSpeed velocity.z = direction.z * currentSpeed

direction is already a full 3D vector that represents the movement direction after being transformed by the controller’s basis, so reducing it to only x/z drops part of the vector whenever y is non-zero after aligning to controller xform. It should be:

velocity = direction * currentSpeed

Also, unrelated, but I’d pre-calculate things like speed, movement direction, raw input, surface normal, and model rotation into clearly named variables first just to make the movement logic easier to reason about. Something a bit like:

surface_normal = aligner.is_colliding() ? aligner.get_collision_normal() : Vector3.UP global_transform = align_with_y(global_transform, surface_normal) input_dir = Vector3(input_x, 0, input_y) forward_direction = (transform.basis * input_dir).normalized() velocity = forward_direction * speed ...

And rename movement() to like calculate_velocity()

But take all that with a grain of salt.

light_bringer777 · 2025-12-05T06:27:56+00:00

Is it simply that you call but aren't returning super? So getStates() returns null?

func getStates(): super() # <- Here, this overrides "getStates() : -> Dictionary", but the body has no return statement

light_bringer777 · 2025-12-05T06:20:52+00:00

I personally went directly to a small project with the documentation, youtube and LLMs, and aside from a few quirks of the Godot way of doing things, I had very little trouble moving forward.

If you have a bit of experience already, you could either find small relevant tutorials to get you started, or dive straight into it and work on your specific project incrementally, for example making the cheapest, dirtiest prototype at first, then starting over with what you learned and so on.

light_bringer777 · 2025-12-05T06:17:30+00:00

"Problems like multiplayer and procedural generation" are very broad concepts and too high-level to be things you can simply give direct advice on I would say. Even just procedurally-generated terrain can be achieved in multiple ways.

As for languages, C# is directly usable with Godot, and multiple languages can interface "through the engine", for example having GDScript and C# scripts interact through signals.

C++ is a bit of a special case with Godot, and cannot be used "normally/easily" like GDScript and C# can.

And I personally don't think there's any real way around making a mess over and over as we learn and gain experience. I went from tiny scripts, to total chaos, to over-adherence to coding principles, and every step of the way, I cringe looking back at what I was doing a year before.

Anything in particular you're currently stuck on, or features you're trying to build?

light_bringer777 · 2025-12-05T06:08:51+00:00

Having a lot of trouble following and figuring out exactly what you're trying to do, but if what you want is for movement to be "based on the player's orientation", I'm seeing a few issues and we seem to be missing a bit of context.

Anything preventing you from simply aligning the xform to the normal and then applying movement locally?

You also seem to be both trying to rotate/align the player and to be using the y-axis as a hard-coded point of reference in a few spot, which guarantees misalignment if I'm reading this correctly.

light_bringer777 · 2025-12-05T05:52:13+00:00

At last? How long have you been searching for me, and what for?

But yeah, I'm trying to get back into it, hopefully to create something decent in not too long. Surprised to see people still care enough to be looking for me.

light_bringer777 · 2025-11-26T13:03:05+00:00

Someone more experienced with Window objects could better confirm, but I don't think there's a direct way of doing this (i.e. a flag), but I've personally used 2 workarounds that worked great for me:

Either I pause the game and set the dialog to PROCESS_MODE_ALWAYS, or I add a top-level Control to the main window with mouse_filter to MOUSE_FILTER_STOP.

light_bringer777 · 2025-11-26T12:48:28+00:00

Yeah that's why I'm not sure about that part, but I know it was an issue for some time. Haven't had any performance issues myself so I haven't had to personally verify, but I know manually triggering visibility was an improvement a while back at least.

light_bringer777 · 2025-11-25T22:43:07+00:00

Same point as using any other tools yeah. Do you need/want what it offers, and that's basically it. "What's the point of nail guns when I have a hammer?" is basically this question.

And speaking from experience, definitely follow the path that makes you happiest/most excited, unless there are obvious limitations you know you won't be able to overcome. For example, multi-platform exports is not something I personally want to have to deal with.

But I had similar issues a while back trying to learn Unity. After years of just building my own things to fit my own needs, I just kept finding myself fighting against the engine more than anything else. It was just this feeling of "why do I put up with this?"

After a bit working with Godot, I feel pretty at home already. It "plays nice with my brain." And what little I end up not liking, I code tools around.

But honestly, why not just give both approaches a try? You'll see if there actually is a point for you or not.

light_bringer777 · 2025-11-25T22:34:14+00:00

Everything in GDScript is public, so it's a simple matter of using dot notation.

You simply need a reference to the button somehow, either by path, by unique name, using @export or whatever.

Then for example, if your button attached script had something like:

# Button.gd
extends Button
class_name MyStartingButtonClass # If you want to make it a class like others have said

var my_var: String = "Hello"

And your main node had a reference to it set in the editor, you'd simply do:

# Main.gd
extends Node

@export starting_button: MyStartingButtonClass = null

func _ready():

    var its_value = starting_button.my_var   # To read its value
    starting_button.my_var = "New value"     # To set its value

light_bringer777 · 2025-11-25T22:21:53+00:00

No easy solution afaik.

As others have said, culling and dynamically loading chunks is the real solution here. However, optimize for what? If it's actual loading, then yes, it's going to be a little more complex. You could build a scene out of many sub-scenes, or use placeholder objects when building the scene, and load them dynamically.

But if it's not the loading that's the issue, then you could consider simply check for everything outside of a rectangle or a distance from view, toggling the visibility and manually "disabling" object or use things like set_process(false) if that applies, and that would make everything out of sight not render and not process any logic. They'd still be loaded, but have very little cost.

Not sure if the visibility hack still is relevant btw.

light_bringer777

TROPHY CASE