It’s going to be at least a week until I get the dev tools updated. I injured my arm and need some rest, and there are more things I realized I should do while I have the game server down.
I thought I should post about the tool both as an update, and it’ll serve as a reference to explain some things for those using it, as I’m thinking of making it so people can try it and out and make their own game so I can get some feedback. What I think is easy an intuitive might not be the same for most people.
And the other things I’m adding that I didn’t think about is that I want to add support for making custom objects/classes. Before I had those NPC cards hard-coded on the server. I need a way to reimplement that without the hard coding. I need to make it so a custom class can be created for NPC cards, and events hooked to deliver them with a scene for that NPC.
Eventually I’ll have the entire game all recoded that way, using the visual scripting. There isn’t too much to convert in that way, but I need to get the basic system in place an extended to allow custom objects.
(It’s still missing lots of functions, and they need their description and such filled out much better)
So before, it was just a simple drop down list of function names, then an input box to type stuff in. You can see that here.
What I wanted to do is to make things mostly just clicking buttons, and it needed to say what you’re supposed to do.
Options were also updated so that they can have multiple arguments and multiple functions. Before they were limited to one.
I also adjusted its look to be a bit more compact(except for options and functions which have more to them)
For example. “isCompleted” is an argument that’ll return true if the supplied scenario, and/or set, and/or scene has been marked as complete. It should say that’s what it does when you hover it, so you can see how to use it.
Instead of one long input, it has it divided up for each applicable parameters, which could be optional, have a default, and tells you what each parameter should be.
So here, it wants a scenario, set(optional), and scene(optional).
In the case of scenario, you can just write “this”. Otherwise, you get a dropdown displaying a list of every scenario that you can just click instead of typing in. Like at the top right, there’s another input that expects a map. When you click it, it displays all maps, and will narrow down the list to autocomplete what you type in there.In the case of “this” for a scenario, it will supply the current scenario there. “this” supplied for a set would supply the set index it’s in. Same for “this” in scenario.
So if you put isComplete this this 1, it would return true if scene index 1 was marked as complete for the player. Otherwise it’d fail.
The functions run if there is no argument, or if all arguments return true. (Or if the “!” is checked and they return false! So you can have something happen only if the argument fails)
The “end” function will stop all further functions after it from running. “goto” also triggers “end”. That’s a way to have a scene redirect, and if it doesn’t have other functions go off. It’s all guaranteed to go in sequence.
If there is an infinite loop, like scene 0 having “goto 1” and scene 1 having “goto 0”, it will detect it and stop it once the infinite loop begins. (So it’d go from 0, to 1, then back to 0 and stop there)
Now, in order to make logic there’s mainly 5 things to know:
Events: In red, these are events that are fired which then run the sequence of arguments and then functions if those arguments pass.
For example, inside a scene you have “sceneBeforeStart” which runs before a scene actually runs and delivers its data to a player. This way, you can direct to another scene, or stop it from starting to begin with.
Then there’s “sceneEnd”. This event triggers when a scene stop. This way you can change something that would have happened at the end of the scene, so you don’t even up changing something that’d make writing parsing behave weird, or make dialog options not work as expected due to a change.
Arguments: In green, these are an “if” statement. You are checking things to see if they pass or fail. The “!” being selected makes it continue if it fails instead of passes. These are optional, and you can have functions simply run anyway. Any number of arguments can be added.
Functions: In blue, these are the actual game logic. They can even do things like trigger an event for something else, which is how you do more complex things.
Lots of functions can be chained together to all run when an argument passes.
Macros: In gold, this is a saved list of arguments and/or functions. When you have a combination of them that you commonly use, you can save them as a macro and plop them in different places.
Objects: This is the general containment of everything else.
Items are an object, where logic runs on construction, instancing, or button presses.
Scenarios are an object, which have logic for when they’re constructed, instancing, when sets or scenes are iterated through, and when options are selected.
So, it can get really complicated when it comes to defining custom game logic. But much simpler than writing it by hand. The benefits are that the client-server interaction and optimizations are handled for you, as well as making mundane things really simple.
The basics are simple. You click “New Default Scenario” and it fills in some basics. Then you just write stuff, and can tell it when to run some functions like when to give a quest to a player. The list of quests is right there where you’d type it in, making selecting it easy. The functions and arguments all say what they do.
The tool is networked
When someone else adds a new Scenario, quest, event, map, etc, it appears for everyone else.
I knew I was going to need a small team of writers, and I wanted to make sure people can collaborate.
When two people are working on the same Object, I want there to be some notification of that. That’s no there now. But there is still the “Revision” system that eliminates lost data.
There’ll also be some way to communicate, leave notes, etc.
Additions and Changes affect the game immediately.
Generally with basically every game out there, you have to compile it, restart the server, and clients need to exit and download an update.
With this engine, everything updates in real time.
If a quest is changed or removed, it knows how to refactor it for people who already have that quest. If an items buttons are changed, it knows how to change those buttons for everyone that has it. New content added is there right away, ready to be delivered when it’s triggered.
This helps make things a lot easier to test, when you can try it in game immediately, among a lot of other benefits.
Open for others to test out… soon?
There’s things in the way of this happening right away, but I’d like to get more peoples feedback on this than just those I’d choose to write for the game.
It’s not so simple to just make it so people can click a button an have their own game with their own url for others to access. I need some way of creating separate game instances linked to accounts.
I’d need people dedicated to actually give good feedback in order to put in that sort of time and effort.
Initially I planned to do this later, because I wasn’t sure I’d get the funding needed to actually complete the game and it’s a lot of extra work that doesn’t necessarily directly benefit LEWD. Now since I’m confident I will, I think it’d be better to make it so others can create their own game sooner, so I can get feedback in order to make the dev tools as good as possible from the start.