There are also a handful of 3d terminal/ASCII engines out there like this one: https://github.com/sephirot47/AsciiEngine
Arguably less useful than something like pygamelib, but still pretty fun.
A (not so) small library for terminal based game development
11–20 of 23 posts
Re: A (not so) small library for terminal based game development
#12Earlier quoted context omitted.
They want people to learn not to mess things up. You learn not to mess up by trying things out and messing up.
That's a bad strategy. The reason people are tempted to mess with internals is that it works most of the time. Unless the library has some way of punishing people who use them, then they'll just do it without regard for, as far as they're concerned, arbitrary toothless restrictions. Sure, some stuff will break, but that's true even if they're respecting the API boundary too, especially for a beginner. There will be z…
I think it's fine to encourage beginners to engage with the internals of an API and do things that are unwise. The goal is educated pupils, not successful or maintainable projects. Let them play in the mud and get dirty. I think the idea that code is something that can be experimented with is one of the most valuable lessons, and breaking things is frequently the path to learning how they work.
Maintainability is one of the finer points that can come later.
Re: A (not so) small library for terminal based game development
#13If pygamelib interests you, you might also be interested in Pyxel: https://github.com/kitao/pyxel
+1 for Pyxel, recently used it for a couple of hours to create a tiny project [1] and loved how intuitive it was.
Re: A (not so) small library for terminal based game development
#14With the Windows terminal stack just now merging Sixel support and good clients available on other platforms quick cross platform but graphically heavy terminal games/apps/hacks could get real interesting soon.
Re: A (not so) small library for terminal based game development
#15Earlier quoted context omitted.
I don’t understand the reasoning; you’d add protections if you wanted them to learn to use the APIs. You’d remove them if you wanted them to mess with the internals of each class.
They want people to learn not to mess things up. You learn not to mess up by trying things out and messing up.
Yeah, you learn valuable lessons like “don’t mess with the code this guy makes, he puts traps on it”
Re: A (not so) small library for terminal based game development
#16Earlier quoted context omitted.
That's a bad strategy. The reason people are tempted to mess with internals is that it works most of the time. Unless the library has some way of punishing people who use them, then they'll just do it without regard for, as far as they're concerned, arbitrary toothless restrictions. Sure, some stuff will break, but that's true even if they're respecting the API boundary too, especially for a beginner. There will be z…
I think it's fine to encourage beginners to engage with the internals of an API and do things that are unwise. The goal is educated pupils, not successful or maintainable projects. Let them play in the mud and get dirty. I think the idea that code is something that can be experimented with is one of the most valuable lessons, and breaking things is frequently the path to learning how they work. Maintainability is one…
Oh, certainly. That's much more reasonable than what this project claims to be trying. :)
Re: A (not so) small library for terminal based game development
#17Earlier quoted context omitted.
> There is little protections against messing up with the internal. This is on purpose, I want the kids to learn to use the API not mess up with the internals of every single class.
I don’t understand the reasoning; you’d add protections if you wanted them to learn to use the APIs. You’d remove them if you wanted them to mess with the internals of each class.
They mean that their code is written with strong assumption everything is written the way it is. If you make modifications to the internal or push an unexpexted type in it, they expected it to fail. There's no guardrail that everything is in a right state.. well, standard internal code.
Re: A (not so) small library for terminal based game development
#18Earlier quoted context omitted.
That's a bad strategy. The reason people are tempted to mess with internals is that it works most of the time. Unless the library has some way of punishing people who use them, then they'll just do it without regard for, as far as they're concerned, arbitrary toothless restrictions. Sure, some stuff will break, but that's true even if they're respecting the API boundary too, especially for a beginner. There will be z…
I think it's fine to encourage beginners to engage with the internals of an API and do things that are unwise. The goal is educated pupils, not successful or maintainable projects. Let them play in the mud and get dirty. I think the idea that code is something that can be experimented with is one of the most valuable lessons, and breaking things is frequently the path to learning how they work. Maintainability is one…
Games are notorious for vendoring a dependency and never upgrading it again. If you use an internal API, it is not like you are forced to be on the upgrade treadmill where the sands suddenly shifted and the secret API does something different.
Re: A (not so) small library for terminal based game development
#19If pygamelib interests you, you might also be interested in Pyxel: https://github.com/kitao/pyxel
This is very cool!
As an aside, I find it frustrating how different Python packaged want to be installed in different ways. Pip this, conda that, and now… pipx?
I worry about how all these systems will interact and conflict.
Re: A (not so) small library for terminal based game development
#20If pygamelib interests you, you might also be interested in Pyxel: https://github.com/kitao/pyxel
This is very cool! As an aside, I find it frustrating how different Python packaged want to be installed in different ways. Pip this, conda that, and now… pipx? I worry about how all these systems will interact and conflict.
pipx is not a different packaging system. It uses pip.
Conda is mostly used by data science people for some reason.