shape_warrior_t

joined 2 weeks ago
 

Found this article via a comment on Lobsters for a completely different article. It's not exactly the type of knowledge I see myself using in the immediate future, but I think it's still interesting and educational to think about.

You can get the exclusive behaviour with random.randrange. (Relevant Stack Overflow question with a somewhat interesting answer)

...Interesting idea. (And also interesting lore implications? Not that the game has any...)

My main thinking right now is: on startup, have the player on an empty field and force them to move (on both inner and outer "axes") onto a specially marked square (and press spacebar) to enter the main menu. (Controls and what they do will be explained in text.) This gets them accustomed to moving around and pressing the CONFIRM key for menuing.

Then have a special tutorial level to introduce the actual gameplay -- similar to the "real" levels, but much slower BPM and attacks are scripted instead of randomly chosen. I don't want to force anyone to complete the tutorial before entering the actual levels, but it would be the menu item that the player first lands on (aside from maybe the one for changing the controls to something less strange than A/D/J/L).

The tutorial level would require some more code, but at this point that might be worth it. (And also it would add another option for user-made custom levels if somehow people decide to edit those in.)

...Honestly, the one thing I'm most concerned about at the moment is getting players to read text, especially if it's off to the side to avoid covering the playfield.

[–] shape_warrior_t@programming.dev 2 points 3 days ago* (last edited 3 days ago)

Probably a good idea, but not one that fits my current vision of the game, unfortunately. Especially since my main idea for adding complexity is increasing the number of sides (square->pentagon->hexagon), so each level already has a different-looking playfield.

...Right, I kind of forgot that the directory structure for my repo doesn't need to look anything like the directory structure of the releases. Thanks for prompting me to think about that.

[–] shape_warrior_t@programming.dev 2 points 3 days ago (4 children)

That was certainly not the first piece of feedback I was expecting to get, but it is one that's good to take into account! I forgot that what seems obvious to me might not be obvious to people who've never seen the game before. I'd like it if players could learn the full game without resorting to textual tutorials, so I'll have to find ways to teach things more clearly, but for now I've updated the README to hopefully make things more clear. Thanks for the feedback!

 

Just wanted to publicly announce this project at this point in time. All the info is on the GitHub page. If you have any feedback, or find any bugs or issues, please let me know in the comments.

[–] shape_warrior_t@programming.dev 6 points 4 days ago (2 children)

Interesting way of handling project vs global scope:

Some package managers (e.g. npm) use per-project scope by default, but also allow you to install packages globally using flags (npm install -g). Others (e.g. brew) use global scope.

I like the idea of allowing both project and global scope, but I do not like the flags approach. Why don't we apply a heuristic:

If there is a .sqlpkg folder in the current directory, use project scope. Otherwise, use global scope.

This way, if users don't need separate project environments, they will just run sqlpkg as is and install packages in their home folder (e.g. ~/.sqlpkg). Otherwise, they'll create a separate .sqlpkg for each project (we can provide a helper init command for this).

Seems rather implicit, though, especially if the command output doesn't specify which scope a package was installed in. If a user moves to a subdirectory, forgets they are there, and then tries to install a package, the package will unexpectedly install in global scope (though this particular version of the problem can be solved by also looking in parent directories).

[–] shape_warrior_t@programming.dev 4 points 1 week ago (1 children)

Played a few rounds just to get an idea of what the game's like. Seems interesting. It took a while to actually figure out what controls were available and what the cards might do. Sometimes the stickmen would group up in the left corner and stay there for a good while, and there was seemingly nothing that could be done about it. The mechanism for scrolling felt a bit awkward to me, especially since the screen scrolled by such a large amount per click. Just some general notes about my experience, take them into account in whatever way best suits your game's vision.

 

An interesting article that lays out a problem and goes through a few different solutions, some of which I haven't thought about much before.

I'm working on a video game in Rust, and I'm running into this kind of modelling problem when it comes to keeping track of the game state. So far I've refactored something that resembles Approach 5 into something that looks more like Approach 3. As I get more confident about the final shape of the data, it (seemingly) becomes a better idea to represent it in a more structured way.

[–] shape_warrior_t@programming.dev 13 points 2 weeks ago (1 children)

Can't resist pointing out how you should actually write the function in a "real" scenario (but still not handling errors properly), in case anyone wants to know.

If the list is guaranteed to have exactly two elements:

fn is_second_num_positive_exact(input: &str) -> bool {
    let (_, n) = input.split_once(',').unwrap();
    n.parse::<i32>().unwrap() > 0
}

If you want to test the last element:

fn is_last_num_positive(input: &str) -> bool {
    let n = input.split(',').next_back().unwrap();
    n.parse::<i32>().unwrap() > 0
}

If you want to test the 2nd (1-indexed) element:

fn is_second_num_positive(input: &str) -> bool {
    let n = input.split(',').nth(1).unwrap();
    n.parse::<i32>().unwrap() > 0
}
 

Thoughts? It does feel like there's a lot of things you can do in comments that would be impossible or impractical to do in names alone, even outside of using comments as documentation. There's certainly much more information that you can comfortably fit into a comment compared to a name.

One of the comments in the Lobste.rs post that I got this from stuck out to me in particular:

Funny story: the other day I found an old zip among my backups that contained the source code of game that I wrote 23 years ago. I was just learning to code at the time. For some reason that I forgot, I decided to comment almost every single line of that game. There are comments everywhere, even for the most obvious things. Later on, I learned that an excess of comments is actually not considered a good practice. I learned that comments might be a code smell indicating that the code is not very clear. Good code should be so clear, that it doesn’t need comments. So I started to do my best to write clear code and I mostly stopped writing comments. Doing so only for the very few parts that were cryptic or hacky or had a very weird reason for being there.

But then I found this old code full of comments. And I thought it was wonderful. It was so easy to read, so easy to understand. Then I contrasted this with my current hobby project, which I write on an off. I had abandoned it for quite some months and I was struggling to understand my own code. I’ve done my best to write clear code, but I wish I had written more comments.

And this is even worse at work, where I have to spend a ton of time reading code that others wrote. I’m sure the authors did their best to write clear code, but I often find myself scratching my head. I cherish the moment when I find some piece of code with comments explaining things. Why they did certain things, how their high level algorithm works, what does this variable do, why I’m not supposed to make that change that looks like it will simplify things but it will break a corner case.

So, I’m starting to think that this idea that comments are not such a good practice is actually quite bad. I don’t think I can remember ever reading some code and thinking “argh so many comments! so noisy” But, on the other hand, I do find myself often in the situation where I don’t understand things and I wish there were some more comments. Now I’m trying to write comments more liberally, and I think you should do the same.

I guess that’s a generalization of the op’s idea.

I can imagine Berdly Deltarune trying to explain this to Kris and Noelle in roughly this tone of voice.