Community
SCI Programming => SCI Community How To's & Tutorials => Topic started by: gumby on September 03, 2011, 09:24:56 PM
-
I think this idea has been tossed around before, but as far I know it has not been acted upon. I was thinking along the lines of something more than the traditional template, perhaps a full working mini-game. Fully documented - maybe we could take the tutorials & how-to's and implement all the examples. Best practices implemented - if they exist or can be determined via discussion.
For sure, I'd like to cover the parser with adequate examples (I feel like I can probably handle this part). A full working inventory would be a good idea based on the threads lately. A point-and-click version would be nice. Sound & music would be good too. Coverage of views, pics, animation, etc.
I'm looking for help and/or ideas...
-
I think we should keep the Template Game as is for the bare minimum of it. The idea of a new and more feature-loaded "Tutorial Game", however, definitely has merit! The "quests" in the game would be about explaining the different features and functions that haven't been particularly clear. Perhaps this is why SCI never really took off like AGI did. It just wasn't as well documented. Granted AGI is pretty straightforward anyway, seemingly, but even so.
We could implement as many examples of popular and necessary SCI features we can think of. A title screen with buttons a user can either select by keyboard, shortcut, or mouse clicks for example. Basic and advanced inventory checking and handling. Changing Ego's "clothes". Adding the "StopWalk" feature troflip helped me out with ages ago (where when the ego stops moving the view changes to another separate view with stopped frames). And if anyone thinks of more features they can request it and it can be added in in some way. It'd be a neat group project we could all build upon. Basically, it should contain working examples of anything we can think of that can be used in an SCI game.
-
Didn't I stick a copy of the pnc template up somewhere around here...
-
It is with your PnC tutorial.
-
Yeah, a 'Tutorial Quest' game sounds really good. But how best to present it? I for one don't think I'd have the patience to play through a paced tutorial - but I suppose one wouldn't have to...
What about utilizing one room per problem/subject? So the player could skip rooms via teleport or just walking. In each room indicate what the relevant code scripts are - maybe embed it in the background of the room, or display a dialog when a specific command is entered 'show code' or something.
Rooms could build on one another, or could be stand-alone. Perhaps both, stand-alone for isolation and clarity of a problem, and aggregated rooms for 'here's how is all works together'. Or maybe a final room with all features implemented.
-
Yeah, separate rooms is what I was thinking. You could have each room be selected from the title screen so people can just click to which tutorial they want to go.
It'd also be nice if the source could be loaded with comments explaining how everything works, too.
-
Nice, I like the idea of being able to select a room from the title screen.
Another thought that just came to me - perhaps a 'step through the code' option could be selected & the code being executed could be displayed in the background as it's executing, line-by-line. Shouldn't be too difficult, just a matter of adding a Display() & a keypress input. Maybe also display a comment where appropriate as well.
I'll start putting together a list of a few rooms & how the subject of each might be approached.
-
Cool!
-
Not sure when I'm going to get more time to tackle this, but here goes...
Here's the list of 'rooms' I came up with, largely based on the existing tutorials and examples. I grouped them into categories to keep things organized.
Text:
- Said(), Parser
- Text resources (inventory, print statements, etc).
- Displaying text - Print(), Display()
- Multi-language support
UI:
- User Interface (buttons, windows, gauges), Menubar, Save/Restore
- Keyboard functions, Keypad class, Using specific keyboard keys
- Mouse functions, PNC
Graphics:
- Control lines/areas
- Doors
- Props
- Inventory
- Actors, Avoid, Follow
Misc:
- Scoring, Death Handling, Winning the game
- Regions and locales
- Loopers
- Music & Sound
- Timers, Turns
- Selectors
-
Proper demonstration of regions and locales is, pretty much by definition, not suitable for a single room. On the other hand, you manage in your post to mention four excellent candidates for regions/locales. Now if only we could come up with some appropriate actions/events for them.
-
Well, it's been 4 years, but this idea still has merit. All the more now that Companion is getting a much needed facelift. This could be a great community project, actually. And it would be doubly beneficial because things various contributors have trouble with and have questions about while making the game can be explained and implemented when they come up.
-
If Companion ends up being complete enough to create SCI1 and SCI1.1 games we will need new template games for those as well. Brian's VGA template is just SCI1 and is not quite complete. He had most of the scripts done, but none of the other SCI1 resources. It looks like that SCI1.1 may be given preference over SCI1 and it will probably need a different template. I am sure that troflip's work on the decompiler will be of immense help here. The other resources would not be that big of a deal after there are proper editors.
-
Yes right on. Template games as well as Tutorial games.
Part of me desperately wants an SCI01 template game so I can use scrolling screen transitions in EGA...I'm so unreasonably hopeless lol.
-
I've been kicking around this idea too, but from a code-generation standpoint. After Soulshade Asylum, I'm thinking about how to get a better end-result in less time.
One of the low-hanging fruits that I see is a tool that will accept input as the game-player would input (e.g. "pick up the small rock"), generate the necessary vocab words, identifying parts-of-speech and possible synonyms, then generate the said strings themselves in a global or possibly region script.
-
These updates to SCI Companion are a ton of work, so I would greatly appreciate any work by the community to create a template game.
I'm probably going to focus on SCI1.1, and I can come up with the meat of a template game based on the decompiler, but I'll probably need the community's help in polishing it up, and *especially* in documentation. We can probably do this through github.
I'll leave a SCI01 template game up to Brandon :P
-
I agree with your focus on SCI1.1. I think it could attract more new developers than SCI0.1 or SCI1 with bitmapped pic resources and discrete digital sounds.
-
lol Like I said, I'm hopeless.
Seriously, I'll be glad to help wherever I can.
@gumby: Wow that's far more ambitious than what I was picturing. But if you can pull it off!
EDIT: One thing I thought of was tools for creating sound and patch resources for SCI1/SCI1.1. The tools we currently have (Soundbox, Syx2Pat, Bnk2Pat, Pat2Bnk, etc) all only currently work for SCI0. I know most people like to go the modern route and just use sciAudio, but.....yeah. Is this going to be considered equally as pointless as making a SCI01 or SCI1 template game?
-
So which game are we looking at building the template game off of... SQ5 I am assuming since it is one that is already decompiled... But then I suppose there is also going to be some bits and pieces from other games (functionality) that we may also want to snag when it comes to finishing off a template game.
I'll admit, looking at the list of sci1.1 games, I haven't completed nearly as many of them as I should have. So I can't think of any examples right now .
-
Probably SQ5 or LSL6. I've been going with SQ5 since I'm a much bigger fan of the SQ games than LSL. But LSL6 has a slightly more modern interpreter - it handles 16-bit audio, I'm not sure if SQ5's interpreter does (or whether that's more a function of the sound drivers).
-
While I too like SQ5 more, 16-bit audio would be great. Even if the ability is in the driver often you cannot mix and match drivers between games. I'll see if SQ5 will accept the driver from LSL6. I assume you mean LSL6 floppy as the CD version is SCI2.1.
-
I was able to add a 16 bit audio sound to SQ5. Plop this 108.aud in your folder, and it should play when Roger exits the simulator. The quality doesn't seem very good though, maybe it plays 16 bit sounds as 8 bit?
-
For some reason it does not override the embedded aud, even though the RESOURCE.CFG is pointing to the right place. It plays fine in SV, but is ignored in the game. It makes no sense. The only other time that I have encountered an SCI game ignoring patches is with some of the earliest versions of the very first SCI games like KQ4 and LSL2 before they added that feature. Could it be that your version has a slightly later interpreter that can handle it and mine cannot so it ignores the external aud? Mine is 1.001.068. I did try the SB driver from LSL6 and it worked, but still does not play your aud file.
-
haha, why does nothing ever work??
My interpreter is the same version as yours. I redownloaded it from this site, and replaced it and it still worked.
This is my resource.cfg:
videoDrv = VGA320.DRV
soundDrv = ADL.DRV
audioDrv = AUDBLAST.DRV
joyDrv = NO
kbdDrv = IBMKBD.DRV
mouseDrv = STDMOUSE.DRV
memoryDrv = ARM.DRV
language = 1
minHunk = 223k
What Windows OS are you using? (I'm windows 7). Maybe you need to "unblock" the file or something? I know exe's downloaded from the web are marked specially, maybe for some reason this file is too?
-
Win7 Pro here, too. Mine comes from my original floppies. I do have nearly all of collections, not sure what differences there are without checking. The only difference with the RESOURCE.CFG is mine has GENMIDI.DRV for the music and the patchDir is specified and the interpreter does recognize that flag. It makes no difference if I use ADL and remove the patchDir setting. There are no permission issues and it was not downloaded from the internet so nothing from the game was not flagged by Windows. I did remove the flag on the aud file, so that is not the reason. In the end, it probably does not matter as long as a SCI1.1 template game accepts the higher bit rate.
-
It doesn't work for me either. I'm using the version from the Space Quest Collection Series. I hear other sounds but when the bridge simulator opens, there is silence.
-
I hear the default sound.
-
Lol well isn't that nice and confusing. I'm also running 1.001.068. I should note that I don't have a patch director specified in the resource.cfg file.
EDIT: Just tried troflip's resource.cfg settings for fun. Same deal. Silence.
EDIT 2: I just realized I might not be playing with a pure copy. I have a file called UTILITY.EXE in my SQ5 directory. When run in DOSBox it extracts 5 files and overwrites them in the game folder:
INTERP.ERR
SIERRA.EXE
65535.MAP
RESOURCE.MAP
RESOURCE.AUD
Seems to be a patch and comes with the game in my collection version. I also have other extraneous files everywhere that aren't usually in there. I've been using the same folder for years and years so it could be defiled in any number of ways. Anywho, I took a pure copy of the game from my collection CD and extracted it. I didn't run the UTILITY program (I don't know if I had in the past or not) and put troflip's sound file in the game folder and now I can hear it. I don't know if the contents of that patch were the culprit for it not working on my end or not, but a pure copy of the game seems to run it fine.
-
That is just part of the floppy installer. Those files do not exist outside of the self extractor. Completely unnecessary and redundant for the CD. I had never noticed it before, but it s simply an oversight by the Space Quest Collection Series designers. There is also the LANGUAGE self extractor from the floppy installer. I was not hearing it because I was using the floppy release, which requires those files.
Curious as to what is causing it. I tried the LSL6 SB driver (which worked alright with the floppy release) and although it does not crash the game, it trashed the sound.
-
Started going through the scripts of the decompiled SQ5... and getting them, hopefully, template ready.
Obviously there are going to be things that I come across that I can't decipher or simply don't know what to do with. A couple that I have come across have actually been exactly the same as our current template scripts with the only differences being the script number.
I am also assuming that (include "game.sh") will also need to be added to the script files...
-
What about the hep files? Are these automatically generated by the compiler or will the developer need to doing anything with them? Do they even have source files?
-
Keep in mind that the decompiled source that troflip provided does not represent the finished phase of the decompiler. There were a number of things missing, like Print windows with buttons. Good starting point I suppose, though.
-
Oh that is a given, but I was trying to anticipate what else would be needed for a working 1.1 template game.
-
What about the hep files? Are these automatically generated by the compiler or will the developer need to doing anything with them? Do they even have source files?
hep resources are just the part of the script resource that resides in the heap. It will be generated by the compiler along with the script resource.
I currently have a tab for them in SCI Companion, but I'll probably remove it. There should be a matching hep for every script, but it's nothing anyone developing a game should need to know about (and I wouldn't want people messing with things by deleting a hep but not a scr).
-
Understood. I was mostly thinking about if there is a decent decompiler it might make for a means to create patches for the bugs that Sierra never addressed. All of the patches for this era of games always paired the matching hep with the corresponding scr. If the compiler can regenerate a new hep for the scr I guess that is all that is needed for such purposes. Although, that does bring to mind a feature that might be nice to have. The ability to compile a single script and not have it packed into the game archive.
-
Oh that is a given, but I was trying to anticipate what else would be needed for a working 1.1 template game.
Sorry, I was actually referring to gumby's task of organizing the current decompiled SQ5 source.
-
Keep in mind that the decompiled source that troflip provided does not represent the finished phase of the decompiler. There were a number of things missing, like Print windows with buttons. Good starting point I suppose, though.
True, there may be some future iterations of compiles that would clear up some things, but right now there are a number of scripts that will remain unchanged from now and then. Those can be addresses now.
-
Yeah. I was just worried about the current decompiled scripts containing inaccuracies...
-
I'm not sure there's anything useful you can do with the scripts now in terms of a template game. Still too many bugs.
-
Scripts like wander, rev, dcicon, etc.
Comparing them to our original sci0 template game there is not much difference. In the event of those scripts and several like them. I doubt there will be much difference between now and when you call the decompilation complete. Those are the types of scripts I am looking at.
What's even cooler though is extending the functionality of the current template game right now using some of these decompiled scripts. Take for example Osc, or short for oscillate. I added the script to the template game and named it osc just like it is in sq5 and drew a quick view.
(use "osc")
and then for the views init
(testViewOsc:init()setCycle(Osc))
and sure enough the view oscillates... goes from first cel to last cel and then backwards to first cel and on and on.
chase seems to pretty much be the same as follow with the exception that once the chasing actor reaches the distance, it stops... at least from my current experimentation. Not sure what the benefit of chase is to follow....
I can't wait to throw a couple of more into the games to see what they do.
-
Haha, that's pretty cool cloudee :D
But just as a warning you may encounter still some pretty bad bugs in the decompiled source. For instance look at CT::doit in the Cycle script. There's a send call there that doesn't have any selector (I know what's wrong, and I believe I can fix it).