Messages

There's a pretty big Interactive Fiction community on the internet, check them out e.g. at this wiki.

...unless of course somebody solved this problem already   Good catch!

For the player:
HTML5 audio has a playback rate which preserves pitch
http://www.w3schools.com/tags/av_prop_playbackrate.asp

You probably knew this, but some MIDI editing tools will be able to pull this off, if MIDI is an acceptable format for you.

The first question is that it's not a lot of work, but that it requires highly specialized software. Most developers just grab standard MP3/OGG libraries because they work (if in a standard way), and almost nobody has any clue how those internals work. If you know that, then writing this app is a few days' work; if you don't know that then that's going to take a few weeks of research.

The second question, porting this is going to be a nightmare unless you are very familiar with low-level audio coding on both systems.

Here's an interesting writeup of the genesis of King's Quest: http://www.filfre.net/2013/07/the-unmaking-and-remaking-of-sierra-on-line/

Very interesting. I didn't actually know that Sierra was already an accomplished publisher with strong ties to IBM before they started KQ. That goes a long way in explaining their architecturally sound engine-first approach to writing KQ.

Yes, but you're applying principles of abstraction that were very far from universal at the time. In the early 80s, the very notion of structured programming (e.g. Pascal and C), with well-defined, reusable functions, was still pretty cutting-edge. Object-oriented programming was a relatively obscure notion mostly confined to academia.

Well, Infocom did it four years before King's Quest, and with a better parser to boot

The answer is that if you had coded the game in assembly, then it would already be the engine.

For example, KQ1 has about 60 rooms. You could write 60 different pieces of code to draw rooms and have a character move around in them, but that would be horribly inefficient. Instead, you write a generic piece of code that handles a room, and re-use it 60 times with different data. You apply the same for characters, objects, and input: a simple generic class that can be reused as often as you need in the same game.

...but that's precisely what an engine is. As soon as that's functional, you can also replace the rooms by other rooms without affecting anything else, and ta dah! You have King's Quest II. It's nothing but smart programming.

Note that LucasArts did exactly the same: when designing their first adventure game, they first wrote the SCUMM engine. Every well-written game with multiple locations will be written as an engine first.

So long, and thanks for all the fish!

Sounds great!

A while ago I also wanted to try this, by entering each MAGS for a year. Didn't work out for me because of lack of time, but it sounds great and I wish you the best!

Excellent choice.

I don't say that because of AGS, but because of having the courage to change your life into a new direction.

I feel very uneasy to rely on such speculations, as whether it is likely that programmer planned something or not. Inexperienced scripter may forget to put a long loop inside "not IsSkippingCutscene" check in a normal event function too.

Fair point, but if you're going to throw a warning for every Rawdraw operation, then that will just flood the logfile with 40+ messages per second. What would help is e.g. detecting if e.g. a full second goes by without the screen being updated; perhaps similar to the infinite-loop check on while loops.

Yes, but if it occurs in other functions, the programmer has most likely planned for it; whereas if it occurs in r_e_a he may not be aware. R_e_as are hard to trace.

I used to be a bit of a MUD addict, but then I went cold turkey on it. I think that's about ten years ago. This is also why I don't do WOW.

I'm not going to make it. Save yourself!

Maybe it's the AGS engine that's responsible for this, but my guts tell me it's a custom script in your repeatedly_execute_always

It turns out you are correct; the culprit is a bunch of Rawdraw code in the rep_ex_al function. Thanks for the tip!

Well, so it was a scripting error. However, perhaps this should be something that logs warnings? E.g. any rawdraw command in rep_ex_al during a skipping cutscene may be cause for a logfile warn.

But you can't count to ten words?!??!?! 8-08-0:P

I design adventure games. Hah!

Perhaps, but I tried removing the VOX file and get the same result.

I have a rather odd issue. In the following block of code, pressing ESC during the cutscene will cause the game to hang for about twenty seconds (as if there were some really expensive/slow calculations being done), before continuing normally. I see no reason why this particular cutscene would take more than a fraction of a second to "fast forward", other cutscenes (in the same room, even) are skipped lightning-fast as normally. Perhaps somebody else has seen this before?

Code: ags

      
        StartCutscene (eSkipESCOrRightButton);
        Speech.SkipStyle = eSkipKeyMouseTime;
        DisplaySpeech (FROTZ, "&101 Well done!");
        DisplaySpeech (FROTZ, "&105 As you've probably seen, you can interact with things by clicking on them. You can look, take things, talk to people, and so forth.");
        DisplaySpeech (FROTZ, "&106 You can walk around by clicking on the floor. If you want, you can use the right mouse button to quickly walk anywhere.");
        DisplaySpeech (FROTZ, "&107 Finally, you can click on yourself to bring up the menu. This shows your inventory and lets you save or quit the game.");
        DisplaySpeech (FROTZ, "&108 More importantly, now that you have your wand, you can cast spells by clicking on yourself and selecting one.");
        DisplaySpeech (FROTZ, "&109 Exactly.");
        EndCutscene   ();
      Speech.SkipStyle = eSkipKeyMouse;

Sorry, I missed that earlier post.

I think the most straightforward fix is still to add a boolean to the game properties pane in AGS Editor for "Use MIDI", defaulting to true. When set to false, AGS should simply not bother trying to initialize MIDI, and only use the MP3/OGG codes. I'm suggesting this because I estimate that 95% of AGS games use MP3/OGG music these days, so supporting MIDI really doesn't need to be a priority.