Quick question-- doesn't "while the program runs" mean "as it's interpreted"? Am I misunderstanding something here?

That's what it means as far as it is useful to you; you have the right understanding.

There are always nuances. "Interpreting" a language means something specific: the runtime is reading the code and executing it as it's reading it. This is in contrast to a compiled language, which is compiled (turned from source code into another representation closer to the machine, something like the actual CPU might execute) and then that compiled version is executed.

Interpreting is generally slow; executed a compiled binary is generally fast. But the main ruby implementation also now has a just in time compiler, so sometimes Ruby is actually compiling the source after interpreting down into a lower level representation for the Ruby VM...

So: "while the program runs" is logically equivalent to "as it's interpreted", although it may or may not be strictly literally the same. 😅

(note that they look like keywords, but are actually methods)

I was just looking at this the other day with a coworker!

the class's methods are being passed as arguments by the access control methods. The text says it's rare to declare access like this.

That's actually how it came up in my discussion with my coworker. Ruby is a super dynamic language and you can declare methods at runtime; you can also use the access control methods with arguments to change their access control. It's definitely rare to declare access like that, but not nonexistent!

I was curious why they're passed as symbols, though. I read a little bit of the documentation but couldn't find the area that covers this specific answer myself. I knew that symbols are referenced values that can be passed like any other value-- but why not pass it as the method name itself? ... This is important, because Ruby will attempt to execute the passed method if it isn't a symbol. In short, it instead references it rather than executing it. I think this is correct anyway, but let me know if I have that wrong at all.

I think that's right, although not quite how I think about it maybe.

When you define a variable, that's sort of different from when you access it. The language decides how to interpret your code based on context.

x = 1
x

When the runtime sees x it looks it up to see if it knows what it is and what to do with it. The same is true of methods.

foo()

When it sees foo() it looks it up to see if it knows what it is. If it does, it executes it; if it doesn't, it raises an exception. And since methods can be called without parentheses, when it sees something like:

bar

then Ruby actually looks up bar to see if it knows if it's a variable or a method.

So yes, if you were to try to write something like:

def foo
  # ...
end 

private foo

Then yes — when it reads foo it will try to look it up to see if it knows what it is. Just like it looks up private to see if it knows what it is. So no, syntactically it wouldn't work to do so — not without special additions to the language. Just like when you write def foo it's special — def is a keyword that says "the next identifier is being defined right now". But we already know that private isn't even a keyword, it's just a method, so there aren't any special additions anywhere!

Symbols are useful as labels. Just like you might use them as hash keys; conceptually you can think of Ruby as maintaining a hash of something that might look like:

{
  foo: <implementation of foo>,
  bar: <implementation of bar>,
}

And so private :foo means something like, "set the method identified by :foo to private`.

That's all of what was said before, but maybe just phrased differently.

He also mentions this is because ruby is a "synchronous language", which I had to Google, only to learn that it means the language is more "reactive" and that it instantaneously / deterministically reacts to input events from its environment.

I think that part of the article is... fuzzy at best. I would describe this behavior just in terms of how the language is specified. foo means "look up foo and then if it's a variable we're talking about it's value and if it's a method go ahead and execute it." I don't think the word synchronous is useful there.

How would this compare to other languages? A source said that asynchronous is multi-thread (operations can run in parallel), while synchronous runs only one at a time. Does that have anything to do with the difference between interpreting a language line-by-line rather than compiling it?

Nope! Totally separate ideas. Think of interpreting a language as reading if foo then bar one little bit at a time and telling the computer how to execute it. Think of compiling as reading if foo then bar and spitting out 001010100010100010101 into a new file which happens to correspond to something that's the same, when you then run the compiled code.

Ruby does have threads, and it has "green threads" with Ractors now, for concurrent and parallel programming. That's a whole separate topic that you don't need to worry about for a good while. Many web devs never learn it; though if you work in anything less forgiving or more demanding you need to know a bit.

Oh! The book is mentioning this implementation now too. It says that defining a method with def returns a value ( "the name of the new method as a symbol" ). I'm glad I read a little more though, becuase I think that would have confused me if I hadn't.

Everything is a value! That value can be used! It's a great feature of Ruby. Beware of nil. :)

This form is the text's preference, because access is more explicitly applied to each method. The first form is the more conventional, but older, way.

The text's advice is probably right. I've been writing it for forever so I use the older way. 😬

