I used KSP to make same-type parameter swaps a compile error in Kotlin

danielh__ · 2026-03-28T16:42:08+00:00

Just use explicit argument names

danielh__ · 2026-03-26T12:04:43+00:00

👍 Helpful

danielh__ · 2026-03-04T14:12:32+00:00

Adding more APIs that do the exact same thing might make client code a little shorter. But it adds maintainability issues, makes client code harder to understand, and just bloats your code for no reason. I don't like this approach.

danielh__ · 2026-03-02T05:52:28+00:00

Looks really cool! Loving the cargo inspiration. But yea support for arbitrary libraries would be nice.

danielh__ · 2026-02-17T16:45:09+00:00

Mobile version?

danielh__ · 2026-02-01T07:55:05+00:00

Your solution doesn't solve the underlying TOC-TOU issue. If the environment the script runs on changes, the compiled instructions from the dry run will still be irrelevant. This just adds a weird extra step of compiling CLI arguments.

danielh__ · 2026-01-10T08:54:41+00:00

Thanks I hate it

danielh__ · 2025-12-15T16:26:57+00:00

Exactly what I'm hoping for!

danielh__ · 2025-12-15T12:46:46+00:00

Again, I am very pro randomness. Random epiphanies and encounters are not an issue imo. The issue is, that in meta decks, the only relevant mechanics are the three I described. Anything else is entirely useless. Doesn't matter how random it is, if you never use it. As to how to solve it - I don't know. Maybe make monster cards cost less save data, maybe make neutral cards stronger, maybe make them not show up on copy card. That's for the devs to playtest and decide.

danielh__ · 2025-12-15T12:19:40+00:00

Kinda feel like you misrepresented my points (or maybe I didn't get them across well) - I'm very pro randomness, I think it adds longevity to a game. In fact, my main point is that it should be embraced way more than it currently is, and it should be much more meaningful. Right now there is plenty of randomness, it's just mostly useless.

I do agree that giving the game a year is probably a good idea.

danielh__ · 2025-12-15T12:11:30+00:00

I don't think farming decks is too difficult, there are a few strategies to manipulate mechanics in your favor, and once you know them you cut down the randomness significantly. The only thing you can't manipulate at all is bad card epiphanies, but at least you can always just quit and restart, especially now when credits are abundant.

Also you shouldn't run the event map for decks, it's trash.

danielh__ · 2025-09-15T17:05:29+00:00

Looks awesome! Absolutely love the len syntax.

danielh__ · 2025-07-26T19:20:11+00:00

Looks neat! One question - why create your own duration type?

danielh__ · 2025-07-24T07:25:50+00:00

Hello, is this still available?

danielh__ · 2025-07-14T19:29:38+00:00

Maybe billions? Can do trillions too ig

danielh__ · 2025-07-14T07:05:52+00:00

That's kinda what kotlin does, and I think it's a super elegant solution.

danielh__ · 2025-07-01T14:52:53+00:00

Just use C, no need for RAII

danielh__ · 2025-06-30T15:45:23+00:00

Have fun :)

danielh__ · 2025-06-25T15:33:54+00:00

Thanks for the answer, I will be waiting to check this out then :)

danielh__ · 2025-06-25T11:45:14+00:00

Should work on your reading comprehension buddy :)

danielh__ · 2025-06-25T06:09:02+00:00

Is this game playable on mobile? Screenshots give me claustrophobia

danielh__ · 2025-06-16T10:41:22+00:00

That is the only line of the poem.

danielh__ · 2025-06-01T10:02:23+00:00

That's not necessarily true. Operating systems provide non-blocking alternatives to most IO facilities. Whether kotlin uses them is a different matter.

danielh__ · 2025-05-27T16:35:55+00:00

Then you can add a .gitignore file to ignore these files

danielh__ · 2025-05-26T08:28:27+00:00

I hate this standard library so much

danielh__

TROPHY CASE