dragonridersunite / book Goto Github PK

Logged by Akzidenz in Discord:

It looks like all the images are failing to load for me. Maybe Safari doesn't support webp files?

In 12-ship-it.md, the end of line 65 is the basically same as line 67 (the next line with text), yet it started like it was going to say something else...

65  [...] Or go back to editing your game and set the **Visibility & access** to be public to launch it.
66  
67  When you're happy with your game and ready for the world to play it, make it public!

Did you mean "editing your game" as in Itch.io's "Edit game"? (in which case it probably would "start" 65 When you're happy [...] instead of 65 [...] Or go back [...].

Or did you mean something like: (This would be the "say[ing] something else" above)

65  [...] Or go back to editing your game.
66
67 When you're happy and ready for the world to play it, set the **Visibility & access** to be public to launch it! 

This paragraph is talking about the engine, so "sync that" is suggesting that we open-source the engine, even though you've just been telling us how not to...

106 The downside to this approach is that you need to ensure you keep your specific engine version parent directory available. You could use version control to sync that and then use Git to publish it online as open-source code.

03-spit-fire.md

61 "We use arrays to represent various data in our game like labels and sprites, but we can create our own arrays to keep track of the data in our game. Arrays are a great way to collect data that we then use throughout our game. In this case, we're maintaining a collection of fireballs."

There is no "negation" of the first part of the sentence, so there should be no ", but". How should it get fixed? is it an "and"? or a new sentence? (". We can [also] create [...] of our data.")

Same/similar phrase in three back-to-back "sentences": "data in our game", "data in our game", and "data [...] throughout our game"

The latter two of those "sentences" are almost, but not quite, saying the same thing.

(The last sentence ("In this case...") is included solely to complete the context/paragraph.")

Seeing that your chap3 explanation of #tick is a nice simple: (#name is Ruby shorthand for "the name method"). I believe that it could possibly be moved to chap2, as that use is: In #tick we'll check [...].

The #greet in chap1 still needs removing (it is redundant, the 'greet method' method and immediately above def greet friend.)

It might seem cool to move the explanation to chapter one, but that is a tighter space to try and shoehorn it into and you should probably say "the name method" a few more times before that combo starts to vanish. There are a nice number of them in this chapter (before and after "the #greet method". (low, it would probably be best to keep this chapter #-less.) In chap2 there are two uses of "____ method", both of which precede the #tick in question.

In chap3 there is also a redundant #tick method ("the tick method method", kind of like "a NIC card" (Network Interface Card card) but not as funny, since with "#tick method" the second method is unnecessary.)

(chapter#, current text, possibilities.)

-chap1:
Go ahead and change the #greet method to:

Go ahead and change the greet method to:

-chap2:
In #tick we'll check to see if a given input is pressed.

In the tick method we'll check to see if a given input is pressed.

In #tick (#name is Ruby shorthand for "the name method") we'll check to see if a given input is pressed.

-chap3:
In our #tick method, right above where we render the dragon sprite,

In our tick method, right above where we render the dragon sprite,

In #tick, right above where we render the dragon sprite,

-chap3:
At the top of #tick (#name is Ruby shorthand for "the name method"), assign an empty array to

At the top of #tick assign an empty array to