Well, the workshop is not going to happen this semester. I guess, given how I wrote about it in the last twoposts 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.”)
Video games. Having devoted much of my time into the analysis, production, and playing of them in recent years, most of my thoughts, when it comes to visual rhetoric, inevitably float back to video games and how any theory, in practice, is used in connection to that medium. It’s just how I roll — as the kids say.
So, in that regard, the flow of information — heck, the Flow of anything, really — is linked back to video games and how interface design, representation, or image analysis is used in connection to the medium, its communities, and the practices that surround them. I sometimes even think in terms of command blocks, too. In using any one theory, like the more mathematical based use of Shannon and Weaver’s communication model in Reading Images or even Norman’s levels of processing, my mind moves through structures of how to move between parts and the modularity of their interconnectivity. The output of one feeds into the input of another, in other words.
With such a mental framework (influenced by my undergraduate time as a computer scientist), it would be inevitable, then, that I’d produce something with a connection to video games. That my output, as it were, would be itself a video game through the process of synthesizing all these, sometimes conflicting, theories into some product. That I’d make a game to both talk about and to the games in its genre or community. Meta. Meta. Discourse. Discourse.
In the addressing modes other than visual, there’s not much to write about video games. That is, there is probably an infinite amount of analysis and study to do, but nothing that directly relates, at least in a strong enough way to discuss it at length, to the theories reviewed and used in the class. We didn’t really touch on the other modes too much and, although they are a part of video games in a strong way, I guess I don’t feel like I could write about them without some theoretical framework in place for the discussion. (As Dr. Rodrigo would say here, “Does that make sense?”)
So, in a super informal conclusion to this, video games. All the time, video games. All the answers, video games. Oh, and video games.
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.
Input. Magic. 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.
Fruit “loops”
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.
I choose a few events in my long-running relationship with the Legend of Zelda series of games as my “digital experiences with design” to create a timeline for. My thinking was, instead of concentrating on a specific interface or even technology, I would reflect on the changes within my own lifetime in how games are “played” and the dynamics of the associated interface framing of them as a result.
I make that distinction, the quotations around played, because they have transitioned from a an experience of me alone with the game to, by the end of the timeline, having moved from the platform the game was originally released on to a purely digital experience: instead of pressing buttons on a gamepad, I was using a keyboard at a computer that was acting as input device and game console all virtually rolled into one.
When The Legend of Zelda (after which the series is named) first came out, it was for the Nintendo Entertainment System. You plugged in the cartridge, which contained both the ROM and RAM, and the system ran it. The game itself existed wholly on some hardware and was “played” in so much that it had to be connected to the system itself. They ran as a unit together.
Later, jumping nine years or so into the future for Ocarina of Time, the system now ran its own software. The game still needed to be plugged into the system, yes, but it was an extra component and not as symbiotic as the NES was to its cartridge. The system existed outside of the game and, in fact, wrapped around it in places, supplying functionality not exclusive to it.
This trend of layering software became even more apparent for the last two items on the timeline, too. For these, I played them via emulation. Beyond simply extending the game itself through software, the “console” used to play the game existed virtually. Some software was running the system software that was, in turn, running the game. The “system” of the console was now just a component itself, an interface between, among, and for other interfaces.
Beller, J. (2013). Kino-I, Kino-World: Notes on the Cinematic Mode of Production. In N. Mirzoeff (Ed. ), The Visual Culture Reader, 3rd Edition. (pp. 249-270). London: Routledge
Grounded in Marxist theories of commodification and the Lacanian understanding of the “the cut” within both words and especially in film as the gap for the unconscious, Beller (2013) details the inner and outer workings of “the cinematic mode of production” (CMP), a description of cinema as both value-production and a form of synecdochic transformation of sensual labor. As Beller (2013) notes, that while “Looking has long been posited as labor by capital” (251) simultaneously “capital [also] co-opts the ever-increasing abilities [of groups] to organize themselves” through the very cybernesis that is presented as freeing (254).
Exploding the definition, Beller (2013) explains cinema as the “means of production of instrumental images through the organization of animated materials. These materials include everything from actors, to landscapes, to populations, to widgets, to fighter-planes, to electrons. Cinema is the material practice of global scope, the movement of capital in, through, and as image” (255). For Beller (2013), cinema is the all-consuming suture point into which both the self is lost and is reconstructed again through visual collision with the capital apparatus in which contact both provides scopophilic pleasure and an effect of being rewritten.
The image itself is a “condensation,” notes Beller (2013). It is a “matrix of partially unconscious forces that means something else” (255). For, as language tries for a complete categorization of the visual, it also fails and with that failing comes a “cinematicity of domination for consciousness” (256). States Beller (2013) simply, “Though not everything is an image, nearly everything is con(s)t®ained by them [sic]” (256). And it is through this fetishization of the image that leads to the “severance of community appearing as an object” as well (262). We seek in the spectacle a false connection to a greater community through its very commodification; “an image of a commodity, [which is] itself a higher order of commodity” (263).
From within this fascinating look into the suturing of subjective-objectification of the gaze through cinema by Beller, I was most drawn to the leveraging of the visual as labor. What does it mean, I was thinking while reading this, if the interfaces of systems become increasing cinematic (if they are not already such)? How are users seduced into the belief of a connection to a larger community through the display of other player’s scores and standing? Is the pursuit of the score or the prestige of placement something directed through the spectacle? In constraining the possibility space of player identification within the system, is the shaping of the interface directing them toward greater commodification through visual avatar “customization,” for example, or does this seeming expressing of individuality push them ever deeper into a submission to the system and its inculcating, capitalist ways?
List 3 connections between Kress and Van Leeuwen and 2-3 other readings we’ve covered. (Not every article you choose needs to have a connection to every other article. Look for common threads.)
Well, it’s a bit of an obvious one, but Barthes is mentioned in many places. The use of the sign and signifier are used, as is the term anchorage early on in chapter one.
There is a general connection to Porter and Sullivan, too. The use of “design consistency” (Porter and Sullivan, 293) links over to Kress and Van Leeuwen’s very detailed application ofShannon and Weaver’s Communication Model to understanding Participants and Narrative process in chapter two.
The same with Kelly, as well. The incorporation of Shannon and Weaver’s Communication Model is something shared between both Kelly and Kress and Van Leeuwen. In fact, I’d state Reading Images might take it a bit too far in its application and use of geometric shapes to explain relationships.
List 3 thought provoking or provocative ideas. What makes them so?
While, on the one hand, I thought Kress and Van Leeuwen might have taken the use of geometric shapes and flowcharts into a land bordering on obsessive, I did like much of the early analysis as a way to describe relationships. Much of the comparisons between the seemingly unconscious trusting of squares and rectangles was particularly spot on, I thought. The use of the paradoxical instability/stability of triangles as a way to describe the communication triad of participant, vector, and directionality was a great insight.
Along those same lines, I at first liked and then grew quickly tired of the constant use of hierarchies of various things. There are different versions of Narrative Processes and Conceptual Representations, as two examples, that spiral out to over a half-dozen taxonomies of various descriptions and usefulness. So, while, yes, it can be provocative to give labels to things, maybe not so much? Maybe? Many of the descriptions didn’t seem useful other than to cover some small part left out by the other categories.
Much of the conceptual relationship descriptions felt very object-oriented to me. The ways of describing if something was part of an attribute or identity seemed to come right out any number of ways of categorizing is-a and has-a relationships between objects. Something that, honestly, I’m a little undecided on as it applies in this context. Between the fierce use of the communication model and never-ending hierarchies, adding proto-OOO is maybe not the best move.
List 3 questions you jotted down for yourself while reading. What sparked them for you and why?
A great deal of emphasis on children. I get that Kress and van Leeuwen come from a background of research in this area, but isn’t it a bit too much? Isn’t it?
The question “is the move from the verbal to the visual a loss or gain?” (31) is definitely an important one to consider? (Indicates question via inflection?)
Yeah, I think, with the above, a closing question I have concerns the book itself. While much of it seems potentially useful, I couldn’t help but to think about Kress and Van Leeuwen kinda writing themselves into a corner because of the more mathematical (or, at least, technical) usage of the communication models to explain everything. Was that wise?
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.