I learned that the assignment aliases an object, which means you can have multiple named variables referencing the same object in memory.

The text explains this can cause problems, but not very often, even in other languages.

I suppose the "not very often" is true in my experience, but it's come up in my career as a category of bugs probably more than most. I find this area critical to know about in every language.

This is colloquially known as "monkey-patching". Does this mean that, whenever I redefine a class definition, I'm monkey-patching?

It depends on what you mean by redefine. Generally the question is: Do I own this type or does something else, maybe even the standard library, own this type?

If I write

class Foo
  def bar; end
end

class Foo
  def baz; end
end

Is the second instance monkey-patching? Well.. it's certainly weird to write it like that, but it's all my code, and I can structure it how I want, and it's all part of my software. Nothing in Ruby is using my Foo, and no other libraries are using my Foo. But if I write

class Integer
  def foo; end
end

well in that case, I'm altering something from the standard library that everything is using. Every library is using integers!

So if some code is expecting abs to return the absolute value of an integer, as is reasonable and is documented, then their code might stop working in strange ways were I to put this somewhere in my program:

x = -1
puts x.abs

class Integer
  def abs
    999
  end
end

puts x.abs

That replaces the abs methods for all integers everywhere. So that's monkey patching.

I thiiink this means I might have redefined Ruby's standard method open to instead funciton specifically for my own game's engine (i.e. opening containers). I wonder if this will cause a problem later on. According to the documentation, it's for opening files and other input-output functions.

Common words are common! I wouldn't stress. But this is also why we use classes and types!

class Door
  def open
    puts "Door is open"
  end
end

d = Door.new
d.open

open 'foo'

File.open 'foo'

d.open is not the same as open, and even if you def open; ... then you still have File.open to reference what you want.

But, it should be done with caution, since some teams don't allow it in their code unless there's an imperative reason to.

Yes. I generally won't let it into a codebase I manage. If we absolutely need to monkey patch to ship something, we do it. But if there's another way, we take the other way.

I enjoy the power and flexibility in Ruby that gives me that choice, though. Most languages have no such abilities. In my work, that means if a library that we depend on is broken, we can fix it while waiting for them to fix it (and contribute our fix back upstream). In other languages, it means you're just stuck until it gets fixed.

I know of a few spots in my own engine that monkey-patch a bit. As I refactor, I'm going to keep in mind that doing so to avoid unwanted global changes.

I'm curious! I'll have to look. I wouldn't expect that to the case; it's not common to stumble into.

There is another way to reopen and update classes, but with less ability to change them (refinements).

These are fun! And pretty new. They're slow in some cases, but that doesn't often matter.

Huge progress, congrats! You've got me working on a text game engine myself now. :)

Interpreting is generally slow; executed a compiled binary is generally fast. But the main ruby implementation also now has a just in time compiler, so sometimes Ruby is actually compiling the source after interpreting down into a lower level representation for the Ruby VM... Ruby does have threads, and it has "green threads" with Ractors now, for concurrent and parallel programming.

If it's slower, why is interpreting implemented? Compiling came first, right?

I don't think the word synchronous is useful there.

That is good to know. Thank you.

Common words are common! I wouldn't stress. But this is also why we use classes and types!

Deal! :D

Huge progress, congrats! You've got me working on a text game engine myself now. :)

Oh, neat! What is yours going to be like? Is it that one you talked about before, that plays in the background? I could talk for hours about text games.

By the way-- how do you decide what projects to collaborate on? Asking because I thought it could be fun to work on something together, but I'm not sure how you'd feel about that. I know my experience is limited to my isolated engine, but exposure to other projects could be exciting?

Anyway, I figured asking that question might at least help me know where / when to look for them.

If it's slower, why is interpreting implemented? Compiling came first, right?

Hmm, history! Wikipedia puts both approaches as early as 1952 (compiler, interpreter).

Everything in programming (life?) has trade-offs.

Interpreting is slow but flexible. You can change what the code does while it's running (like with open classes and monkey patching), or define new language features on the fly. Interpreters can also be much simpler to write. Eventually, you should write one! Here's a great pragmatic book on it: http://craftinginterpreters.com (eventually)

Compiling is significantly less flexible in the general case. It takes in one program and spits out an executable. That executable can be executed, but not easily changed. On the other hand, a compiler can take as much time as it wants inspecting the code and optimizing the executable that gets output — so it can become very, very fast.

