Testing out Twine, since it's the way of the future.
Moderator: Ice Cream Jonsey
-
pinback
- Posts: 17849
- Joined: Sat Apr 27, 2002 3:00 pm
- Contact:
Testing out Twine, since it's the way of the future.
Am I a hero? I really can't say. But, yes.
-
Flack
- Posts: 9057
- Joined: Tue Nov 18, 2008 3:02 pm
- Location: Oklahoma
- Contact:
-
Jizaboz
- Posts: 5420
- Joined: Tue Jan 31, 2012 2:00 pm
- Location: USA
- Contact:
-
pinback
- Posts: 17849
- Joined: Sat Apr 27, 2002 3:00 pm
- Contact:
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 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.
Am I a hero? I really can't say. But, yes.
-
Tdarcos
- Posts: 9529
- Joined: Fri May 16, 2008 9:25 am
- Location: Arlington, Virginia
- Contact:
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.
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.
"Baby, I was afraid before
I'm not afraid, any more."
- Belinda Carlisle, Heaven Is A Place On Earth
I'm not afraid, any more."
- Belinda Carlisle, Heaven Is A Place On Earth
-
Jizaboz
- Posts: 5420
- Joined: Tue Jan 31, 2012 2:00 pm
- Location: USA
- Contact:
Agreed! Excellent, Paul.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.
(Twine still sucks)