Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - troflip

Pages: [1] 2 3 4
Question is pretty much in the title. I'm trying to formalize how NPC conversations take place in Cascadia Quest. You'll be able to 'talk' to someone, and also 'ask about <topic>'. But sometimes the NPCs ask you a question (typically yes/no, but could be other things).

Were there any Sierra games (text parser) where NPCs ask questions, and how was it handled? Of course there was the odd thing like saying "the word" in SQ2, but I'm talking a more general mechanism.

SCI Syntax Help / color names
« on: October 20, 2017, 12:42:43 AM »
Any idea why Brian used the odd color names he did in the code (For SCI0)? e.g. fuchsia, purple, maroon... when the actual color names are well known?  ( - and presumably the names used in AGI too )

The Games and other Sierra Adventure stuff / Void Quest
« on: May 20, 2017, 07:48:54 PM »
Over the past two weeks I participated in Adventure Jam 2017 and made a game that explores the backstory of one of the minor Cascade Quest characters. It was my hope to flesh out some of the interactions and controls I'm using for Cascade Quest, and to avoid "wasting" 2 weeks (because I may include this inside CQ).

Anyway, here it is (submission to the jam required uploading it to gamejolt):

If you try it out, let me know what you think! I probably went a little too heavy on content and a little too weak on polish, as there are still a lot reasonable input that doesn't generate good responses.

Finally got around to starting my Cascade Quest-specific dev blog!

Space Quest 3 with speech recognition :P. Have a look:

Weird question:
Can anyone think of a time in any of the Space Quest series where you get an inventory object from an alien?
(bonus points if the alien has the ability to teleport)