And then it gets complex, where some compiled languages have very dynamic runtimes (like Objective-C), and some interpreted languages have lots of compiled pieces (Ruby is written in C and gems can be implemented in C and it has a JIT compiler).

What is yours going to be like? Is it that one you talked about before, that plays in the background? I could talk for hours about text games.

I think there's a joke about game developers not wanting to make games but game engines. I've been prototyping an engine that would power the game I mentioned before; but it could also power the rendering for any other terminal based game. It's focused on managing the terminal UI and layering in animations and special effects. There are only three visual elements in a terminal (I think): the characters printed out, the foreground color, and the background color. I've got ideas about how terminal games could use those three things to add some interesting experiences.

Here's a very hard to watch trippy proof of concept: https://imgur.com/3K8Jzk6

It's hard to tell, but all of the characters and the foreground colors and the background colors are changing. It's just prototype level code powering it; tons more to do to tidy it up.

Some idea for what you could do with it in a text adventure:

day night cycle by having the background colors change through daytime, sunset, night, dawn
cast fireball -- an explosion animation is played in color behind and in and around the words on screen
low on health: the corners pulse dark red, blood "drips" by changing characters red in a falling down fashion
you don't know an NPC's language: their speech is constantly changing which characters are displayed

I'm sure there's prior art that I'm unaware of, but it's a neat idea to me nonetheless.

By the way-- how do you decide what projects to collaborate on? Asking because I thought it could be fun to work on something together, but I'm not sure how you'd feel about that. I know my experience is limited to my isolated engine, but exposure to other projects could be exciting?

I haven't collaborated with many people outside of work — I don't usually actually do a large amount of development outside of work. I do contribute to open source when it comes up, but usually when it comes up with work. :)

But I'd be open to exploring a collaboration with you on project if we can find something that would work for both of us. If we did a text adventure we'd probably have to start an engine from scratch so that we don't step on the toes of your darling!

Eventually, you should write one! Here's a great pragmatic book on it: http://craftinginterpreters.com/ (eventually)

The idea that I can write an interpreter someday is wild.

I think there's a joke about game developers not wanting to make games but game engines.

I feel this! I could make a simple game with my engine as it is now, but I can't stop dreaming of features to add. The goalpost has been moving from "I want to make a game!" to "I want to make this engine." the last year or so. The idea that I could make infinite games with it became much more attractive than the game concept that inspired it.

It's focused on managing the terminal UI and layering in animations and special effects. There are only three visual elements in a terminal (I think): the characters printed out, the foreground color, and the background color. I've got ideas about how terminal games could use those three things to add some interesting experiences.

I'm super interested in this. Specifically, I've been wondering about what tricks the terminal hides that I don't know about when it comes to UI. I've gotten the text and background to change color, and have gotten text to blink. That's all though. As far as animations like this:

Here's a very hard to watch trippy proof of concept: https://imgur.com/3K8Jzk6

That is neat. I didn't realize you could do that! A year ago, I was stuck trying to make the game frames change. Initially, only one frame was supposed to be visible at all times. But, I couldn't figure it out, which is why it scrolls now. I slapped a page count on the end of each frame and called it a feature. It happens to work well for a story-themed game at least.

That makes me wonder, am I able to couple terminal programs with sound files?

Some idea for what you could do with it in a text adventure:

day night cycle by having the background colors change through daytime, sunset, night, dawn

Day / night cycles is such a great concept (especially for something like Bonecrawl where time passes and affects the gamepieces).

cast fireball -- an explosion animation is played in color behind and in and around the words on screen

That sure beats simply colorized text. For casting a fire attack, I was just going to have the text go red. Super great idea.

low on health: the corners pulse dark red, blood "drips" by changing characters red in a falling down fashion

This idea sounds super creepy and great-- do you envision it trailing like the matrix rain (but slower / with a fade effect)? I love how struggling to read could simulate struggling to survive.

you don't know an NPC's language: their speech is constantly changing which characters are displayed

Fun! Reminds me of the first time I played Link to the Past as a kid, before I found the Book of Mudora.

But I'd be open to exploring a collaboration with you on project if we can find something that would work for both of us.

That's great! I think it could be fun to design something together. I wouldn't want it to feel like extra work for you, though. I'm open to learning new concepts or engines before we started, or as tasks are assigned so I'm not dead weight.

I got a bunch of ideas in my journal if you want to spitball sometime :D (graphics could be fun?)

A year ago, I was stuck trying to make the game frames change. Initially, only one frame was supposed to be visible at all times. But, I couldn't figure it out, which is why it scrolls now. I slapped a page count on the end of each frame and called it a feature. It happens to work well for a story-themed game at least.

This is what you're missing: https://en.wikipedia.org/wiki/Curses_(programming_library)

The usual one used these days is the open source ncurses, which is installed in a lot of places already. Ruby has bindings to the library: https://github.com/ruby/curses

My demo stuff is built in Rust; partially because I want to learn it better, partially because I want it to be as fast as possible, and partially because I want to be able to compile a binary to distribute that would hide the source code as well as be easy for players to run.

The terminal manipulation is rather slow by computer standards. Normal graphics are actually way faster. In a medium sized terminal window it takes about 5ms to render a frame on my brand new machine. In a very large terminal window I can only maintain ~10fps. All of that is ncurses overhead though. If it was still 5ms rendering in Ruby that leaves 10ms available per frame, which is probably plenty. So it likely could be done in Ruby.

do you envision it trailing like the matrix rain (but slower / with a fade effect)? I love how struggling to read could simulate struggling to survive.

Something like that, yes. I was working on the matrix rain effect this week in my little proof of concept, but kanji and other characters are an awkward width in the terminal, so it didn't look as good as I hoped in the early stages and I stopped. I should finish it though even with just Latin characters.

I got a bunch of ideas in my journal if you want to spitball sometime :D (graphics could be fun?)

We should think of something small and see what happens! My main criterion is probably that it should be game jam sized. Something small enough that a team of experienced people could knock it out in a day or two; so that if we take a very slow pace it still wouldn't take more than a month or two. If we do graphics I wouldn't mind experimenting with Godot; but I'd also be happy to see if we could do anything innovative generally with text, in the terminal, or even just with HTML/CSS and Rails on a website.

Decided to play with curses a little bit in Ruby — https://github.com/ianterrell/ruby-curses

Your terminal has to be... modestly sized for it to run smoothly. 😅

This is what you're missing: https://en.wikipedia.org/wiki/Curses_(programming_library). The usual one used these days is the open source ncurses, which is installed in a lot of places already. Ruby has bindings to the library: https://github.com/ruby/curses

I wasn't even aware you could implement something like that for the terminal in Ruby. That has exciting prospects for what I'm writing. I wonder if I can rewrite the interface to include the arrow keys for player movement.

Decided to play with curses a little bit in Ruby — https://github.com/ianterrell/ruby-curses

Ahhhhh, that was fun. Looks stellar :D

We should think of something small and see what happens! My main criterion is probably that it should be game jam sized. Something small enough that a team of experienced people could knock it out in a day or two; so that if we take a very slow pace it still wouldn't take more than a month or two. If we do graphics I wouldn't mind experimenting with Godot; but I'd also be happy to see if we could do anything innovative generally with text, in the terminal, or even just with HTML/CSS and Rails on a website.

I've been interested in learning Godot in particular! But, some HTML / CSS and Rails experience would be super beneficial too. I'm actually struggling with HTML / CSS more than Ruby, and I have no Rails experience at all. Considering the scope of what we'd build, I thought something like tic-tac-toe might be close, but that project feels overdone by CS students.

I've been playing a lot of Splatoon3 the last few days and felt inspired. If you're not into this one, no worries, but: What if our gameboard was a 10x10 grid of squares? One color could be assigned to each player. The object: tag as many squares your color to grow your turf before the stopclock ends, or they're overtaken completely.

Details:

The first move of each player can be anywhere on their respective side's first row.
From that point on, the player can add one square per turn to grow their turf, but:
Each square must be touching another square that they've previously tagged.
This applies to anywhere on the board. If the player reclaims all but one enemy square, that enemy square is still in play.
That considered: Power ups like WALLS or BOMBS can be awarded to the player.
Walls could prevent the opponent from passing certain areas, blocking their turf from growing (Tron-style).
Bombs could be set stealthily without the opponent knowing, and explode at player's command when they're losing. Good for reclaiming a few blocks of turf and catching the opponent off guard.

What do you think? Do you have any pitches? And by the way, I can always try any of my ideas solo, so no worries at all if you're not into any of them! This one just felt like it would be a reasonable scope for the parameters we set.

Also: I think this particular game could be really fun on mobile, but I know that's a whole different hurdle. Still, I bet it would be reasonable to pull off some minesweeper type interface that changes color :-)

