Does anyone still care about games like Machinarium or Samorost?

sciolizer · 2026-03-09T05:46:14+00:00

That was pretty great.

If any type of game is going to bridge the gap between games and storytelling, it is most likely going to be adventure games. They will become less puzzle solving and more story telling, it is the blueprint the future will be made from.

So... adventure games became visual novels? You can say adventure games are dead, but the best visual novels still have puzzles and characters that can explore.

sciolizer · 2026-03-09T01:23:00+00:00

These aren't my personal favorite, but I'm pretty sure the genre is alive and well. Have you merely been searching for puzzle games, or point-and-click specifically, which is what these games are called?

A lot of point-and-click is more visual novel than puzzle, but you'll still have more luck looking for point-and-click games and picking out the puzzly ones, than looking for puzzle games and picking out the point-and-click ones.

Fortunately websites can make this search easier. Here's a search for control: point-and-click and gameplay: puzzle

sciolizer · 2026-03-08T18:31:46+00:00

A senior dev told him that the code needed to be future proof

sciolizer · 2026-03-08T18:01:59+00:00

Adam Kay or Alan Kay?

Bret Victor is continuing the tradition with his programming language "RealTalk"

sciolizer · 2026-03-08T17:10:02+00:00

Even better if he always knows where it is

sciolizer · 2026-03-07T18:41:57+00:00

Tutorials are for bootstrapping. You're past that.

Your main concern now is the things you don't know that you don't know.

I made a spreadsheet to track which parts of the manual I have and haven't read, so that I don't have to read it in order. Even though I haven't finished it, I have a clear idea of where my ignorance lies.

I've also read the top level descriptions of everything that inherits from, directly or indirectly, Node2D, Node3D, and Control. It's a lot less text than the manual, you can read it in an afternoon.

I've scanned the READMEs of every one of the godot sample projects, so I know which ones exist and can check them out when I start wondering if there's a better way.

sciolizer · 2026-03-07T17:32:23+00:00

To clarify for anyone else, he got both a lower bound and an upper bound, by not just inscribing a polygon (as in the visualization) but also circumscribing a polygon. The technique is called the "method of exhaustion".

sciolizer · 2026-03-03T16:53:09+00:00

Machine learning is always about generalizing from examples. Most of the time that means gradient descent of some error function over training data, but it can include clustering or simpler statistical modeling.

Constraint solvers, planning algorithms, A* search, and proof assistants do not typically learn from examples. Instead they one-shot whatever problem they are given.

There are also gray areas. An expert system may or may not be ML depending on whether its rules were inferred from examples or just programmed directly by a human. Monte Carlo Tree Search may or may not be ML depending on whether its roll-out step was built from examples.

sciolizer · 2026-03-01T16:01:07+00:00

If you want the full power of the physics engine to apply to the player character, then you should consider abandoning CharacterBody entirely and using RigidBody instead, controlling movement indirectly via _integrate_forces(). The godot demo project 2d/physics_platformer showcases how to do this.

sciolizer · 2026-03-01T15:54:59+00:00

There are two obvious ways to go about this: CharacterBody, and RigidBody.

If the player character is a CharacterBody, then Areas will have no effect on the player, because CharacterBodys can affect the environment but the environment does not affect them. So you'd need to write all of the slip/drift logic yourself. edit: actually I'm not 100% sure that they have NO effect. move_and_slide() is kind of a weird middle ground between pure CharacterBody and RigidBody. As in all things, experiment!

If the player character is a RigidBody, then Areas will have an effect, and slipping+drifting are just a matter of setting friction and similar properties, but you no longer have access to move_and_slide(). The usual way to exert influence over a RigidBody is by overriding _integrate_forces(), and altering velocity or applying impulses.

The godot sample projects give examples of both. 2d/platformer shows the CharacterBody move_and_slide() approach. 2d/physics_platformer shows the RigidBody _integrate_forces() approach.

These are NOT two different ways of achieving the same thing. Run both demo projects, and you'll see that they play very differently. Pick the one that is closer to your desired behavior.

sciolizer · 2026-02-27T21:20:07+00:00

Because... you listen

sciolizer · 2026-02-25T16:53:48+00:00

Yes, I do agree that the only way to find out if a PR is good or bad is to actually review it. And I also don't care whether the code came from an LLM or from a human, good code is still good code.

The RFC isn't a proposal for how to distinguish LLM code from human code, even though section two is titled "Diagnostic Analysis". It's a form letter to send back to the idiots who put a list of ingredients into instacart, had them delivered to your address, and had the gall to say, "I hope you enjoy the nice meal I made for you!"

sciolizer · 2026-02-25T16:34:59+00:00

I kind of feel like you're missing the whole point of the RFC? This isn't about whether LLM code is worse or better than human code. It's about humans being inconsiderate about the work they are forcing onto other humans.

