Totes done!

Kinda. Sort of. Mostly.

Well, done enough, anyway. There isn’t enough time to do more — although I would really like to! Combined code and text, it’s around 7200 words total. (26 pages double-spaced.)

As I type this, I am considering adding in a bit more, maybe another few hundred words within section four “Animation and Tweens,” I think. Although, given the other final projects due over the next few days, that may not get done, either. Maybe so, though?

But, anyway, I did get three sections done. That’s something, I guess. It’s a few hundred lines of code and a couple thousand words of explanation about the code. I didn’t get to the videos, but, well, I didn’t think I would, given how the semester was going for me. My hope, I’m now thinking, is to get more down in later Maybe once the semester is over. But, again, maybe not that either depending on some things that may take up my schedule around that time.

So, I did a large chunk done (3/5), but only because I decided to cut out one of larger parts of the project and only then by leaving out those last two sections. Still, a many-hour investment spent across many days and mostly nights of working on it. And, of course, something I plan to keep working on for the future and hopefully finally hold one day — because, otherwise, it was kinda a waste of my time, right?

Well, the workshop is not going to happen this semester. I guess, given how I wrote about it in the last two posts discussing it, that’s to be expected, in a way. With me taking over as president of the student organization of MediaCommons and then my heavy involvement in the planning and execution of Humanities Unbound, I was swamped with other things and didn’t have the time to try to plan, setup, and then actually have the workshop. However, in not having it, I’ve had more time to plan for its parts and, of course, use it as the final project for the class.

Toward that end, I’ve already typed up a pretty final first page (minus the video I want to create for it). I now need to write up three more pages of roughly the same amount and I’ll be done. (If the other pages follow the first one, that’s roughly 2K words per page and roughly 8K total minus the code examples and videos. It’s actually going to be pretty big, all told.)

So, that’s what I’m working on for the Teacher aspect. I’m adding in the writing, the code examples, and plan to match it with some videos explaining the concepts at some point. I think, though, on that issue, I might end up dropping the videos, maybe, depending on my schedule. I’m more concerned with the writing and code examples than the videos. I mean, I want to include them, but it might not happen depending on me meeting those other two goals first and then, and only then, addressing the video content. We’ll see.

Since my last post, I’ve made considerable progress toward learning Ruby. In fact, I’ve even written up a (probably too long) post on creating a text parser, too, covering most of the basics up through and including input, output, and creating objects. I won’t write I’m expert — very far from that — but I like to think I can at least read some Ruby now, have a general understanding of how objects are constructed, and at least a working-knowledge of the different iterator functionality it has (both Proc and lambda).

Still, other than learning the language and writing that post, I haven’t done anything special with it. Haven’t really had the time to try to setup some project or create a website — although I do hope to do that by the end of the semester. No, most of the time spent on this aspect of Artist was on just learning in the language and then writing up a post about how to try a text parser. Nothing fancy, I admit, but it does get the job done, as it were.

So, really, that’s it. I learned a language. I can write some simple things in said language. I can describe, to some degree, what is going in in that same language. All things that satisfy the requirement of the class, of course, but not much more than that. I did what was required, but might not get to beyond that within the next two weeks of the semester. There just isn’t time to work on a longer-term project AND do all the other things I’m working on at the same time. (As Dr. Rodrigo mentioned to me this morning, “Welcome to academia.”)

 

Welcome to a tutorial on creating a basic text parser like those found in older interactive fiction games.

Now, I write “basic” here because, while this tutorial will walk you through the steps of creating a text parser example, it will not cover the more advanced functionality of navigating a world or an inventory system. This will, however, get you going with how to approach the problem.

To start, let’s look at the way a variable is created in Ruby:

someVar = "value"

That’s it. Unlike many other scripting languages, Ruby has no type, word, or punctuation requirements to creating a variable. It is simply some collection of numbers, letters, and the underscore. No dollar-sign needed!

With variable creation underway, let’s look at input and output.

 

In Ruby, the default input is the system default input. In nearly all cases, this is the command-line. It’s the same with the output, too. It defaults to the command-line as well. Getting input or putting output is a matter of working with the command-line.

In Ruby, we use the following to output text:
puts "Some string"

For input, we use the following:
gets

Like in Python and other scripting languages, you may have noticed that I have not used any semicolons in any of these statements. That’s because, while you can use semicolons, the common style is to exclude them. You can simply end the statement, press Enter to make a new line, and type more code.

Also like in Python, function calls can be made using only the keyword, a space, and the argument. While Ruby allows for parenthetical usage, the common style is to leave them off most method calls and only use them in the definition of a method. (As I’ll cover later.)

In practice, then, if I wanted to ask the user a question and then get their input, I would use the following code:
puts "Hey, input your name!"
name = gets


In use, that would look like this:
Running from the command-line, it asked for a name and I typed mine. During runtime, the value “Dan” would have been in the variable name.

To output the value of a variable, however, we need a process called interpolation. In Ruby, we need to encapsulate the name of the variable in two brackets and start with the pound sign. This allows us, if we want, to run functions on those variables, too.

