Community
SCI Programming => SCI Development Tools => Topic started by: troflip on June 02, 2015, 10:56:08 AM
-
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)
-
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!)
-
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?
-
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.
-
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.
-
Yeah, I think the most efficient path to a polished SCI 1.1 template game is just to keep the method that SQ5 used.
-
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"
-
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:
(send gEgo:
setLoop(-1)
setLoop(stopGroop)
setPri(-1)
setMotion(0)
view(13)
state(| (send gEgo:state) $0002)
)
and a typical room init looks like
(method (init)
(super:init())
(self:setScript(RoomScript))
(switch (gPreviousRoomNumber)
(default
(send gEgo:
posn(150 100)
loop(1)
)
)
)
SetUpEgo()
(send gEgo:init())
)
-
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.
-
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:
signal(| (send gEgo:signal) $1000)Modifying the signal selector explicitly in this way should always raise some eyebrows...
-
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
(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,
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.
(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
)
)
)
)
)
-
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.
-
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.
-
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.
-
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.
-
I haven't been able to get sound looping to work. Anyone else? You can plop sound resource 31 from SQ5 into the template game, it has a loop point. But no matter what, either setting the loop property to some number, or calling setLoop on the sound, the sound will never loop.
-
I haven't got anywhere near sound yet. Maybe I'll take a look at it here after bit.
By the way, changed global2 to gRoom... That's what it was in the original template and I don't see it used here anywhere.
ex.
(send gRoom:newRoom(253))
-
Actually, I just realized it's pretty pointless to work on sound with SCI Companion alpha build I released... sound support isn't there for SCI1+ yet! lol...
-
Script 20, the deathRoom, is going to need a bit of overhauling for the final template release.
Messages for room 20 currently don't exist, as well the script calls for view 2099 (restore, restart, quit images) which is not included and really should be. The call to sound 45 can be removed or a default death sound included, as well the script calls for a view to be overlayed to the left edge of the death message box (currently Roger) but a death icon would be just as acceptable. Also, as a side note, if you restart to pic 000 then be prepared for some weird palette issues... It is looking like pic.000 really shouldn't be an acceptable resource.
global39 and global40... so weird that they seem to be unused by the game's scripts, but when they are commented out then my intro's npc actor does not get inited or moved across the screen.
-
What do you mean restart with pic 000? Do you mean that you made pic 000 something other than a black screen, and it caused issues? (e.g. implying pic 000 should be left as is).
I'm surprised anything works when you comment out global39 and global40 (or are you running this under Scumm?) gDongle must be set to 1234 or else Sierra's interpreter won't run the game, and if you comment out global variables before that, you'll change the position of gDongle.
-
No I left pic 000 as is. I have been using it as my title screen for now instead of the one (300) that was included. Everything works fine at start up and running. But tonight when I got the death room working I actually clicked on restart. It was quite the rainbow effect. If you still have a copy I passed along, you should be able to see what I mean. Just start the game and the first chance you get select restart from the menu, I was using 000 then too. Its the same call to restart, so it produces the same effect. Again, this is only an issue when the title screen is 000. I copied the pic and saved it as a different number and there was no issue whatsoever. So it's nothing wrong with the actual picture resource itself per se, just the resource number. So just something to take a mental note of... steer clear of using pic 000, it may have some adverse effects.
And no, I have only been using dosbox to develop with, not scumm. The gDongle must be why there were some issues, we'll probably want to throw in a couple of comment lines not to add any variables etc above here or something to that effect. Really I was just going through some of the globalxx variables and seeing if I could come up with a more relevant or throwback name... like global2 => gRoom, etc.
-
I haven't been able to get sound looping to work. Anyone else? You can plop sound resource 31 from SQ5 into the template game, it has a loop point. But no matter what, either setting the loop property to some number, or calling setLoop on the sound, the sound will never loop.
I finally managed to get it to work (I think?). Apparently channel 15 (where cues and loop points are set) needs to start with a cue point with value zero, followed by a reverb command and a pan position command. After that, the rest of the cue points and can appear. Without those first three things, the interpreter will freeze. Very strange.
-
I'm surprised anything works when you comment out global39 and global40 (or are you running this under Scumm?) gDongle must be set to 1234 or else Sierra's interpreter won't run the game, and if you comment out global variables before that, you'll change the position of gDongle.
This code was removed in LSL6. On the other hand, there is still global 84 (gNewEventHandler).
-
Oh right, the dongle thing was when I was using the SQ5 interpreter. What's the deal with gNewEventHandler? I don't recall that discussion...
-
Oh right, the dongle thing was when I was using the SQ5 interpreter. What's the deal with gNewEventHandler? I don't recall that discussion...
The Animate kernel function (or most of it) is disabled when global_84 is not NULL.
-
The template game has been updated in the latest version of SCICompanion (http://sciprogramming.com/community/index.php?topic=1420.msg6314#msg6314).
I haven't replaced the Sierra views yet (anyone want to take a stab at the icons?), but I added some resources for the death room (the SCI0 template game sound and view, and the missing buttons), and cleaned up the death script. Interacting with the object on the first screen will kill you.
-
script 12 - global room pallettes... it just holds a single procedure that is used by main. I don't know if it is a consensus or not, but I went ahead and just moved the procedure into main, added it to the export list at the top and freed up the use of script 12 all together.
script 14 - Log Events... This one holds two small procedures. Again, I moved those to main and freed up script 14 for use. Thinking about making a new global variable to turn logging on or off and then seeing what I can do about sprinkling some calls to the procedures around in order to make use of them
script 21 - FlickerCycle... Moved this class to the osc script, freeing up script 21 for use.
script 976 - Cat of Actor Class... appears to be unused (even in SQ5). Removed from game
script 13 - AboutCode of code... moved to script 976
script 938 - ROsc cycle class ... moved the class to the osc script 939
script 15 - sq5invitem ... moved to script 938
script 941 - randcycle ... moved to osc script 939
script 16 - dinvd ... moved to script 941
script 942 - MCyc ... move to osc script 939
script 24 - sq5contolItem... moved to 942
-
Why? With SCI1.1 there are more script numbers available than ever. All this will do is exhaust your heap faster because of the rarely used code always being present.
-
I really don't like having the script numbers spread all over the place, I want them grouped together. I may end up breaking some of them back up later, but even then, they will be consecutively numbered not totally random.
-
I really don't like having the script numbers spread all over the place, I want them grouped together. I may end up breaking some of them back up later, but even then, they will be consecutively numbered not totally random.
But they are not totally random: The high numbers are system classes, the low numbers are game-specific general classes - and those in between are rooms and room-specific classes. Regions sometimes get a range of their own. The even higher ones (> 1000) are talkers. Starting a game off with the SQ5 look and feel changes this somewhat, but it's still not random.
-
Some of them are kind of random though. Like SpeakWindow (877) (I guess that's game-specific class). And the "controls" class always seems to be 255. I wonder why that is. Is there something special about that number?
Maybe some of the feeling of "clutter" comes from the fact that there are all these game-specific classes with low numbers, and when you look at the script list, the rooms (which is what you generally care about), tend to be scrolled off the list?
I don't necessarily mind moving some of the scripts around in the template game, but maybe we can come to some kind of consensus? There's enough space between 900 and 920 to stuff all those low-numbered scripts, for instance. Or maybe we can "reserve" the 800-900 to these types of game-specific classes (instead of 10-9, like seems to be done now)? I dunno...
Also these seem like they should be deleted:
GravMover.sc
Cat (as you mentioned)
VelocityMover.sc
commandWindow.sc (is this related to the command verb in SQ5?)
-
That's fine... I am going to keep moving forward with my rearranging. I am trying to get the game.sh file definitions in as well so that will make moving them again later much easier. As well as tracking down the scriptid(xxx stuff and getting the definitions in there instead of the hard coded number.
I didn't expect this to be the final iteration, but it is a big step towards making it easier to achieve.
Some of the cycle classes, I definitely think should be combined though. They aren't ever going to get used much and they aren't that big to begin with... ie Osc and ROsc. But like I said, we can get all that sorted out later on.
I figured once I got them all somewhat together, I would go ahead and attach a copy to a post so that it was available to grab for whoever wants to add their two cents in the final arrangement
-
If a standard is to be set it might as well be the way Sierra did it.
-
So the changeScore method of game and the addtoscore procedure should both work about the same.
addtoscore checks and sets a btest value whereas the changescore just simply adds to the score.
Both work, however changescore has an issue... it updates the score, but not the status line that displays the score.
Just so there was a way to change the score without needing the btest flag, my fix was to add a new public procedure by the same name to the main script which I just stuck all the way at the bottom. Then I added the procedure name to the export list. commented out the method in the game script and finally went into the couple of files that did call out the send gGame changescore and changed those to call the procedure instead.... but if anyone knows a better way to fix the SL:doit... that would be much better.
-
Just a quick thing that seemed to work is to add this line to the end of main's init:
(SL:code(statusLineCode))
SL:doit calls its code's doit method. So assigning it statusLineCode makes it run that.
Looks like it was just a "bug" in SQ5, which didn't matter since no code used it.
(As an aside, when would you want to change score without a flag?)
-
For instance if you get a point when you click with and item, and in the end of it, the item is taken away then there seems little point to check a flag. Likewise if you interact with a view which results in the view disappearing, again no reason to check a flag.
I have already had to bump up the number of flags that the game makes use of, in some cases like those mentioned I don't need a flag, just to up the score.
As far as it being a bug in SQ5, I checked kq5,kq6, sq5, and some other game, can't think of it now but the changeScore wasn't used in any room and the SL doit method of game was identical in all. I wrote up a quick tutorial adding a ChangeScore procedure... Is this lil bug something that you are going to squish for the final release? If so, I'll rewrite the first add to player score tutorial to show both methods and ditch the modification tutorial. If not, I'll probably just leave them as is.
-
No, I don't think I'll change the template game code - for this release of SCI Companion, I'd rather keep it as close as possible to the original code, and I want to avoid any unforeseen side effects in case we're not understanding something properly.
For those usage cases you mentioned, I would still recommend using a flag (for instance, "if you interact with a view which results in the view disappearing", you'll need to know not to init the view next time the room is entered, so you'd want a flag). A flag takes up a minuscule amount of memory and prevents any bugs involving the score being add to more than once (from what I recall, a common occurrence in fan-made SCI0 games).
For games where you have an unbounded score - maybe like a fighting game, or something like that - then your tutorial to fix it makes sense.