posted
TWEAKS, TWEAK STRINGS, and MAP INSTANCE DATA
I get closer to implementing map instance data, with the goals
* starmap defines the data it needs * all players start with that * moderator copy updates game state and pushes instance data to all players as it changes * any play can save the current instance data (for this map) in a local file on their device. * any moderator can load a previously saved file (and distribute the new instance data to the other players)
This should allow
* resuming play later, though multiplayer data is then cast upon the current players. Instance data is mostly GAME state, not individual player state. Still, the red team base belongs to the red player, whoever they happen to be.
* saving a favorite scenario/problem at an interesting point (before others have 'ruined' it :-) private instances used as personal terrarium/screen savers.
But what IS instance data? As a rule, I declare it is mostly "small arrays of float values" and largely centered on the concept of 'the tweak'
The synSpace game engine is already littered with dozens of 'tweak' values. (but not an organized tweak system) Each value is compiled to a fixed value (the default value) and the idea is then for the starmap to be able to override the values it wants to control, and leave the others alone.
So I have been taking baby steps into how Lua would do that. And it looks like the winner is:
game.setTweaks( "tweak string" )
Where a tweak string looks like this:
"1=2.3,4.5,1323,9=2873764.3"
The simplest tweak string is:
"45=-9.8"
Which means "tweak number 45 has the value -9.8"
If you add additional values, they are assigned to the following tweak numbers, so
"10=1.0, 2.0, 3.0"
would set tweak 10 to 1.0, tweak 11 to 2.0, and tweak 3 to 3.0
My thought is to organize the tweak id numbers (which then must never change after being documented on the web site somewhere) so that all the tweaks for the terrain are 'in a row' and all those for climate 'are in another row'
Then finally, by adding an equal sign, you can switch rows in the middle:
"10=441,102,37, 40=17,32,63, "
sets tweaks 10,11, and 12, then tweaks 40, 41 and 42, leaving the intervening tweaks alone.
This way, a starmap can define a complete planet terrain/climate with just a couple tweak strings (which are also easy to edit in the starmap file, and I might ultimately provide an ingame editor for these as well)
A tweak string might be one pieve of instance data for the map, so the map has a section of named instance data, like
Where twkTerrain and twkClimate are names defined by the starmap and have no meaning to the engine, but the engine can store these values and jam them back into the lua memory (and then back into the engine as needed)
Other instance data might be
data.numVillages="46"
some sort of 'score' data of interest only to lua, and then there is some specialty data like
posted
So, nothing to report to speak of, but I did add minimal support for Stereo placement of music (I'm thinking the BAND panel will eventually have a UI for placing instruments/patches, but I just added the infrastructure support for sending stereo samples to the speakers.
And, as it turns out, I had apparently misunderstood the documentation for android AudioRecord and AudioTrack. I had always found the buffers a little mysterious, but, as usual, there is no mystery at all, and I was nervous about all sorts of phantoms.
Bottom line, however, is my buffers have always been the wrong size, and it's interesting how well it has adapted to that. Now that part is ship shape, and I fantasize the 'audio lag' is maybe a little less than before. Still present, however, to the degree I think you can't generally play 'triplets' as you normally might.
Probably broke a lot of stuff in the vocoder (which only processes in mono), but I think it's mostly stable after stereo-i-fication.
The reverb is also still mono, and once the infra is solid, I still have to add official reasons for stereo, but if nothing else, I can use the note pitch to select stereo position (higher notes on the right, like a piano)
But in theory, I could place a BAND in world and then walk around and hear the individual instruments in different mix levels based on where I am standing. That feels slightly novel. (as opposed to a complete piece of music all from one spot in space (announcements))
Anyway, I'm busy failing at work, so no time to fail at home :-)
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
i IMplemented a location system where I can have up to a million 'fractally-generated' flora/fauna/whatever objects placed by the starmap (on each planet the map knows about)
Of course, no such objects exist yet, but I know one class of them will be vegetation (trees, bushes, pebbles) etc. These act both as 'ground clutter' and also as potential materials for the starmap's crafting system, if any.
While this system doesn't increase the number of things I could render (only the closest trees will be rendered, for example), it helps organize my thoughts, and it keeps things persistent. If I walk away until a tree is out of sight, then turn around, the same tree should appear in the same location.
My existing primitives look like they might handle a variety of tree shapes, but I would love to have a 'radius function' that created 'gnarled tree stumps/trunks'
And just because I am who I am, and am subject to subliminal signals unintentionally sent by my smarter friends (lookin' at you, JW), I am starting Yet Another System to handle it.
I do NOT have a good name for this, but basically I 'grow' the object, like this:
1.) start with a triangle (see, my other stuff starts with a square). For now, this starts as a flat triangle on the ground, rotated to some compass heading
3.) call my new recursive function with that starting triangle and a pointer to a basket of object properties (like the overall desired height and width of the growth, and its position on the ground in world coords)
5.) if it comes up zero (well, ok, 1) then you're done, just render this triangle. That would be a boring tree.
6.) if it is non-zero, then create a fourth point, forming a tetrahedron (that's a "pyramid" with a triangle bottom instead of a square bottom). The placement of this fourth point is my new 'radius function' and basically, for a tree, I try to grow 'up and out' while staying inside my object width and height constraints.
7.) using that new point, form three new triangles (the sides of the new 'pyramid')
8) recurse into the same routine, for each of those triangles.
Then each of those decide to either stop (emit their triangle), or continue recursing.
---
I actually do this as part of the render (I grow the tree again every frame) since that seems like it could be cool, but it rquires a repeatabe random number stream common to all tetrahedrons of the tree. Right now I am just passing in an array of 1024 random bits which I then consume as part of the recursion. I also limit the recursion depth, but even so, I am likely to reuse some of the same random bits for a close tree.
ANYWAY, it seems like it should be able to make interesting forms of a roughly dendritic nature...
But, of course, this is an ALIEN tree on an ALIEN world, so.... the more unique the biodome can be on every planet the better.
Though I guess that's two different random streams. Something for 'the world' that is true for all trees, plus the unique per tree 'character' of the individual decisions.
the world stuff may just have to be the material/colors and the general aspect ratio and size. But the 'radius' function here is wide open and could have all sorts of specializations (classic tree branches being an important one)
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
This 'million entry table' has me a little excited. (And it can be smaller, as needed by the starmap)
To break up the text in what promises to be a long blabber, I will paste in random screenshots that don't relate in particular :-)
In most ways it's just a pre-computed table of random values, but:
* it's synched for all players (by a seed value distributed via the starmap)
* It's evenly distributed over the entire game map
* I have 'some obvious' meta data (also largely determined randomly) for each 'object' in the table.
* the game engine only knows object's by their id numbers, and some properties set by the starmap, bound to each id.
* the properties determine what the engine should do for each id, with regards to interactions with it, can it be harvested?, what resource does it yield? Do you collide with it? Can you walk on it? Can it be moved? (temporary animation that returns to original location?) Does it stand in for a critter? Any sort of critter? Only one antagonistic one? And, what message to send the script when something happens? (took damage, was destroyed, etc).
damage (applied by engine, reported to lua, debited by lua, lua commands removal upon destruction, engine removes object until told to restore it)
lua decides when enough damage has occurred, or to recharge the hit points. maybe the engine never sees the hit points. Plan for a situation where the engine knows nothing about hit points, but knows what message to send to lua when object N of type ID has been interacted with by tool T at the command of player P.
lua then reminds itself what that ID is, and if it's a tree, then looks up the damage points from a lua table, applies it to a lua table of hitpoints (only for active objects that have hitpoints), and decides when the tree has been chopped.
lua then sends messages as needed to inform anyone else that cares, that this object has been chopped, and everyone animates it falling into a pile of lumber, and then being collected into the player's inventory.
Or maybe it just lies on the ground until someone wants to pick it up. Maybe trees die a natural death sometimes, when no one is around (forest fires from lightning)
When you walk around, you are always inside of one terrain cell (and I can easily find adjacent cells) so I have easy access to the meta data for all nearby objects, without having to scan the million entry table from top to bottom.
So, the meta data tells me for each tree, whether it was chopped down and harvested. That informs what I render (nothing, pile, or tree), and if the tree is naturally reoccurring, a time stamp of when it was re-seeded.
Alternately, if I cast some tree seed about, I can scan for all 'dead tree slots' in the nearby object data and consider turning one into a seedling, that grows over time into a full tree (maybe can't be harvested until full grown)
For fauna, the starmap can tell me "object id 35 is a standin for a critter, referred to as critter C within this starmap, and a separate lua table knows the configuration data for each critter populated in this way.
These assets from lua, do need to pass into the engine at some point (and be distributed between players). In addition to the existing asset distribution system, I want to provide this support for 'not quite assets' that are defined in the starmap itself and might not have formal asset ids
(but the starmap itself DOES have an asset id, which is crc checked to ensure all players have the same starmap (well, highly encourage, and then I will eventually have to have tools that let you self select the people you're willing to play with. sigh. I just have to avoid incentivizing negative behaviour.
To that end, let's call this form 'data' and note we need an API for setting game engine data from strings provided from lua.
game.setData( dataId, configurationString )
The game engine could have some default data pre-installed (like the cessna overcoat), but the starmap could overwrite it with this api call, or define new ones.
The dataId would be managed by the starmap, and the engine would probably provide a limited range of number values.... data 1 to 1000, say. And the map would decide which ones were AEROs, FACEs, SHELLs, CRITTERS, etc. And that assignment could vary from map to map, though obviously I would try to build in some standard support for the most popular.. um.. paradigms?
lua would define object properties via the setTweaks command, I think. Again, with a base number, say '200' defining a range of tweaks associated with 'objects' So
game.setTweaks(200=47, 201=prop1,prop2,prop3,...)
Where "200=47" selects object 47 (of 1 million) as the current object, that will be affected by subsequent tweaks.
"201=prop1" sets the first object property to the value you like (a number)
If you don't provide the "20x=" and just add commas, you can assign properties 'in order' from the last one you called out. I like that part.
So one line of text like that would be sent from the script to the game engine, at time of script load, for each 'object id' that was to exist. Possibly overwriting a few default ids set up by the game engine to support lazy scriptwriters (me)
obviously, I should support strings inside of tweak values, I just balk at having to handle missing quotes or other syntax flaws. But I guess if I just reject a poorly formed string, I don't have to auto-fix it, just draw the author's attention to it.
These objects need a 'probabiity' assigned to them.. either "there is a P percent change of any given object being one of these" or maybe "there are only P of these in world"
So, when the map loads, and I get the new terrain fractal seed (from lua) and build the island, and populate the million object table (million virtual objects), when it comes time to set the id value for each object (including the value 0 which should mean 'unused' but maybe it still causes a little ground texture at the location), it rolls a die of the number of sides set by P, as it were, and thus are objects populated
More script hints are needed for things like "the probability of one of these occurring is also contingent upon the altitude, temperature, wetness, and surrounding objects (I am in the shadow of a big tree?), and I guess those should be also set in the per-object setTweaks call.
Then, when you are walking around, it considers all the nearby object, um nodes, gets their ID and meta data and renders something. If it's a critter spawn point, I guess it could statically render a critter skeleton at that point (seen from a distance, but not an actual animated critter yet), but I remember which of these critter objects has been seen recently, and can decide to spawn an actual critter at that location (and maybe I rendered nothing before then, or a gopher hole or something)
That critter then keeps track of each time it is rendered, and if it ever goes more than a minute of not being rendered, it updates its own meta data for any memory it wants to retain, and then suicides (um, returns to dataspace after backing itself up)
But if I walk through the woods, and pick up a pack of critters along the way, that follow me, and remain visible, I could have a swarm of critters around me.
The starmap would have to provide some basic critter facts as well (in the metadata for the id) like 'predator or prey', 'pheremone info', 'fearfulness' 'rpg stats', etc.
And some of that is used knowingly by the game engine (the pheremones, for example) and some of it is just regurgitated later back to the script in some message to help the script remember what was being talked about.
Always with the goal of leaving the 'story' inside of Lua. Only lua needs to know that I picked up the Everlasting Gobstocker of Destiny, or that it is the only weapon capable of destroying the big boss, but the game knows (via metadata) to send the message 'gob' whenever that weapon is used by the player.
as needed, the message may be forwarded to the moderator who has final determination of move-legality (but local script should also check things)
For the gobstocker... I would have one or more of these in inventory, and one equipped,
I would be on planet, near some opponent, and I have 'clicked on them' to set them as my target and my 'gob' button is glowing in anticipation.
I tap 'gob' and the game engine knows to automatically dim it and start a recharge (recharge time from id metavalue) before I can use it again.
Meanwhile, the 'gob' message is sent to local script, which probably decides immediately what the outcome should be (maybe the game engine even suggests something as part of the message), but all players should get this message and start the 'gob' animation if they are close enough to care.
If it's a fail/miss/dud one copy of the game should decide this and send a message to all about it. (I'm thinking each critter has a 'host' player, which is known to all players, and anyone can send a message on behalf of a critter, but it is only obeyed by copies of the game that agree that message came from the host.) So the host player (possibly the moderator, but maybe the player that caused the critter to spawn) decides if the attack was successful or not, and what 'rpg changes' (hit points, experience) need to adjust as a result.
In theory, this allows lua to control each attack in a battle, with the game engine never deciding how many hit points or what buffs/debuffs are pending
and I know WoS world developers were always asking for more control over battle dynamics.
So, if I 'gob on a critter', I send the gob message to all players, but only the host player responds with the results, all other players accept this because it is from the critter's host, known to all.
the response message is sent to all immediately (within a moment of you 'casting the spell') and contains info about whether it failed, or how much damage, etc.) and whether the critter was destroyed as a result (hit point counts known only to lua, and official only on the host machine)
players receiving the result message decode it and create several game api calls to run animations and emit text "Samsyn sends the throatwobbler back to its home planet on the gobstocker" without needing to understand why. The result message might also describe any loot drops, but there would still need to be a loot message sent from the winner to claim the loot (and make it disappear from all players) if it's that kind of loot.
but again, this could now vary with the starmap and not be a large system mandated by the engine, just limited by the things the engine knows how to do.
For what you see, I hope to provide some sort of 'fractal flora' generator that defines some number of base 3D shapes you can bind to your object properties (all object id 47s use THIS model, but can vary its size within THIS range randomly, and randomly pick from THIS color set)
But eventually I will support simple skins (technically I already do!) and probably use the setDATA api for the starmap to declare some number of skins right inside the map, to be used on objects as needed. With their being code numbers for any geometric primitives (cube, sphere, etc) I provide, as well as custom stuff like the 'fractal gnarled tree trunk' code)
But simple. really simple.
-- But right now, I am just trying to learn what feels appealing in a size/distribution sense. A tradeoff between too sparse (one tree every square mile) and too dense (can't see your opponent for all the trees in the way),
with some solutions being 'clearings' (applied by fractal lumberjacks during the world creation), and 'canopies' (still vaporware, but some form of auto-generated geometry to imply lush forests in the distance, informed by the actual million object table, but just once at world creation).
Maybe a high rez image for each terrain square, which are then composited in real time into an amalgam that covers multiple terrain squares in a single triangle. Again, still vaporware.
I think I also need to lean towards 'wide things are below and above eye height, but only skinny things predominate at eye height. maybe. so trees with wide bases and full canopies, but skinny trunks once you get to eye level (typical camera) and probably some 'make this object invisible when close to camera, or between camera and target'
but I hate that sort of coding (adds player restrictions, is usually CPU expensive, and provides little pleasure, even when it works correctly)
posted
Now that I blabber everywhere, it's even harder to remember what I have already blabbered about.
v1.08 no longer works on most phones, so I need to push 1.09 asap to have a working version in the store(s).
So I had to relearn how to make a signed release build (it's been over a year, and the process has changed ever so little that I have to completely re-learn how)
And now I am just trying to fix the biggest 1.09 bugs so as not to release something actually buggier than the previous version (which isn't buggy at all, per se, but needs to get on board with the new android permissions scheme)
Plus we had an earthquake (4.2 with epicenter about 10 miles from here). I assume that was somehoe related to aftershocks in Indonesia
So the first big bug I fixed was the 'often, when looking straight down, the screen turns black'
I knew roughly what was happening. Somewhere a 'divide by zero' was leaving some values set to "NaN" (not a number), and then if you don't check for that (and there is no exception for it since it is 'ok' in floats). And once you have a NaN, if you multiply or add it with any other number, the result is also a NaN, so I call it the "NaN Virus" which rapidly corrupts all your computations and eventually affects something that draws your attention.
In my case, that's the black screen.
Add to that the fact that the debugger often won't even hit break points, let alone do any profiling, but I have put together a handful of superstitions and now at least I get breakpoints half of the time.
ANYWAY, so working backwards from the 'first NaN seen' I was ultimately able to point the finger at
Matrix.setLookAt()
Yay, not my code! not my code! I do NOT check for a NaN result, as rule, but I DO check for zero before dividing, so I didn't want this to be my fault.
But it's still my fault. setLookAt builds a 4x4 view/projection matrix for you (the transform that defines your '3D camera' which allows you to view your simulated 3D world.).
It builds this matrix based on numbers you provide. You give: the XYZ of where the camera is, the XYZ of a point the camera is looking at (center of the screen), and a vector pointing 'up' which basically sets the camera 'ROLL' value (and in my case, I never let the camera roll)
So, I was lazy and just gave (0,0,1) (z axis is straight up in my world) and that worked fine.
Unless, you looked straight down. At that point, the FORWARD vector is straight down, and the UP vector is still straight up, so they are in line with each other (colinear) and setLookup gets a zero at some point of computing a couple cross products and doesn't throw any exceptions or return a boolean, it just sets some values in the array to NaN, and if you don't check all 16 entries for that, you might be screwed.
But we're not mindless children! We know exactly what circumstances will lead to this problem and w can easily avoid it.
In fact, since it is going to derive the full vector basis anyway, we only need an approximation of UP, but it should be 'camera UP' not 'world UP'
If you aim your camera straight down, then 'UP' is no longer to the sky, it is 'in front of you if you weren't bent over looking down at your camera'
Since in synSpace, the only waY that can happen is via the player-controlled 'camera pitch', I can know exactly when this happens, and could just snap to a 'more horizontal' UP when pitch was > 45 degrees.
To get that horizontal up, however, I could need the sine and cosine of the camera 'heading' (itself a bit of an unknown when pointing straight down). But in my case, heading and pitch are known exactly, and forced into a restricted range even, so 'horizontal up' is just
(X,Y,Z) = (sin(hdg), cos(hdg), 0)
And that would be good enough since setLookAt will do a cross product to get the real up vector.
but since I already had the pitch and heading sines and cosines, I can get a 'correct' up from
again, I wouldn't do that if I had to Math.sin() every time!
I just update the values when the player actually steers the camera. (or the camera changes). Though sin() and cos() are not as slow as they used to be.
ANYWAY, once I gave it a horizontal-friendly up vector, the symptom immediately disappeared and I can look down all I like.
--
so then I could release it, right?
Well, no, then I noticed the 'belt inventory' buttons were flashing oddly, and not playing their four stage animation.
Looking into that found something dumb which I might have done elsewhere in my life. Starting with a 64 bit unsigned long measuring 'milliseconds since 1970 or so', I divide it by 250, to get a number that changes every quarter of a second. Then I modulus that number with 4 because that's how many frames of animation I have, and that should leave me with 0,1,2, or 3, which I can then use an as image number.
And that has worked for literally years (not new code), but now it was broken. I assumed by some change I made, but ultimately I was able to rule that out, and I had just done something stupid
int imageIndex = ((int)(msec/250))%4;
when I meant to do
int imageIndex = (int)((msec/250)%4);
and the value of 'msec' just gets bigger every millisecond and apparently has only recently increased to a value large enough that msec/250 is larger than can be held in an int, and I end up doing the modulus on a negative value, and the code has no image for a negative image index. ooops!
So I'm glad I caught that, and looked for other instances, but that seemed to be the only place (powerup images)
--
so THEN I could ship it, right?
Well, I have learned from past experience that if you push a release with known bugs, people will find those bugs and report them and then not report any other bugs, so you have to reply with "yeah, I already knew about that one, and even wrote about it in the release notes" but that is such a lame answer and you end up spending much more time documenting the bug than fixing it. Better to fix it.
So now I am just sanding off the roughest edges and wondering if maybe I will add just a little code to the tutorial map, just so you get a particular synchronized planet. Should you experimentally try to land.
And while I am at it, why would I push a version with the oldest bug in the world (animation system glues feet to ground and they can stretch for miles behind you as you walk).
And why does the cessna overcoat drift uphill, into the wind sometimes?
And shouldn't I try to make at least a couple official flora object 'models'?
And why isn't rain happening? Isn't the planet overheating? And why aren't the climate tweaks available to lua yet?
I literally have 30 pages of one-line 'things that need to be done' for what I envisioned as 1.09, and now I guess that's my vision for 1.10 and I need a quick vision for 1.09 other than 'bugfix'
And I would LIKE to have a working 'harvest mechanic' for harvesting flora objects, and a working inventory system to hold your spoils, and working map-storage to remember your inventory (for that specific map, all instances thereof)
so that won't happen, but it would be good to have specific objects for tree, bush, grass, rock, hut, factory, castle, etc.
OK, so, say I just had these primitives (cube, sphere, dome, vcylinder, and cone), but there was to create a 'set' made of these primitives placed nearby each other. So a box with four corner cylinders might be 'a castle'... with a 'stone' texture.
And some way up in lua to build these strings of numbers to describe each 'setpiece' and then other numbers to define 'sets' and then drop/pickup entire sets as needed. blow sets up... restore to default, etc.
or build the sets in world graphically, and then export the numbers to map instance data.
Well, none of that will happen for 1.09 either.
though having said "map data" and "map instance data" near each other, maybe those are good names.
"map data" represents what you have done on that map, from all the instances you have played it. So this would include most RPG elements like your max hit points, your character level (on this map), etc. This would include your wallet (local map currency), and inventory (the 256 stacks of things available on this starmap)
"map instance data" represents stuff about a particular instance of this starmap (including the starting instance data from the starmap itself, then modified by instance data for 'changes to that, since the instance started, up until the moment you saved the instance data to a file' It includes 'what buildings have been built, what trees have been cut, since this instance started. It does NOT include inventory or wallet.
I think each starmap has its own currency (with its own name) and can thus have complete control over that economy and can give/take that currency with abandon.
But the global currency (galactic credits) is earned at soem rate which is not controlled by the starmap, and cannot be taken from you by the starmap, but the starmap CAN offer things for sale in GC, and the player can decide whether or not that's worth doing.
"player storage" also exists, that transcends all starmaps. So it doesn't have any RPG in it per se, but it does have your GC balance and your grid-space stats (like #winsLosses)
The 'quest tokens' however, are 'map data' (not 'map instance data') so returning to the map in a new instance let's you resume your RPG stats where you left off.
So when I join a running instance, I get:
* my GC balance from 'player storage' * my quest tokens from 'map data' * my map currency from 'map data' * my map inventory from 'map data' * my RPG stats from 'map data' * the starting map instance data from the starmap * the list of world changes from 'map instance data' (via the moderator)
'map data' and 'player data' get stored automatically, but 'map instance data' (from the moderator, in general) can be manually saved to a local file, by any player, at any time, so they can resume this map in a new instance with these world changes, but with the 'current' map and player data (so credits spent in an instance are gone when you start a new instance, but credits NOT spent are still there.)
Yes, I think that's the clearest explanation of that yet.
I think the 'map data' (incl RPG values) hs to come FROM lua. so lua needs to maintain a full understanding of each player's RPG stats (and lus should share that as needed with other players, without the game engine needing to know about it)
Some things the engine will need to be told, and it will be Lua's responsibility to inform it. But as little as possible.
For example, if I want to cast a spell on another critter:
* via the UI I select my target critter, and click the appropriate attack button
* that tells lua "player casts SPELL on critter N"
* local lua then sanity checks the request, fetching detals about player, spell, and critter
* local lua decides if the spell will fail or not (maybe) and sends a fizzle or a casting message back to the engine (telling the engine which critter animates to play for a failed spell, or to start waving its hands for a spell that will work)
* maybe each request has to go to the moderator for approval, but probably not, individual fight actions can probably just be announced globally (local lua forwards original messaghe 'player cast spell on critter' and adds 'and it worked') so they can all start animating stuff as well, if it is visible to them.
* either local lua or moderator decides what the final result is and sends a message to all so they can animate the result, and update their copy of game state (critter now has 23 HP left)
* each critter has a 'host' and it is the host's job to decide when a critter has been destroyed. And then to announce that to all players and hand out loot.
probably not in 1.09 either :-)
--
The thing I was trying to get to was 'performance on Samsung is particularly sucky' and it would be great to do something about that.
I finally got the profiler to work (by reducing the size of my million entry table!) and was able to see that yes, Math.random() is horribly slow on the Samsung, as was Canvas.drawRect()
I think this also relates to device screen resolution. I limit the resolution of the 3D world (even added a NERD option for that), but grid-space is done at the full resolution of the device and there was a starting full screen drawRect (with alpha) that was burning about 50ms on the samsung. So I just got rid of it. grid space bleeds through a bit more than I'd like (like through the ocean....) but I can worry about that later.
Just doing that brought me from 6 fps to 10 fps, sort of. I've replaced ALL the calls to Math.random() with ThreadLocalRandom.current() which is much faster and works for me. Then I wrote a separate RNG for sequences I needed to be repeatable.
still very slow. maybe because of a high rez screen. maybe because of paranoid thread locking. But with profiler working, I can at least approach it deterministically!
ANYWAY, no excuse to hold on to 1.09 longer than One More Weekend.
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
Player Data (all maps, all instances) saved only on player machine GC balance win/loss chess rating
Map Data (per map, all instances ) quest tokens map item inventory
Instance Data (per map, per instance) game rules and state baked in assets (FACEs CRITTERs..) world modifications since instance start can be saved by CLONING starmap 'with current instance data'
So, this removes the concept of 'saving instance data to a file' with 'clone the current starmap, but include the current instance data as the starting data for the map.
So rather than creating a new kind of asset file, iot would just inject some lines into the lua source... assignments like:
Then, if you started a new server session with that modified (cloned) starmap, it would start with THAT instance data instead (or some blend of the two maybe, like load all the original, and then load all the overrides)
I think that would make it slightly simpler to parse, and also be more securely stored in a database instead of a zillion files you have to micromanage.
Also, it's probably how you would develop the starmap in the first place (decorate 'in game' and then clone for publication)
Note that I would still need a button somewhere for 'save the current starmap to an actual file' for people who want to edit the actual script, and maybe even a way to import a starmap without disturbing your current instance data. (to pick up script changes without altering current assets baked into the map)
--
Getting closer.. it's just a big win to have simple names for these. Player and Map data are already covered, so I just need to clean up the details on instance data, which I think boil down to 'numbered strings' of 'engine-opaque' data, that only lua really knows what it is.
I need to, at map load time, inject the appropriate set of instance data strings, and then distribute them (moderator control) as they change during the game. Only Lua knows what each string is for, but the data payload is probably in a form the engine can at least partially decode. (the engine wants to keep a copy of the strings that it can access at 'clone' time, and which just remember the last setting that came from lua, or any manual editors involved)
So, I am thinking, the starmap designer thinks "Ok, let string 1 define the current planet, and let string 2 define a critter skeleton"
Then whenever the planet changed (new fractal, say) lua would craft a new 'string' (which would probably just be a 'setTweaks' command) and store it in its master copy of the table (in lua memory) and then call into the engine
game.setInstanceString(1, "the string")
so the engine would have a copy, and then send it to other players (from moderator to other players, I mean)
game.sendMessage(all, instance, 1, "the string" )
Each player receiving such a message would then
* validate it (from the mod, legal) * store it in its own copy (lua table of strings) * pass it to its own engine (engine copy of strings) * "effectuate the change"
That last bit requires lua to know what string 1 was all about (setTweaks for planet), and then to invoke the specific game engine commands to apply that instance data (usually just a setTweaks command that takes the data text straight in)
But other than effectuate, I think lua can pretty much just have a single handler to distribute and cache these instance strings. And the engine is kept up to date so if can do a sensible CLONE WITH DATA command.
posted
Well, still not released, sorry. I made some progress over the weekend, but found a few more bugs that would taint the release (the stick figure animator is broken at the moment)
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
Well, I suspect I have removed enough bugs, but now I am left with a hollow feeling that there is no fun added.
It would pay the biggest dividends if I fleshed out the tweak values available to lua to set. Then 'fun' could be added via script. As it stands, if I do make a nice script, I will also have to release a new app that supports it, though I guess that's probably inevitable for awhile.
Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
whew, all released and working on all my devices, so fingers crossed. it's not clear if it updates itself or if you have to re-visit the store and select UPDATE.
And let's see if I can channel my blabbering correctly. in 'meet synspace', it is 'free blabber', but in 'v x.y release notes' it should mostly document specific developments, if any :-)
---
So, random free blabber about the 'game' on this new starmap. (Currently called "Utopia" and the bottom line is there is a planet, you can land on it, your goal is to terraform it in some ways, so as to make it pleasant for a particular set of critters.
But you clearly don't know what you're doing, and make many (instructive tutorially) mistakes along the way. My thought is that since you are comfortably at home on earth, holding the remote control which has connected you to a bio-synthetic critter on some planet out in our galaxy...
that perhaps you have somehow stepped into someone else's connection, and so everyone on the planet thinks you are this expert multiplanetary terraforming wizard contractor, and are paying you to do this.
but really, ... I don't know if another backstory makes me happy or not, but it seems to be what I generate the most of :-)
But more specifically, I know I want you to be able to tweak the atmosphere, and that critters will have specific atmosphere needs.
And that a large claim dome will manufacture the right kind of atmosphere, and 'leak' it out into the existing atmosphere, and change it.
And that the change is a color-mixing game (you know I love those) where the three primary colors (RGB) map to three gasses that sound reasonable, like oxygen (for mammals), co2 (for plants), and methane (for alien stuff)
blue has to be 'oxygen' (or whatever the mammal friendly gas is, might be Hydrogen?)
green feels more stinky to me (methane), but it's also the color of chlorophyl. I guess the client who has ordered the dome could call it chlorophyl, but it would still just be the green one' from the engine's point of view. Anyway, star map defines the three fun gas names, as needed.
But the engine (climate system) tracks changes in a set of counters (tweak values that are initially set by the starmap instance data, and hence changes persist with the instance)
Right now I just have a subset of these, but I think I am heading towards
The starmap then sets these initially to whatever. I'm not sure if I need an inert gas or not, but I think it's convenient if 'pressure' is a function of just the inert gas, and that the colored gasses are always in much smaller amounts, but are biologically important all the same. So the amount of inert gas is a measure of how much atmo there is over all. So if the planet is a rocky asteroid, it should start with zero, and the sky should just be the black of space.
The starmap recomputes the sky color, based on changes to the gas amounts.
The starmap has a list of all the claim bubbles (instance data) out and about, and their current production rates. It runs a simulation (once a second or two) that works out the new RGB values and sets a tweak or two in the engine that actually controls how the sky renders (factoring in the current time of day and sun position)
I guess there should be devices you can obtain/craft to remove specific gasses as well. Though CO2 should be removed by helping the botanicals on the planet (maybe by improving hydration somehow... fertilizing.)
Or right, critter poop! Doesn't have to be graphic. I already have the engine spawn blades of grass wherever critters walk (still thinking about pathfinding and 'animal trails' and 'dirt paths' and 'paved roads' stuff. Some sort of spline-y thing driven from control points and automatically returning modified terrain elevation values and materials so nearby road is tesselated to small triangles and each triangle is then rendered entirely from either the ground texture or the road texture (but sadly, not a blend of both).
So yes, I should be formally tracking the 'nitrogen content' of each terrain cell and plants and animals interact with the dirt, and then let that influence crop production, and that then influences atmosphere gas distributions.
Big floral bloom burns all the CO2 and releases a bunch of O2 (and C in inventory from the harvested flora), and then all the plants die from lack of CO2, leaving more carbon around.
Eventually someone lights a match and the carbon and oxygen get back together, the CO2 skyrockets again, and the plants bloom again.
Only each time, the flora and fauna grow back a little differently. A little more tolerantly, maybe.
If the flora and fauna exhibit actual behaviors, then the cycle might reward some behaviours over others, leading to population dominance (game score)
Plus, you can always breed better critters, and hunt the less desirable ones. Everything is a bio synthetic, and is backed up in dataspace, so nothing really ever dies. This is also my explanation for the art flaw that the skeleton critters are always drawn on a layer above the 3D render, so they can never go 'behind' walls, trees, mountains, etc. But the REASON for that is that a bio-synthetic is BIO (has bones), but they are SYNTHETIC (and have a plasma glow that your display always shows, no matter what mass is between you.)
So if someday, some parts of the critter get an actual skin (like maybe a cylindrical head, with your current FACE icon rendered 'on the front'), then the triangles of that head WOULD disappear 'behind walls', but the skeleton bones would still be visible. It would be a game thing. "Look, this is the game with the glowing x-ray bones!"
and then I can say I did it on purpose. Actually, I *have* several half-baked solutions for the glowing bones, if I absolutely have to behave like a real object. I just assume they are more expensive than the lines, and actually 'less expressive' And if the lines are thick enough, whose to say they aren't thick 3D bones? (that are just glowy). Who is to say? It is impossible to know.
ANYWAY, each critter will have a 'perfect gas formula' for what it likes, and any differences from that lead to some discomfort and inefficiency in the critter's BIO values (some RPG stuff) ultimately affecting agility etc.
I think each critter remembers where it was born and assumes the air is good there, and will try to return to home if they can't get what they need from the atmo.
the claim dome should then also be a biosynth cloning factory where you have a cool genetic control panel and 'craft' critters with specific characteristics (maybe you are given one critter as a template and use the genetics machine to 'breed' it with local fauna, until you find a combination that thrives. That sounds game ish
Also, this would explain the lack of sex, since you just scan the living creatures and then use the computer to sequence something out of raw materials you have assembled.
But maybe you would implant in a real critter, so they could have babies in world. But mainly the babies would be something the starmap script would be simulating (game score)
At some point, I suppose a skeleton could be derived algorithmically, melding from the parents in some satisfyig way that you can somewhat predict (other than mutations.. have to have mutations)..
OK, so clearly I need to think up a fun control panel for the genetics mini-game. Then maybe you fly around and implant a bunch of local critters, using some sort of critter radar tuned to their pheremone signature.
* should show two critter genomes at once * let you see where they line up * let you slid things around until they line up better * they might never line up (can't have a baby) * they might line up in an imperfect way, but then the next generation can be lined up better (maybe) * You can 'save' any experimental genome you like * You can inject any genome into a captured host critter, and then track it in the field until it is born.....
no, the ones you make are born in a claim dome.
the starmap then tracks 'total critters of genome X' and just assumes they will breed in captivity inside the dome (OK, some sort of sex glyph to let you know conceptions are happening) a "+1" floating up into the air...
But just because you have caused the creation of a new species that now has millions of individuals, doesn't mean you actually see a million critters around. The million is just a number the starmap shares as your score.
But it is associated with the claim dome (which is also making food, which is also spreading outwards from the dome in some way, converting local flora to this new flora.
I think these are actually engine components (spread of atmosphere and food) with the starmap converting a small number of engine values into a fun text description of what's going on.
But the pheremones need to blend with this system, and BE the genome, determine predator vs prey, animal vs vegetable, organic vs mineral, preferredAtmoColor, poisonColor, foodColor, bodyShape, bodyScale
And I am determined that it all be shoved into a single unsigned 64 bit long, and that I call it a pheremone, no matter what it really is.
Some number of bits are reserved for the individual, but most bits are common to all critters of the same species.
THEN, I want a VQ brain (one per species, I think) that 'learns' from pheremones left behind. So if a wolf eats a bunny (so to speak), that sends out a signal in the form of a pheremone, which I probably something like "the pheremone of the wolf, the pheremone of the bunny, some bits that indicate what happened --- though I am tempted to say 'some bits of the pheremone can only be 'smelled' if the critter has been 'opened' (so to speak), so if I can smell the bunny's inside pheremones, then I know it was an unhappy ending for the bunny, and either that makes me hungry for a bunny, or afraid of a wolf, depending on what kind of pheremones I am made of. (I am also a predator that enjoys the smell of blood)(I am also a prey that enjoys the smell of hay)
(the flora objects would then also have their own sorts of pheremones, and their own BIO simulations that also affect the atmo (and this is again computed periodically by the starmap, based on its understanding of the plant health and distribution. Probably the engine sends a periodic flora updatw "there are 1234 trees" so the starmap doesn't have to know the state of each individual tree
I get pulled back and forth on that. There ARE things being simulated that are in the thousands, and those have to be done by the engine to make sense (they get rendered).
And the starmap has to know the simulation values to do its score computations and game over detection and such. But hopefully it doesnt have to know all the details, just info about the event that just happened. Let the engine provde its value, believe it or not based on game state, and advance the score engine appropriately (involving the moderator where needed, and dstributing the fin result (new sky color)
In specific, I walk up to a tree and decide to chop it down:
* the starmap provided hints that resulted in this tree being here, and that it supports the 'choppable' property (this was computed once at map load)
* the engine sees me get close to a choppable object, and presents a CHOP button, and the message that button should send, when pressed
* I press the CHOP button when I feel like it. U just send the message I was asked to send. But I append to that some details about the object I am chopping (floraId, height, color, etc), and I start an animation which triggers some sound effects and chopping begins.
* local script catches the message, grabs the details and has another chance to consider whether this should be allowed, but assuming it is, it just sends a message back to the engine "tree X has been chopped by player Y resulting in resource Z being added to inventory"
* maybe this is forwarded to all players, if they are sharing this resource (so they all see that tree disappear, but otherwise could still have their own copy of the tree, waiting for THEM to chop it down)
* engine receives the message, and changes the animations and such to the successful chopping and updates local inventory. tree disappears in a shower of wood and leave (brown and green triangles)
* button stays in cooldown until recharged (and also disappears if no nearby choppable objects remain)
Now, does the script have to know my inventory? I mean, the script defines all possible invenoty items (itemId) and I have a inventory stack for each of those, and the engine has to know how many I own (as a number in that stack slot)
The script needs to know, if it wants to check if it is legal for me to do something "you need 32 more sugar crystals to make that bottle of wine"
But if the script pre-registers all crafting recipes with the engine, then the engine could pre-check (based on numeric itemId, since the engine doesnt KNOW what an item is)
Then, the button that means "make me a cessna overcoat" just sends a message to the script that appends my inventory counts, just for the ingredients mentioned in the recipe for a cessna overcoat.
And if the script feels those counts are good enough, it sends a message back to the engine "Make that overcoat!" and the engine decrements the local inventory (which WILL be saved in the persistent map data for this map -- not the instance data), and starts whatever timer is needed, and places the construction request in the manufacturing queue.
Probably each building (claim dome to start with) has its own manufacturing queue (and maybe this is where reciples are stored... I mean, maybe the script predefines all possible 'units' and those which can make stuff have their recipes declared at that time. Then each instance of that unit has a manfacturing queue that can make a certain set of items at a particular rate.
for a realtime strategy game (Command and Conquer, Empyrion!)
But to start with, let my portable nano factory do all the manufacturing. Which means, at the time I tell "Ping" ("Nano"? "Pin"?) to make something, I need to also indicate 'where it should go' (so a building would just grow up at that spot, and the spot would have to be prevalidated to obey rules of overlapping and suitable foundation terrain...)
But yeah, I walk to where I want the building, I dial up the recipe on Ping, he says it needs a spot so and so big and highlights where he would place it. If I walk around, that highlight walks around with me, until I push the button, then the above message exchange takes place and the building eventually appears.
Yeah, something like that. I guess it would be easy enough to just render the building 'as if it were there' to fully preview it, and use free camera. Have to worry about 'drop to ground' 'float' or 'explicitly set altitude/heading/tilt'
Same mechanism in "super fun time power show" to let you pre-decorate a planet and get it into the map instance data.
OK, enough blabber for now, thank you!
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
Hmm, if I have one VQ brain per species (instead of per critter), i think that makes the data manageable and results in critters with similar behaviours, which is probably useful if they are to become the 'battle units'
But then I don't have to be subtle about the pheremones. If a wolf eats a bunny, that very bunny can add one more engram to the collective brain on its way out, thus immediately informing all bunnies everywhere to avoid wolf pheremones.
Then, I can still use lingering pheremoones registered to terrain cells, so that other bunnies, fearing that pheremone, can avoid it if they sense it in a nearby terrain cell (and can go the other direction). So the immediate engram teaches the new fear of 'what', but doesn't tell you 'where', and that's left up to lingering smells left behind when any critter passes through a terrain cell.
So that could get fancy (list of the N most recent smells, that fade over time), or just simple (pheremone of the most recent critter in the cell)
So a 'learning event' (defined as adding an engram to the VQ) can just be applied by the engine for specific cases when they happen: "got hurt, got fed,.." so it knows which VQ table to add it to (the scary list, the friendly list, the delicious list, etc.) since a VQ brain is actually several brains, each answering one question (like: should I approach or flee or ignore this pheremone)
And I guess the delicious table would have to start empty and each species would test eat what it finds, and update the hive mind when poisoned or sated. (and plants also have pheremones in this system). Once it had some experience, it could play safe, or still be willing to try new things, while avoiding known-to-have-killed-others things.
I bet you could have a pretty interesting set of interactions with very few rules.
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
* critter eats some plant, his BIO remembers it * as he walks around, he periodically drops an invisible little poop/seed combo that immediately starts growing. * it is the seed of the last thing the critter ate * if he lives a long time, he might drop more of these than if the first one kills him)
Hence, overtime, the plant population is converted from 'iincludes poison' to 'all the poison has been eaten and very little has been replanted, so most remaining plants are now safe'
very simple rule, indeed!
And, to be clear, the pheremone of the plant includes its major ingredients, and the pheremone of the critter includes its allergies/poisons, as well as its nutritious elements.
So the starmap populates the planet with 'red grass' which has a lot of Arsenic in its pheremone, and 'green grass' which is full of something nutritious (to this critter).
So there is no list of 'these foods are for this critter' and each critter can just match up the ingredients with its own peculiarities and we know if it is food or poison for this critter.
the first bunny has no food engrams in its hive mind, and eats the first thing it finds (red grass), starts pooping red grass seeds, but dies before doing that much. Another rabbit eats green grass and poops green seeds for an hour. And at this point the bunny hive brain has two engrams, so all bunnies can avoid red grass, and seek out green grass, but still eat yellow grass at least once.
And the way the engrams work, they will still poison themselves with red grass now and then, but the engrams will get strengthened as a result and eventually all bunnies will run from red grass. (or leave it alone).
Plus there will be evidence of bunny 'game trails' in the regions now seeded with green grass. (which is why I have critters plant seeds as they walk in the first place. In fact, the seed is dropped at the very poiint of their footstep and is a diagnostic for the walk animation :-)
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
getting close to implementnig the 'rpg battle system' which I hope will be a little more flexible than what I did in WoS, and give the starmap more control over everything.
To that end, the starmap must provide all names (like the name of currency, spell categories, etc) and the game engine has to know how to use 'standard attributes' no matter what they are named
So the engine will maintain my normal RPG values (level, maxHP, maxMP, STRength, WISdom, Stamina, Dexterity, AGIlity) plus some new ones like "foodColor" and "poisonColor" and "atmoColor" and "waterColor"
Then I have a new system called BIO which is more or less what was happening inside WoS Pokegatchis. Only now it is inside the critters themselves and is the main way they heal/recharge.
Food, air, and water are each made of ratios of three components (always red/green/blue) and your 'foodColor' is the 'perfect ratio of what the critter needs nutritionally. But food comes in its own colors and if you eat something with a mix of RGB, I keep track of 'total R eaten, total G eaten, etc) and 'digest it' over time, recharging your hit points
If you eat your perfect food mix, it recharges quickly, if you eat your perfect poison mix, it discharges rapidly (for the duration of the digestion, so if you eat a lot of poison, you will pass away) food and poison still work when the color is just 'close' but the further apart the colros are, the less effective.
Likewise you're trying to tune the atmosphere (or breed critters with different atmo needs) RGB and the ocean RGB as part of your terraforming goals.
ANYWAY, so RPG items are like your level-earned maximum values, while BIO items are more transient (energy in your blood, food in your belly), and change in real time and are affected by your exercise in battle since you can be 'fit' (or not).
So the starmap does the rock/paper/scissors math to set up an interesting combination of available critters ('rolling their character' as it were) for balanced gameplay, and provides names for all the critters and their starting RPG values (and only the starmap adjusts RPG values, while only the engine adjusts BIO values (I think that's a goal)).
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
And that means I should add a class "Bio" with a suitable api to provide info to the battle engine when needed. (I think the npc RPG values are just set in the same lua table that declared what 'monsters' are on this map. like
Oooh, 'clawfish' good name. Like 'crawfish' but, with a claw! Let's check google. Hmm, mostly just mis-spellings, but some people have said it on purpose as well, so I only give myself 91% originality on that.
When I was a kid, we 'fished' for 'crawdads' which were simultaneously disgusting and delicious (though the taste was probably mainly butter).
You know, is it unusual that these alien-looking creatures are spread all over? In WarPath I am always pushing the theme that the astrological symbols represent aline civilzations that have visited from those constellations, and they left behind members of their planet who have 'devolved' (or evolved, as the case may be) from the more 'humanoid' version (apex critter of their planet) we met in the past. Though maybe they came to visit while we were still apes or dinosaurs, so to speak. But crabs we eat, are ultimately from genetic material brought here sometime in the past by creatures from a star in the constellation 'Cancer'
That sort of thing.
Lately, I also am leaning towards 'pan-spermia' as a system by which one advanced society could micro-engineer molecules that can react to local conditions and express themselves as 'components of life' where conditions allow.
Then you make giant balls of these molecules and fire them off in random directions through the galaxy.
Billions of years later, some of them land on earth (and everywhere else) and find what they need to kick off an initial bit of dna, that then just struggles against current conditions and evolves into whatever can succeed, with most failing sometime along the way, thanks to the galaxy mostly being unfriendly to life (radiation mostly -- too much or too little)
Which I guess is to say, I find it PLAUSIBLE that humans could do that someday (make a molecule that turns into amino acids when in contact with salt water, say) and then design this kickass DNA string that tries all sorts of things "can I be carbon based here? No? Well, can I be silicon based? OK? can I have a nervous system here? No?, well, that sucks! bye!
I think that's how cell specialization works (my theory, don't learn science from me): each cell, starting with a more or less identical DNS sequence, 'starts from the left' and tries to be the first thing on the list. That can be suppressed if the body (local area of the body where this cell was born) already has too much of that (I fantasize that the output of one cell, is conveyed by 'the goop between cells' to nearby cells and can either stimulate or suppress the 'reading' of the dna. "too much liver poop in the area, you can't be a thumbnail cell, try something else, maybe a liver cell?"
This allows each cell to just be a machine (stuff in + energy --> stuff out) and to be in it for itself, with no external organization (no supervisor monitoring the overall construction of the body), just a bunch of cells duking it out to become various body parts, and a DNA sequence that defines all the possible parts that could be enabled or suppressed.
And communicating via 'goo' with their 'poo'
So each of your cells feels it is afloat in your ocean of goo, but molecules move fairly slowly through the viscous goo, and have to pass by all the neighboring cells along the way, so they rub up againt a lot of receptor areas and might 'fall into' a cell whose membrane is permeable to them, or bounce off of a cell that is not permeable to them (and of course, if you don't rub against the receptor, or get close enough to it, you don't get snapped to alignment by the charges on your molecule, so just because a cell would accept you, doesn't mean it will manage to eat you. This is a syetem based on zillions of molecules slidiong over things and depending on statistics to ensure enough of everthing happens to make a difference. And like any society, the cells are probably not all pulling in the same direction (be a fish! no, be a flea!) and there is some uncertainty as to how it will all pan out.
Well, I was GOING to say, that the Bio class is where I model the stomach turning food/poison into energy/hit points, and the lungs turning atmo gas into energy as well. (and mana is a flavor of energy? Or do magical creatures have a 'mana' organ that digests some pergect color (manaColor) (would be cool if having a spell cast on you 'fed' your mana organ maybe)
Well, this is what blabbering is for. So for any number (like manapoints) BIO can have a simple simulation of an 'organ' (you never see this, though I should give you a bio scanner so you can watch it in action (not gross)) that adjusts (recharges) those points.
And then have an organ for each basic RPG stat (WIS/STR/STA/DEX/AGI)
STOMACH basic energy - hit points MANA SPLEEN magical energy - mana points MUSCLES strength stuff HEART stamina stuff BRAIN wisdom stuff SKIN dexterity stuff
For example MUSCLES, perhaps, would be 'fed' by exercise, turning energy into strength, but also tracking muscle use and becoming 'tired', so the BIO simulation is tracking this and boiling it down into a couple numbers that battle can use (like your overall 'vigor' at the moment, which scales your attacks and defenses)
So I think that means that the game starts with your current stats ("my wisdom is 45 points") and then 'modifies' them with your BIO condition ('my brain organ is currently providing +10 wisdom points')
and then your brain organ is the part of you which is affected by a 'sleepiness' spell (or potion, or aspect of some food you find) and is then 'de-buffed' "You are sleepy for 30 seconds" and starts providing -20 wisdom points instead, until it wears off or you eat some potion with instant-action for brain organs.
So that can be (the BIO class) where I store the knowledge of what temporary buffs are affecting you. (and have them affect your RPG stats, which it provides on demand.) So maybe the engine stores the RPG stats in the same class, so I can just ask questions like:
wisdomPoints = critter.bio.WIS( time );
And that would take care of all possible modifications to your current RPG Wisdom points.
And wisdom points then are passed to the lua script engine. Say, I hit you with my axe (sorry, I'm so clumsy!). The game engine just knows "player X used tool Y on player Z" where x, y, and Z are the indices into the player table and tool table, which are generally set up by lua when the map first loaded, and declared all the tools available on this map, all the critters and their starting RPG values, etc.
So when I tap the button, it sends that message to lua, and lua might just turn it into a message "Dan casts Necrolean Sap Fire on Fredo", but more likely it validates that Dan has the right to do that, looks up what Necrolean Sap Fire is good against (rock paper scissors), and sends a result message to all who care "Player X attack with Y on Z is successful" and then each player knows (via script) what the result is.
Oh, and I meant to say there, that the message to lua "X hit Y with Z" also includes all the current numbers from the BIO. so the script may not have access to the BIO data directly, and the engine just works it out at the moment the button is pushed and includes it with the message
So lua can then think about it "gee, his WIS is kinda low at the moment -- maybe I don't know why, but I won't let him cast this spell right now."
So you're stuck with the concept that there IS a 'wisdom point' value, BUT: your starmap doesn't have to factor it into the battle results, and you don't HAVE to call it wisdom, but if you don't, you will have to call some api that changes the name from the default "WIS, wisdom, The ability to think, of great value to magical classes" (a code, a name, and a description, seems nice)
ANYWAY, that's not what I meant to do this weekend, and now I have burned half the weekend and done my usual nothing but blabber.
But blabbers help me. It's my... process.
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
So, I took the first steps towards unifying BIO and RPG.
BIO * tracks when you are hungry, thirsty, or gaspy * (you then eat/drink/breathe, when you can, and when it is a priority) * digestion gives you 'pep' points, which accumulate in some invisible pep bladder. * when you have a lot of pep, you have a spring in your step (literally, I hope), and perform nominally/supernominally. * your body burns pep as you walk around, fight, etc. And it also burns a small amount of pep while you are asleep (but very little) * if your pep ever gets low wnough (10% ish), you get sluggish first, and then you fall asleep (enter the sleeping state and starting the sleeping animation)
RPG: * while asleep, your RPG Hit Points (HP) charge at some rate (also influenced by your current pep, I think, but not yet). Other than 'healing' spells and consumables, sleep is the only way to recharge HP. (script can, of course, grant HP at any time) * once your HP hits your current maximum (set by script, probably changing with level), HP stops charging. * but you can't wake up until your pep is back to 50% or so, so I need your pep to also recharge, but if you're starving, I need you to well, become edible.
The way I implemented that so far is not feeling quite right, and I think the key would be:
"even while asleep, I depend on my body making a little pep (always has the goal of getting to at least 50% pep) And I guess that would be a specific rate. pepBurnedWhileAsleepForOneSecond.
* and it would be mandatory to burn that much pep, and if you didn't have enough pep, it would burn HP to get some back (at a poor exchange rate). I guess that's a little like reabsorbing your muscle mass, so maybe the 'pep bladder' is 'your muscles' That's probably a good metaphor.
ANYWAY, I just mean that BIO should slosh back and forth between HP and pep, with 'new' pep coming only from food, and some sort of 'pep from HP' when desperate.
But pep is transactional and based on points and rates of point changes per second.
ANYWAY, so now I have a herd of critters walking around, eating, and getting sleepy when I starve them. :-) Soon that will make them testy and aggressive :-)
I'm going to need some DNA soon. And I think DNA is a subset of pheremone. A pheremone 'tells a story' which might include some of DNA from two or more critters (winner and loser) plus a location code (bioLocation id), so the pheremone can drift in the air, but remember its original terrain cell. Maybe scatter N copies, and let them migrate to nearby cells, following local wind.
Then, critter DNA would just be a list of 'genes', each of which controlled some critter aspect or behaviour (personal space radius, for example)
The game engine defines the available genes, since each of those implies some game mechanic the engine is responsible for implmenting, but the DNA author (starMap? player using genetic manipulatin machine? Control panel on a Hive to modify what it is stamping out?)
I also need the concept of 'aggro'
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
* HP behaves ' as in an RPG' and your character stops being useful when HP hits 0. That would be the definition of 'death'
* HP=0 can be resurrected by spell (in theory)
* HP < x is cured by 'sleeping'
* Pep is generated via food digestion
* if pep < 10% you fall asleep until it returns to > 50%
* while asleep, HP recharges first, pep recharges second (to 50%, then you wake up)
So you wake up with 100%HP and 50% pep (after falling asleep with 10% pep)
food digestion can then boost you to about 150% pep (super human performance)
So, sleep is all you need to recharge (and spells and potions can do the same thing at the command of the starmap).
I might try to stick something in to make you a little more tired at bed time, so you sleep through the night, as it were, but maybe not.
Today's sticky wicket is: If you get beaten down to, say 10% HP, and 10% pep, and you fall asleep (in mid battle!),,, then you start recharging HP right away, but it isn't instantaneous, and if your opponent is still beating on you, you run the risk of HP=0 at which point he gets to start eating you, if so it's a teensy bit like being 'eaten alive', which is possible a bit creepy (even for stick figures)
but no eating yet, that comes next :-)
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
posted
I keep forgetting that 'tweak strings' can easily support string values as well as floating point numbers.
So I can use a normal tweak string to add, say, items to a table of 'all available items on this starmap, as defined by this starmap author'
like, if tweaks starting with "200" were 'item tweaks' then a tweak string to definr 'item #19" might look like:
code:
setTweak( "200=19, -< select slot 19 201='Starshine Megahammer', <- name 202=3, <-- item type (say 'tool') 203= some other attribute of items
So an item could have, with this system, up to 99 attributes that describe what interactions it supports, what resources it provides, its normal cost, weight, whatever. And probably the 'magic qword' sent to the script when one is invoked.
The item table (this is not your inventory, this is a list of all available items in this star system, whether you own any or not. Ideally, additional items could be added over the life of an instance, but assume not.
The engine starts up with an empty items table, with every field filled with some inoffensive default value.
Then the script, upon being loaded, gets to add/overwrite entries as needed, providing only the fields they want that differ from the defaults.
the slot number is the unique item id, and is used elsewhere, such as the inventory. Inventory is a series of small stacks of items. I posit no limits on stack size. Though I suppose I should leave that up to the starmap (item field #3 might be 'max you can own', for eacmple)
Anyway, so your starmap has a function that just initialized the entire items table, before anything else happens.
Your inventory, on the other hand, is persistent and reloaded when you picked the map/loaded the map (you have a different inventory on each starmap, other than galactic credits, which are universal)
For each bag slot, I only need to record:
itemId HowManyYouOwn timeYouCanUseAnotherOne
Pretty much that should be it, though 'which slot is it' adds the possibility of drag and drop between inventory slots.
So, if I get some gumption, and some visual clarity, I should set a weekend goal like "ability to own a cessna overcoat and invoke it from inventory on demand, and take it off later. (item field 5 might be 'what happens when you take it off, does it go back in inventory, or just evaporate?)
That would require implementing the Inventory Panel, which today does not exist. And it's been a gumption trap since I didn't want to step on the starmaps toes and do too much in the engine, but I think I am already decided that 'There is an inventory system in the engine, but the items shown are all defines by the starmap, and the engine just sends a script message when an item is invoked (you tap its button) and the script then implements what happens. (by asking the engine to perform some number of game mechanics that it knows how to do)
I have also broken my rule to have all the RPG math be done 'in the script'... While this also remains to be implemented, I now think that 'the engine offers a set of RPG equations, which are based on a series of field values with names like HP, MP, Wisdom,... and there is some baked in math (the BIO system food digestion and sleep, recover HP, for example)
So it's going to look pretty hard wired to the WoS RPG elements, but I hope its really just "you get this many numbers to remember per character, and whenever I send a message to the script, I include all the numbers.
So a battle might include:
* critter 1 pickes critter 2 as target * critter 1 pickes item 34 as weapon * critter 1 decides to hit critter 2 with item 34 sneds packet to all, announcing that fact
That packet, also includes all the numbers known (for example, the critter 1 numbers), but the critter 2 numbers are maybe not sent, bt even if they are, they might not match the numbers seen on player 2' screen... a problem to solve.. i digress
Anyway you tap on 'use item 34' and a packet goes just to your copy of the script. It decides the legality of the move and then announces it to all, but adds on the outcome "and the effect will be to damage their shield, and reduce dexterity by 10 percent for 40 seconds"
And that all happens instantly, so now all copies of the game know this move is starting, and how it will end. They then all independently animate it for a second or two, and then apply the results on their copies of the critters.
However, someone out there is the host for any given critter, and when they get the packet announcing the result, they are the only ones that can announce a binding result for 'critter was destroyed'. Everyone else just sees the critter last a long time with just a sliver of energy remaining.
So, in this case, if they agree they have been conquered, they send a packet to the local script "engine says I died" and the script just forwards that along to all players "critter N hosted by player 3 declares itself dead by spell S of critter Z and provides this much XP and treasure"
(of course the actual packets are more terse)
And then the moderator script would probably score some points on the master score sheet, and move the vanquished player back to some spawn slot.
Just filling this out..
so when I receive a 'critter says its dead' message, check the source (each player controls a unique range of critter id, say 0-99 for player 0, 100-199 for player 1, etc. Maybe 128 critters per player. (and that player would be the HOST for any of those critters that are instantiated at any given time)
In fact, when I spawn a critter (because, say, I am standing near a hive), I send a packet to the local script "I just spawned a critter, index 35, at flora location 12345, and it has an empty stomach
The local script works out any legality issues, then forwards to all players, who again check the source, and only accept actual updates from the critter's host player.
One field included is 'what planet is the new critter on' (in the case of a starmap with more than one planet), and if I am another player, and I am not visiting that planet, then I just rememver the last update I received for each critter slot and when I later land on that planet, I can choose to instantiate all that I know about that are still there, if they seem close enough to know about.
Hence... I, on planet 3, can be walking around, and get into a fight with a critter I am hosting. You, somewhere else, get told that critter index N now has a critter defined by a pretty short string ",,," (since the critter details themselves are set separately in the critters table, initialized tbye the starmap, pre-declaring all the RPG values for all known critter species on that star map.
And then you come and visit my planet, and you notice you were never told that critter died, and as you approach my position, you get close enough and spawn yout own copy (which you do NOT publically announce, since you are not the host and just have 'a copy')
But you see the critter I am interacting with.
sort of. It's likely the update packets won't have ALL the info about the critter, nor are they sent often, so the critters will walk around with their own AI and might be in completely different locations.
But you are the host, so when your copy of the critter makes a decision to do something, you announce that and I update my copy of the critter to want to do the same thing, and if the thing involves a destination, they both start waling to the same destination, and hence are briefly in the same place.
During an RPG battle, there should be packets every couple seconds, so the position error shouldn't be too irritating.
After the battle, the survivors will wander off as is their way, and position error will increase until you start a new interaction.
and if a critter wanders far enough away, then any player can despawn their copy. (but no one but the host of that critter slot could spawn something new in that slot).
So I think the table ot 'last known update' should be pretty permanent, and persist even after you despawn you copy of the critter. (and you should be able to respawn it later as the same critter)
But if the host no longer needs that critter, and despanws its copy, then it can spawn anythig it wants in that same slot, sending another 'spqwn' message to all players, who just obey it, so if they were looking at a critter in front of them, it might suddenly disappear (becoming a different critter at some other location).
But since you're not hosting that critter, you don't have the authority to have it make decisions, so if you needed the feeling that that same critter suddenly attacks you, you might react to a 'host is terminating this critter slot' message by making a copy of the critter and hosting it in one of your own slots (and announcing that), so it would actually be a different critter. re-host it, basically.
I guess I could interact with an orphaned (host moved on) critter with the engine just running the AI, but without the ability to every mark it 'vanquished' since that determination must come from the host.
But yeah, in the extrem case where a host player leaves the game, it might be nice if the orphaned critters just used their critter AI to mill about until that player returned. Or someone else picked 'the blue thumb' in my absence, in which case probably the moderator player would have to send them all the latest update packets... hmm.. from all players, I guess, but specifically from moderator copies of orphans.
Or, orphans could all disappear the moment their host left.
Hmmmm
Well, that's enough babbling.
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
so.... the dust is still settling on the flora collision system, including the method by which the starmap creates floraIds.
There are 1024 available floraIds (per map/starmap), shared by all planets on the map (if there is ever a multiplanet map)
to be a 'flora' you pretty much just have to be 'mostly stationary' and most of the imagery comes from the name you give it, so these are all 'flora'
"pile of leaves" "oak tree" "copper vein" "mosquito pool" "bird swarm epicenter" "bugs" (that crawl around a fixed area) "hives" (that can emit new critters -- which are NOT flora)
critters are thoughtful and choose their own motion. They are not flora, even though they are manufactured by flora. That will take a bit of backstory to justify someday :-)
but, in general, each floraId needs its own visual expression in the world (i.e. some form of '3D' model'). I have some experimental tree trunk code, and some ideas for leaf masses. My grasses bend in the wind (a bit clumsily since I am too cheap to do a square root to preserve their lengths when bending), and I have ideas for how I want to do minerals (involving a tool called a 'ore magnet' which pulls ore triangles out of the ground when you are standing over a vein outcropping) (straight into inventory as 'dust' of various kinds (gold dust, copper dust, bauxite dust, etc. Whatever your starmap needs for a low level material)
I'm still torn on whether I have to use a tool (axe) to chop down a tree, or if I just bash it with my vehicle. Probably both, with damage points accruing in both the tree and the vehicle until final destruction of either.
And.. right, I have a means to repair things, since the inventory panel is a connection to "Ping" (my personal autonomous nano-factory), and he will notice and offer to repair my stuff any time I like. He might even communicate proactive notifications via the inventory button (which I think should feature his face, the the emotion of alarm appropriate to your current disaster)
Anyway, I guess this is a virtuous cycle that will just have to spin a few more times before all the bits and pieces are plumbed.
Oh, right, itemIds. So, it's another Tweak type, and let's pretend it's the range 300-399 (since I forget and will likely renumber them before releasing v1.10)
so, set tweak 300 to the floraId you want to change/define (1-1023), then set tweaks 301-399 to configure individual properties of that floraId. All of which should be doable from a single tweakString, so it should be script-friendly.
The individual properties are things like:
code:
floraId: 47 name: "Oak Tree" min/maxheight in meters (when spawning a new one) mass in kgrams type: tree (vs rock, hive, etc) controls harvest loot: <loot string> hitPoints: decrements with damage to 0 for destruction state (growing, maturing, exploding, etc.) flags (miscellaneous 1 bit properties)
It's mainly the 'type' that controls what interactions you can have, and then the mass (relative to the mass of you and your vehicle) that controls ther severity of the outcome.
I might need more 'rpg elements' if you want a lot of variety in how you harvest stuff, and probably some sort of a 'menu string' the optionally gives you some popup menu commands when selecting one of that floraType.
Like maybe a PICK FLOWER button when selecting a flora of 'type=flower'
The loot string has to convey WHAT you get (an itemId in most/all? cases) and HOW OFTEN you get it (probability of success). Currently I do that like this:
loot = "25=50,30=50,1022=50"
In each pair, the first number is the itemId (not the same as a floraId) which is what you will receive (will be placed in your inventory), and the second number is the probablity you will get one (just one.. if you want the possibility of two, then you have to call them out as two pairs in the list)
And your probabilities don't have to add up to 100, I will total them and then use that total to scale the individual components appropriately, so that 70 happens twice as often as 35, no matter what the total is.
That being said, I think I want to take a detour into the AERO code and flesh out VEHICLE TWEAKS (let's call that 500-599) where
500 - select one of N vehicle slots ) 501-599 set various properties of that vehicle
but within those properties is something like
- vehicle name - vehicle type (land, sea, air, space,...) - total aeros
And then something like
510 = index of the aero you want to define 511-526 = individual 16 floats defining one aero
So a vehicle like the cessna overcoat requires five aeros, so that's like 60 values, organized as 5 lists of 16 floats each.
Other vehicle types will require that I add more aero types, and many vehicles will require many more than 5 aeros (especially if I make a 'quad' aero that lets you build a 3D model out of textured rectangles)
But now that I have an inventory system, I should have more than one thing to store in it, right?
Plus, I need to make an Ore Magnet (tool) and that opens the can of worms for "connecting a tool to the current pose of the critter's hand, plus a little inverse kinematic so it stays plausibly aimed in the direction of the current target)
And THAT takes me back into the stick figure animator code to add the 'end node declarations' *this is a FOOT (that gets IKed to the ground), this is a FACE (that is looking in a particular direction), this is a HAND (that can hold tools), this is a BUTT (that can sit on things).
I think I will just add one more 'joint' to the end of the current limbs, which is never rendered, but acts as a final direction pointer. At render time, I will calculare its on-screen position (even though not rendered) and use that (and other nodes) to place the tool (while also keeping the pitch level whenever the hand pitch is relatively horizontal, but following the pose for acute angles).
that probably didn't make any sense, but I think I know what I meant.
Remind me to ask for suggestions for 'pew-pew' weapons in grid space, where my goal is to maintain 30 fps, but within that I wouldn't mind if it had satisfying particles to look at.
It looks like it will be hard to maintain 15-20 fps in critter world, though.
But this should be the weekend of 'vehicle tweaks' with at least one new stock vehicle added (and supporting engine infrastructure)
Darth Crow is back. I wonder if he might be a Raven somehow. He's pretty huge and has a sort of darth vader helmet head shape (feathers sticking out around neck line).
We also have a sad baby crow (except he's been sounding like this for over a year). He just sounds so sad, and squawks all day from a nearby tree -- though you can hear when he flies from tree to tree, never getting very far away.
But it's the plaintive whiny tone of a hungry child wondering why mommy never returned. It's kind of heartbreaking. And yet, time goes by and it's still alive, so it must have survived somehow.
I have never seen it, that I know of (yes, would be cool if this were darth crow, but seems unlikely. There are tons of crows around, though it seems like a fairly small set visits our backyard (usually to use our bird bath(s) to wash off whatever garbage/scavenged gunk they are eating that day (if we're lucky, it's just a Eggo waffle, and not some mystery organic).
This is of course, highly entertaining for kitty, who watches the window TV and 'window hunts' most of the day, getting extremely excited over birds and squirrels, but oddly cool around the huge crows and occasional falcon like thing.
But this sad crow just doesn't sound like the other crows at all (and I'm not sure what a Raven sounds like when it isn't quoting Edgar Allen Poe in a stentorian english voice)
It took me a long time to settle on 'sad crow' over 'sad squirrels' (the squirrels can make some very un-squirrely noises, but I have been pretty fluent in squirrel since college... plus the sad crow vocalizations can clearly fly, and while a squirrel could sort of tarzan its way from tree to tree, it seems more reasonable that this is a crow/bird
I guess I can tell from the sound that it is a crow-sized bird. (not a teensy little bird, which we also have plenty of -- and who occasionally fall into the house by accident for some close up interactions) such precious little clockworks they are. (ok, I was just 'being a writer' there, and that's probably not how I would normally phrase that.. but I *have* been struck by how impossibly delicate they feel when trying to rescue them out of the house. Side effect of needing to stay light enough to fly. But totally at risk of cat-assisted avicide, being crunched in a helping ham hand.
pro tip: capture them (against a window they are trying to fly though, that you can't open) with a little tin foil 'box', and then gently collapse that around them as needed, and carry them outside with minimal squishing.
but it finally hit me that what sad crow's moans actually sounded most like were duck calls. (classic wooden duck calls as seen on TV and in movies) only modulated with sadness instead of a sharp blast.
So now I wonder if baby crow, lost its mom right away, and fell in with a family of ducks, and was raised by them (you know, two tarzan references in the same babble!) and now just speaks crow with a duck accent.
I know this is POSSIBLE because I know a little bit about how the local ducks operate. There are large ponds of water for them to do their ducky stuff in, but at night they find a bush and hunker down.
And for them a 'nearby bush' might be several blocks away (they can fly), and on at least one occasion, it was OUR bush.
And sometimes eggs get laid, ducklings get born, and inevitably they need to follow mom (on foot) to the nice food source.
I wouldn't put it past them (ducks) to have actually scouted the situation out and to know in advance which fences have holes in them large enough to fit the family through, and where no cats have been seen. Still, I'm sure there is a horrible duck tragedy every day, just beyond my sight.
Still, the horror aside, it is so amazing to watch a family of ducks pour forth from your bush and waddle out the fence on more or less a bee-line to the big pond. Maybe they even get air support from other ducks, though I have never seen the mom fly off and leave the kids alone while on this trip.
Changing the subject, but keeping it on a theme of animal behaviour and fun aspects which could be in synSpace someday, I saw that report on Wolf behaviour. The one that basically claimed "everything we knew was wrong" and that the whole "alpha wolf" thing was a mis-interpretation based on the data having been collected in a zoo with an artificially selected wolf 'pack'
Apparently, accorting to this NEW science, which is presumably even more science-y (though no one blames the original report which was apparently great, but just based on "what happens when a bunch of woldf strangers are thrown together"
Anyway, in the wild, they say, it's just a momma and poppa wolf (and he's always the alpha no matter how old or frail he gets) taking care of their babies and the occasional second-generation, living with their parents (though young ones often/always split from their families (and then I guess sort of marry into a new wold family, which would help prevent genetic inbreeding to a dangerous extent)
I'm not sure if momma gets to be an alpha or if there is sexism there as well, but it sounds like the general consensus is that wolves are loyal and loving family members and the parents will spare no effort to spoil their children in any way they can.
Which is more in line with what I see in dogs, so it 'makes sense'
Of course, reporting on this study mainly focuses on "so you 'alpha male' types should stop calling yourselves that. hah! you're just a loving parent!"
Of course, that's not meant to white-wash wolf-on-wolf violence. Which is probably based largely on fighting over resources and, um, reproduction rights.
And I'm sure you feel differently about any animal if its food source is something you love to pet.
Hopefully there is enough land for wolves to be wolves somewhere, and for us to insist they be more dog-like when within civilized society.
hmm, ok, according to the Internet, wolves and dogs can inter-breed, and hence they will when territorial conflict beceoms inescapable (as we encroach their historic areas and bring dogs with us), so the system will be dynamic and all parts can evolve towards a symbiotic relationship. (in the long run).
When interbreeding is NOT possible, it's probably a bad outcome for the non-human. Hmmm, I know what I MEANT there, but I guess that might raise some other questions.
I just meant the wolves would lose, and not end up being happy members of our society, eating from the same garbage cans we dive daily.
But now I'm happy, since I know the wolves can eventually join us, once we've reached their level.
Moving aloong those lines, I watch a lot of youtube animal videos (cute ones mainly) and watching young mammals play, you see them basically doing the same things, and then you realise: dang, that's not a mammal, but i plays just like one, and I think that kind of takes you to 'has a level 3 brain' and that play is just a result of a certain level of neural network (self training),
Now, do ants play? I'm sure they probably repeat actions which generate appealing pheremones in response. They have really good dexterity, and something that works like an opposable thumb (some sort of sticky spot on their 'hand'), I wouldn't put it past them to play, but I don't think I have seen it. I guess life is pretty serious when you're small.
enough babbling for now.
-------------------- He knows when you are sleeping. Posts: 10902 | From: California | Registered: Dec 1998
| IP: Logged
Printer-friendly view of this topic
