Ah, but IF is constrained by design, and willing to do so. As an IF writer, I don't give the player a world filled of interesting things to do and then suggest some goal: I simply plan about an specific puzzle and then populate the world with the minimal actions and objects needed to win. Any side addition such as extra actions available and more objects to define the world and interact with, are considered simple flavor or clues for the player, when this form of interactivity should be the central point of the experience instead of yet another word puzzle or yet another story to be told. It is incredible just how so many games blame the player when s/he attempts to interact with some things not related to the plot ("this is only scenary, you idiot!").
The game industry is in no good shape, but there is hope. Serious research has been going on the field since the 60's at least, and there is the literature to prove it. There is no excuse to ignore all this work, neither for the professional 3D-wizbang developer (who unfortunately usually does) nor for the amateur game writer.
Actually, I see Photopia as a step backwards. I agree it's a fantastic story, but there is no interactivity at all. The command prompt in Photopia could be substituted by a "press any key to continue" message and the overall experience could be about the same. Perhaps better, because the "puzzles" in Photopia serve no purpose at all and can distract you. Photopia triumphs with the fiction part while dismishing the interactive one.
I have to concede at least that the IF designer does not have nonsense marketing constraints such as the need to do big, flashy 3D graphics. Actually, the command prompt would be the best interface there is IF (and it is a big if) it understands everything. Then it is the equivalent of a Star Trek computer hearing your voice and doing just what you said. The problem with current command prompts, and the cause they are substituted by GUIs, is they don't. They only understand a tiny subset of verbs you're supposed to memorize. Interactive fiction "pretends" it understands a lot. You're supposed to try anything you want. The reality is, however, very different. There is a tiny subset of commands accepted, and you know them either because you're familiar with the genre or because guessing them is part of the puzzle. This is horrendous interface design at best. There should be another way, maybe inverse parsers, maybe some new interface abstraction not seen yet.
Finally, I'm not interested in historical retrogaming. There are other good points to bring interactive fiction to the table. Anybody could write it, for example, transforming the genre to a medium and not only a bunch of "games" (it's not true today simply because the current tools are simply not designed this way).
Interactive fiction games are actually not very interactive.
The word interactive suggests some kind of system capable of adjusting and modify itself to your reactions in some manner. Such a system should do its best to watch your movements, whatever they are, trying hard to provide a reasonable response to them. Interactivity is all about giving you as most freedom as possible. Interactive software is expected to allow you to do almost anything you wish and provide reasonable and interesting responses to all your actions. Chris Crawford refers to the process as a listen/think/speak loop between two actors, and the most thinks you can "say" that your listener will understand, the more interesting is the converstaion.
However, "interactive fiction" is filled by constraints. The game limits as much as it can the things you can do: you can't move to any place, you can't take anything, you can't speak to other people, and when you're able you can't say almost anything to them. You're expected to find the "commands" the game understand, and the game world is filled with random constraints called "puzzles". While I expect the presence of conflicts and obstacles in a game, the moment there is a predefined, designed set of closed solutions you almost can't talk about interactivity anymore. You should create problems instead of puzzles, as any modern game designer would say. Problems are interactive and solutions beyond the creator's grasp are expected to exist given the broad number of actions at your disposal. Puzzles, however, are not interactive. There is a solution, find it or you're stuck and punished. But the action you need to do is hidden to you, even if logical. You should figure the exact word or sentence: if it where presented to you, the puzzle whould be so simple there would be no point to its existance. You're fighting the interface.
Interactive fiction is out of touch of modern game designing techniques. There is nothing wrong with text-only interfaces and textual descriptions, but the whole genre needs a deep rethinking if it is going to be something more than fine books so difficult to read that you need to figure puzzles before you can turn the page (and this in the better case).
AS SET FORTH IN SECTION 3 OF YOUR LICENSE AGREEMENT, IF YOU DISTRIBUTE ANY SOFTWARE
CREATED USING THE AMIGA SOFTWARE, YOU MUST PAY AMIGA A QUARTERLY ROYALTY. YOU ARE
ALSO REQUIRED TO PROVIDE AMIGA A REPORT OF YOUR DISTRIBUTION AND THE RIGHT TO AUDIT
YOUR RECORDS. To review details relating to these obligations, including the royalty rate you are
obligated to pay, you may click the "Previous" button below to review the License Agreement again.
I'm sorry, but such an stupid license prevents any useful development on the platform. If you are serious about creating a new platform and gaining some market share, make the development as open as possible, and open-source it if possible in order to gain developer mind share. Are you aware of any succesful development system that is not royalty-free?
Don't get me wrong, some of the ideas are somewhat cool (a portable assembler looks neat for a VM). I would like to see an open source assembler-like VM project and/or a minimalist windowing system with alpha blending and usable font support.
You can read a very cool article on the subject here.
Part of Quake 2 source included?
on
Quake 1 GPL'ed
·
· Score: 1
I just noticed a lot of #ifdef QUAKE2 in the WinQuake source tree, and I was just wondering... Anyone tried to compile it? In the WinQuake/docs directory I found also a scary INSTALL.Quake2 file...
This is most likely remainders of an early experiment by JC. I recall too many differences in the games (16 bits, transparency, model interpolation) just to be the same engine.
Ah, but IF is constrained by design, and willing to do so. As an IF writer, I don't give the player a world filled of interesting things to do and then suggest some goal: I simply plan about an specific puzzle and then populate the world with the minimal actions and objects needed to win. Any side addition such as extra actions available and more objects to define the world and interact with, are considered simple flavor or clues for the player, when this form of interactivity should be the central point of the experience instead of yet another word puzzle or yet another story to be told. It is incredible just how so many games blame the player when s/he attempts to interact with some things not related to the plot ("this is only scenary, you idiot!").
The game industry is in no good shape, but there is hope. Serious research has been going on the field since the 60's at least, and there is the literature to prove it. There is no excuse to ignore all this work, neither for the professional 3D-wizbang developer (who unfortunately usually does) nor for the amateur game writer.
Actually, I see Photopia as a step backwards. I agree it's a fantastic story, but there is no interactivity at all. The command prompt in Photopia could be substituted by a "press any key to continue" message and the overall experience could be about the same. Perhaps better, because the "puzzles" in Photopia serve no purpose at all and can distract you. Photopia triumphs with the fiction part while dismishing the interactive one.
I have to concede at least that the IF designer does not have nonsense marketing constraints such as the need to do big, flashy 3D graphics. Actually, the command prompt would be the best interface there is IF (and it is a big if) it understands everything. Then it is the equivalent of a Star Trek computer hearing your voice and doing just what you said. The problem with current command prompts, and the cause they are substituted by GUIs, is they don't. They only understand a tiny subset of verbs you're supposed to memorize. Interactive fiction "pretends" it understands a lot. You're supposed to try anything you want. The reality is, however, very different. There is a tiny subset of commands accepted, and you know them either because you're familiar with the genre or because guessing them is part of the puzzle. This is horrendous interface design at best. There should be another way, maybe inverse parsers, maybe some new interface abstraction not seen yet.
Finally, I'm not interested in historical retrogaming. There are other good points to bring interactive fiction to the table. Anybody could write it, for example, transforming the genre to a medium and not only a bunch of "games" (it's not true today simply because the current tools are simply not designed this way).
Interactive fiction games are actually not very interactive.
The word interactive suggests some kind of system capable of adjusting and modify itself to your reactions in some manner. Such a system should do its best to watch your movements, whatever they are, trying hard to provide a reasonable response to them. Interactivity is all about giving you as most freedom as possible. Interactive software is expected to allow you to do almost anything you wish and provide reasonable and interesting responses to all your actions. Chris Crawford refers to the process as a listen/think/speak loop between two actors, and the most thinks you can "say" that your listener will understand, the more interesting is the converstaion.
However, "interactive fiction" is filled by constraints. The game limits as much as it can the things you can do: you can't move to any place, you can't take anything, you can't speak to other people, and when you're able you can't say almost anything to them. You're expected to find the "commands" the game understand, and the game world is filled with random constraints called "puzzles". While I expect the presence of conflicts and obstacles in a game, the moment there is a predefined, designed set of closed solutions you almost can't talk about interactivity anymore. You should create problems instead of puzzles, as any modern game designer would say. Problems are interactive and solutions beyond the creator's grasp are expected to exist given the broad number of actions at your disposal. Puzzles, however, are not interactive. There is a solution, find it or you're stuck and punished. But the action you need to do is hidden to you, even if logical. You should figure the exact word or sentence: if it where presented to you, the puzzle whould be so simple there would be no point to its existance. You're fighting the interface.
Interactive fiction is out of touch of modern game designing techniques. There is nothing wrong with text-only interfaces and textual descriptions, but the whole genre needs a deep rethinking if it is going to be something more than fine books so difficult to read that you need to figure puzzles before you can turn the page (and this in the better case).
I'm sorry, but such an stupid license prevents any useful development on the platform. If you are serious about creating a new platform and gaining some market share, make the development as open as possible, and open-source it if possible in order to gain developer mind share. Are you aware of any succesful development system that is not royalty-free?
Don't get me wrong, some of the ideas are somewhat cool (a portable assembler looks neat for a VM). I would like to see an open source assembler-like VM project and/or a minimalist windowing system with alpha blending and usable font support.
You can read a very cool article on the subject here.
I just noticed a lot of #ifdef QUAKE2 in the WinQuake
source tree, and I was just wondering... Anyone
tried to compile it? In the WinQuake/docs directory
I found also a scary INSTALL.Quake2 file...
This is most likely remainders of an early experiment
by JC. I recall too many differences in the games (16 bits,
transparency, model interpolation) just to be the same engine.