SCI 1.1 Template Game

[troflip]

Let's use this thread to discuss things about the SCI 1.1 Template Game. For example, stuff like:
- This variable does this, and so it should have this name
- New Room functionality should include these things...
- This FooBlah class does this
- I'm going to make a replacement view for this particular view, etc...


TODOs:
- rename CueObj.sc to Feature.sc
- put setOnMeCheck values in game.sh: $6789 -> omcDISABLE. 1 -> omcCOLORS, 2 -> omcPOLYGON
- (method (setOnMeCheck checkStyle params))
- deathroom needs reworking (and missing resources)

[troflip]

I'll start: I'm going to make replacement views for the command/verb icons (so as to not use Sierra's content). I have an icon maker program, and this will help me figure out a good workflow for doing stuff like this (e.g. I'll need to be able to export palettes!)

[MusicallyInspired]

I'm going to attempt to make replacement Ego views. Both the walking 8-frame animations and the standing still animations. To that end, I have a question. I notice that you're basing the Ego sprite on SQ5's sprite which has the idle frames on a 9th loop in the same View. Other Sierra games use a completely separate View with the body only in 8 different positions with 1 loop each and then a 9th loop with each position of the head. This allows games to animate the character's head looking in different directions while standing idle. Should we go that route with the template game and redesign the stop/walk code? Or leave it as is?

[troflip]

Awesome, that would be great! Do you have an example of a game that uses the different method you described? I'm trying to understand it.

[MusicallyInspired]

I've just been going over the games to see which ones do. So far I've found:

Games with (8-directional) walking animations and standing idles in the SAME View:

-SQ5
-KQ6
-PQ1VGA
-LB2
-FPFP

Games with (8-directional) walking animations and standing idles in SEPERATE Views:

-PQ4

Games with (8-directional) walking animations and standing idles in SEPARATE Views (with a SEPARATE loop for idle heads):

-SQ1VGA
-SQ4

Games with (4-directional) walking animations and standing idles in the SAME View (with a SEPARATE loop for idle heads):

-PQ3 (has 8-directional walking animations in certain areas, but main-size Ego has only 4)
-KQ5 (has separate loop for ALL heads, not just idle frames)

It seems that most SCI1.1 games just use the SQ5 method that the current template already has. We can just go with that as it seemed to be the most popular choice. People who want the extra head idle animations could just program it themselves if they want it. Probably not a needed feature for a simple game anyway, unless everyone thinks it would be worth it.

[troflip]

Yeah, I think the most efficient path to a polished SCI 1.1 template game is just to keep the method that SQ5 used.

[Cloudee1]

Ok, I seem to be doing something wrong...

I added a new room, room 1. Created the pic by importing an image. Edited the message that displays for the look room and changed room 100 so that it loads into room 1.

When running the game, at the point of going to room 1, I get an error "65535.v56 not found."

EDIT:
When changing it back to open in room 110 following the intro and then setting room 1 as east of room 110. When I attempt to enter the room the error is "1.v56 not found"

[lskovlun]

When changing it back to open in room 110 following the intro and then setting room 1 as east of room 110. When I attempt to enter the room the error is "1.v56 not found"

You are running into the problem I described in the other thread. You need to fix the SetUpEgo proc and use it.
With my fixes, the last part of SetUpEgo looks like this:

Code: [Select]

    (send gEgo:
        setLoop(-1)
        setLoop(stopGroop)
        setPri(-1)
        setMotion(0)
        view(13)
        state(| (send gEgo:state) $0002)
    )
and a typical room init looks like

Code: [Select]

   (method (init)
        (super:init())
        (self:setScript(RoomScript))
        (switch (gPreviousRoomNumber)
            (default
                (send gEgo:
                    posn(150 100)
                    loop(1)
                )
            )
        )
        SetUpEgo()
        (send gEgo:init())
    )


[troflip]