I wasn't even aware you could implement something like that for the terminal in Ruby. That has exciting prospects for what I'm writing.

You could do it all manually like with the colors https://en.wikipedia.org/wiki/ANSI_escape_code

Refreshing my memory in your bonecrawl codebase, it looks like you're using the rainbow gem: https://github.com/sickill/rainbow

That's using the same stuff. curses just exposes more of them and wraps them in a higher level C api.

I wonder if I can rewrite the interface to include the arrow keys for player movement.

You definitely could! At least, the movement part is easy. Adding that into your existing codebase where most of the output is via puts and the input is gets might be harder. I'd sort of expect the interface to be sort of all one strategy or all the other. But I could be wrong.

(All one strategy: the engine I'm working on is ncurses based and implements the one strategy for all of it. In theory. WIP.)

But movement itself within that strategy? Pretty easy. I'll do a little coding challenge... it's 1:37pm, and go!

https://github.com/ianterrell/ruby-curses/blob/main/navigate.rb

Okay, it's now 1:57pm. That took longer than expected. I had to learn about keypad mode in Curses.

This got me there: https://stackoverflow.com/questions/25319194/how-can-i-get-ruby-curses-to-respond-properly-to-arrow-keys
But now reading more carefully I also see it in the Ncurses how to: https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/keys.html

So! I learned something, and I need to add it to my game engine.

Decided to play with curses a little bit in Ruby — https://github.com/ianterrell/ruby-curses

Ahhhhh, that was fun. Looks stellar :D

Haha, thank you! It sounds like it rendered properly. I have a newfangled terminal app that I just tried it in and it rendered with whites and grays. 😬 But it worked nicely on my default terminal app.

I've been interested in learning Godot in particular!

As I reflected on it, there are a few more that I've been interested in playing with for a number of years that could work for something graphical:

Considering the scope of what we'd build, I thought something like tic-tac-toe might be close, but that project feels overdone by CS students.

One of the first things I ever wrote was tic-tac-toe. In fact, I had a bug in it that I remember vividly to this day. I wrote something like to toggle some boolean variable back and forth:

if x == true
  x = false
end
if x == false
  x = true
end

I try to remember that bug when I see code that doesn't seem to make much sense. I wrote code that didn't make sense once upon a time, too. We all start somewhere.

I've been playing a lot of Splatoon3 the last few days and felt inspired. If you're not into this one, no worries, but: What if our gameboard was a 10x10 grid of squares? One color could be assigned to each player. The object: tag as many squares your color to grow your turf before the stopclock ends, or they're overtaken completely.

I should add one more criterion: it should be single player. One thing I think we really want to avoid in a project right now is networking. Pass and play could work if we really want to pursue two player games.

But, some HTML / CSS and Rails experience would be super beneficial too. I'm actually struggling with HTML / CSS more than Ruby, and I have no Rails experience at all.

... that might be the exception. An asynchronous two player game would work well powered by something like Rails. I log in, make a move, it emails you to say it's your turn, you log in, make a move, it emails me, etc.

But it would probably be prudent to work through most of the Ruby book and at least some of the Rails book before diving into something like that.

But all of that said, if you're learning Ruby, maybe it makes sense to keep working in Ruby. We're both interested in terminal stuff right now, so maybe working there makes sense, too.

So if the Splatoon like game could be workable in a terminal with curses in Ruby... we could give that a go! I'd just want to brainstorm a way that the second player is AI.

Separately, I noticed this in the README as I went to look at your color usage in bonecrawl:

I would love to see this work as an MMORPG (especially for mobile), and I'm planning to make monthly adventures on a subscription basis. If you're interested in collaborating either with code or content, please reach out!

Have you played any MUDs? I didn't play many single player text adventures growing up, but I played the shit out of MUDs. They're less popular these days, but still around.

> I try to remember that bug when I see code that doesn't seem to make much sense. I wrote code that didn't make sense once upon a time, too. We all start somewhere.

Taking bite-sized lessons every day is pushing me to more fluency though, and I'm thrilled about it. Writing isn't as confusing as it used to be, and I find myself understanding why something breaks if it does break. Sometimes I catch snippets that would cause unexpected behavior. Usually it's poor encapsulation or misguided inheritance attempts.

You could do it all manually like with the colors https://en.wikipedia.org/wiki/ANSI_escape_code

Looks like there's a gem for it? https://rubygems.org/gems/ansi/versions/1.5.0

Okay, it's now 1:57pm. That took longer than expected. I had to learn about keypad mode in Curses. This got me there: https://stackoverflow.com/questions/25319194/how-can-i-get-ruby-curses-to-respond-properly-to-arrow-keys But now reading more carefully I also see it in the Ncurses how to: https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/keys.html

That's super nifty! Your implementation is very easy to follow. I'm tempted to use the same feature, but I don't want to take your code either. If you don't mind, I'd like to also read those links and try to implement my own version without copying your work?

https://www.lexaloffle.com/pico-8.php

This is lovely! I adored the capability; I played the witch game a little bit. I also see there's a version of Celeste that was made for pico-8. Had no idea it launched for that platform. I'm a fan of this little console.

I should add one more criterion: it should be single player. One thing I think we really want to avoid in a project right now is networking. Pass and play could work if we really want to pursue two player games.

Totally fair! I'd love to get into the pass and play territory eventually, but I don't want to take on too much. AI opponent would work well for a proof of concept I think :-)

