Narration app for fan games

[gumby]

I've put together an application which will read all the printed text displayed within a game.  It calls the Google Translate API in real-time while a game is playing and speaks the displayed text to you.

It's a fun little project that I hacked together this weekend.  It utilizes the ability for an SCI game to write to a file.  It runs externally to the game, monitoring a file that I've modified the Controls.sc script to write all the print statements to.  The application picks up the changes, ships them off to the api, saves the results to an MP3 and plays them.

Here's the script modification:

Code: [Select]

   (if( <> STRINGS_EQUAL StrCmp("Enter Input:" @msgBuf))
   (if( <> NULL (= hFile FOpen("print.txt" fCREATE)) )
   FPuts(hFile @msgBuf)
   FClose(hFile)
   Wait(30)  //wait a bit, so we can sync the text with the voice (sort of)
   )
    )

I've uploaded a modified template game demonstrating the app.  The executables: SCI_Narrate.exe and madplay.exe (madplay is needed to play the MP3s).  If you want to incorporate a 'narrator' into your game, just copy the exe's into your game dir & modify or replace your Controls.sc.

I've included the C# source code for those interested.

[Collector]

Cute, but impressive, too. Although on a more practical level, I am wondering if this could be adapted to hack in digital sounds into the template game, not just a narrator; character speech, sound effects, digital music, etc. without the size limitations with embedding it into a SOUND file. Having the game output to something that other programs can read or interact with suggests a lot of ways to extend SCI0's capabilities externally.

[gumby]

It also has the added benefit of not being restricted to one sound playing at a time.  I'm thinking this style of solution would be appropriate for background music/sound effects that would perhaps loop for a particular room, rather than say a sound effect that is bound to a specific in-game event (opening a door, for example).  This would avoid timing issues.

[Collector]

The auto narration is cute, as I said, but I am more excited by the implications of extending SCI0.

[gumby]

I'm agreeing with you .  What I meant by 'style' was the style of solution, having an external application monitoring in-game events & playing MP3s.  Instead of a narrator, I'll switch it up with a preset list of MP3s, maybe one for each room so when the ego enters the room it will trigger an MP3 to play.

[Cloudee1]

This sounds pretty damn cool, you mean we could have talking games. Look out AGS lol! But seriously, just writing a line to a file and an mp3 will play?

[gumby]

An external command line application has to be running, but yeah, the game just writes to a file and the external app reads it and calls the API.

Could just as easily have the game write out the name of an MP3 and have it play that instead.

This will be fun to tinker with.

[Cloudee1]

So really all we need then is a new batch file that launches both the midi file and dosbox simultaneously to make it as pain free for a user as possible then right?

[gumby]

Yeah.  I'm thinking about creating another demo game to add externally played MP3 music, which would switch songs between rooms.  I also need to add some logic to kill the currently playing file.  I'll need to create a new command line app.

We could also modify the narrate app to use an actual narrator, playing canned MP3s.

[Collector]

Is more than one simultaneous sounds doable?

[gumby]

Is more than one simultaneous sounds doable?

Absolutely.  In fact during my initial testing I was playing the MP3s asynchronously, so playback had three different voices at the same time.  I'm thinking about having multiple files create/monitored that the application would work against.  Maybe one for sound effects and one for music?  Probably don't need more than two sounds at the same time, yes?

Plus, we always can have one in-game sound additionally playing as well.

I've modified the app to run without a command window (it's totally hidden now) & to kill itself off after RUN (Collector's DosBox game runner), DOSBox or SCIV are no longer running.  I think that covers all our bases, correct?

I've also written a little batch file:

Code: [Select]

start SCI_Narrate.exe
start RUN.EXE
And changed my 'run' option to use 'run.bat' instead of 'run.exe'.  It seems to work quite well.

I'm moving forward with a new demo, this time with background music.  Hopefully will have something to share soon.

[Collector]

Possibly three; music, sound effects and then speech. I can easily modify the DOSBox run to accommodate it.

[gumby]

Makes sense to me.  I'll create 3 subdirectories, each for holding the different MP3s (music, sound effects and voices).  Along with this, I'll create 3 different text files that will be monitored by the app.

This could be a bit tricky, as I'll need to allow for both playing sounds serially as well as in parallel.  I'll provide this as an option for the developer.  Probably need an option to kill all currently playing sounds.  A looping option will also be provided.

I'm also thinking about providing a volume option so that background music (or effects) could have a lower volume level than say the narration tracks.  It'll be important to make sure that all MP3s in a game (or at least within each subdirectory) have the same gain levels, otherwise the user will constantly be fiddling with their volume controls.