intfiction.org

Here's my next review, in unofficial draft form. Four games down, 31 to go.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

This year we gave you The Absolute Worst IF Game in History and The Absolute Shortest IF Game In History.

Thanks for the review.

Emilian

No... "FutureGame" from IFComp 2005 is the shortest I've seen. It's only a couple of minutes long, and it's just one or two keypresses.

Well, the shortest CYOA-game I saw, was back in 1989. It was written in BASIC by a german programmer for the Commodore 64. The game was about a teddybear (like this one). The player was given 3 or 4 choices. Whatever choice you made, you died afterwards.

Hello Merk,

now that the comp is over and we authors can speak openly about our entries I like to comment on some points you made in this review. I also want to mention that I really liked reading your reviews for all the other entries too. Really, they were constructive, informative and not insulting. That's how it should be imho.

Ok, let's start...



It's correct that most of my effort went into the development of Node-X and that I hadn't finished the game in time, because the deadline was approaching and I had to hurry. But Project Delta was NEVER intended to showcase my system! That's what many reviewers misunderstood.

Perhaps I should have written in my game blurb that "Project Delta: The Course" was a short test game for Node-X, a homebrew system which was in its early development stage, but no beta anymore.



The console-mode representation is for the old retro-feel only. It is being used until I decide that Node-X is polished enough to be ported into a true Windows-interface. Since everthing is coded in Freepascal it is easy to turn a console-mode program into a Windows-interface program, although Windows Programming in Freepascal is not always an easy task and even I have to dig some Freepascal tutorials first to learn it a lot better.



I agree with that. Just read the introduction at the official Freepascal site, so you can get an idea of all the possible platforms and representations I can compile my sourcecode for.

However, I'm focusing on DOS and Windows first.

Concerning web-based interface, I always wanted to write a text-adventure in HTML and with some javascript. Since I had designed some websites back in 1998 this should be no problem for me these days. I'm not that skilled in Javascript though, but pure HTML is fine for me. And the best thing about text-adventures in HTML is that you can add images, sound and even flash-sequences, so it doesn't have to be text-only! Who knows, maybe I will submit a HTML-based IF in one of the next competitions.



Sounds cool. You should release it! I'd be the first to try your system.....



Ofcourse a CYOA-game has to be menu-based. There's no other way.

I mean the original CYOA gamebooks by publisher Bantam Books (see CYOA on Wikipedia) were written and printed in following format, for example:

You stand in front of the cave entrance.

If you decide to start back home, turn to page 4.
If you decide to wait, turn to page 5.

Now how to translate this into a computer program? Right, you have to use a menu-based interface. So it will look like this on the screen, for example:

You stand in front of the cave entrance.

(1) start back home
(2) wait

Sure, you could make it look more like traditional CYOA:

You stand in front of the cave entrance.

If you decide to start back home, press 1.
If you decide to wait, press 2.

But in a videogame it would look confusing and boring, wouldn't it? Because each time the same line "If you decide to ..., press ..." has to be repeated. Authors could not even compensate it by using alternate lines such as:

If you want to start back home, press 1.
But if you think you should wait, hit 2.

That's even more confusing. So I think there is nothing better than a menu-based interface in this case.

And that's how it works in Node-X. You get no corny sentences, but some choices listed, make a decision by pressing the according key (1 or 2 in this case) and then the program "turns" (jumps) to the chosen "page" (node).



I don't understand your point. What do you mean the more IF-like your CYOA becomes? Is there really such a great difference between IF and CYOA?

Isn't IF (Interactive Fiction) just another name for textadventure, be it parser-based or multiple-choice-based?
And isn't CYOA just another name for multiple-choice textadventure?



Ditto. A lot of reviewers wanted the same thing, so I'm adding this feature to my latest Node-X version right now...



Another point of yours which I really can't follow. What the heck do you need an UNDO feature in a videogame?

If the player makes a bad choice during game, he/she just loads his/her last savegame.

And by the way, in Project Delta the current progress is even quicksaved automatically at a certain node, just in case you haven't noticed it when playing my game and checking the Load/Save menus afterwards. That's because I added an autosave-feature to certain nodes. Scripters/Authors - who write custom adventures for Node-X - can determine at which point they want the player's current progress being autosaved, regardless of the player saving his/her progress or not.



Node-X binary file format (*.nx1, *.nx2, etc.) is compiled script. The script itself is simple text which can be written in Notepad or any other text editor, just as HTML. So if you want to port it to other interpreters or other platforms you don't really need to focus on the binary format. You could interprete the script instead. Just a hint.



It was a bug and has been fixed.



I worked so hard on Node-X itself that I had less than 24 hours left to write an adventure for it. This is no joke!

At least I delivered something. Good for me, because I was able to take part in this year's competition! Bad for Node-X, because it didn't show the capabilities of my system.

But don't worry. My next Node-X adventure will be a lot better and longer. And it will be a real adventure and not just a demo/tutorial.

Greets

Certainly... but that's not exactly what I meant. I meant that instead of having a "Choose Your Own Adventure" where each choice branches the plot (often wildly, as in CYOA books), The Course pretty much replaces likely interactive fiction commands with choice numbers. In other words, you don't click (1) to ride a rocket to Mars or (2) to shuttle to the center of the Earth... rather, you click (1) as a substitute for "go east" and (2) as a substitute for "talk to man" (generic examples). In other words, CYOA isn't constructed the same way that interactive fiction is. What you ended up with (and, like I said, what I did as well) is a more traditional text adventure where the most likely "commands" are given to you in a menu. I hope that makes sense.

I have a couple dozen books in the CYOA series, as well as a few CYOA-like books from other sources. The choices usually lead to whole new plot segments, not just a small piece of the game. That's what I meant.