I don't know if you saw my Bonecrawl repo in a bit, but it's got some mockup screenshots, and more concept "art" for the game. I feel like a graphics-based overhauled version of it would work well on this console. Maybe platform-puzzle solving (Adventure of Link style).

So if the Splatoon like game could be workable in a terminal with curses in Ruby... we could give that a go! I'd just want to brainstorm a way that the second player is AI.

That sounds like a fun challenge! Do you want to do that then? We can write the Splatoon prototype for terminal, and work on solving the AI problem. I'm thinking of parameters for the AI now, like: how does it decide where to move? How does it handle power-ups like bombs or walls? What unexpected behavior might it exhibit, and what controls would need to be made? How do we make it challenging for the player?

Have you played any MUDs? I didn't play many single player text adventures growing up, but I played the shit out of MUDs. They're less popular these days, but still around.

It's so funny you'd ask me that! I only really played predecessors like Zork and Colossal Cave Adventure. I messed around on MUDs a little in my childhood, but more passively. Still, I would definitely say they were an inspiration on some level.

You could do it all manually like with the colors https://en.wikipedia.org/wiki/ANSI_escape_code

Looks like there's a gem for it? https://rubygems.org/gems/ansi/versions/1.5.0

Looks so indeed! I hadn't seen that one; thanks. That gem, the rainbow gem, ncurses — they're all doing the same thing under the covers. Using something like that could likely layer into your existing codebase more easily than something like ncurses.

That's super nifty! Your implementation is very easy to follow. I'm tempted to use the same feature, but I don't want to take your code either. If you don't mind, I'd like to also read those links and try to implement my own version without copying your work?

Take my code, play with it, remix it — if you want. I've just licensed the repository to make my intentions there clear.

Obviously it's also good to build it yourself, too, from scratch. You'll do things differently, some ways maybe better. But there's a lot of value to learning from live code as well. Definitely an and situation rather than an or situation.

I also see there's a version of Celeste that was made for pico-8. Had no idea it launched for that platform. I'm a fan of this little console.

If I recall my history, the Celeste version on pico-8 is actually the original. :) They made it for a game jam and then after it found a little success they built the big published version. Wikipedia confirms!

Development of Celeste began in August 2015, when game developers Maddy Thorson [a] and Noel Berry participated in a game jam, where they created Celeste for the PICO-8.

So, pro tip to making a super popular game: write for the pico-8!

I don't know if you saw my Bonecrawl repo in a bit, but it's got some mockup screenshots, and more concept "art" for the game. I feel like a graphics-based overhauled version of it would work well on this console. Maybe platform-puzzle solving (Adventure of Link style).

I just peeked again and saw the graphics, etc — looks great! That's super fun. When we build something I'm probably going to rely on you for anything that wants to look nice. 😅

Do you want to do that then? We can write the Splatoon prototype for terminal, and work on solving the AI problem.

Alright, let's do it!

(Coming out of the business world, I want to make sure everything is clear. My general assumptions: non-commercial project, not intended to be sold, shared copyright, open source, some permissive license, both of us credited, we can each display it anywhere. If you disagree with any of that let me know; no pressure, just my assumptions.)

If you like, go ahead and set up a repo and invite me to it. We can plan iterations and things to work on and how to split up work there. We'll solve the second player or AI after we get something running.

