Testing out Twine, since it's the way of the future.

Let's make some video games!

Moderator: Ice Cream Jonsey

Post Reply
User avatar
pinback
Posts: 17672
Joined: Sat Apr 27, 2002 3:00 pm
Contact:

Testing out Twine, since it's the way of the future.

Post by pinback »

I don't have to say anything. I'm a doctor, too.

User avatar
Flack
Posts: 8822
Joined: Tue Nov 18, 2008 3:02 pm
Location: Oklahoma
Contact:

Post by Flack »

I won, but it took 14 times.
"I failed a savings throw and now I am back."

User avatar
Jizaboz
Posts: 4811
Joined: Tue Jan 31, 2012 2:00 pm
Location: USA
Contact:

Post by Jizaboz »

20x better than 99.9% of the crap written in Twine.


Also, Twine sucks.

User avatar
pinback
Posts: 17672
Joined: Sat Apr 27, 2002 3:00 pm
Contact:

Post by pinback »

I don't believe Twine itself sucks, I just don't think that "interactive fiction" is its best use. I would suggest that it may excel as an educational tool.

I have no basis on which to suggest that, but I'm just gonna go ahead and do it. Don't like it? CLICK HERE TO EAT MY ASS.
I don't have to say anything. I'm a doctor, too.

User avatar
Tdarcos
Posts: 9333
Joined: Fri May 16, 2008 9:25 am
Location: Arlington, Virginia
Contact:

Post by Tdarcos »

I won the first time.

Someone once said "a poor carpenter blames his tools." Every language intended to provide a solution to a problem domain has good points and bad points.

Some programming systems are domain specific and some are general purpose. And one can have problems if you pick the wrong language to solve the problem. Cobol is an excellent language for handling financial applications; I suspect it is horrible for writing device drivers.

Interactive fiction languages are designed around the most common practices in a typical IF game: processing text commands and allowing the commands to advance the story of the game. The language does, or at least attempts to, take over the "heavy lifting" of the "backoffice processing" of the application: accepting input, parsing the user's commands, processing the commands to effect the user's instructions and to affect the game state. Thus the writer can focus on the story and let the computer handle the grunt work.

If a language is designed well so that implementing the game has very little friction and is straightforward, you may not even notice the underlying design system. But if you have to fight the system and do workarounds to get around problems or deficiencies in the language, then you are likely to complain about how bad the system is. Whether that's a valid criticism from someone who knows what they are doing and has recognized flaws, or someone who has not adequately learned the system and is misidentifying their own lack of experience for system flaws and inadequacies in another issue.
Alan Francis wrote a book containing everything men understand about women. It consisted of 100 blank pages.

User avatar
RealNC
Posts: 2244
Joined: Wed Mar 07, 2012 4:32 am

Post by RealNC »

I beat it! I don't know what it was about. I saw links and clicked them, then "*** you won ***" appeared.

User avatar
Jizaboz
Posts: 4811
Joined: Tue Jan 31, 2012 2:00 pm
Location: USA
Contact:

Post by Jizaboz »

Tdarcos wrote:I won the first time.

Someone once said "a poor carpenter blames his tools." Every language intended to provide a solution to a problem domain has good points and bad points.

Some programming systems are domain specific and some are general purpose. And one can have problems if you pick the wrong language to solve the problem. Cobol is an excellent language for handling financial applications; I suspect it is horrible for writing device drivers.

Interactive fiction languages are designed around the most common practices in a typical IF game: processing text commands and allowing the commands to advance the story of the game. The language does, or at least attempts to, take over the "heavy lifting" of the "backoffice processing" of the application: accepting input, parsing the user's commands, processing the commands to effect the user's instructions and to affect the game state. Thus the writer can focus on the story and let the computer handle the grunt work.

If a language is designed well so that implementing the game has very little friction and is straightforward, you may not even notice the underlying design system. But if you have to fight the system and do workarounds to get around problems or deficiencies in the language, then you are likely to complain about how bad the system is. Whether that's a valid criticism from someone who knows what they are doing and has recognized flaws, or someone who has not adequately learned the system and is misidentifying their own lack of experience for system flaws and inadequacies in another issue.
Agreed! Excellent, Paul.

(Twine still sucks)

Post Reply