Adding to our existing code, it would look like the following:
puts "Hey, input your name!"
name = gets
puts "Your name is #{name}"

Run, it would look like the following:

It asked for my name, I typed it, and it wrote what I typed.

Okay, so that’s variables and some input and output done, right? What if we wanted to test that input against something?

For that, we will use the case statement. In Ruby, this is the stand-in for the switch in many other languages. In fact, it works the same way.

case variable
when value1
#do something
when value2
#do another thing
end

For case, it starts with the variable or value to compare as the first argument after the word “case” and then, on the next line, a when and then, on the line after that, something to do. (Note: Ruby automatically ‘breaks’ for each when. There is no need write the word break in Ruby. It does it for you!)

Each command block in Ruby also ends with an end. For using if, or in this case, case statements, it needs to end with an end.

Going back to our example code, we can expand it to test our input.

Running, it would look like the following:

 

Using case, then, we can test our input against a number of different options and then do something in response.

With that in place, let’s add in a method to do something.

In Ruby, functions are called methods. (The same with in Java, too.)

To create a method, we use def and then an end. (Like in command blocks, methods end in an end. Nearly everything does in Ruby, actually.)

Adding to our existing code, we write the following:

The method in the above example does one thing: puts some text.

Something important to remember about methods in Ruby is that they do not need a return statement. Like many other styling options in Ruby, the return statement has been dropped in favor of the built-in “return the result of the last statement in a method.”

Along with seemingly missing semicolons and a lack of return statements, too, Ruby can actually look really foreign to those coming from learning code through the C and C++ family of languages like Java and other ECMAScript groups like ActionScript and JavaScript. But, in truth, it takes after Python and other languages like PHP in many ways, blending many of the positive aspects of those languages into its own way of doing things.

Coming back to our code, we should write another method for the other option.

Notice, this time, I’ve renamed the first method. With two methods “responding,” it would not be useful for them to have the same name. Now, we have a good_response and a bad_response. Both are called from within a case statement.

I’ve also been using another method I haven’t discussed yet. When using gets, it is often useful to “cut off” (chomp) the newline and return characters. Instead of reading the full input from the command-line, it can be useful to treat the string as something without the new and return characters. chomp lets us do that. It also is part of how Ruby calls methods part of an object’s class and parent object.

Like in other object-oriented languages, Ruby is based on the idea of everything being an Object. Numbers and String, as they are represented internally by Ruby, are they themselves objects. They have built-in methods and attributes.

One of the built-in methods for strings is the chomp method. As I wrote above, it “cuts out” the return and newline character from the input, making it easier for us to deal with what we get from a user typing on the command-line.

Running the code, it looks like the following:

Looking at the screenshots, it seems as if the input and output isn’t changing much from one to another. The reasoning for that is pretty simple: it isn’t.

In moving from a case statement to then one calling methods, we aren’t changing the interface for the user. Instead, I am demonstrating different ways to approach the problem. While Ruby can be treated like a scripting language, in that it runs and does one thing in that file, it can also be used in more complex ways, too. In fact, I’ve been moving from a straight-forward way of addressing the problem toward a functional programming model and will now show how to approach the same problem from an object-oriented way of thinking as well.

Creating objects in Ruby is pretty similar to how we’ve been using methods and command-blocks. However, instead of using def, we start an object with a new word, class.

In Ruby, a class is an object definition. It defines how an object should act and what its attributes are. However, unlike in other languages, Ruby has a special method for initializing the parameters and attributes: initialize. When a new instance of a class is created, its initialize method is called first.

Since we are moving toward an object-oriented approach, we need to move our code into our new object. Since we’ve already created the two methods of good_response and bad_response, we can copy that code over into our new class.

However, we’ve now got a problem. Where should we put the case statement? How about we put it within its own method? That way, we can call it as needed.

Good. Now, we’ve got code to parse some content and call the responses needed. However, it’s still only the definition. We need an instance of the object to actually do something.

To do that, we follow the syntax demonstrated with gets.chomp. We call the built-in method of new with the object of Parser.

As I wrote before, Ruby was created with an object-oriented approach in mind. So, not only is everything an object in Ruby, but the language also understand the concepts of public and private, too. In object-oriented design, this is a way of separating methods between those that are called from within classes with an inherence chain: either the parent or child of some class. (Ruby also allows mixins, but that’s a more advanced topic.)

In Ruby, to make some methods public, we use that word, public. To make others private, we use that word, too, private. In each case, it is on a single line and takes effect on all methods below it until the use of the other word or the class definition ends.

For example, going back to our code, we would have the following:

We can safely call parse from our instance of the Parser object because it is a public method.

If we run this as is, we get:

However, if we tried to access some private methods, we would get the following error (when trying to call good_response, for example):

Ruby will, as you see above, enforce the rules of public and private within an object. If a method is private, it cannot be called from outside its family of inherited objects.

Okay, so, we moved through a functional approach to a fully object-oriented one. What is next? Well, we still need something to puts some output in the form of a question, let us input something, and then let us do it again and again.

For that, we turn to one of the unique command functionalities of Ruby: loop.

 

