STARMAP DEVELOPMENT TIPS

IN LUA, IT'S ALL ABOUT THE TABLE

Lua tables are super easy to work with. And since lua thinks of code as just another kind of data, tables can have functions and thus become independent objects with their own behaviour.

In the simplest case, a table looks like this:
            local myTable = {
                name    = "Danny",      -- note the COMMA that separates each item in the table
                age     = 35,           -- each item has a name ('age') and a value ("35")
                weight  = 173,          -- I think it's OK to have a comma here, on the last line
            }                           -- table definitions are in curly braces
            
            -- then I can read the data easily
            local myWeight = myTable.weight
            
            -- or even add data at any time
            myTable.shoeSize = 11
            
            -- And, where it makes sense, you can also say stuff like
            local myAge = myTable[ 'age' ]
            myTable[ 'numFingers' ] = 10  -- again, you can add new data to your table at any time.
            
            -- for bonus points, lua tables can contain tables that contain tables
            local something = user.account.serviceRep.phoneNumber
            
            
        
If you follow my pattern (and I repeat, you don't have to), you will have at least one 'scene' and probably several 'bot' characters (also referred to as NPCs). Each of these objects is represented by its own lua table. You would declare a new scene like this:
            myNewScene = newScene( sceneRoot, {
                -- required table entries
                id          = "Main",                   -- each OBJECT needs a unique id
                
                -- optional table entries
                anythingILike = "whatever pleases me",  -- data private to this scene
        
                -- this is called when player first becomes aware of starmap, before launching
                onAwareCutScene = function( scene )
                    wait( 3 )                           -- they see map preview
                    setCamVeil(   0, 500 )              -- fade map preview to some percent of normal
                    wait( 1 )                           -- let the preview fully disappear
                    ...                                 -- everything else you want to do...
                    end,                                -- note the comma after each table entry
                    
                } ) -- closes the 'newScene' command

        

Note that 'newScene' command takes two arguments. The first is a lua table which is the 'parent' of this new object. The new object starts out identical to its parent, and then the second argument is a table of 'just what is different from' the parent.

Making a new NPC or bot is pretty much the same

            botCharley = newBot( botRoot, {
                -- required table entries
                id          = "botCharley",                   -- each OBJECT needs a unique id
                
                -- optional table entries
                anythingILike = "whatever pleases me",  -- data private to this bot
        
       

CODE IS JUST ANOTHER KIND OF DATA

I'm just old, so this sort of thing excites me even though it's nothing new. For me, a function looks like this:
                function doSomething( arg1, arg2, arg2 ) 
                    .. do something useful here
                end
            
I mean, once you buy in to the lua use of 'end' and 'then' and '--' and such. But lua only accepts that syntax as a convenience, what it is really thinking inside its deepest thought is:
                doSomething = function( arg1, arg2, arg2 ) 
                    .. do something useful here
                end
            
You might think of that as 'doSomething is a reference to a three argument function. The point being, when you think of it this way, it's easy to see how you could store that code inside some memory struction, like a variable or a table, creating additional references to that same function, which is in memory SOMEWHERE, but you don't really care exactly where, so long as you can find it when you need it.

YOU'RE THE BOSS

The starmap represents your entire universe and doesn't have to be compatible with any other starmap. Each can be implemented in its own way, to meet its own goals, and one thing that makes this easy is that you can add data to your scene at any time.
Say you get the idea to force the player to collect 5 of something, before they are allowed to continue the plot line. You'll need a place to store the count of how many have been collected.
            -- he needs to collect five of these, this is how many he has
            
            scene.numFlagistansCollectedSoFar = 0
            
            while( scene.numFlagistansCollectedSoFar < 5 ) do
                wait()  -- we have nothing to do, other than hurl insults
            end
        
The point being that we didn't have to make a plan, or declare the data a thousand lines away from where it is used. We just hacked it in as soon as we thought of it. We just have to remember to add that 'scene.' to the front, since that's where the data IS, in the scene table.