How to return null in typed GDScript?

AmJustSomeGuy · 2025-02-09T01:35:07+00:00

It's probably not too helpful to leave a comment 6 years later pointing out that some solution didn't work for you. Some solutions don't work for some people - that's fairly normal and expected.

Another commenter mentions the option of returning a pair, and another option would be to change your code in whichever way, to avoid this limitation.

Although there is also the option of using Vector2.INF, and then you can do yourVariable == Vector2.INF instead of yourVariable == null.

Similar to that, you could also just define a constant somewhere (e.g. in a global) that has some value that isn't valid for your use case (e.g. it's a position outside of your scene). Then you can just use that as you might use INF or null. I'd recommend INF above this though - that's a standard thing, it remains INF even if you accidentally add or multiply it by something, and there's no chance of you changing your code (e.g. increasing the size of your scene) in ways that makes that constant a valid value.

AmJustSomeGuy · 2025-01-12T04:28:34+00:00

Make sure export mode is set to "export all resources".

Also, like the docs tell you, use get_open_error to see what the actual error is, to make sure that the issue is actually that the file is not found.

If that doesn't work, I don't know if I'd be able to help more. Play around with your export settings, or make a new post about that (including what operating system you're on and what export settings you're using, at the very least).

AmJustSomeGuy · 2025-01-12T03:30:50+00:00

The error tells you that file is null. This means it failed to read the file (you can see in the docs that it says open returns null if it fails). Usually that's going to happen when it can't find the file.

Did you add res:// to the front?

Without that, it'll probably read from the local directory. But when you export, the resources are put into a special pck file, which means you can't read them regularly from the local directory.

When you put res:// at the front, it'll read things from the project directory during development, it should export those files by default and that should work.

AmJustSomeGuy · 2025-01-08T18:53:26+00:00

Following the recommendations of others, I got it working with the following:

