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

Let's make some computer and video games!

Moderator: Ice Cream Jonsey

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

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

Post by pinback » Thu Mar 02, 2017 3:10 pm

Above all else... We shall go on... And continue!

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

Post by Flack » Thu Mar 02, 2017 4:40 pm

I won, but it took 14 times.
"Jack Flack always escapes." -Davey Osborne

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

Post by Jizaboz » Fri Mar 03, 2017 7:18 am

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


Also, Twine sucks.

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

Post by pinback » Fri Mar 03, 2017 7:38 am

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.
Above all else... We shall go on... And continue!

User avatar
Tdarcos
Posts: 5208
Joined: Fri May 16, 2008 9:25 am
Location: University Park, Maryland
Contact:

Post by Tdarcos » Sat Mar 04, 2017 1:14 am

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.
The lessons of history teach us - if they teach us anything - that no one learns the lessons of history. tdarcos@tdarcos.com

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

Post by RealNC » Sat Mar 04, 2017 1:23 am

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: 1139
Joined: Tue Jan 31, 2012 2:00 pm
Location: USA
Contact:

Post by Jizaboz » Mon Mar 06, 2017 5:25 pm

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