So, short version is that if there's anything you need to store outside an individual function call in Decker, the intended solution is to store it in a widget, on a card. Values of variables otherwise don't persist outside the specific piece of code that you're running at the time.

Let's say if you need to store a string named "mystring", you'll probably want to make a field widget to store it in, let's say it's called field1. Then in your code you can just store it like this

field1.text:mystring

And you can then access field1 from any other bit of code on the same card and retrieve the string from field1.text. And if you don't want the user messing with it at runtime, you can "lock" the widget or set its view attribute to "none" to hide it.

If your widget is on a different card, that's no problem either. I find it can work to have an inaccessible "utility" type card for holding onto variables. Let's say if I have field1 on a card named "myvars" for example, I can refer to it like this

myvars.widgets.field1.text

If you're storing values other than strings, in theory pretty much every Decker datatype can be serialised into a string but it might make more sense to use other methods for different data, depending on what you want to do. There's a bit of information in Phinxel's Field Notes, in the Lil section on the "Storing Information" page that might come in handy here.

It sounds like you've tried something like this but run into some issues, maybe you could go into details? In theory even if you're doing something "wrong" Decker shouldn't be hard-crashing so if you've got some examples of that then that could be handy in case there's a bug.

If you want to have a global constant though, that's a bit of an easier matter. You can at the top of a widget script, or a card script or the deck script, predefine the values of variables to essentially use them like global constants. Something like this

magicnum:1234
mystring:"Hello, World!"

I hope this makes sense but let me know if you need more explanation.

Some supplementary information about how to make this kind of "embodied data" act a little more like global variables:

You can set up a storage card for all of your data-holding widgets. One that (probably) your player will never navigate to (there are ways to make it harder to reach, as well, if your users are meant to navigate with arrow keys). It could have checkboxes for true/false, fields for text, grids for spreadsheet type data, etc.

And then you can set a sort of shortcut variable in the Deck level script (Accessible with  with File > Properties > [Script...]  Or if you're already in a script editor you can use File > Go to Deck to move to the other script directly.) which is a quicker path to the widgets on that specific card. 

Here I'm setting a shortcut to the widgets on a hypothetical card called myvars (using Millie's example):

vars:myvars.widgets

And then be able to use that shortcut variable to streamline your other scripts when you're referring to your other stored data, like:

vars.field1.value

instead of having to write the longer address every time you want to refer to your stored information:

myvars.widgets.field1.value

It's often a little easier this way.

Or you can use this kind of shortcut to go directly to a single widget, if it's one you're updating and referencing often:

thatfield: myvars.widgets.field1

I hope this helps.