In many programming languages, there are ways to create looping structures. Using for and while are very common across languages. However, in Ruby, there is a very literal way to create a loop: use the loop keyword.

For example, if we wanted to create a basic loop, we might do something like the following:

Right before starting the loop, we set a variable to be a value we are going to check within it (to prevent infinite looping). Then, right inside it, we subtract one from the variable, output its value, and then check to see if we should break.  (The use of break within loop is why it is not used in a case statement. It already existed in this usage.)

Moving back to our code, we could implement a loop to ask for input, parse it, and then ask again.

Now, as long as we don’t enter “quit” from the interface, we can keep entering anything we want. It will check against the two options, “Dan” or not, and then act accordingly.

Running, it looks like the following:

And, using another set of inputs, it looks like this:

This is all very silly, you might be thinking. Checking input against names isn’t particularly useful outside of examples and wouldn’t really be used in any real-world projects.

And, of course, you’d be right. The example isn’t very useful by itself. However, it is the basis of  the parsing text input mechanics for many interactive fiction games. It uses the idea of some looping interface, a Parser object, and some feedback for the player to see.

In each case, the player enters text, presses Enter, and then revises her strategy accordingly.

So, if we were to change the example into something more like a text adventure, it might look like the following:

Now, instead of names, we input verbs for the parser to handle.

For example, running it with new input might look like the following:

It looks much more like interactive fiction now, taking verbs as input and outputting some responses in turn. In fact, we we wanted to build on this, we’d need to program some nouns into the system, pairing up what was valid input for a pattern of “verb + noun” and translating that into something that had an effect.

As a final note on our changed and much more complex “basic” text parser in Ruby, there was a new method call snuck into the last update: downcase!. In Ruby, the use of an exclamation mark at the end of a line means the value of the object that invoked it is changed as a result of the call. Instead of passing back or returning some value, the function acts on the calling object instead.

In this case, that means that downcase, the method to change some string into its lowercase letters, is called on the variable and is changed in the process. The reason for this change has to do with case-sensitive string comparison. To simplify comparing some string to another, we reduce the first, incoming string to lowercase. That way, the code only need make one comparison and not account for all the variations in capitalization that can occur within the input string.

 

Well, the workshop didn’t happen. But maybe it will in the future? I’m hopeful for that, I guess.

That was my main frustration when I wrote the last post, of course. I was trying to find time to complete my preparation for the workshop. Which, you know, I still haven’t done. Yet. Yet!

Still, other than finishing Design For How People Learn, I haven’t made any progress on that, either. My Spring Break ended up being mostly about me being really sick for several days — during which I did nothing else but feel pain and try to get some sleep.

So, in the mad-dash to try and catch up on things I had hoped to do over Spring Break, I’m doubtful I will be able to apply the notes I took from Design in trying to plan for my workshop this week (16 March to 20 March). But, you know, maybe at some point soon. I will present that workshop before the semester ends. I will!

I just, you know, need to finish making it and then figure out a time to have it when there aren’t a bunch of other things happening at the same time so people can attend. (And I also need to write all the code, make the lessons, and record several videos for it, too. Too many things, actually.)

Since the last post, I’ve narrowed down to using Ruby as the language I’m in the process of learning for the class and Rails as the context for it. However, I haven’t spent much more time beyond my initial exposure to the Lynda.com video on learning it.

As for how I will employ this within the Artist schema, I am still unsure. Presumably, and as I mentioned in the previous post, this will be web related in some form. And probably use Twitter, as that has been my continuing fixation within my own work outside of the class. However, as for how these different things will collide, I’ve still have yet to figure out.

On that same front, I did finish reading Form + Code and did like a great deal of it. Much of it was geared toward the artist crowd (i.e. people without my background), so there wasn’t too much I hadn’t already be exposed to from a general content point of view. However, I did really enjoy the examples, even if constantly wished they had more space for printing the algorithms and steps involved instead of merely pointing people towards the website to get the code.

I will probably borrow from these — once I actually get around to visiting the website to get the code — for my own project. Perhaps doing some sort of visual presentation of textual data somehow, maybe. I’ve always wanted to play around more with the ideas from Graphs, Maps, Trees.

While I’ve been reading book on and off over the last few weeks, I’ve also been working on a workshop designed around teaching the HTML5 game framework Phaser. Principally (and hopefully), it is in compliance with both my role as the Site Administer for the Media Park and as an assignment for this class. Fundamentally, since it is about teaching technology — writing in digital spaces –, it should be killing the digital bird with two, er, digital stones.

However, time is the mind killer. And the thing I seem to have the very least of. Initially, the workshop was going to start tomorrow (24 Feb 2015), but I’ve had to push it back another week because I’ve fallen behind in basically everything across the board. Not fun at all.

So, in summary, and to write some words here, I was looking forward to the workshop until I had to do all these other things like lots of readings for my various classes. Probably the workshop, which will have started by the time of the next post, will be going in full motion soon, though. At least I hope so, anyway. Maybe it won’t. We’ll see. Or we won’t, I guess. One of those will happen for me.