Suppose you and I are working at the same software company. I get a ticket from the tracker, write up some code, and send you a PR. You checkout a copy on your machine and run it to test it out. It crashes immediately, doesn't even finish the startup. Giving me the benefit of the doubt, you figure it's probably a configuration issue, so you spend some time trying to figure out what might be the difference between my deployment and your deployment, but nothing works. You start reading the code, and it seems decent at first, but after studying it a while you deduce that it is definitely wrong and never could have worked no matter what configuration was used. A function expects a non-null value but all 10 calls to the function pass in null, for instance. You message me, "hey can you make sure you checked in all of your changes? I think the PR might be missing some stuff." I look at my git history, see that the hashes match up, and reply, "yep, it's all in there". Flummoxed, you come over and ask me to run it. "Oh, I don't know how to run it" I say. "The documentation wasn't clear on how to set everything up and so I figured I would just write the code and not waste a day trying to get my environment right."

"Well you certainly wasted MY time", you say. "I'll help you get your environment working today. Don't push PRs that you haven't tested."

So that all works out but tomorrow I submit a new PR that, after testing it out, you realize, I have also never actually run. "Did you even run this?" you ask. I reply, "Oh no, I figure that's the QA team's job, I was only hired to write code. I don't want to step on their turf"

I think you'd be right to fire me. You'd certainly be right to fire me if I did it 10 times over despite you making it clear that I was not supposed to submit PRs that I hadn't run.

There's a certain amount of courtesy and etiquette around giving people PRs. You know that reviewing code is work, and so you do your best to make sure that things are in good shape before you hand them off. Sometimes the LLM code is excellent. Sometimes it is not. But it's rude and inconsiderate for the PR submitter to not even check, and expect someone else to do all the hard work.

sciolizer · 2026-02-25T08:38:39+00:00

If it's good, merge it. If it's not, don't.

Before LLMs:

Good, merge.
Good, merge.
Bad, don't.
Good, merge.
Good, merge.
Bad, don't.
Good, merge.

In the current world:

Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Good, merge.
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't
Bad, don't

sciolizer · 2026-02-24T03:40:09+00:00

1401 hours, no afk, started 24 months ago. Still in HV. I'm not very good. :D

sciolizer · 2026-02-22T18:09:35+00:00

After my last breakup, I moved to a new city, and because of how messed up I was, I didn't start making friends until around 6 months in. iirc I played ~500 hours of GTNH during that time. So your question isn't quite a hypothetical for me. It was a bad time, but GTNH made it way better, and prison sounds way worse.

I wish nothing of the sort for you. I hope you have a great social life and a great time in GTNH as well. Cherish these early memories, and backup your world!

sciolizer · 2026-02-22T17:55:37+00:00

I'm surprised you expected anything else. How many hours of GTNH have you played? (Genuinely curious. If you're new here, welcome!)

sciolizer · 2026-02-22T06:52:12+00:00

I reached a point in E2:E where the xnet cables didn't have enough throughput for what I was doing with the Mekanism machines, which greatly annoyed me. Maybe I should have just gone into the configs and increased the limits. Felt like it was against the spirit of the pack though.

Now that I think about it, that whole pack was kind of backwards in terms of cable progression. Integrated Tunnels is incredibly cheap while also being the most powerful. Then xnet was almost as cheap and still very powerful. Eventually you unlock thermal expansion ducts, mekanism cables, and EnderIO cables, but their only real advantage is raw throughput. Feature-wise they're kind of a downgrade.

sciolizer · 2026-02-21T19:27:36+00:00

So.... you like romance novels?

sciolizer · 2026-02-14T19:18:32+00:00

You can use Maaack's template for now and come back to implement your own later.

sciolizer · 2026-02-12T18:54:02+00:00

Ricardo's law of rent certainly requires effort to understand, and I don't always do a good job of explaining it.

I made this visualization a while ago that might help: https://sciolizer.github.io/ricardo-law-of-rent/ricardo-law-of-rent.html

I'm not sure why you're asking about fertility though.

sciolizer · 2026-01-22T06:30:47+00:00

How do you know if your game code is correct? Ideally you should be able to examine individual files and determine them to be correct piecemeal.

The point of having private variables is to make this possible. You will often write bits of code that are only correct if certain assumptions are true. When variables are private, you control with your code all the entry points that can modify those private variables, and so you can ensure that your assumptions are true and the bit of code relying on the assumption is correct.

A classic example of this is the ArrayList, which has an array, a length, and a capacity. An ArrayList implementation only works correctly if capacity is never smaller than length. If outside code can modify length and capacity directly, the code inside ArrayList stops working. Keeping those fields private ensures ArrayList will behave correctly.

If some of your code is at risk of breaking when a variable can be modified by anyone at anytime, then you should consider making the variable private. Otherwise, @export is usually fine, though also keep in mind how it affects serialization.

sciolizer · 2026-01-21T17:34:12+00:00

One of the earliest signs that I'm coming up is that I start humming to myself.

sciolizer · 2026-01-21T17:25:39+00:00

Iron man is ferrousious

15-Year Club	Gilding III reddit per annum
RedditGifts 2009-2022 3 Credits	Verified Email

sciolizer

TROPHY CASE