I suppose that writing out the questions above have exorcised any desire I might have had to do them. That's acceptable to me. I tried doing them yesterday. I let them go.

day 2, i have a game idea from yesterday that has lost all appeal, but the story i wrote a week ago still speaks to me, as does especially the minor life event that i wanted to record. it is diary game time, as described in Yes, this is the way it is.

BLARGH. This is a lot more work than I want to deal with tonight!! I am going to bed!!!

It's important to me to finish something each day. I guess I do have an idea. What should I do tomorrow? If GB has defeated me (has it?) then I look forward to trying to implement it in something else.

the big engine search day 1 result: DEFEATED BY GBDK.

Backlink - the big engine search

OK, I have a nice basic idea. I'm going to start a gb project from scratch... I just want to make a teeny tiny infinite climber. With my new understanding of KISHOTENKETSU, though, I want to be sure that there is a twist.

ki - You are at the bottom of the tower
sho - You begin to climb the tower, it is difficult because

(MINI DESIGN CHALLENGE #1; why is it difficult?)

... OK, keep it simple: it is difficult because you can miss a platform and fall! And if you fall off the bottom of the screen, you die. (The screen scrolls up when you pass the halfway point.)

ki - You are at the bottom of the tower.
sho - You are climbing the tower, jumping from platform to platform, and if you fall then you die (GAME OVER)
ten -

(MINI DESIGN CHALLENGE #2; what could be unexpected, what twist could there be?
gravity reverses? the platforms start to fall? an enemy starts to chase you? you start to collect little coins? locked doors?
suddenly there's a timer: enemies pour out of windows in the tower)

ki - You are at the bottom of the tower. The tower has platforms and windows. you can run and jump.
sho - You are climbing the tower. There are easy jumps and difficult jumps, and you usually choose the easy jumps. Why not, right? There are coins that give you points, though. You want those points.
ten - Some of the windows have glowing blinking eyes inside them. Bats burst out of one of them when you get too close, giving you quite a fright ---- perhaps knocking you off the tower?
ketsu - You get to the top of the tower. You win! Give the player a score and send them on their way.

----

TECHNOLOGY:
- How the hell do I do a scrolling tower sequence?
- How do I do platforms? I am going to do simple one-way platforms.
- How do I do the bats that attack you?
- Points, I need to track points
- How do I generate the level? . . . I should just design it by hand, that'll be easiest.

Today I've been learning GBDK using a set of tutorials by GamingMonsters... my response so far to making gameboy games is that it's easier than I expected! I'm running into friction, and I want to put my finger on exactly where that friction lies.

I am hesitating to create methods. I probably shouldn't; I want to take high level actions, I want to structure things neatly, nest them inside each other... handle problems within their contexts...

As mentioned in my close reading of Leaving Rust, I am trying to find a new engine maybe. Or maybe I'm just learning about what I like by trying other things.

QuoteClosing thoughts

QuoteWe've been using Rust on basically all of our games since mid 2021. This was when BITGUN initially started as a Godot/GDScript only project, and as we ran into issues with Godot's pathfinding (both performance and functionality wise) I looked into alternatives [..]

Quote[..] the article isn't written from a point of ignorance or not trying the correct approach. The #1 argument I hear people say when someone points out issues with Rust as a language is, jokingly, "you just don't have enough experience to appreciate this". We repeatedly tried both more dynamic and fully static approaches to doing things. We tried pure ECS, and we also tried no ECS.

I don't know if I'm correct about what I want, but very few points here have at all contradicted what I think I want.
In particular, I suppose I don't think that this person did ever try the correct approach, because the game that they produced looks like it was made by a Unity dev. This is not meant to be derogatory, it has a kind of vibe about it. It doesn't strike me as the kind of game I'd seek to make with something like Rust, and I can see where trying to design a game like this full of casual rules exceptions and stuff would run into problems.

QuotePositives of Rust

i will take this section with a grain of salt but maybe it will be useful!

- nice compiler (i know this already, yes it is quite nice)
- it is performant (cool, truly good to know!)
- enums are nicely implemented (yes so are a bunch of other things, it's a nice language for programmers)
- weird backhanded compliment about a feature i know nothing about, skip
- traits (see comment on enums)

hmm

'orphan rule' ... this is something about rust crates, i.e. the ecosystem ... i don't know if i have the capacity to care about ecosystem woes

compile times ... i care about this a lot! no clear information, i'll have to try it for myself

people are excited about Rust, there's hype ... i don't care, this might be useful to someone who has been touched by Rust hype, i have not. ah, more about the ecosystem, e.g. there's no good 2D physics library! i don't mind. i'm going to be making weird little systems, i grew up in a time when physics engines were not good. when i use Godot's physics engine i feel a bit filthy and i constantly expect it to break. i will never outgrow this feeling, i suspect.

... something about global state, too complicated for my sleepy brain right now to read
... something about crashes and 'dynamic borrow checking', is this a real thing
... skip skip skip, sleepy brain, forgive me tomorrow