A (not so) small library for terminal based game development
1–10 of 23 posts
Re: A (not so) small library for terminal based game development
#2If you don't want people to use the internals, why not make them `__private`?
Cool project!
Re: A (not so) small library for terminal based game development
#3If you don't want people to use the internals, why not make them `__private`? Cool project!
> 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.
Re: A (not so) small library for terminal based game development
#4If you don't want people to use the internals, why not make them `__private`? Cool project!
> 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.
Re: A (not so) small library for terminal based game development
#5Earlier 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 want people to learn not to mess things up. You learn not to mess up by trying things out and messing up.
Re: A (not so) small library for terminal based game development
#6Earlier 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.
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 zero learning about API boundaries in particular.
Re: A (not so) small library for terminal based game development
#7If you don't want people to use the internals, why not make them `__private`? Cool project!
> 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 left this shotgun here, kids need to learn that shooting yourself in the foot really hurts."
Re: A (not so) small library for terminal based game development
#8If pygamelib interests you, you might also be interested in Pyxel:
Re: A (not so) small library for terminal based game development
#9I love ASCII/terminal games. The creativity involved with creating a graphical game in something that was only ever meant to display lines of text is super interesting to experience for yourself. This project far surpasses my own personal library for terminal games, well done.
Re: A (not so) small library for terminal based game development
#10Earlier 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 left this shotgun here, kids need to learn that shooting yourself in the foot really hurts."
This is parenting 101 for anything non-permanent. For a piece of software it's basically common sense.