Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

This tool is hard to understand

A topic by LimiDrain created Jan 21, 2024 Views: 139 Replies: 1
Viewing posts 1 to 2
(1 edit)

This tool is not intuitive for beginners. It's like, it's not even a simplification. I have no understanding of how to process that in the game engine.

What do * {playerApproach} and * * [yes] mean in the Branching Scene Example? It's just a General block type.

#set book_quest=true is pretty clear, but where does book_quest come from? In screenplay everything is formal, but in gamedev we need specifics. For instance, a list of available variables.

If it's a non-strict system, then transferring texts from Excel is still the same. Writers can use #set book_quest=true in Excel. Also I can make a list of available variables in the same spreadsheet, so that the writer can choose from the available ones. So what's the advantage over more flexible spreadsheet systems?

Host

Hello! Thank you for trying Scripto out and posting this. You are correct it is a non-strict system -- the flags and branching examples are just ways you COULD go about structuring a script, with the processing work passed on to your engine. So as to why some might prefer this over a spreadsheet format, it comes down to a couple things:

1) Fluidity of writing. In a script, you can write a scene top-down and think about every line in context. In a spreadsheet, this context and flow can be lost when hopping between cells. It is also harder for voice actors to make sense of spreadsheets than the screenplays they are generally used to receiving.

2) Automatic per-line GUIDs. Our system assigns a unique ID to every line of every script on creation, and that ID travels over the API. This is a key part of localization and VO that is often assigned later in the development process, and can be labor-intensive, so it's time-saving to generate them in Scripto.

You're correct there are some affordances we could be making to global variable lists and auto-completion -- we're working on that! In the meantime, if you are looking for a fully interpreted language whose affordances are more strictly defined, I recommend trying out our implementation of the Ink format -- Ink is well-documented and has been used in many commercial projects. Ink will also compile in-browser and let you click through the choices you've written, and there are a number of downstream integrations that already exist for bringing it into Unity, Godot, etc.

Thanks again for your feedback here!