Taking bite-sized lessons every day is pushing me to more fluency though, and I'm thrilled about it. Writing isn't as confusing as it used to be, and I find myself understanding why something breaks if it does break. Sometimes I catch snippets that would cause unexpected behavior. Usually it's poor encapsulation or misguided inheritance attempts.

This is really great — congrats. & definitely keep going! There's going to eventually be a bit on automated testing. That's a tool in your toolbox that will really give you an advantage in making sure the code does what you want it to. We can set it up for the game for practice.

Of course, you can still change your mind and we can build it for pico-8. It really does look fun.

Take my code, play with it, remix it — if you want. I've just licensed the repository to make my intentions there clear.

I've read through some of the licenses that GitHub recommends, and the differences between them. Some are subtle and some are big. The subject of licensing is foreign (and a little intimidating) to me. What helps you decide?

So, pro tip to making a super popular game: write for the pico-8!

It looks like I'd have to learn some Lua syntax! In terms of output, what would make this better than the engines that take Ruby? I know of Ruby2D, Gosu, and Dragon Ruby.

I just peeked again and saw the graphics, etc — looks great! That's super fun. When we build something I'm probably going to rely on you for anything that wants to look nice. sweat_smile

Hey, I appreciate that! The image is just a mockup of what I envision for the website. I have no idea how to put the terminal on my site yet. But, I believe it would be doable based on what I'm learning in HTML and CSS (but the functional game part's going to be the real goalpost).

(Coming out of the business world, I want to make sure everything is clear. My general assumptions: non-commercial project, not intended to be sold, shared copyright, open source, some permissive license, both of us credited, we can each display it anywhere. If you disagree with any of that let me know; no pressure, just my assumptions.) If you like, go ahead and set up a repo and invite me to it. We can plan iterations and things to work on and how to split up work there. We'll solve the second player or AI after we get something running.

That all sounds copacetic to me-- I'm in it to learn! I set up a repo called "War-Paint" and invited you to it. I'm giving it The Unlicense agreement.

There's going to eventually be a bit on automated testing. That's a tool in your toolbox that will really give you an advantage in making sure the code does what you want it to. We can set it up for the game for practice... Of course, you can still change your mind and we can build it for pico-8. It really does look fun.

It might be really helpful for learning automated testing to have experiential application of it. Would you be disappointed to save pico-8 for another project if this one goes well?

I've read through some of the licenses that GitHub recommends, and the differences between them. Some are subtle and some are big. The subject of licensing is foreign (and a little intimidating) to me. What helps you decide?

I almost always license my open source work as MIT. It's one of the most common licenses, and it has two great attributes: it requires including the copyright on distribution of it or meaningful derivatives, and most or all corporations allow usage of it. If you want something to be useful to the largest number of people, including employed people, MIT is the way to go. There are a few others people use in this arena; Apache being what I see next most often.

If you want to restrict commercial use, GPL is the way to go. That requires releasing source code, which no company will do.

I'll occasionally pick another random license, like the other little repo's Unlicensed agreement or sometimes a Creative Commons one. In the Unlicense case it was just for crystal clarity: this is public domain use it however you like. It's just a little toy repo.

It looks like I'd have to learn some Lua syntax! In terms of output, what would make this better than the engines that take Ruby? I know of Ruby2D, Gosu, and Dragon Ruby.

The pico-8 comes with some rails: it has a built in sprite editor, map editor, and sound editor, and it's built for 8x8 sprites, and has strict code size limits. Limits help guide creation and decision fatigue/analysis paralysis.

Also the cartridges are cute little pngs. :)

It might be really helpful for learning automated testing to have experiential application of it. Would you be disappointed to save pico-8 for another project if this one goes well?

I'll survive! We'll do Ruby terminal as planned.

That all sounds copacetic to me-- I'm in it to learn! I set up a repo called "War-Paint" and invited you to it. I'm giving it The Unlicense agreement.

Cool!

Sorry to mislead with Unlicensed — I generally do not recommend that and would not make it a habit.

But also, All Rights Reserved in either open source or closed source is a totally reasonable starting point (and ending point) for personal projects. The engine I'm working on may become open source eventually, but only if I get it going well and likely only after I publish projects leveraging it. 🤷

Thanks letting me know your thoughts on licensing. I've read a bit and still struggle to see the difference between the various options-- and I worked in the legal industry before! Sometimes it feels like the licenses are splitting hairs, I guess.

