Hi, I could use some help

[Justin]

Hello, I apologize if I am not posting this in the right place or if there is some other channel I should use to ask this question:

I have recently downloaded SCI Companion and got it running without any trouble on a DOSBox.  When I compile the template game, it seems to compile with no errors.  However, I do not find any output.  How can I generate the SCIV.EXE , if that is what I should be doing?

When I tried to Run the game from inside the IDE, it started the DOSBox and the DOSBox closed almost immediately.  However, when I drag the SCIV.EXE for the template game that came with the download onto my DOSBox icon, it loads perfectly and I see the ego in the empty room and can walk it around.

So, how am I supposed to genereate a new SCIV.EXE , or what am I doing wrong?  I appreciate your help.  Thanks,

Justin

[Collector]

It does not compile SCIV.EXE. SCIV.EXE is the interpreter that uses the scripts and resources that you build upon that come with the template game. it compiles the script resources and adds the new resources to the main resource file.

The new alpha build of Companion has the run via DOSBox built in. If you have DOSBox in "%ProgramFiles%\DOSBox 0.74" it should work as is. If you are only seeing a Window flash, perhaps it is only the CMD prompt for a moment and closes when it does not find DOSBox in "%ProgramFiles%\DOSBox 0.74".

[troflip]

Well it just so happens I'm writing SCI Companion documentation now, and I want to make sure people understand how a game is constructed and that it's easy to set up.


Collector, can you suggest some ways to facilitate this? It looks like I can copy DOSBox.exe and its necessary dlls straight into the game folder, and then use only relative paths in the run.cmd, running DOSBox from there. Then someone can download SCI Companion, create a new game, and run the game without any hassle.

I could have a checkbox in the "create game" dialog that says "Copy DOSBox to game folder" or something, and it would be checked by default. And more advanced users could uncheck it and provide a path to their installed location or something.

[Collector]

Yeah, setting it up to use DOSBox probably needs to be made to work more automatically. It can be done to take the guess work out it for the user. What I was doing with my Developer IDE was I had DOSBox in a sub directory under the program. This allowed it to always be able to find DOSBox, regardless whether the user had DOSBox or did not have it in the default location. It did not need to have to copy it to each games' folders during development. I did also provide a place in the options form to allow the user to browse to a different build if they wanted.

Another feature that I had in my SCI IDE was a publish function. It generates an NSIS script for the game. The developer could add any extras he wanted to include by dropping them in an "Include" subdirectory of the game's folder. It has a checkbox to add the game's source. You can compile the installer directly or just open the generated script in the script editor if you want to inspect the script or manually tweak it before compiling. This feature requires NSIS to be installed.

Alas, Developer may never be completed since Gumby has vanished and much of the backend stuff is beyond my abilities. Too bad since the logic backend for the AGI side is about the only big thing left before the AGI part is usable enough to actually be able to develop AGI games.

[Kawa]

And then there's me hacking up ScummVM to automatically load any SCI game in its starting directory.

Would ya look at all these options...

[troflip]

Yeah, setting it up to use DOSBox probably needs to be made to work more automatically. It can be done to take the guess work out it for the user. What I was doing with my Developer IDE was I had DOSBox in a sub directory under the program. This allowed it to always be able to find DOSBox, regardless whether the user had DOSBox or did not have it in the default location. It did not need to have to copy it to each games' folders during development. I did also provide a place in the options form to allow the user to browse to a different build if they wanted.

Ok, I've made some changes for the next release of SCICompanion. DOSBox has been included with the install for a while, but I wasn't actually using it anywhere.

Anyway, I've set up a list of "profiles" you can choose from in the Game Properties dialog. Currently they're hard-coded to DOSBox, ScummVM and "Other". So you can easily switch profiles to run the game with a different interpreter.

By default, the DOSBox path is set to that under the SCICompanion folder, and the ScummVM path is set to %program files(x86)%\ScummVM\ScummVM.exe. So for most people, when they create a new game, they should just be able to run it immediately with DOSBox (which will be the default profile). And if they have ScummVM installed, then they can switch to the ScummVM profile and that should "just work" too.

Then, for custom options, they can use the "Other" profile. If you've already got a game where you've set the executable (run.cmd, or whatever you're using), then that should be picked up automatically and listed in the "Other" profile, and the Other profile should be the default.

For Sierra games (which won't have a game.ini or anything like that), the profile will be set to DOSBox automatically, and we'll scan for known executable names (sierra.exe, sciv.exe, etc....) and construct the DOSBox command line to make running the game also "just work".

Still doesn't solve the issue of packaging the game to make it easier for others to run, but it should ensure that people can get up and running right away with SCI Companion.

[MusicallyInspired]

Cool! *thumbsup*

[Collector]

It probably makes more sense to refer to %ProgramFile%\ScummVM since that is the default, regardless of version. DOSBox's default path changes according to version.

As to packaging a fan game what I did for Developer was written in C#. Don't know how much help that might be. I could do a package that the user could just drop into their game for distribution if anyone is interested.

[troflip]

As to packaging a fan game what I did for Developer was written in C#. Don't know how much help that might be. I could do a package that the user could just drop into their game for distribution if anyone is interested.

Is your packaging system complete and self-contained (like, not tied to Developer)? Like, you can just point it at a game folder, and go?

If so, and you uploaded it somewhere, I could have a link to it from within SCI Companion (or if you felt comfortable releasing the source code, it could be checked into the SCI Companion git repository and included in SCI Companion).

[Collector]

It is a separate class in Developer, but it would be possible separate it. Developer's script editor has a few methods to interface with it. The script editor also displays the StdOut feedback from makensis in real time, which is helpful for debugging a s script.

The way that it is setup it will generate a script for the currently loaded project. Just load a project and click the publish button and it will generate a script in the project's folder. In the preferences you can set whether or not you want to compile after the script is written. If not you can open the script by browsing to it in Developer's project manager and double clicking on it to open for inspection and editing before compiling. It would be simple enough to add a browse to a folder if you didn't want to have to load the project first.

I'll look into either lifting the publish from it or rewrite it. I suppose that I could do a standalone app that you could invoke from Companion, but if you wanted to simply incorporate it into Companion I would think that it would not be that hard to port to C++ since it is mostly string manipulation. In the mean time, while I really don't want to make it public at this early point in its development, I could privately send you a build if you want to take a look. A regression broke the loading of Text and Vocab resources and most of the SCI graphical resource editors are just place holders. The AGI part is more complete.