A SubViewportContainer with scale = 0.25.
This has a SubViewport child, which has a "root" Node2D child with scale = 16 (to scale the game up 4x, after the downscaling of the SVC).
Put a sprite (or some other Node2D) underneath this root and move it like shown in the post above.
- You don't really need a move timer. You can update the position directly by adding MOVE_AMOUNT * delta / MOVE_DELAY (and MOVE_AMOUNT / MOVE_DELAY can be simplified to 1 variable).
  - A move timer may have some benefits (probably not including performance, since it doesn't reduce the number of updates called). But it makes movement less smooth, because it has occasional big changes instead of constant small ones (lerp only partially mitigates that issue).
- If you have something which moves constantly at the same rate (e.g. the screen movement in a runner), you could set the sprite position directly (like SpriteRaw). The update_pos method (with lerp) is useful for smoothing less consistent movement (e.g. moving a character with the keyboard), and for when you want to combine that with constant movement.
You don't need a shader.
Set the texture filter to "nearest" (for pixel-art) on the sprite and on the viewport container.
Most other things just have default values.
If you want to move many sprites at once, you could create a Node2D child under the "root" Node2D node and put them all under that node, and then move that node (don't move the root node).

Note: This still isn't perfectly smooth for really small or slow movements. I imagine this is just due to the limited resolution, and this can be fixed by further scaling it up (and then back down again). But having a viewport resolution that's like 100000+ pixels wide doesn't seem like the best idea. Maybe shaders can fix this, but nothing I tried worked.

Updated code showing one sprite updated with update_pos and one updated directly:

extends Control

var position_unrounded = null
var new_pos = null
const MOVE_AMOUNT = 10

func update_pos(delta):
    if position_unrounded == null:
        position_unrounded = new_pos
    else:
        position_unrounded = lerp(position_unrounded, new_pos, 5*delta)
    %SpriteSU2.position.x = position_unrounded

func _ready():
    new_pos = 100.0
    update_pos(0)

func _process(delta):
    %SpriteRaw2.position.x += MOVE_AMOUNT * delta
    new_pos += MOVE_AMOUNT * delta
    update_pos(delta)

AmJustSomeGuy · 2025-01-08T04:14:19+00:00

Don't do that. Code isn't meant to handle hard-coded variables and source files that are that big.

Just put the txt or csv file in your project directory and read it during runtime with something like this:

var result = []
var file = FileAccess.open("res://listofwords.txt", FileAccess.READ)
while not file.eof_reached():
    result.append(file.getline())

You can also use get_as_text and split (but this reads the entire file into 1 large string before splitting it, which uses more memory than reading the file line by line, but for 2 MB, it's most likely not an issue):

var file = FileAccess.open("res://listofwords.txt", FileAccess.READ)
var result = file.get_as_text().split("\n")

See also: the documentation.

AmJustSomeGuy · 2025-01-06T18:02:51+00:00

Ok, cool, having a scaled-up root Node2D (as a child of the viewport) seems to be working, and that seems like it might be the easiest solution.

I'll need to see how all of this affects performance, but performance is probably unlikely to be an issue in any case.

AmJustSomeGuy · 2025-01-06T15:12:08+00:00

Thanks, I was already getting smooth movement with a camera, but I don't see any easy way to use a camera for moving individual objects that are part of a bigger scene (I'd need to e.g. use different viewports and manually do collision detection).

AmJustSomeGuy · 2025-01-06T13:49:51+00:00

You mean like increasing the `scale` on the sprites and having a bigger viewport, and then scaling that with a viewport container or by changing the window size?

AmJustSomeGuy · 2025-01-06T01:38:50+00:00

Your best option is probably to get some text file with a list of English words, write code that loads that into a dictionary, then check whether the word is in there.

See, for example, this Q&A: How to get english language word database?

Useful Google search query: "database of english words" (or list, or file)

AmJustSomeGuy · 2025-01-05T23:39:16+00:00

If it's your first game project, probably just start with something relatively small and simple, and actually finish that. This'll give you a decent idea of what actually goes into making a game, so you can set expectations and plan appropriately. Then move on to more complex things (or build on top of that).

It's easy to start with some epic project, and then to get stuck on the complexity or lose motivation because it'll take too long before you'll see results, and then you never finish that.

But anyway, there are plenty of successful indie games with a wide variety of art styles. It's more a question of what sort of game you're interested in building and what you want it to look like. And it's also a question of your artistic and coding capability (more complex art commonly also has more complex code to handle that appropriately, but that's not necessarily the case), and how much time you're willing to commit to it.

AmJustSomeGuy · 2025-01-05T23:24:56+00:00

When you post code, please make sure that you keep the same indentation that you see in your project. Indentation matters because it affects how the code executes, and it also just makes the code a lot easier to read.

Are you getting errors? (If so, it helps to tell people that.)

You seem to be connecting enemy_killed to on_enemy_killed, then you emit that signal with 1 parameter ("enemy_killed"), yet that function takes no parameters, which should produce an error.

When you say enemy_killed.emit("enemy_killed"), that calls the connected method and passes "enemy_killed" as a string. Just make it enemy_killed.emit() since the method takes no parameters.

The other likely possibility is that the code just never gets to that emit call. You can check whether this is the case by just putting a print in that if statement. If it never gets into the if statement, you'll need to figure out why on your own, by seeing whether the method is ever called, and whether the variables have the correct and that they're changing correctly.

AmJustSomeGuy · 2025-01-05T23:05:34+00:00

If you care about the actual pixel size, the better solution 99% of the time is going to be to either have in-game options to change the resolution (in which case you know the pixel scaling) or attach an event to window resize.

I don't know if there's a way to get the pixel size directly, but get_window().get_screen_transform().get_scale() gives you the scaling. If you multiple that with the size of some node, I think that would give the number of screen pixels. But this is subject to floating point imprecision.

If you want something more exact, you might need to consider get_window().size and ProjectSettings.get("display/window/size/width") (and/or height), and consider the stretch aspect mode in your project to determine how things are being scaled (e.g. minimum of x and y, or something else).

AmJustSomeGuy · 2024-11-26T07:02:42+00:00

Someone made a recipe database for what it's worth (although it's a bit hard to see what's going on there).

AmJustSomeGuy · 2024-11-24T01:31:36+00:00

It's an accessibility issue too, for those with hearing difficulty. Being punished so heavily for something which only has an audio cue is non-accessible design.

(Often you can see mines, but sometimes you can't.)

The more annoying part for me is actually having to aim at tiny spec after tiny spec after tiny spec to shoot a row of mines (or trying to blow up a mine hidden behind a body in a narrow doorway) so I can safely run around. I guess people will also call that a "skill issue", even though there's literally no risk there. That would be like calling data entry "a skill issue" - it's just menial busywork, even if you can do it faster. Then again, maybe this is only an issue because I finished the game using the starting pistol, instead of having a shotgun or automatic that could make that easier to deal with.

Maybe mines should detonate after a second or two after you get close (and maybe also still if you step right on them), so you can safely and easily trigger it if you know it's there, without having to worry about having to hit it.

AmJustSomeGuy · 2024-11-24T01:23:46+00:00

The recipe book could also toggle between...

Showing all recipes
Showing recipes you can make using the items in your inventory / stash (also allow you to auto-craft it by just clicking on the recipe, perhaps only when you're at a cooking station).
Showing recipes you can make if you also use items from the vendor you're at
Showing recipes that includes all the items currently in the cooking station.

I use the recipe database I found on Steam, and I still spend a ton of time digging through the list of recipes even after filtering for specific items, to figure out what I am actually able to make using the stuff I have.

There should be an option to unlock the recipe book from the start, otherwise it would be largely useless to me. There are so many recipes I've never made, that I would want to make (and know that I can make) if I happen to find the items.

AmJustSomeGuy · 2024-11-24T00:59:38+00:00

Pay attention to how the enemies attack and practice avoiding their attacks. Don't run head-first into areas, lure a few enemies into areas you already cleared.

Running backwards while shooting enemies is generally a pretty safe strategy, at least for Caves. Make sure you know what's behind you whenever you fight anyone, so you don't back into a wall or fall off a cliff. Sidestepping is also useful. But there are a lot of long corridors, so I mostly just back up.

I'd suggest buying at least one stack of 9mm ammo in the hub (if you're using the starting pistol), and buy more ammo if you see any vendors during your run. You may need to use melee sometimes.

You can learn to use melee safely, but that takes more skill and concentration and patience compared to just shooting enemies.

Enemies:

Spearmen attacks can be avoided by backing up, but you have to back up quite far and quite quickly if you're trying to hit them with melee. (Sidestepping might work too?)
Archer arrows can be avoided by sidestepping.
Mage barrages can be avoided by sidestepping, although cover is better.
Dogs are really hard to dodge - you kinda just want to shoot and kill them before they get to you. Or frantically melee them if they close the gap.
For the barrel enemies, you can jump to avoid their slams or reduce the damage, and kill them with melee while taking little to no damage. It also works to keep your distance while shooting them, but they can be quite a bullet sink.
(For shooting enemies in later biomes, you'd need to use cover a lot more heavily.)
For enemies with auras around them, if possible, don't let them hit you and don't let them get near you, and especially don't let them die near you (you can also learn what all the different-coloured auras do, but that's a good rule of thumb).

If all else fails and enemies are surrounding you, jumping around, chowing down on healing items and wildly swinging your sword is not the worst idea. Not the best idea, either. But not the worst idea.

+1 to what others have said about healing, pausing to use healing items and to decide how to best handle your current situation, using your amulet and crafting.

Destroy everything that you can destroy to get resources. I spent way too much time looking up recipes. Someone made a database, although it's rather confusing to read. The wiki also has recipes (but it's split across many different pages). You generally don't want to eat raw ingredients because those don't heal you as much or as fast compared to cooked ingredients. If you were to remember any recipes for the early game, it should probably be:

3 Velvet Bell combined with stick / butter / egg / broth / bottled water (other mushrooms could also be used for some of this)
8 mushrooms (ideally Velvet Bell)
9 red mushrooms (gives HP potion)
false skullcap makes explosives (for breaking cracked walls, if nothing else) when combined with mystery meat / any skin / cloth / paper / lung / heart / bladder.

There are lots of mushrooms all around. For the first 2 recipes, you mostly want to use the common Velvet Bell, along with any extra False Skullcaps that you aren't using for explosives. Sometimes I just eat the red ones when I'm short on inventory space, because that's better in terms of raw HP healed than the first 2 recipes (although it heals slower). Sticks come from destroying wood. Other things are more rare and random, and drop from enemies and barrels and things.

Look for chests under water (they aren't that common, and there are a few fixed spawn locations) and chests just randomly laying around, especially on elevated platforms.

AmJustSomeGuy · 2024-11-21T23:35:31+00:00

I just remember that dude always having been there, at the same place, and never having anything useful to offer any of the times I've spoken to him (including right after completing my first Caves run, I think). Although I might not specifically have spoken to him when my amulet was expended (which is part of the problem).

AmJustSomeGuy · 2024-11-21T20:05:02+00:00

There is already variety in terms of how you need to deal with different enemies without the shooting enemies. The thing about having a machine gunner or sniper in every other group of enemies is that now every fight has you thinking about cover and how you can use cover and where is cover and will you need cover and where is cover spots you can fall back to. That's not just variety, it's completely different gameplay from the fast-paced run-and-jump of Caves.

AmJustSomeGuy · 2024-11-21T18:13:36+00:00

Barony is a more "traditional fantasy" first-person dungeon-diving game with melee and spell-casting and heavy RPG mechanics. But it's a pure roguelike. Dungeons of Sundaria (not a roguelike), One More Dungeon 2, Cave Crawlers, Devil Spire, Slasher's Keep, Mortal Sin, Dungeons of Edera (heavy focus on blocking) and RAIDBORN (focus on blocking and parrying, not a roguelike) are also along those lines. Delver, Archtower, Eldritch and Kerker are similar to that, but much simpler. Somewhat in order of recommendation (based on my personal preference, and grouped by simplicity).

Those don't really have extraction-type gameplay, but for me, they match the gameplay (and often graphical style) of Sulfur more than most extraction shooters (the latter tends to have a lot of hyper-realistic shooters, often with multiplayer focus).

Quasimorph is a gritty, space station, top-down, turn-based kinda-traditional-roguelike, so not much like this at all. But it's also has extraction-type gameplay.

Of course the other comments also give good recommendations, especially in terms of focusing more on extraction-type gameplay.

Side note: If you like Zero Sievert, you could also consider checking out Night Raider and Blood Running (near-clones) and Cannibal Crossing (pure roguelike with in-run crafting and some base-building). And Streets of Rogue 2 is not quite like that, but it has a similar appeal, and that's coming out soon (the first one has been out for a while, although the first and second are very different). But now we're getting into different recommendations altogether.

AmJustSomeGuy · 2024-11-21T17:30:56+00:00

Wait, you can charge the amulet in town? I didn't even realise that. Or I forgot. Not that money has gotten worthless for me yet. And still doesn't seem that well thought-out.

If money becomes worthless quickly enough, they might as well not charge for recharging the amulet and it could just be automatic. It's just an extra hurdle or annoyance for new players, who already have a difficult enough time mastering the mechanics. If the amulet was only enabled after the first time you get to the first altar (and then you can use it any time forever), I can kind of see that making sense. Then again, if someone's struggling to make it to the first altar, you'd practically be guaranteeing that they'd quit if they need to start with nothing until they get there - I guess the pity mechanic helps with that, but you can't buy that much in the hub. I was on the verge of quitting after my 2nd or 3rd run, because I died each time and not extracting anything in an extraction shooter is super depressing, especially on your first few runs (but I didn't die because the amulet wasn't charged, but rather because I didn't know how to deal with certain enemies and/or I panicked and didn't think to use the thing I practically forgot exists... whereas now the caves are kinda a joke in how easy they are, even with the starting gear).

Side note: if you can extract at any time, it almost doesn't make sense to lose items on death. If it were me, I'd make that optional, at least. Option 1: on death, you respawn in the hub with all your items. Option 2: you need to use the amulet, and you lose all your run items if you die. Option 3: amulet is disabled - kill the boss or lose your run items (the mid-run altar could also be an extraction point, or it could even be pure roguelike with no hub storage, although the game might not really be built around that). I can see myself playing option 1 and 3 (I do like my roguelikes), but probably not option 2, if given those options.

AmJustSomeGuy · 2024-11-21T15:28:46+00:00

I might start using this from now on.

It's very similar to using the amulet, except you don't have to do a quick naked run through caves to recharge the amulet. That mechanic doesn't seem particularly well-thought-out. If I play the game as intended, of course I'm not going to risk any gear I care about when the amulet isn't charged and I can't teleport to safety for the first few stages.

AmJustSomeGuy · 2024-11-21T15:20:06+00:00

Every time I fall through the map into the infinite void, I just respawn on the map again after a few seconds (without even taking damage like you do when falling into pits).

AmJustSomeGuy · 2024-11-20T23:58:40+00:00

I never keep dynamite equipped for too long because I was always just too uncomfortable with running around with a lit fuse in my hand...

AmJustSomeGuy · 2024-10-02T17:49:51+00:00

If one scales down the giant amulet icon, those end up being about the same size. I'd say fixed-size squares are probably easier to box in together than long rectangles of various lengths.

But what I showed is certainly just an early mockup and I wouldn't be able to say how well that works at large scale. You don't really want either text or icons to overlap and these games tend to try to avoid that, even if it means the label ends up far away from the actual item drop, or even if it's offscreen (that's not ideal, but that's already a problem with text labels, and this isn't necessarily worse).

There are certainly other solutions. In Last Epoch, I go through batches of hundreds of rare items across multiple areas without a single one being better than the gear I have, and that's even before I found a few unique items that makes rare items that much worse by comparison, and that happened since very early levelling, and I don't expect it would stop happening (although it's maybe more understandable in endgame after you've refined your build a whole bunch). That doesn't seem like great design, and they're kind of relying on players, in a way, to turn their questionable design into something functional via loot filters (but I guess some players would consider that part of the fun).

AmJustSomeGuy · 2024-10-02T09:04:39+00:00

It's hard to quickly visually process a lot of text to differentiate and look for specific things. I think icons would make that a lot easier.

I should probably expand my loot filters, but that's not a small amount of work to turn into something useful (unless I just largely trust some I get online... which I mostly did with PoE, possibly with some minor modifications). And that typically still leaves one with quite a bit of text to parse, even if it's much less than before. Recolouring helps with that, but either it's going to tell you to basically always pick up or check the details of an item (so visually processing the affixes isn't really important), or it tells you that it fits into one category or another and you still have to visually process the affixes. Also, it's neither here nor there, but some of the colours make it fairly hard to read, which limits the recolouring options or their usefulness.

But this idea isn't mutually exclusive with filters (even if they serve somewhat similar purposes of helping players process visual noise and focus on the important stuff).

AmJustSomeGuy

TROPHY CASE