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.