Yeah, the one described above. But it's more than that. Interactive Fiction lets you work in a more free-thinking way. CYOA just has you progress through the plot by flipping page. But the introduction of inventory, dialogue, etc, starts bending this more towards the realm of interactive fiction. So you're not using CYOA as CYOA was envisioned, you're using it more like interactive fiction. And the more like interactive fiction (of the parser-based variety) it becomes, the more that interactive fiction should probably be what it is...


I may be stealing this from something Andrew Plotkin observed several years ago, but it's more interesting to replay a section of a video game than it is to re-read text over and over trying to find the right solution. Also, text games really aren't "video" games (although it worked well enough in the new Prince of Persia series).

I use UNDO just to peek a couple turns ahead. It lets me see what clever or witty thing the author might have anticipated to an undesirable action, without forcing me along that path permanently. It's not such much a matter of necessity in that regard, but it is a much-missed convenience. And without "UNDO" the game just feels incomplete.

Taking it back to CYOA books, UNDO was inherent. It was called "going back to the prior page if this choice looked like a mistake." So its absence is probably even more glaring in CYOA than in IF.


I don't think anybody will dispute it. But the reasons you see comments like this -- and about it being a poor choice as a game to showcase Node-X even if that wasn't the point -- was because the competition was for games, not game systems. I'm not saying you shouldn't have entered -- only that you didn't give judges the thing they were expecting to judge...

Exactly, the most obvious choices in a particular situation are given to the player in a menu. That's how I write text adventures with Node-X. So yes, I see your point now. It's true that The Course is more like traditional IF where the player is progressing through small pieces of the game and not jumping to whole new plot segments.

But that's just my style, however. Other authors - who are interested to use Node-X for creating their own adventures - don't need to do it that way. They could write it more CYOA-like if they want to. So a choice like "ride a rocket to Mars" would teleport players directly to "Mars". In my adventures players would be required to "enter the rocket", "start its engines" and "fly it to Mars" before they can reach the destination "Mars", maybe even find a key or operate the controls first to start the "engines". That's the difference, yes.

Also I want to make one thing clear, so that everyone can understand: Node-X is a system made for its own subgenre which is a mix of multiple-choice adventure, CYOA, Text-RPG and traditional IF. It doesn't even try to compete with Inform, TADS or other parser-based systems. The "parser" in Node-X is only used for special functions such as load/save game, change palette, show inventory, transcripts, etc.



Well, the way you describe it I do see the necessity of an UNDO function now. Okay, I will add this feature too.

But I have one question: Is it enough when the UNDO function jumps back to the player's previous page (node) or do you want me to code the UNDO function in a way that you could even jump back multiple pages?

I imagine this could be pretty funny actually. A player finishes the adventure and on the last node he starts to undo everything node by node until he reaches the start again, hehe. Like pressing rewind on a tape recorder or something. Wierd, but why not.



Next time I will give judges what they expect. At least I hope so. I mean the IF competition is intended for "short works of interactive fiction" anyway, isn't it?

I wonder how short a text adventure can be to make judges still happy. The IF Comp Rules only state the maximum length ("game must be playable within 2 hours"), but not the minimum length...

So what is the minimum length of a game entered in the competition? 5, 10 or 15 minutes?

As you said, there is no minimum length. I would say most games with a playing time under 15 minutes will have disadvantages. Although, I think games like 9:05 would always have a rather high rating, in spite of its shortness.

Bob

In IF, you can UNDO several turns. This often doesn't amount to the entire game (I've seen it vary, but it never appears to be infinite). Maybe a dozen turns, but definitely more than one is typical.

I don't know anything about your Node-X, so I don't know how you would implement this. It might be possible to have an UNDO that goes back indefinitely. That would certainly be the case if you had no inventory or state management other than the concept of a "page number" because your UNDO facility would be an internal list of page numbers you just flip back to.

This is more complicated if there is inventory and other state considerations. The two likely ways to do this would be to put the game state in a virtual envelope (i.e., everything that would go into a SAVE goes into the next available UNDO slot instead), or track just the state changes for purposes of reversal (i.e., every time you do anything to change the state of the game, write a reversal to the UNDO list, whether it's to flip back a page, put an inventory item back where it originally was, or whatever).


Well, take the example of a movie. You can do a lot in 2 hours, and people will probably feel their $10 ticket price was justified. If the movie lasts just five minutes and really doesn't tell much of a story, they're gonna be royally ticked off. Not that judges pay to participate in the IFComp -- just an analogy.


There isn't a minimum set by the rules. But judges expect something that's at least substantial. This is more wisdom by observation rather than any hard and fast rule. Longer games tend to do better. Longer games tend to be viewed as having more effort put forth. Longer games tend to be able to tell better, more complete stories. Longer games tend to look like more serious, honest entries. Granted, when I'm down to the end of the competition and I'm starting to get cranky, I'm happy to come across a shorter one.

Approaching or exceeding two hours doesn't automatically make a game good. Just look at the competition results. But anything less than half an hour seems far too short to me, given that this is just 25% of what the author could have given me. Fifteen minutes is a snack. Five minutes just feels like a non-effort.

There's no minimum game length for the competition, but I think people are looking for something that is substantial enough to have (in itself) some kind of point: to tell a story, to provide a fun gaming challenge, something along those lines. If you can do something really interesting in five minutes, so be it. (Though I think a lot of judges also factor the ambition of the project a bit into their scoring, so something that is very small may not place as high -- see the reactions to "Snack Time", which most people thought was fun and cute and well-implemented, but just not trying anything quite as challenging as the games that ranked above it. On the other hand, Sam Barlow's "Aisle" has gotten a lot of respect over the years even though it is a one-turn-only work.)