(SCI 1.1 doesn't really need this since it has true pathfinding).

This "SliderMoveTo" can be used in place of the "MoveTo" class. If the client hits a boundary, it'll try to adjust its direction a bit to move past it. It's kind of like an Avoider, except it's more predictable and not nearly as drastic (no back-tracking, or anything like that). It's basically just useful for the ego not getting "stuck" when moving along a wall that isn't perfectly aligned to their direction.

edit: Original version has some bugs, should be fixed now.

Code: [Select]

; How much we turn left or right trying to get around an obstacle.
; How many times we can turn the above amount when trying to get around an obstacle.
(define NUM_SIDE_STEPS 2)

(procedure (ReinitSliderMove angleOffset &tmp theDX theDY newX newY theClient theLooper theHeading)

(= theClient (self client?))
(= theDX (- (self xOrig?) (theClient x?)))
(= theDY (- (self yOrig?) (theClient y?)))

; x = x * costheta - y sintheta
; y = x * sintheta + y costheta
(= newX (+ (- (CosMult angleOffset theDX) (SinMult angleOffset theDY)) (theClient x?)))
(= newY (+ (+ (SinMult angleOffset theDX) (CosMult angleOffset theDY)) (theClient y?)))

(self x: newX y: newY)
(= theHeading (GetAngle (theClient x?) (theClient y?) newX newY))
heading: theHeading
(if (theClient looper?)
(= theLooper (theClient looper?))
(theLooper doit: theClient theHeading)
(DirLoop theClient theHeading)
(InitBresen self)

(class SliderMoveTo of Obj
client 0
caller 0
x 0
y 0
dx 0
dy 0
b-moveCnt 0
b-i1 0
b-i2 0
b-di 0
b-xAxis 0
b-incr 0
completed 0
xLast 0
yLast 0
; The original direction we were trying to go:
xOrig 0
yOrig 0
; The last direction we had to turn (1 or -1)
lastDirection -1

(method (init theClient theX theY theCaller &tmp theCycler)
(if (>= argc 1)
(= client theClient)
(if (>= argc 2)
(= xOrig theX)
(if (>= argc 3)
(= yOrig theY)
(if (>= argc 4) (= caller theCaller))
(= completed FALSE)
(= b-moveCnt 0)
(= xLast 0)
(= yLast 0)
(= theCycler (client cycler?))
(if theCycler (theCycler cycleCnt: 0))
(ReinitSliderMove 0)

(method (doit &tmp reinitAfter numSideSteps angleOffset multiplier)
(if (== b-moveCnt (client moveSpeed?))
(= xLast (client x?))
(= yLast (client y?))
(= reinitAfter FALSE)

(DoBresen self)
(= numSideSteps 1)
(= multiplier lastDirection)
(while (and (<= numSideSteps NUM_SIDE_STEPS) (client isStopped:))
(= reinitAfter TRUE)
; Couldn't move - try to the left and right a little
(ReinitSliderMove (* multiplier SLIDE_ANGLE_OFFSET numSideSteps))
(DoBresen self)
(*= multiplier -1)
(if (== multiplier lastDirection)
(++ numSideSteps)

(if (and (== x (client x?)) (== y (client y?)))
; Ok, we *really* couldn't go anywhere.
(self moveDone:)
(= reinitAfter FALSE)

(if reinitAfter
; reset to going straight for next time, so we actually make progress.
(ReinitSliderMove 0)
(= lastDirection (- multiplier)) ; since we toggle it before heading out of the loop
;(= lastDirection -1) ; reset, I guess
; Actually no, because this object may have been destroyed in moveDone:

(method (moveDone)
(= completed TRUE)
(if caller
(= gCastMotionCue TRUE)
(self motionCue:)

(method (setTarget newX newY)
(if argc (= x newX) (= y newY))

(method (onTarget)
(<= (Abs (- (client x?) x)) (client xStep?))
(<= (Abs (- (client y?) y)) (client yStep?))
(return TRUE)

(method (motionCue)
(client mover: NULL)
(if (and completed (IsObject caller)) (caller cue:))
(self dispose:)

I'm trying to figure out how to draw glaciers and ice caves. I find that pixel art ends up being best if sourced from paintings, so I "import bitmap to pic"'d several paintings I found on the internet. Which of the following looks best/most convincing as pixel art, and a good direction to use for drawing?

Can anyone think of any examples of this in Sierra's catalog? (in any version of SCI). It's fairly straightforward to do if the objects are part of the room (just make them part of the cast), but not so obvious if you want this in a popup dialog...

Everything-Else / What's the name of this?
« on: September 14, 2016, 04:51:00 PM »
Since it's quiet around here, what would you call these things on the tree?

(I know what I call them, but I'm trying to figure out what the common name would be...)

SCI Development Tools / How did SCI render in CGA?
« on: September 07, 2016, 12:36:55 PM »
I know it was automatically done by the interpreter/engine, but does anyone know the particular algorithm?

(ScummVM has a "render mode" for this, but it doesn't work)

[edit: ok, easy enough to get working in DOSBox]

They start and stop movement instead of the "if key is down, then move" behavior common today.

Was this some technical limitation back in the day, where the keyboard drivers only produced keydown events?

Or is there some gameplay reason why this is preferable?

Nearly everyone who's tried my game (that didn't play the quest games back in the day) is confused by the behavior.

Hi All! I've finally made an official landing page for my Cascade Quest project:

Code: [Select]
Game KQ4 KQ1 SQ3 LB1 CQ-7/16 CQ-old
Pics (KB): 866 570 460 522 280 222
Pic count: 150 86 115 88 81 70
Views (KB): 1340 784 709 1370 586 506
Text (KB): 135 109 103 327 89 67
Scripts (KB): 369 389 345 577 196 176*

I just thought it would be cool for me to look at.
- Interesting the huge amount of text for Laura Bow compared to the others
- Still have only about half the "pic content" of a typical Sierra game (KQ4 is inflated because day/night scenes).
- Fairly close in text content (which surprises me), but only about 50% of the script content. I'm guessing that's because I haven't coded a lot of interaction details (like coding up an animation sequence for giving an item to someone, or something like that).

Ok, well the distribution must have been through a BBS or something - but that's not really my question.

The save game system of SCI (and I presume AGI) involves saving the entire 64K heap to disk. That means if you modify scripts and such, any saved games will still load old versions of the script into memory when restoring the game. Any generally, chaos ensues. Some scripts never get unloaded during room changes, so you'll always be left with an old script for the remainder of the game. Fixes to logic in individual rooms wouldn't be a problem, unless you were in that room during a save (so maybe this isn't as big a problem as I think?)

I think this probably got a bit better when Sierra split script and heap resources... so code was no longer in the heap. But that could mean code pointers (which the heap part of the script would contain) move around, so maybe it actually got worse?

Given today's frequent-patch mentality (and plus to help with beta testing, etc..) I'm planning to work around this by also saving just the relevant global state to a file, and only supporting saving/reloading on room changes. But I'm wondering how Sierra managed not voiding people's save games with patches? Or did they just say "screw you"?

Pages: [1] 2 3 4

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.19 seconds with 19 queries.