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

"the problem with rust is nobody has written a nice library to solve a complicated problem that i don't want to solve myself"... ok i just have to sanity check, what engines did this person say they've used

QuoteWe've released a few games across Rust, Godot, Unity, and Unreal Engine, and [..]

OH, THEY'RE COMING FROM ONLY HAVING USED THOSE ENGINES, AND BEVY/RUST???

next three points are complaints about specific GUI implementations in the ecosystem. sure, whatever. i like Godot's system. i also like HTML and CSS. most other GUI systems are crap and all i need is to draw some text to the screen anyway.

QuoteWhat I'd want instead is to have a very pretty GUI, with lots of custom sprites, animations, vector shapes, particles, effects, flashes, etc. I want my button to wiggle when it's clicked, I want my text to animate as it's hovered, I want to be able to use a custom shader and distort it with a noise texture. I want particles to fly around when a character box is selected.

so just, like, do those things???

I'm not going to go bullet by bullet anymore, I don't think it's worth it. Clear formatting isn't worth it, anyway. Let's see.

"Procedural macros" ok ok ... "using reflection in C# is extremely easy, and if performance is of no concern (which it often isn't in cases where reflection is used) it can be a very quick and useful option for building tools or debugging. Rust doesn't offer anything of the sort" ... well I do like tools and debugging, in theory! In theory. Somehow I've managed to make games with bad tools and debugging habits. Maybe it has created an obsessive need for completely understanding a structure. But debugging has always been kind of a nightmare. This sounds so dumb but why not just make a game that you don't have to debug that much??? Huh???

...

"Hot reloading is more important for iteration speed than people give it credit for"

I AM NOT CONVINCED THAT THE TOMORROW CORPORATION TECH DEMO ACTUALLY REPRESENTS SOMETHING
USEFUL FOR ME. I don't work with others well. I just want to understand the thing I'm building -- and I can get to the finish line that way.

"Debugging with immediate mode drawing/geometry. This is probably my favorite use case, especially around debugging character controllers and physics, where I might enter an unexpected/buggy state, and with hot reloading I can simply add a line few lines to draw the relevant values in-game to see what's happening without having to reproduce the issue again."

Yeah, this is legit. One of the biggest issues I had with trying to break out of Godot a while back was how difficult it was to get the onscreen representation of something to work. Being able to visually wiggle a thing around to get it into the right spot or to go at the right speed... really useful. A killer feature, compared to bare code.

I'd rather have a good tool than hot reloading. Hot reloading is a crappy cheap half-measure. Sometimes you need a crappy cheap half-measure but I don't like 'em.

QuoteMaking a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that

Again, this seems like it sums up previous points... holy hell, I hate the way this article is laid out. Truly genuinely awful. Impossible to parse.

I just want to say that the problem being described is not a technological problem. Nobody is forcing you to prototype in Rust, it's a game engine not a prototyping tool. These are allowed to be separate things. As a designer, you may choose to prototype in the same engine in which you program your game, but that is a choice. Hmm. I need to get this through to myself somehow.

QuoteECS solves the wrong kind problem

Not a useful header. OK, so what's the content of this section? What is 'the wrong kind of problem'?

Quotemany times people use ECS because it solves the particular problem of "where do I put my objects", without really using it for composition, and without really needing its performance

OK, interesting. I skimmed the previous chunk of this section, but I saw there was some stuff about performance. I, too, do not really need performance. But composition? What's that?

... back

QuoteECS as dynamic composition, allowing combinations of components to be stored and queried and modified together without having to be tied in a single type.

OK, what's the benefit of this, why might I care...

QuoteI've been in countless arguments where someone tried to convince me how I absolutely should be separating Position and Health out of my objects, and how my code is spaghetti if I'm not doing that.

Oh, I've encountered this, haha. Yes, LogLog, we're on the same side of this argument here. I also like "fat components."

Quotegenerational arenas generational arenas generational arenas

I don't have a clue what generational arenas are. TODO: What are generational arenas?

QuoteGeneralized systems don't lead to fun gameplay

OK... Immediate response: fun systems can be generalized, though.

QuoteHere's a few things that I think create good games, that are going directly or indirectly against generalized ECS approaches:

A lot of these are things that don't quite gel with how I've designed some of my games, like Probability 0, Starseed Pilgrim... but  since moving to Godot I have made a lot more games that leverage this particular strength of Godot. But for the most part these are things I kinda don't like? I won't get into it.

I'll bring this one up though because I'm not sure what's being described:

Quote- VFX that are not based on having lots of same-y particles, but time synchronized events (e.g. multiple different emitters firing on a hand-designed schedule) working across all the game's systems.

Oh, okay, this is just talking about a thing that needs a timeline. Not really my jam.

QuoteA good example game here would be The Binding of Isaac, which is a very simple roguelike with hundreds of upgrades that modify the game in very involved, interactive and deeply complex ways.

Hmmmmmm. I disliked BoI and I think this might be part of why? Hmmmmmmmm.

When I designed SSP I wanted "La-Mulana but it follows an underlying logic." I like an underlying logic. It's fine if that's not what you want to make, though.

QuoteRust is the type of language where wanting to do a new type of upgrade might lead you down a path of refactoring all of the systems, and many would even say "that's great, now my code is much better and can accommodate so many more things!!!". It sounds like a very convincing argument [..]

Actually it really does not sound like a very convincing argument at all!
This sounds like hell. Don't... don't do this. Or, I should say, I don't want to do this, I want to lay out a big block, a big canonical system, and say "This is the game," and then carve pieces out of it.

I still think about the one side chamber in PZERO. It felt like I was breaking a rule. I was breaking a rule. It was significant to me because I set rules up ahead of time and then the game was allowed to live and breathe within those rules.

Making games not like that seems like an exercise in madness now that I'm thinking clearly about it.

QuoteA more flexible language would allow the game developer to immediately implement the new feature in a hacky way, and then play the game, test it and see if the feature is actually fun, and potentially do a bunch of these iterations in a short amount of time.

See above.

Oh, the author links this talk about game design as search. Good talk, I recommend it.

Game design as search. Hmm. I'm beginning to wonder.