I’m not sure when it started. That is, I’m not sure when the fight of those who would exclude Twine games from the the genre of “games” moved away from the larger battle of definitions and began trying to take apart what might make a “game” to dismiss Twine projects. Regardless, I imagine it to be the act of people who, finding out they cannot push something so large over, are now trying to dismantle its footing. It smacks of desperation to me.
John Brindle takes up this idea in his own post what a mechanic might be from his (pragmatic) view. However, in reference to how Twine works, he writes “In Twine games, as Raymond Neilson pointed out earlier today, the basic mechanic is ‘click’ (or rather, in the backend, ‘move’ from one tile to another).” Later, he elaborates, writing:
Also arguably, Twine games and text adventures completely blow our ideas about ‘how games work’ out of the water. For example, a big part of the ‘interactivity’ of Christine Love’s Analogue: A Hate Story is remembering stuff you read in one part and applying it to a decision later. The same is true in Twine games: one of the player’s actions is to read meaning from passages of text and carry it with them until it informs their decisions or reading of another. This is a basic unit – a ‘mechanic’ – of linguistics and literature, but not of games, because we don’t think about them that way. And yet, isn’t it just as large a part of games? When you see an enemy for the first time in a game, don’t you, to exactly the same extent, ‘read’ their appearance on the screen, ‘read’ the signals about your HP and their HP that you get, and carry that knowledge forward?
In reading that, I had a slight problem with how he expresses that Twine “in the backend, ‘move’ from one tile to another” as that’s not actually true. It doesn’t act that way. It, in fact, overwrites what the player is actually seeing on the page itself. Because of the player reacting to what they are presented,the content changes. Passages, while it is convenient to think of them in terms of hypercards, are actually data that is manipulated and whose states are being changed by the act of interacting with the story.
This is vitally important for his later comparisons of literature (the reader carrying information forward) and interactive fiction (a player needing to use that information to progress) as it speaks to the difference between a hypertext and Twine game too: the act of mutation marks one as a game and another as a text. This is, in my eyes, the ultimate proof Twine games are “games”. A text does not change its content from interaction. A game, on the other hand, does.
The internal memory is changed as a reaction to the presence and actions of a player. This is my own definition of a mechanic: a reaction to an event. Texts do not have this. The act of interacting with a novel does not change its contents. Sure, you can add more data or even remove it. But, in the reading moment, it is not changed. Even hypertexts do not have this.
While hypertexts are thought of as having many valid paths through its content, they do not change states. Twine does this constantly. Each new passage is added to the History object and is saved during the session. Playing anything created in the Sugarcane format shows this as the generated hashes of each new passage shown is concatenated to the current URL for bookmarking purposes. The Twine game itself is changing its internal memory during execution.
It’s a combination of code and interpreter in one package. A Twine game creates itself from its own data — reads through the text content of the children nodes of the div ‘storeArea’ — and maintains a Tale object that is composed of what it found. However, during execution, the page itself, both what the player sees visually as well as the DOM of the page itself, is changed. Child nodes are read, changed, and appended — all as a response to what the player does.
I would go farther then to define the basic mechanic of a Twine game to not to be based in a ‘click’ event, as Christine Love’s Even Cowgirls Bleed and my own little Not Game shows. Instead, it’s the movement of the mouse itself — the mouseover and click DOM events. There must be a clear intention toward interaction. The movement of the cursor across a page bubbles the event across every element it touches. When this is caught, it triggers the mechanic and calls whatever function was listening for it.
This is what makes a game the same as that of one created through Twine: not only is information passed, but progression comes from decisions. Passages do not exist within the narrative of the History object until they are generated as a result of the player. This is unlike a text, whose content is fixed ahead of time or even a hypertext whose nodes exist in connection to the previous one. The passages within a Twine game exist always in potentia until they are rendered.
Passages do not have connections to one another until they are shown to the player. They exist as saved wiki text within the Tale object. By choosing links to follow, their connections to each other come about because of a reaction to the player. A decision is made and the code reacts to create the next passage visually from what an author wrote within it, influenced by the other JavaScript code, CSS rules, and even other HTML elements that exist before it.
The player both reads and writes the story in Twine.
Digital Ephemera 
I’m going to disagree with you a bit. Interactivity in itself doesn’t make something a game (am I reading you right there? I think that’s what you meant). If it did, then a light switch could be considered a game, which it’s obviously not. What you’re missing is challenges. This is what distinguishes games from stuff with interactivity.
So, some projects made in Twine are games (have challenges), others are interactive fiction (have decisions), and others are just pages of text with links (links function only as hyperlinks). Since texts and hyperlinks are the only tools the creator has available, the only games that one can make in Twine all involve reading skills (scanning, skimming, remembering information). That is, excluding macros and other functionality (needed to feasibly make text adventures) or funky stuff like emulating Mario Bros with ASCII. I’m still learning about Twine, so I’m all to happy to dispute that last point and be proven wrong.
I’ll agree with you that interactivity in and of itself does not make something a game. However, I disagree that “challenge” is a prerequisite for something to be a “game”. For one, it’s too subjective a term. What might be a challenge for one set of people is not necessarily the same for all. Plus, there are situations where a group might be described as playing a game where there are no challenges at all. (If by “challenges,” you mean rules in some sense and Huizinga’s ‘magic circle’, we might possibly be more in agreement though.)
One could make the argument that all Twine games are interactive fiction. However, even that term is not as helpful as it could be in some situations. Super Mario Bros., by a very strict interpretation, fits that category as it is both interactive and fiction. However, yeah, most people wouldn’t agree with that assessment. No, Interactive fiction has come to mean entering commands or clicking on objects — mostly text with a limited verb set.
What are text adventures but text and some connective mechanic though? Is there really that much of a difference between clicking on a text link or some other graphic representation? I mean, it’s quite reductionist to write that projects in Twine are only “texts and hyperlinks” as that also describes nearly all websites on the Internet too. Those are fundamental parts of the medium itself.
Because Twine produces HTML files, yes, it is going to probably use text and hyperlinks at some point. However, the engine itself, part of every Twine file, is JavaScript. It runs in real-time in the memory of the browser, which is what makes Twine so unique and interesting right now: it’s both interpreter and source together as one file. That’s something quite rare to find.
I’m also not sure what you mean by “the only games that one can make in Twine all involve reading skills” because I interpret that as “the only video games Twine can make are those that are visual.” It’s probably not exactly what you meant, but since I consider all texts — including compiled code — to be based in language, it’s hard not to think that. I’ve seen many Twine games use images too, if that is what you mean though. And I’ve also come across several that use audio too, but it’s uncommon because cross-browser support for HTML5 audio isn’t standardized at the moment and it’s often more trouble than it’s worth.
1st paragraph:
I think you might have misunderstood my point on challenge. I mean trials in which the player must use skill to overcome, not difficulty. As for dys4ia, Proteus, Journey and other “games” without challenges, I would argue that they’re not games. (Not that not being a game is bad or less valid, but that making the distinction allows for clearer communication).
If you do mean challenge as in my definition (trials that test skill), then what distinguishes a game from a light switch?
Second paragraph:
Great point. All games are interactive and all games tell stories, ie. fiction, through play, and so all games can be considered as interactive fiction. The term itself is quite troublesome, isn’t it? I only used it for convenience. I also agree with what you say on text adventures.
“I mean, it’s quite reductionist to write that projects in Twine are only “texts and hyperlinks” as that also describes nearly all websites on the Internet too. Those are fundamental parts of the medium itself.”
I’m confused by this and the comments that follow. Yes, there are many different features in Twine, but from my understanding hyperlinks and text are the core tools. If one is to make a game with Twine (one with challenges that test the player’s skill) then one needs two things: mechanics (player functions/abilities) and game elements (enemies, objects, etc). Since clicking through to the next page is the only function in Twine, all mechanics are based around hyperlinks and the text that contextualises them. Putting macros, images, sound, and other elements aside, text is the only tool that the player has to create game elements. Because the game world is built of text, the only skills one can test are those relating to text. That is unless they make a funky ASCII visual game or convert other games (like say a questionnaire game) into Twine, but neither would work very well.
I’m gonna poke around at some of your Twine games for a bit. 🙂
See, I have a problem with calling things “not-games” though. Well, I have a problem when the usage is to undercut the meaning of an artifact. When it is used, like in the movement to get away from the baggage of “games,” I’m fine with it and even promote it. (See http://notgames.org/). However, many — and I’m not accusing you of this but others have and continue to — say something is “not a game” in order to control it or lessen its power. It’s a rhetorical move often used to discriminate.
As to the original point though, I’m not sold on this usage of skills, challenges, or even difficultly to mark something a “game” or not. As someone who has personally played around with trying to program procedurally generated content in games and has spoken to Ed Key myself, I have intense respect for Proteus and definitely think it is a game. After all, progression is marked by an understanding of the game’s metaphors. You cannot move through the seasons without processing what is going on and then making a decision about if to engage with the game or not.
(Plus, and this is what makes Proteus so utterly amazing to me: no words! It’s a game without words — no score, UI messages, or anything else. That by itself is what marks it as completely mind-blowing to me. It’s a design achievement that is incredibly rare to find.)
That’s the same for Journey and dys4ia too. As a player, you must process the metaphors at play and come to a conclusion about how to proceed. It’s a constant series of choices — even if they might all be an illusion.
“…my understanding hyperlinks and text are the core tools. If one is to make a game with Twine (one with challenges that test the player’s skill) then one needs two things: mechanics (player functions/abilities) and game elements (enemies, objects, etc).”
Yes and no. The point I was trying to make is that HTML as a medium is made up of text and hyperlinks. That’s how it works. Now, yes, there exists a great deal more elements (audio, video, canvas, and object) now in version 4 and 5, but it’s basically still text and hyperlinks at the core. So, because Twine produces HTML files as output, most authors are probably going to use the prominent mechanics of the medium — it’s going to be mostly text and hyperlinks.
Mechanics, like the word gameplay, is hard to define. What exactly is a mechanic? Is it a rule or reaction? If the code takes no action when I do something, is that a mechanic? It’s tough to strictly define. I usually, and this is how I used it in my last paragraph, say it’s a reaction though. The code had some rule that responded to what I did in a player-noticeable way. (That’s a humanistic take on that though.)
“Since clicking through to the next page is the only function in Twine, all mechanics are based around hyperlinks and the text that contextualises them. Putting macros, images, sound, and other elements aside, text is the only tool that the player has to create game elements. Because the game world is built of text, the only skills one can test are those relating to text. That is unless they make a funky ASCII visual game or convert other games (like say a questionnaire game) into Twine, but neither would work very well.”
Clicking is not the only “function” (event) though. It’s the default one because that’s the way people usually understand web pages to work: you click on a link and something happens. It’s not something exclusive though. Twine could easily use any other user-generated event such as keyboard input, page loading, or anything other event the browser generates. In fact, because it’s JavaScript anyway, new events can be created to handle things like holding down multiple keys simultaneously or for new input devices.
All game worlds are built with text though. It’s all code. That’s what my slight tangent into writing about texts and compiled code was about. Images do not a video game make. Many can have their “video” part be text, like in the text adventures I’ve made in Inform 7 or even those games I’ve made in Twine too. The perceived depth of a world like Super Mario Bros., to return to that example, is nothing but a trick. It’s z-layers and parallax scrolling.
Like, if you look at the HTML5 projects I have listed on the right-hand column, they seem closer to what I think you might consider games, but they really no different at a code level to me then the Twine projects. They are all HTML and JavaScript. The visual difference comes from me usually spending more time making images for the HTML5 games than I do for the Twine ones because the expectations are that Twine games will use text and hyperlinks.
“I’m gonna poke around at some of your Twine games for a bit.”
My stuff lately, for the last few weeks or so, has been about playing around with trying to generate glitches — if that is even possible. If you look at the last few weeks worth of Twine projects from that link to the 52 Twine Stories tumblr, that’s what those are. However, the other ones I list on the right-hand side are closer to being interactive in the sense that they respond to the player in some way.
If you are looking for Twine games to try though, I actually recommend Howling Dogs (http://aliendovecote.com/uploads/twine/howling%20dogs.html) as it’s probably the most famous one. Then there is Depression Quest (http://www.depressionquest.com/). And you might want to look at Even Cowgirls Bleed (http://scoutshonour.com/cowgirl/) too.
There’s even TwineHub (http://dl.dropboxusercontent.com/u/87314472/twinehub-play.html), which is a a listing of Twine games made in Twine, including many of the things I made earlier this year.
I think this “not games” argument is more of an issue of labels and credibility. The word “game” has capital and so when people comment that, say, Journey, isn’t a game, others interpret that to mean that it’s less credible. If people want Journey to be considered a game, then they have to be prepared for it to be interpreted as a game, and in that regard, all of these non-games are abysmal failures. See: http://critical-gaming.com/blog/2012/7/23/the-end-of-the-journey.html I think it’s much easier to treat these “non-games” for what they are so that they can be fairly understood and evaluated by players.
There is some sort of difficulty in Proteus (“You cannot move through the seasons without processing what is going on and then making a decision about if to engage with the game or not” + spatial navigation, etc), but there is also some sort of difficulty in flicking a light switch (spatial skills, dexterity). The challenges in games are of a much higher level than the ones in Proteus, Journey, light switch, etc. So, I ask again, if challenges of skill aren’t the differentiating factor between games and light switches, then what is? (Without challenges of skill, games wouldn’t be systems of education and mastery that they are).
On mechanics, it’s much clearer to say that mechanics are functions, usually ones that the player can execute. In a game system, there are potentially millions of things reacting to other things, some of them are important (player jumps, player falls into spiked bit), some of them aren’t (the wind blows against the grass..but it was out of the player’s view). So no wonder you find this definition so hard to use. Player function is much easier. Mario’s jump is a mechanic. Samus’s grapple beam is a mechanic.
On functions, you make some interesting points. For better or worse to the conversation, I’ve been trying to focus just on the text and links because I’m writing an article on how to make a video game in Twine (as opposed to an interactive narrative or website, it must have challenges of skill to qualify) while I try to make that game in question.
” Images do not a video game make.”
Yeah, absolutely. But because the “game world” in Twine, sticking just to the text and hyperlinks, is composed of text (“made of” was probably a poor choice of words), the only skills that can be tested are reading and memory skills.
Cool, I’ll check out more of those links. Thanks for the heads up.
Wait. What? Journey is very much a game. To use your own emphasis on skill and challenge, the player must learn how to use to use the jumping mechanic in order to progress in the game. Now, as for it not having having a hard fail state for the player, that perhaps mitigates the challenge somewhat, but it’s not very different than, in another context, a large number of “lives” or checkpointing.
I meant to ask this in an earlier comment, but where is this “a game must have a challenge” coming from exactly? Because the major voices in the field of game studies don’t use that definition (See http://www.jesperjuul.net/text/gameplayerworld/ for a decent breakdown of the past several decades worth of books on the subject). Nearly all either use a formalism approach (rule-based) or come at from the narrative side. (Hence the debate of ludologist “versus” narratologists.)
As to mechanics and functions, that can be tricky to deal with too. When I read “function” I often think of it in the programming sense: some block of code. Like, consider the following few lines from one of my own projects using the HTML5 JawsJS library:
if(jaws.pressed(“w”)) {
player.dy = -15;
player.move();
}
…
player.move = function() {
this.y += this.dy;
…
this.dy = 0;
}
When the player presses the ‘w’ key, the player object on the screen appears to move because its delta-y (dy) is added to its current y coordinate. It’s a translation on the screen because, each time the key is pressed, an image moves upwards (towards a lesser amount of y).
Most people would consider that a mechanic of some sort — a player function, if you will. However, what if I change that code some in testing but forget or decide not to restore some checking. What if it now was the following:
if(jaws.pressed(“k”)) {
//do nothing
}
Is that a mechanic? It becomes an interesting knowledge problem. If the player does not know some functionality exists, does it still “exist” to them? If I bound a key in one of my games as the only way to ‘win’, but didn’t record anywhere what it was — or even had it be randomly picked each session — is that then still a mechanic?
That’s part of the reason I usually go with a more humanistic approach to mechanics: a player must be aware of or initiated an event that is the response from the rules. It means things like Samus moving or Mario jumping are mechanics. Things like object collisions frequently aren’t unless the response in code produces an effect that influences future player response. Examples of this would be Mario colliding with the ground or bullets hitting enemies. Because those collisions lead to results the player “cares about,” they become mechanics.
(It’s not uncommon to have object collision code for other objects that do not or will not ever collide with the player-controlled object too. For example, the cloud in this game, http://videlaisstudios.info/games/2013/jawsjs/perseverance/, will only ever wrap around the screen. The player-controlled object cannot collide with it.)
To loop back into the Twine discussion though, this means that the clicking or the mouseover event (see my own http://videlaisstudios.info/games/2013/twine/notGame.html as an example of a Twine game without clicking), are mechanics because they lead to state changes. If a player clicks on a link, something usually happens as a result.
But anyway, if you are looking for resources on making projects in Twine, I’ve also created a bunch of stuff to help people.
I wrote a three-part guide on Gamasutra:
http://www.gamasutra.com/blogs/DanCox/20130203/185939/Learning_Twine_Part_1.php
http://www.gamasutra.com/blogs/DanCox/20130209/186341/Learning_Twine_Part_2.php
http://www.gamasutra.com/blogs/DanCox/20130218/186810/Learning_Twine_Part_3.php
Posted weekly code examples from my own projects for a couple months:
https://videlais.com/category/twine-tuesday/
And even have a series of videos I produced:
Once you have something made in Twine, please let me know. I’m always interested to see what other people come with and what metaphors others use in their work. I’d like to see how you translate challenge into something created in Twine.
(And, just so you know, you have “challenged” me, as it were, to see if I can create something in Twine that uses neither text, hyperlinks, nor clicking. I think it’s an interesting exploration of what might be possible in Twine without relying on the default mechanics or controls.)
I’m going to start a new reply so that we don’t squish up the writing space.
On challenge and notgames
Sure. Your comments on Journey are quite correct. Perhaps it wasn’t the best example of a pure “not game”, but it’s certainly somewhere close. Allow me to elaborate. One can cleanly distinguish between games and non-games by seeing if they do or don’t have challenge. At the same time, within games there are games which privilege gameplay (challenges, education, mastery) and those which privilege it less so or privilege other elements (graphics, story, ideas). To take a few examples, a puzzle game like Picross values gameplay (because the player’s interactions and the results of those interactions are the most important parts of the game, the visuals, story, etc are all downplayed). A game like the new Tomb Raider sits somewhere in the middle. The game values its story to the detriment of the game’s challenges. A game like Journey is on the opposite end of the spectrum. The player can’t interact with the world very deeply. The gameplay is poor but the presentation is rich.
My point on games having challenges comes from trying to distinguish games from not-games (from my 1st reply, you agree on interactivity, but we disagree on the challenge point). I’m glad that you mentioned Jesper Juul and game studies, because that’s where many of my ideas come from too. Under the “A new definition: 6 game features” heading in the article you linked to, when you put points #1-5 together, translate to challenges. That is, challenges are made up of rules, win/lose outcomes, player effort (exertion of skill), and player attachment. The meaning is the same.
On mechanics and functions
Since the player can’t see a game’s code, it’s much easier to talk about the stuff that’s in the game then what’s in the code. So, if the player presses a button and nothing happens, then obviously it’s not a mechanic. If the player presses a button and something happens, then yes, it’s a mechanic. How much needs to happen for something to be considered a mechanic is another topic altogether. I think we agree here.
Object collisions are interactions that occur between two game elements. Not mechanics, player abilities. I think we agree there too, but judging mechanics based on what the player “cares about” is a poor way to judge mechanics. It’s much easier to think of mechanics as things the player can do and all this other stuff as what it is. Personally, I see this stuff as:
mechanics – what the player can do
game elements – enemies, coins, ammo, etc
interplay – interactions that happen between game elements (Mario steps on Koopa Troopa, KT goes into shell, Mario kicks KT)
rules – conditions like timers, points needed to win
These terms are strict and clear. Your last comment shows that you already understand mechanics, as functions the player can do, quite well.
I have a few questions that I was hoping we could work through in regards to making a game with skill-based challenges in Twine. Can you help?
-What other examples do you have for game mechanics in Twine? (Can be made with additional code and tricks)
-Aside from mouse look and click, are there any other game mechanics that be be created without additional code or tricks?
-Assuming that you agree with my points on games having challenges which test skills, are there any other skills that can be tested besides reading and memory skills?
I have already played a number of your 52 Twine Story games and checked out the video tutorials. I still have quite a bit to go through yet. All very interesting.
This site may act as inspiration for your quest: http://dontclick.it/ Just replace the text with colours or something. This discussion has been great so far. Thanks for all the learning. ^_^
I finished the draft of my Twine game today, I’ll send it to you when it’s polished up a bit.
“A game like Journey is on the opposite end of the spectrum. The player can’t interact with the world very deeply. The gameplay is poor but the presentation is rich.”
Yeah, but that works for games like most first person shooters too. There exists a vast amount of objects and doors the player cannot interact with through the character. We have these vast and beautiful worlds which are, once we investigate them, actually very reminiscent of museums: “Look. Don’t touch.”
I actually get the feeling we agree on most of this except for the challenge issue. I just don’t like that idea. If we agreed to call them generally “rules,” I’d be comfortable with it, but I don’t like the word challenge because it necessitates a value judgement on the material. As I wrote before, what might be a “challenge” to some subset of players might not be for another.
On mechanics and functions:
Yeah, I slipped into one of my favorite discussion points: the knowledge problem. It basically comes down to how information affects narrative-encoded artifacts. Like, how knowing the end of Braid affects how you come to see the previous time spent playing it and learning the actual origin of Tidus in Final Fantasy IX comes to effect the outcome of the story.
As a more recent example, Antichamber features this idea. Once you figure out how to solve a certain set of puzzles in that game, it becomes incredibly easy. There is a knowledge threshold that many don’t quite reach that prevents them for finishing the game. However, once you know how some combinations of mechanics work together, the game can be finished in less than an hour — after, that is, the 10 or so hours building up to that point and learning how the puzzles work it takes most people.
Twine:
“What other examples do you have for game mechanics in Twine? (Can be made with additional code and tricks)”
Potentially, anything any other JavaScript-based project can do, a Twine project can also do. However, even with some (what I would consider) basic JS code, Twine sometimes doesn’t act as you expect it to. Part of the problem, from my point of view at least, is that it isn’t designed to do anything more than keep track of some variables and parse its internal text. Adding more functionality can often be very frustrating because the code must be written and tested outside Twine before adding it to a project. (It has to do with how Twine handles ‘script’ passages and program scope during execution.)
“Aside from mouse look and click, are there any other game mechanics that be be created without additional code or tricks?”
JavaScript is a event-driven language, so, as implemented in Firefox for example, it can listen and act on any of these events (https://developer.mozilla.org/en-US/docs/DOM/Mozilla_event_reference). That covers all possible input from traditional devices like keyboards and mice, as well as some things Mozilla decided to include like touch controls and support for some card devices.
From that, someone could write something that acted like Mario or really any other game. The great problem with breaking away from the webpage paradigm though is that an author would need to basically create a separate game engine and then place it in Twine. And it’s just not worth the trouble. There are far better libraries — like JawsJS — that are designed for creating more image-based projects in JavaScript.
However, like I wrote earlier today, you’ve got me thinking about what it might take to remove hyperlinks from Twine and substitute something else like keyboard support instead. It’s an interesting problem, especially when paired with trying to make a project without text too. I plan to see what I can come with tomorrow when I get some time to work on it.
“Assuming that you agree with my points on games having challenges which test skills, are there any other skills that can be tested besides reading and memory skills?”
I have a problem with your premise. Since I take a very post-structuralist view of cultural artifacts, I see everything as composed of language in one form or another. So, my answer would be that interaction comes after reading, which is a part of all visual interpretation of signs.
In order to press start on a game, you must first understand the words “press” and “start” as well as the grammar expectations of the controls too — what the “Start” button might be and mean. All games, then, have a reading aspect to them, including those with very limited usage of words like Proteus or even the recently released Kairo.
So… yes?
If you are asking if most Twine projects will be entirely audio-based or something like that, the answer is probably no. Twine’s not really the right tool for that job. It shines for projects that are based in text and use hyperlinks to move between passages.
I mean, I could make something that was twitch-based, I guess, but JavaScript doesn’t have reliable timing functions. Well, it does, but because the language is interpreted in real-time, any timing is going to be slightly off below a certain threshold. It makes developing games that require fast reaction times from both the player and game harder. (Plus, you know, in order to respond fast, you must be able to ‘read’ the screen and come to a decision about what button to press.)
“Thanks for all the learning. ^_^
I finished the draft of my Twine game today, I’ll send it to you when it’s polished up a bit.”
You’re very welcome. Like I wrote, you’ve made me think about what might be possible in Twine and consider how I might create some interesting edge cases. Because I’m making something new every week this year, it’s nice to have some extra ideas and theories for projects. It is surprisingly easy to burn through different approaches after making a dozen or so weekly projects.
On challenge,
Absolutely. FPSs have a hard time creating deep interaction because of the lack of interplay inherent to gunplay (I shoot, you die, that’s it for the most part). Then there’s the museum effect you talk about.
I don’t think I can change your mind on challenge. I’ve linked it to the academia you provided, talked about the value people hold in the word “game”, and you still haven’t told me the difference between a light switch and a game. Challenge is simply not the issue. So long as games are good teachers and well designed, then challenge is never a problem. How do you explain the phenomenal success of Tetris among “non-players”? Why don’t people complain about the presence of sudokus and crosswords in newspapers as belittling them? Why is it that my wife, a non-native speaker of English who doesn’t play games much, when left to her own devices, can master and complete Critter Crunch in an afternoon? I think the real problem is that a lot of the games you make are non-games and so when I say all this, you probably feel that I’m making a value judgement on your work, which is not the case. Books aren’t lesser than film because they lack moving images, just as non-games aren’t lesser than games because they lack challenges. They’re just different mediums.
“what might be a “challenge” to some subset of players might not be for another”
This is true, but it’s the same for all players. I’m pretty good at games, I guess, but I still find some genres, like rouge likes, to be pretty tough. This is the nature of skill-based learning systems. I don’t feel bad that I’m no good at rogue likes, I just play the games I like.
This series of articles might help explain some of the ideas that I think are at work here and why gameplay and challenges are important:
http://critical-gaming.com/blog/2012/4/4/a-defense-of-gameplay-pt1.html
On mechanics and functions:
I think this has turned into something else now, but yeah, good observations. Any game that deals with knowledge skills, ie. puzzles, has this element to them.
On Twine
The answers to your question are fantastic and fit in well with this article I’m writing, do you mind if I quote you and link back here? I don’t have anything more to add.
On game ideas
I haven’t seen any text or graphical adventure games with permanent mechanics like look, pick up, and so on. Would it really be so hard to, say, port Granny’s Garden to Twine? I haven’t even seen a game where you pick up and maintain inventory, that could be a game changer. By the same account, any sort of turn-based game could technically be made in Twine. Your game cnossus also reminded me of this game http://ian.janasnyder.com/13gates.html I’m not sure if there’s a way you could combine the ideas.
“I don’t think I can change your mind on challenge.”
You probably can’t, which is actually a good thing. It’ll allow us to have interesting conversations from different positions.
“How do you explain the phenomenal success of Tetris among “non-players”? Why don’t people complain about the presence of sudokus and crosswords in newspapers as belittling them?”
In Homo Ludens, Johan Huizinga makes a case for civilization being based in play and therefore games being at the very root of how humans think. They “make a game” of serious matters and can abstract out battles as chess and other sets of rules. It’s a fascinating approach, but can be rather dry reading at times (it was written in 1955).
It’s very hard, then, to find someone who has never played a game. Maybe they have never played a video gamer per se, although even that is decreasing, but a “non-player”? That’s, at least according to Huizinga, not possible.
“I think the real problem is that a lot of the games you make are non-games and so when I say all this, you probably feel that I’m making a value judgement on your work, which is not the case. Books aren’t lesser than film because they lack moving images, just as non-games aren’t lesser than games because they lack challenges. They’re just different mediums.”
Oh, I’m not getting upset about my stuff. I work all the time and can’t really invest in my projects as much as I’d want. They are mostly exercises to keep me making things. What I worry about is how definitions affect other people and their projects. As I think I wrote at some point within the last few days, I’ve seen the term “not-game” used to discriminate against including certain groups and creations.
“On Twine
The answers to your question are fantastic and fit in well with this article I’m writing, do you mind if I quote you and link back here? I don’t have anything more to add.”
Sure?
I highly encourage you, if you have the time and inclination, to chase these ideas some yourself though. It’s a very exciting time in game studies as the Twine Revolution is maturing and, at least as I’ve seen to the case, “systems” are being examined as a way developers encode meaning and even their own cultural values in games.
“I haven’t seen any text or graphical adventure games with permanent mechanics like look, pick up, and so on. Would it really be so hard to, say, port Granny’s Garden to Twine? I haven’t even seen a game where you pick up and maintain inventory, that could be a game changer. By the same account, any sort of turn-based game could technically be made in Twine. Your game cnossus also reminded me of this game http://ian.janasnyder.com/13gates.html I’m not sure if there’s a way you could combine the ideas.”
The reason why this harder to do than it appears is that permanent storage in browsers doesn’t really exist outside of extensions — if it did, it’d be a security flaw. So, trying to save items (basically telling the browser to remember a value) isn’t easy to do cross-sessions. And, again, Twine isn’t really designed to do that.
However, yes, it is certainly possible. I’ve been working on some code for JawsJS (what I use for my graphical projects) that would use the functionality in different browsers to save content across sessions. Once I get it working, I’ve been considering porting it as something others could use in Twine projects too.
Sure, asynchronous play (turn-based) would be pretty easy to do in Twine too. There would probably need to be some server code written for a multiplayer approach though — another reason most people don’t do it. I mean, that’s really, building off of that point, why many people — and me — don’t make larger projects: the time investment.
Because Twine, like I think I wrote before, is HTML at its core, it can be anything any other webpage can. There are no real limits. Could it use Flash? Sure. Use HTML5? Absolutely. Incorporate other libraries like jQuery? Of course.
What makes Twine so great is that programming has been (nearly) removed from the equation. In order to make a game, others don’t need to know how JavaScript works or have a working knowledge of ActionScript 3 (Flash) to make something. It’s the best solution, at the moment anyway, for putting the tools for making games in the hands of anyone who has access to a browser.
On challenge,
So, then, challenge isn’t a problem? @_@ I don’t understand how challenge necessitates a value judgement.
On Twine,
I finished my Twine game last week and have been thinking about doing a follow up project, but I really don’t think that I can make another game in Twine. That is, I don’t think it’s possible without stretching the medium in any strange ways or adding some external code. Although Twine is becoming more and more popular, the limitations for making games (with challenges) is pretty much set, I think. I’ve been playing quite a number of Twine stories lately, but none of them are games. Your last comment shot down some of my other ideas, so I’m not left with much. I think that I’ll get some feedback on my game and start writing my article first. That should help me clear my thoughts. I will send you a copy in the next week or so and we can continue this discussion by email. Does your site have an RSS feed btw?
To me, no, challenge is not important. I don’t consider it an essential part of what games are — or could be in the future. It’s too limiting, and again this is how I personally think, to delineate that these artifacts have challenge (and are thus games) and these others don’t. It’s not useful.
The value judgement part comes in what you consider a challenge to be. For example, since I consider all systems to have rules and thus grammars, all valid interactions with that system make up its language. This is true for economic systems and its true for games like Tetris.
Trying to learn each system’s ‘language’ could be seen as a challenge, I’ll grant you that, but it’s not one many other people would mark as one. People don’t usually consider learning a non-native language a game, but it certainly could be one too.
That’s the problem with that word for me. A challenge for who exactly?
Twine:
“Although Twine is becoming more and more popular, the limitations for making games (with challenges) is pretty much set, I think. I’ve been playing quite a number of Twine stories lately, but none of them are games.”
As someone who makes things on a fairly regular basis, I’ve come to really like constraints. It’s nice to have a sandbox that has walls. Sometimes, the smaller the canavs, the more inventive you need to be in order to get a message across.
That written, I don’t we have seen the limits of Twine games quite yet. Porpentine’s Naked Shades (http://vote.runhello.com:4334/twine/shades.html) points at what a always-connected world using Twine might look like. And I’ve been playing around with using just keyboard input (http://videlaisstudios.info/games/2013/twine/relationship.html — WASD to move). There’s still lots of interesting interactions out there to mine for projects.
“Does your site have an RSS feed btw?”
You reminded me that I needed to post that, so I just added an icon as part of the right-hand column. It’s also at https://videlais.com/feed/
On challenge,
“Trying to learn each system’s ‘language’ _could_ be seen as a challenge,”
This quote makes me unsure if we’re even on the same page. Beating a level in Super Mario Bros is a challenge, it requires various skills (dexterity, reflex, timing, knowledge, adaption). If “Trying to learn each system’s ‘language’” is meant to mean using interactions to exert skills/in a way that shows mastery (and not “understanding how a system works” which it could be inferred as, and just means having a working knowledge of a system) then how can you say that beating a level in Super Mario Bros _could_ be seen as a challenge? Of course, it’s a challenge. According to the academia you referenced, it has rules, win/lose outcomes, player effort (exertion of skill), and player attachment.
Also, if you “don’t consider [challenge] to be an essential part of what games are” then can you please tell me what’s the difference between a light switch and a game? If you can’t answer me this question and tell me why the academia you use aligns with my own views more so than your own, then I’ll take it that you concede these points.
On Twine,
Oh, I absolutely agree. Limitations are fantastic. One of the reasons why I’m so fascinated with Twine is that it has such narrow limitations. Naked Shades isn’t a game, but your WASD movement project could be turned into a simple puzzle game. I guess there is potential to be mined with stuff that moves away from text and “links”, but I think that’s getting away from the essence of Twine. I’m not so sure. I’m willing to give you the benefit of the doubt on this one.
Thanks for the RSS link and being so open to direct dialogue. 😀
The question becomes if, when a machine does it, is it still challenge? That’s what I’m getting at in bringing in language and interpretation. It’s a slippy slope of judging games from the perspective of one group versus another that making challenge be an essential part of what games might be brings to the table.
As for the light switch question, my answer is this: yes. A light switch can be a game. What you didn’t ask is if light switches are always games. In which case, the answer is probably no.
I can make a light switch into a game by adding rules like how many times can each person flip it in a short amount of time or in how fast someone might be able to flip the switch and then run away before getting caught. There are any number of ways in which a light switch could become the core mechanic of a game.
In fact, if we consider the light switch to have two exclusive positions, on and off, it could be used to construct a state machine and thus build towards having an accepting language. With the necessary time and equipment, it is possible to make a programming language, in a sense, using only physical light switches. (It’s often used a thought experiment in explaining computer architecture.)
Twine:
See, I don’t think Twine has the limitations you think it does. Just because Twine uses the same paradigms of hyperlinks that most HTML does, doesn’t mean it is limited to that. Like I showed, it is possible to do any number of things that browsers are capable of understanding. From graphics to sound, even video.
On Twine,
Yeah, I agree with you here. My point is based on trying to make a game only with text and hyperlinks, but given that I’m willing to give you the benefit of the doubt.
On challenge,
I don’t understand what you mean by “when a machine does it”. Whether games be digital or physical, physical human beings do the challenges.
“It’s a slippy slope of judging games from the perspective of one group versus another that making challenge be an essential part of what games might be brings to the table.”
As I said in the other comment thread, and wish I’d brought up much earlier, I define games by the same definition that has defined games for hundreds, if not thousands, of years: “a form of play or sport, esp. a competitive one played according to rules and decided by skill, strength, or luck.” (Oxford dictionary). I didn’t just invent this whole thing on challenge because of the zinesters vs formalists debate. I’ve been using this as the basis of my writing for years. If by “one group versus another” you mean players of different skill sets, see my earlier comments on this, and your reply (Homoludens).
“I can make a light switch into a game by adding rules like how many times can each person flip it in a short amount of time or in how fast someone might be able to flip the switch and then run away before getting caught. There are any number of ways in which a light switch could become the core mechanic of a game.”
Ah, so if there are rules (conditions) that the player has to meet, then it is a game. So, by adding rules it becomes “a task or situation that tests someone’s abilities”, ie. a challenge (Oxford Dictionary). This statement, like the Jesper Juul, Homo Ludens, and a few of your other comments, tells me that we actually agree 100% and that you just don’t like the connotations of the word “challenge”.
Pingback: Daniel Primed:: Hobbyist Game Analysis » On Games and Non-games, I Made a Game Too [Playtesters Needed]