Sorry to mislead with Unlicensed — I generally do not recommend that and would not make it a habit.

Totally weren't misleading me about using The Unlicense--I just thought it applied to this project too (but let me know if I'm wrong!). I was also reading a little that "All Rights Reserved" isn't always valuable in court, but that a simple copyright is. It's a little disorienting to navigate, but that's the nature of law I guess.

I was asking because one intent of my Bone Crawl title is to explore "evolution of game design" as a study anthology for myself. I was going to start with the text engine, then go to 2D, and ultimately 3D one day (the latter two employing existing engines). But, I was also interested in pursuing commercializing it someday if my skills progressed enough.

I know you said visual art isn't your strongest skill, so I'm not sure if you've explored this topic but: What do you think would be an appropriate way to protect artistic content like mine? For instance, there's content (like the story), but then there's the design flow for each page that borrows from predecessors (specifically to mind: the hearts meter is used in several other titles, the most popular being Zelda). At the same time, some aspects of the interface is unique in its arrangement / pacing for a text adventure. Yet, it's modeled after the very page of a book, which isn't a copyrighted design.

A cursory search from wikipedia says:

"The computer code or other fixed medium is considered copyrightable, and the game's presentation can be copyrighted as a literary work or dramatic work, while elements like character design, art and sound and music can also be copyrighted."

How exactly is that broken down though? How is "presentation" being operationalized? No worries if you don't know, and maybe I went a little too far down the rabbit hole today thinking about branding. I'm not a capitalist by nature, but I figured I ought to think of these things if I want to monetize a skill I someday plan on marketing.

I've read a bit and still struggle to see the difference between the various options-- and I worked in the legal industry before! Sometimes it feels like the licenses are splitting hairs, I guess.

I expect you're right on splitting hairs. My own usage of them is really guided by the various communities I've been a part of rather than strict study of them all. 😬

I was also reading a little that "All Rights Reserved" isn't always valuable in court, but that a simple copyright is.

I'm sure you're right; my understanding of All Rights Reserved is not that it's meaningful as a thing so much as it's shorthand for "I haven't licensed this, therefore the default rules apply." Copyright is automatic and protects all protectable work by default.

How exactly is that broken down though? How is "presentation" being operationalized? No worries if you don't know, and maybe I went a little too far down the rabbit hole today thinking about branding. I'm not a capitalist by nature, but I figured I ought to think of these things if I want to monetize a skill I someday plan on marketing.

I have what I consider to be a decent grasp of copyright issues, but IANAL. I mentally divide it into clear areas that I have some confidence in and and gray areas where lawyers and perhaps lawsuits would have to settle

Source code? Copyrighted. New music composition, drawings, sprites, 3d models, anything else that's clearly art and was clearly made for your game — copyrighted. (Although be careful of who owns the copyright.) All of the dialog and textual story are clearly copyrighted. Unique characters created for your game, with names and identities and costumes — copyrighted. Logos and icons, copyrighted.

I would never reuse any of the above from any other project, even in part. What constitutes fair use and what constitutes a derivative work? That I don't really guess and would leave to lawyers.

Game mechanics? Not copyrightable at all — "steal" away. Layout, graphical design, etc — not if generic, possibly so if it's a unique expression. Story structure and beats? Backstory and plot elements? Not copyrightable to my knowledge. Anything else that doesn't fall into a clear bucket above? I would generally assume not copyrighted but if I had a stranger look at my own version of something and they said, "That's really just XYZ," I'd avoid simply because it's not worth it even if I wasn't violating copyright.

Anyway, just 2¢ and quite potentially wrong in parts; just my current internal understanding, although with some minor and legally untested experience.

What do you think would be an appropriate way to protect artistic content like mine?

If you might want to commercialize your work, I would err on the side of clarity of reserving rights — rather, of not licensing them away. To me that means not making the source public or, if made public, not attaching any open source license at all. Copyright is by default and doesn't need claimed, but adding a copyright notice isn't likely to hurt.

Most of those statements I have high confidence in; a few only medium. :)

Thank you for your thoughts on the differences! I realize that I forgot to close this issue out. It's been a long day and I'm beat.

erikamaker / pickaxe

Chapter 3 Notes Feedback Round 2 #5

> I try to remember that bug when I see code that doesn't seem to make much sense. I wrote code that didn't make sense once upon a time, too. We all start somewhere.