As I'm primarily a developer, not artist, I actually start with the engine/functionality before procuring most of my assets. I deal mostly with Unity, although I have tried my hand at basic HTML5 games and CryEngine as well. Unity is a nice fit for me because 1.) lots of professional and community support 2.) choice of C#/Javascript/Boo as your scripting language 3.) Can easily port to all major mobile devices + PC/Mac (and consoles, but I believe it's a lot more paperwork/money for licenses) 4.) The Unity Asset Store lets you buy & sell assets/scripts/plugins that can sometimes help you shave off a few days/weeks of work or just to get a sample project to look at
CryEngine is actually fairly easy to get set up initially and incorporates a lot more already-built-in functionality, but has a much steeper learning curve than Unity. If you've got a decent understanding of C++, love working with Visual Studio, and want to get down and dirty with customizing the engine, go with CryEngine.
If you're attempting to edit an existing sound byte, you can use Audacity to pitch-shift/time-shift the sound. I've never attempted it, but it should work.
The biggest issue with this is that it's only meant for scripting, not running Python scripts that natively draw/interact with the user. So instead of C#/Javascript/Boo, you'd use Python. There will probably by obscure bugs as well that you'd need to watch out for.
A game the scale of which you are describing would take an entire development team months, if not years, to develop. I would suggest adapting your game into a Visual Novel (much like a choose-your-own-adventure), since your game is story-driven (the best kind). Not only would it be radically simpler to design, but there are free tools to do exactly what you need to do, such as this Unity extension:https://www.assetstore.unity3d.com/en/#!/content/9416
I think it's safe to say that over 90% of storage space required for modern games consist entirely of multimedia assets - images, videos, music, 3D models, textures, etc. The rest consists of the assorted scripts, save files, game executables, log files and other small miscellaneous files. Keeping this in mind, the relatively small filesize scripts are usually always easily accessible - whether through being kept in memory or kept in the hard drive cache. The game engine takes care of the heavy lifting of maintaining what is kept where, so unless you're building a 3D engine from scratch, you can stop worrying about what's kept where for the most part.
The programming philosophy I was taught, was something to the effect of "Get it working first, then optimize", in other words, don't worry if what you wrote works slowly, as long as it works correctly. Programming bottlenecks are often hard to discern from source code, as compiled code differs dramatically from source code.
Unity, and I think it's safe to say Unreal/Cryengine/most other game engines, utilize programming models that allow for the separation of data, graphical components, and user interface. With this in mind, the scripts can be executed upon user input, which updates the underlying data, which is then seen when the graphical components are redrawn on the screen based upon the underlying data.
Actually, having it in a single file might make it easier to process the script. So it looks to me that you just perform a Goto when you go room-to-room/system-to-system, is this correct? If so, you would be able to load the entire script into memory (I'm assuming filesize < 1mb, even larger is fine too) and just link the Goto tag to the line number. When a goto is encountered, you would be able to load the lines starting at the tag and run them.
In this fashion, you would no longer actually be using Windows batch scripting, but rather a custom interpreter that is based upon a subset of Windows batch scripting commands. New functionality could theoretically be added that doesn't necessarily work in Windows, such as -any "echo" command that includes "LETTER)" will create a selectable button -any "echo" command that include "CHARACTERNAME:" will create a speech bubble for "CHARACTERNAME"
As for Unity, you technically don't need to have any 3D modeling programs. They have a certain amount of built-in 3D tools, such as a terrain generator and basic 3D shapes (sphere, cube, cylinder, etc.). There are also free and paid 3D models available in the Unity Asset Store, which can be easily imported into the Unity environment. To import your batch script, you would need to create a Javascript or C# script (the languages supported by Unity) that would do like I suggested and be an in-between step between the batch script and Unity scripting.
Here's an example of what I was talking about (C# pseudocode):
File f = File.Open ("filename.bat"); string line = ""; //Read file line-by-line until ReadLine returns nothing/EOF while (line = f.ReadLine()) { //Split the line into words/symbols, separating by whitespace string[] symbols = line.Split (" ");
//Take the first symbol and perform an action dependent upon it if (symbol[0].Equals ("if")) { //Do IF command parsing //symbol[1] is equal to PARAM1 //symbol[2] is equal to COMPARATOR //symbol[3] is equal to PARAM2 //symbol[4 to n] is the statement to execute // IF PARAM1 COMPARATOR PARAM2 STATEMENT_BLOCK } else if (symbol[0].Equals ("echo")) { //Output symbol[1 to n] to console/GUI/speech bubble/audio file/etc. } else if (symbol[0].CharAt(0) == ':') { //Register Tag symbol[0] by saving it in a variable } else if (symbol[0].Equals ("rem")) { //Ignore REM lines and do nothing } }
And to read/write batch scripting variables, you could save them in the game engine in a similar way to how CMD.EXE stores them.
If your scripts don't do much more than IF statements and outputting, something like what I described should be a lot easier than trying to rewrite all of your existing scripts.
Just based upon the batch files you've shown, it may be possible to parse the batch files to be usable by a game engine. Realistically, it would probably be more work than re-writing what you currently have, but you've already written 46k lines...
As for the game engine, you may want to try Unity instead of Unreal if you're not totally invested. Not only does it have a better support community, but many plugins exist for code-less scripting, such as drag-and-drop event systems. You would need to reproduce your scripts in a different form, but may be easier to manage in the long run.
As I'm primarily a developer, not artist, I actually start with the engine/functionality before procuring most of my assets. I deal mostly with Unity, although I have tried my hand at basic HTML5 games and CryEngine as well. Unity is a nice fit for me because 1.) lots of professional and community support 2.) choice of C#/Javascript/Boo as your scripting language 3.) Can easily port to all major mobile devices + PC/Mac (and consoles, but I believe it's a lot more paperwork/money for licenses) 4.) The Unity Asset Store lets you buy & sell assets/scripts/plugins that can sometimes help you shave off a few days/weeks of work or just to get a sample project to look at
CryEngine is actually fairly easy to get set up initially and incorporates a lot more already-built-in functionality, but has a much steeper learning curve than Unity. If you've got a decent understanding of C++, love working with Visual Studio, and want to get down and dirty with customizing the engine, go with CryEngine.
If you're attempting to edit an existing sound byte, you can use Audacity to pitch-shift/time-shift the sound. I've never attempted it, but it should work.
http://manual.audacityteam.org/o/man/sliding_time_scale_pitch_shift.html
If you want to try integrating Python with Unity, there *is* a plugin that uses IronPython (built on .Net framework 2.0): https://www.assetstore.unity3d.com/en/#!/content/645
The biggest issue with this is that it's only meant for scripting, not running Python scripts that natively draw/interact with the user. So instead of C#/Javascript/Boo, you'd use Python. There will probably by obscure bugs as well that you'd need to watch out for.
A game the scale of which you are describing would take an entire development team months, if not years, to develop. I would suggest adapting your game into a Visual Novel (much like a choose-your-own-adventure), since your game is story-driven (the best kind). Not only would it be radically simpler to design, but there are free tools to do exactly what you need to do, such as this Unity extension:https://www.assetstore.unity3d.com/en/#!/content/9416
I think it's safe to say that over 90% of storage space required for modern games consist entirely of multimedia assets - images, videos, music, 3D models, textures, etc. The rest consists of the assorted scripts, save files, game executables, log files and other small miscellaneous files. Keeping this in mind, the relatively small filesize scripts are usually always easily accessible - whether through being kept in memory or kept in the hard drive cache. The game engine takes care of the heavy lifting of maintaining what is kept where, so unless you're building a 3D engine from scratch, you can stop worrying about what's kept where for the most part.
The programming philosophy I was taught, was something to the effect of "Get it working first, then optimize", in other words, don't worry if what you wrote works slowly, as long as it works correctly. Programming bottlenecks are often hard to discern from source code, as compiled code differs dramatically from source code.
Unity, and I think it's safe to say Unreal/Cryengine/most other game engines, utilize programming models that allow for the separation of data, graphical components, and user interface. With this in mind, the scripts can be executed upon user input, which updates the underlying data, which is then seen when the graphical components are redrawn on the screen based upon the underlying data.
Actually, having it in a single file might make it easier to process the script. So it looks to me that you just perform a Goto when you go room-to-room/system-to-system, is this correct? If so, you would be able to load the entire script into memory (I'm assuming filesize < 1mb, even larger is fine too) and just link the Goto tag to the line number. When a goto is encountered, you would be able to load the lines starting at the tag and run them.
In this fashion, you would no longer actually be using Windows batch scripting, but rather a custom interpreter that is based upon a subset of Windows batch scripting commands. New functionality could theoretically be added that doesn't necessarily work in Windows, such as
-any "echo" command that includes "LETTER)" will create a selectable button
-any "echo" command that include "CHARACTERNAME:" will create a speech bubble for "CHARACTERNAME"
As for Unity, you technically don't need to have any 3D modeling programs. They have a certain amount of built-in 3D tools, such as a terrain generator and basic 3D shapes (sphere, cube, cylinder, etc.). There are also free and paid 3D models available in the Unity Asset Store, which can be easily imported into the Unity environment. To import your batch script, you would need to create a Javascript or C# script (the languages supported by Unity) that would do like I suggested and be an in-between step between the batch script and Unity scripting.
Here's an example of what I was talking about (C# pseudocode):
File f = File.Open ("filename.bat");
string line = "";
//Read file line-by-line until ReadLine returns nothing/EOF
while (line = f.ReadLine()) {
//Split the line into words/symbols, separating by whitespace
string[] symbols = line.Split (" ");
//Take the first symbol and perform an action dependent upon it
if (symbol[0].Equals ("if")) {
//Do IF command parsing
//symbol[1] is equal to PARAM1
//symbol[2] is equal to COMPARATOR
//symbol[3] is equal to PARAM2
//symbol[4 to n] is the statement to execute
// IF PARAM1 COMPARATOR PARAM2 STATEMENT_BLOCK
} else if (symbol[0].Equals ("echo")) {
//Output symbol[1 to n] to console/GUI/speech bubble/audio file/etc.
} else if (symbol[0].CharAt(0) == ':') {
//Register Tag symbol[0] by saving it in a variable
} else if (symbol[0].Equals ("rem")) {
//Ignore REM lines and do nothing
}
}
And to read/write batch scripting variables, you could save them in the game engine in a similar way to how CMD.EXE stores them.
SortedDictionary<KeyType, ValueType> variables = new SortedDictionary<,> ();
//Read variable
variables["VariableName"]
//Write variable
variables["VariableName"] = variableValue;
If your scripts don't do much more than IF statements and outputting, something like what I described should be a lot easier than trying to rewrite all of your existing scripts.
Just based upon the batch files you've shown, it may be possible to parse the batch files to be usable by a game engine. Realistically, it would probably be more work than re-writing what you currently have, but you've already written 46k lines...
As for the game engine, you may want to try Unity instead of Unreal if you're not totally invested. Not only does it have a better support community, but many plugins exist for code-less scripting, such as drag-and-drop event systems. You would need to reproduce your scripts in a different form, but may be easier to manage in the long run.