Given the arrow keys no longer move the ego, and it's very hard to click right on the edge of the window to move the ego to the next screen (unless you lock the mouse cursor in DosBOX, but even then), what's a good way to have easy north/south/east/west exits from a screen? I would have thought there might be some "border" property that lets you inset the edges of the screen a bit. I didn't see one though, and the code that detected the ego and moved to the next screen was checking against hard-coded numbers.

It wouldn't be hard to code up (maybe an edgeBorder property on Rm or something), but I would have figured this functionality was already there.

[lskovlun]

It wouldn't be hard to code up (maybe an edgeBorder property on Rm or something), but I would have figured this functionality was already there.

It is. There is a bunch of custom code in SQ5 that I don't quite understand yet, but some of it will definitely have to go.
(there were some leftovers in the old SCI0 template game as well; I don't think anybody ran into it, though)
Look at how room connectivity works in SQ4, for instance. It's quite like SCI0.

EDIT: This turned out to be as easy as removing a single line of code in SetUpEgo:

Code: [Select]

        signal(| (send gEgo:signal) $1000)Modifying the signal selector explicitly in this way should always raise some eyebrows...

[Cloudee1]

Thanks Lars, I made the edits but still ran into the same errors. When I removed the setMotion moveto from the ego prior to initing it, that cleared the errors up.

In other words, this through it off (send gEgo:posn(280 110)loop(1)setMotion(MoveTo 0 110))

In the ego.sc... wouldn't tweaking the doit method give you a bit wider edge to hit

Code: [Select]

    (method (doit)
        (super:doit())
        = edgeHit
            (if (<= x 0)
                4
            )(else
                (if (>= x 319)
                    2
                )(else
                    (if (>= y 189)
                        3
                    )(else
                        (if (<= y (send global2:horizon))
                            1
                        )(else
                            0
                        )
                    )
                )
            )
    )

*Edit
I just added a new global variable to the main.sc,

Code: [Select]

gEdgeDistance = 10
and then went through the doit method that I pointed out above so that it makes use of the new variable.... So now to play around with it, and or change it in game it is just a matter of changing the gEdgeDistance value.

Code: [Select]

    (method (doit)
        (super:doit())
        = edgeHit
            (if (<= x (+ 0 gEdgeDistance))
            4
            )
            (else
                (if (>= x (- 320 gEdgeDistance))
                2
                )
                (else
                    (if (>= y (- 190 gEdgeDistance))
                    3
                    )
                    (else
                        (if (<= y (+ (send global2:horizon) gEdgeDistance))
                        1
                        )
                        (else
                        0
                        )
                    )
                )
            )
    )


[lskovlun]

The ExitFeature concept of some SCI32 games seems useful. Borrowing it for the template game might be worth considering. That way, you could have any number of exits anywhere on the screen.

[Collector]

Given the arrow keys no longer move the ego, and it's very hard to click right on the edge of the window to move the ego to the next screen (unless you lock the mouse cursor in DosBOX, but even then), what's a good way to have easy north/south/east/west exits from a screen? I would have thought there might be some "border" property that lets you inset the edges of the screen a bit. I didn't see one though, and the code that detected the ego and moved to the next screen was checking against hard-coded numbers.

It wouldn't be hard to code up (maybe an edgeBorder property on Rm or something), but I would have figured this functionality was already there.

But the cursor keys will move the cursor to the edge of the screen. Still be best to not have to move back and forth from mouse to keyboard just to walk to the next room.

[troflip]

But the cursor keys will move the cursor to the edge of the screen. Still be best to not have to move back and forth from mouse to keyboard just to walk to the next room.

I'm talking about having a border region that acts as an exit (rather than just the extreme edge), not about making the arrow keys do different things.

[Collector]

Yes, I understood you the first time. I was just noting that the cursor keys are not completely useless. I was also agreeing with you that your suggestion would be better that having to move back and forth between keyboard and mouse.