Tsa05
Member
StormingLeech Interactive Dialog Game Engine
(Limited time, whole engine is $3 to give more people a chance to play)
DEMO*
VIDEO (Zzzzz--a 17-minute long explanation of how to set up data and start building a game. Boring but thorough.)
How-To Wiki
*Some features in the demo are odd due to html5 export; eg, needing to click on the window to activate sound, game size not set to scale to browser size...
In-game visual editing
Style editors for creating/editing the global appearance of text and choice boxes
Character editor for layering and grouping character expressions and poses
What is SLIDGE?
It's HuniePop. There, I said it. The idea is simple: You want to use GameMaker to create some kind of game mechanics--platformer, match 3, hidden object, mmo, all the usual--but then, you have the twisted idea to attach a dating sim to it. Ok, maybe not a dating sim. A "Visual Novel." Or dating sim. Something with textboxes, choice boxes, characters who enter and exit and say stuff.
Of course, your text has to be wrapped and paginated and colored and typewritened and fonted and wiggle and shake and have emojis and sound effects and a fancy-looking box and bouncing icons and stuff.
RenPy, RPGMaker, Twine...they all make it so easy to create the dating--sorry, the visual novel part of the game, but then you've got to do the rest of the custom game mechanics you wanted without a handy Game-Making tool. Then there's GameMaker--the handy game making tool--that has...totally vanilla..text. SLIDGE does the fancy stuff, and more.
Why is SLIDGE?
There are dialog engines for GameMaker. All of the engines go straight to code. And there's absolutely no need. Visual Novels are visual.
If you use an engine that requires lines for each piece of text or action, how will you organize your game's innumerable dialog scenes and moments? How will you edit the appearance of scenes, insert new scenes, or adjust the positioning and timing of stuff on screen? Several thousand lines of engine calls and IF statements?
How are you going to localize your game in different languages?
With code-based solutions, you'd double all of the engine's text function calls. Or triple them. Or hand it to a language translator and ask them to program (correctly) for you?
Engines need code, sure, but why does the dev have to type all the code? That's not how these things work; the contents of a Visual Novel are data, not code. Why isn't it easy to set the data (the text, the character, etc) visually?
SLIDGE is a wysiwyg editor.
And if you *are* coding a game...
SLIDGE is a 1-object complete engine. Create an instance of SLIDGE anywhere, any time when you'd want dialog.
But wait, there's more.
SLIDGE integrates data with your game. Mmhm. Yours.
The player does stuff in-game, and when the dialog launches...it's changed because of stuff the player has done.
You've played games like this before. You get to the end of the adventure and the game has a series of "things" that happen.
In a normal branching dialog system, you'd have to duplicate entire branches and make adjustments...or hijack the engine with custom code. In SLIDGE, the "end action" of any Scene, or the "target link" of any Choice Button can be the name of a scene.....OR a name of a room, OR a SLIDGE variable.
Somewhere along the way in your game, during some dialog or as a result of some other play elements, Johnny's fate is decided. Does he become a doctor? Will he successfully terraform his parents turnip farm into a replacement spleen farm??? You make the vital choice that determines Johnny's fate, and then go on with the game.
But your choice changed everything. Yep. The engine produces (or refers to, if already existing) a variable called global.register, which is a DS Map. You can invent variable names as you go along, tracking things you'll want later. Maybe you've decided that certain actions from the player change the value of "johnnyFate" in the Register. Within the engine, you'd attach that value to certain button choices. If you're coding? global.register[?"johnnyFate"]="farmerScene". Or anything you want.
What does that do for you? Well, when the game reaches it's final scene, you don't link to a specific scene name. Instead, set engine to go to the variable johnnyFate. You have altered fate itself! The chapter, the game, whatever, will re-route to whatever scene you name.
And yes, the engine has the ability to add and subtract numbers in the register, and also to perform setting, adding, or subtracting based upon conditions--eg, only set Johnny's fate to "becomesSquirrel" if he went nuts back in scene 3, else set his fate to "becomesDoctor".
And, of course, since it's all in a global ds_map....any other game mechanics you happen to be coding can use and modify that info. You could get a player's name and store it in the key: "playerName." The engine could print out "Hello [r=playerName]!" You get the idea. This engine, with visual editing, is sufficient for most visual novels or even point-and-click adventures. It could handle the dialog for your own RPG, or...anything. The data is all JSON, easy to use or edit in other tools as needed.
Point is, it's a very, very powerful system; It's in version 1. There will be updates. There will be bugs. There are, due to the complexities of the engine, and the fact that it uses practically everything in GameMaker, always going to be many ways to make it crash, break, or hiccup. Don't, and we'll both be happy. But I will also be evolving this as I create my own stuff.
As-is, you can go a very long way very easily, and I've created a full getting started video and a Wiki. And a demo. Check out everything, ask questions, and omit negativity (pls).
Where is SLIDGE
On the Marketplace. Eventually, it'll be on itch.io also. And, if people start using it--we'll call you pioneers--then there'll become a Patreon way of getting it via supporting ongoing dev/features. We shall see, the future is in your hands.[r=future]
One final thing about SLIDGE
For better and for worse, SLIDGE is written in 100% GML. That means it's as portable and cross-platformable as GML. As portable, not more. HTML5ers, you have been warned.
For example, as of this writing, an object's image index won't advance automatically in HTML5 the way it does in Windows when no sprite is set for an object. I had to assign a 1 pixel sprite to my engine object for the HTML5 demo, just to make things animate...
In the past 3 years, I have had more issues with annoying things not working in HTML the same way they did in Windows... Rawr. The Dec 5th 2018 patch with 115 bug fixes helped a lot Made the demo actually possible to put online~
(Limited time, whole engine is $3 to give more people a chance to play)
DEMO*
VIDEO (Zzzzz--a 17-minute long explanation of how to set up data and start building a game. Boring but thorough.)
How-To Wiki
*Some features in the demo are odd due to html5 export; eg, needing to click on the window to activate sound, game size not set to scale to browser size...
In-game visual editing
Style editors for creating/editing the global appearance of text and choice boxes
Character editor for layering and grouping character expressions and poses
What is SLIDGE?
It's HuniePop. There, I said it. The idea is simple: You want to use GameMaker to create some kind of game mechanics--platformer, match 3, hidden object, mmo, all the usual--but then, you have the twisted idea to attach a dating sim to it. Ok, maybe not a dating sim. A "Visual Novel." Or dating sim. Something with textboxes, choice boxes, characters who enter and exit and say stuff.
Of course, your text has to be wrapped and paginated and colored and typewritened and fonted and wiggle and shake and have emojis and sound effects and a fancy-looking box and bouncing icons and stuff.
RenPy, RPGMaker, Twine...they all make it so easy to create the dating--sorry, the visual novel part of the game, but then you've got to do the rest of the custom game mechanics you wanted without a handy Game-Making tool. Then there's GameMaker--the handy game making tool--that has...totally vanilla..text. SLIDGE does the fancy stuff, and more.
Why is SLIDGE?
There are dialog engines for GameMaker. All of the engines go straight to code. And there's absolutely no need. Visual Novels are visual.
If you use an engine that requires lines for each piece of text or action, how will you organize your game's innumerable dialog scenes and moments? How will you edit the appearance of scenes, insert new scenes, or adjust the positioning and timing of stuff on screen? Several thousand lines of engine calls and IF statements?
How are you going to localize your game in different languages?
With code-based solutions, you'd double all of the engine's text function calls. Or triple them. Or hand it to a language translator and ask them to program (correctly) for you?
Engines need code, sure, but why does the dev have to type all the code? That's not how these things work; the contents of a Visual Novel are data, not code. Why isn't it easy to set the data (the text, the character, etc) visually?
SLIDGE is a wysiwyg editor.
- You pop an edit object into your game, and play.
The editor is overlayed, you paste in text and design characters and scenes and stuff visually, and the data gets spat into %localappdata%. - You swap the edit object for the play object and add the data files as "included files" and your game is ready for the big-time.
And if you *are* coding a game...
SLIDGE is a 1-object complete engine. Create an instance of SLIDGE anywhere, any time when you'd want dialog.
But wait, there's more.
SLIDGE integrates data with your game. Mmhm. Yours.
The player does stuff in-game, and when the dialog launches...it's changed because of stuff the player has done.
You've played games like this before. You get to the end of the adventure and the game has a series of "things" that happen.
Non-linear dialog."Johnny went on to become a doctor," "Sarah underwent robot transformation surgery," "Case never saw Molly again."
In a normal branching dialog system, you'd have to duplicate entire branches and make adjustments...or hijack the engine with custom code. In SLIDGE, the "end action" of any Scene, or the "target link" of any Choice Button can be the name of a scene.....OR a name of a room, OR a SLIDGE variable.
Somewhere along the way in your game, during some dialog or as a result of some other play elements, Johnny's fate is decided. Does he become a doctor? Will he successfully terraform his parents turnip farm into a replacement spleen farm??? You make the vital choice that determines Johnny's fate, and then go on with the game.
But your choice changed everything. Yep. The engine produces (or refers to, if already existing) a variable called global.register, which is a DS Map. You can invent variable names as you go along, tracking things you'll want later. Maybe you've decided that certain actions from the player change the value of "johnnyFate" in the Register. Within the engine, you'd attach that value to certain button choices. If you're coding? global.register[?"johnnyFate"]="farmerScene". Or anything you want.
What does that do for you? Well, when the game reaches it's final scene, you don't link to a specific scene name. Instead, set engine to go to the variable johnnyFate. You have altered fate itself! The chapter, the game, whatever, will re-route to whatever scene you name.
And yes, the engine has the ability to add and subtract numbers in the register, and also to perform setting, adding, or subtracting based upon conditions--eg, only set Johnny's fate to "becomesSquirrel" if he went nuts back in scene 3, else set his fate to "becomesDoctor".
And, of course, since it's all in a global ds_map....any other game mechanics you happen to be coding can use and modify that info. You could get a player's name and store it in the key: "playerName." The engine could print out "Hello [r=playerName]!" You get the idea. This engine, with visual editing, is sufficient for most visual novels or even point-and-click adventures. It could handle the dialog for your own RPG, or...anything. The data is all JSON, easy to use or edit in other tools as needed.
Point is, it's a very, very powerful system; It's in version 1. There will be updates. There will be bugs. There are, due to the complexities of the engine, and the fact that it uses practically everything in GameMaker, always going to be many ways to make it crash, break, or hiccup. Don't, and we'll both be happy. But I will also be evolving this as I create my own stuff.
As-is, you can go a very long way very easily, and I've created a full getting started video and a Wiki. And a demo. Check out everything, ask questions, and omit negativity (pls).
Where is SLIDGE
On the Marketplace. Eventually, it'll be on itch.io also. And, if people start using it--we'll call you pioneers--then there'll become a Patreon way of getting it via supporting ongoing dev/features. We shall see, the future is in your hands.[r=future]
One final thing about SLIDGE
For better and for worse, SLIDGE is written in 100% GML. That means it's as portable and cross-platformable as GML. As portable, not more. HTML5ers, you have been warned.
For example, as of this writing, an object's image index won't advance automatically in HTML5 the way it does in Windows when no sprite is set for an object. I had to assign a 1 pixel sprite to my engine object for the HTML5 demo, just to make things animate...
In the past 3 years, I have had more issues with annoying things not working in HTML the same way they did in Windows... Rawr. The Dec 5th 2018 patch with 115 bug fixes helped a lot Made the demo actually possible to put online~
Last edited: