posted
Not much to say, since the game is still un-released (it's been in development for years, though, so it must be pretty great, huh?) Great enough to deserve its own Forum section.
As I have said elsewhere, the REAL plan is to get Well of Souls: Rune Runner to be a full multiplayer game with player-created worlds, like Well of Souls for Windows.
But rather than do that development inside of Rune Runner itself, which would make sense, I am developing the needed architecture in synSpace: Drone Runner instead. (A simpler environment to work in, I tell myself)
So far, that includes: a new server, a new asset management system, editors for asset types, a 'collectibles' system (gotta get 'em all!), some re-usable java classes for networking and asset distribution, and whatever else took my fancy on the Sunday in question. My most recent digression was the music editor/synthesizer so you can make music for your worlds (you also have to make the instruments themselves by tweaking the synthesizer patch)
In addition to the basic Space Game (same as in Arcadia: synSpace for Windows), compatible with the old starmaps (I grabbed a bunch of the old ones, and preserved whatever credits you put in them in the first palce -- looking at YOU, Mosquito - thanks!). I will eventually get around to the map editor, but the new maps also can be scripted (in lua) (similar to what you can do in Arcadia: TurnAbout).
So the MAP is now the moral equivalent of a web page, with 'elements' (like barriers, zones, stars, etc) and the script acts like javascript might, to modify/enable/disable those elements in reaction to the needs of the map (for example, THIS map has a capture the flag game, while THAT map is a timed-maze to solve, with moving barrier walls.)
The asset distribution deserves a little summary. Like everything else in Synthetic-Reality, it's really peer-to-peer, with a central server used only to pass packets between players (rather than having the client's try to connect directly to each other, which is a nightmare in the 21st century), but the server is game agnostic.
Each asset has an id which is formed like this <authorSerNum>_<creation_Index>
Your serNum is assigned when you first play the game (and is NOT saved anywhere else -- if you install to two devices, they each get their own sernum. This could mean loss of asset ownership if you had to reinstall, though if I supported GSes....)
The creation index is just your 'opus number' that goes up by one each time you make something. Making soeething works like this:
* you always start with an existing thing * you directly edit that thing (changes are NOT saved back to the original) * once you have something you want to keep, you CLONE it (this is copying the original PLUS your changes) and give it a name. That's the only time anything is saved. And once saved, you can depend on everyone with that id has the identical version of the asset. (solves the version stuff from Empyrion)
So you can immediately 'publish' your work (just by using it in front of someone else), and if you subsequently tweak it, it automatically gets a new unique id (it also has a NAME, which is not unique)
The general principle is to remember everything you've ever made. You can delete your local copy, but if anyone else ever saw it in use, then it will continue to live on (and you might even get it back someday).
What Can You Make?
* SHELL well, you can make those little vector image ship 'shells' (fulfilling a promise I made in synSpace for Windows that the next version would let you customize that)
* FACE you can draw a little icon of your alien face (the SHELL represents the drone you are piloting remotely. the FACE represents you, the pilot)
* STARMAP (no editor yet) defines the play space, stellar backdrop, and scripted elements (games, quests, etc)
* PATCH. The game has its own additive-synthesis music synthesizer (9 harmonic oscillators, 6 contour generators, 3 LFOs, noise, FM, AM, and a flxible filter. The full sets of knobs for a particular instrument is stored in a PATCH asset.
* GROOVE. This is the equivalent of a song/composition, where you can record multiple 'jam' (yes, synJam is in here, too!) channels, as well as a 'loop' performance (each groove can have 15 loop channels which can be turned on and off, and just do a sequencer pattern when on (you define the patterns, of course).
In addition to map music, I'm thinking of using the groove system for interesting sound effects, as well as maybe some personal entrance/exit music that plays when you enter the server (for example).
The actual distribution is officially peer-to-peer where someone uses something in front of you for the first time and you fetch a copy of it from them directly. However, I am experimentin with a simple web database that gets a copy of every clone created. So, in theory, if you create something, it exists both on your device, and in this database, so when you encounter something new, you can fetch it directly from the DB, OR from the player who mentioned it, whichever is best.
I would like to release the current version, as soon as possible, but:
* I can only develop this on the weekends (no time during the week), so nothing happens quickly
* It would probably be misleading to publish without some form of working map editor
I don't mind doing multiple releases to get to the eventual goal, I just don't want anyone mad at me during any given release (since this will cost a couple bucks (you only pay once, of course))
Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
Hmm, maybe a youtube would be better. Oh right, first I have to process my raw video into something more youtube-upload friendly, though with my new network, maybe that's old think.
posted
I do not. I am dragging my feet and rewriting stuff most of the time.
But one limiting factor was that I didn't want to release it without some form of starmap editor (unlike on a PC, you can't conveniently just drag files around)
Anyway, I finally came up with at least an interim plan. And I just got it to work after many hours of struggling with the copious documentation
But here is how it works:
* You have collected a bunch of starmaps (or Rune RUnner maps)
* you decide you want to make one of your own
* you consult the documentation on the web site (really? where is that?)
* you craft a lovely plain text document, in notepad or something.
Now, how do you cram it into your mobile device?
1.) drag it to your Google Drive (drive.google.com, you don't need anything more than a Chrome Browser)
2.) start up synSpace on your mobile device
3.) select IMPORT STARMAP (on the options panel)
4.) your GDRIVE appears as am activity and you scroll around until you find the file, press SELECT
Bingo schmingo, it fetches the file and creates a 'temporary' map in your list of star maps. YOu can select it like any other and play with it.
If your google drive is shared (or you otherwise share the text file) your friends could also import it and then playtest alongside you.
And maybe google collaboration tools will let you work together as a team easily.
The trick is, of course, making plain text files when Google Docs wants to make full formatted documents. synSpace will only load plaintext, not full google docs.
I find if you 'drag a notepad file' to the gdrive window, it remains plaintext, but if you then edit it, it gets promoted to full doc.
So, if you need to edit plaintext on your gdrive, you can RIGHT-click on the file and select OPEN WITH and then select 'chrome notepad' (something like that, I forget).
====
And it works (well, the reading from gdrive works, I haven't done the 'temporary map' bit yet)
So there WILL be a map editor in the first release.
=====
Oh, I forgot, once you're happy with your temporary starmap, you use the CLONE button to make an official named version you can start using normally with other players (who then do NOT need to import it, and who are all guaranteed to have the same version, since each clone jas a unique ID and clones cannot change after creation)
This project took at least 4 times longer than I expected, and I screamed a few times.
Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
When using drive.google.com, you can install the "Drive Notepad" extension, and thereafter you can directly create and edit plaintext files without having to start in windows notepad and drag it to the drive.
To install said extension, click NEW then MORE then CONNECT TO MORE (assuming you don't already have it)
That shows you a list of extensions and you can search for "Drive Notepad" which may or may not be the only/best one, but it works for me.
----
And I continued the IMPORT feature so now it fetches the text of the file, and creates a new (temporary) starMap as described above.
And it doesn't crash, it doesn't seem to impact performance, and the GDRIVE stuff (inside synSpace) doesn't even get turned on unless you push the IMPORT STARMAP button.
Well, on Kindle, it crashes, though I guess I should try today's build. Still, synSpace StarMap designers will need an "android, not kindle" device.
Yeah, still crashes kindle
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
By any chance are you planning on making "Golden Souls" files to be saved on Google Drive? That way it could be used on multiple devices connected to the Google account used.
posted
Actually, while I would love to honor Golden Souls in the android games, I don't think I legally can as it would represent "selling in-game features, but not using the Android Market to facilitate the transaction"
So if there WERE an android GS, it would probably need to be bought in game, and possibly each game would have to do it separately.
Economically, my preferred model for android games is:
* no ads, not free, but nominally priced (a couple bucks)
* some sort of value-added content periodically unlocked in game, sometimes requiring in-app purchase.
Of course, the real money comes from selling lollipop hammers, but I am still against that, morality-wise.
But money is such a remote possibility, I refuse to plan for it :-)
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
Haven't added much recently, but the last tranche (if I used that right, which I suspect I did not) was to add the starmap clone and delete functions, so now it is more true that I can publish a new map as a regulare player
But today I am thinking about achievements, or 'tokens' in WoS-talk.
One of the issues I had in WoS was that I needed a unique id for every token, and the world developer could only specify the 'least significant bits' of that id. They could control "this is token 1 of 8000 in this World" but I had to control the "which world are you playting in at the moment"
Which was fine, I used the filesystem, and saved the tokens inside of each
In synSpace (and hence eventually in Rune Runner), i use a local databse (sqlite) to store this stuff, and the unique id is just one column in that table.
Anyway, I finally decided this works pretty well:
* take the sernum from the assetId of the starmap. every starmap has a unique assetId whose sernum is that of the person who made the clone. So if you have to clone the map 20 times to get the final version you like, it will have 20 unique assetIds, but all with the same sernum - you.
* take the mapname from inside the etxt file (the file you imported from your google drive). The intention is that this is the only way of setting the mapName, so cloners cannot modify the root name. (though they DO get to provide a new name, the original name is remembered until the designer changes it in the map text file.
* take the characrer name, if meaningful (run runner will store things per character, while synspace does not)
Then the unique assetId is
[sernum]_[worldName-CharacterName]_[local id from map]
So in the map file there is a new section that defines all the achievements/tokens defined for this map, and those are numbers from 1 to whatever you want. Some tokens are probably invisible (like the micro stages of some quest) and others show up on some fancy achievements page, but the main goal of these factoids is to allow your scripting to make choices based on the player's past actions.
In the case of synSpace, that's probably just to unlock the starMaps in some order. But in rune runner it would be the usual "i told him about the dragon, he has met the dragon, he has killed the dragon, I have praised him, I have rewarded him" where the only achievement is "You have slain the dragon"
When your script wants to know "does the player have achievement 3?" you (your lua script) only have to provide that number, and the system will work out the mapname, sernum, and character name which are appropriate, and then search the table.
the achiecements table (maybe I will call it tokens) in the map text file will need everyting required to subsequently display to the user (should the game offer some sort of trophy case), and that should work even if the map itself has subsequently been deleted.
ANYWAY, the whole point of the above is just to make sure no two map designers step on each other's achiecemenets, and that players are not expected to have to re-capture all achievements every time a new version of that map is released.
With this system, you only need to redo the achievements:
1.) when starting a totally new (to you) map 2.) if the developer changes the NAME of the map inside the starmap text file 3.) if the map is actually cloned by a different player (getting a new sernum)
Anyway, that's today's plan for unique token Ids, which I always wished I could have, and now I think I can.
But yeah, if I could use GS codes to let you set your own sernum, so that you could recover from a move to a new device, or a catastrophic failure, without forcing an interruption of sernums, leading to players needing to start over on the next release. Again, no big deal for synSpace, but probably quite the pain for rune runner.
[UPDATE]
I ultimately decided that the new collectible type would be 'ACHIEVEMENT' though it includes the concept of WoS 'token' within it. Some achievements are more newsworthy than others, but all are stored in the same table, per starmap but not per version of starmap.
The URI components are:
mapSerNum:mapRootName:accountName:achievementId
where
mapSerNum comes from 'outside' the starmap file (from the asset_id that was loaded).
mapRootName comes from 'inside' the starmap file and is limited to ascii alphanumeric only. If you don't declare one, I generate one from your mapName (also declared inside the starMap file)
accountName is really player name but allows for the concept of changing your name from time to time. SynSpace has only a single account, so I just use 0. Rune Runner lets you create multiple characters, where each would be a different account (and have different achievements) (though having typed that, nothing prevents me from having achiecements that affect all of your characters. I would probably use "0" in that case as well, so cool. a free feature.
achievementId is a number or string that looks like a number or maybe a string, but it would need to be controlled character set, so lets start by calling it a number -- but pretty much any number you can think of.
That number then relates to a new INI section in the starMap File:
[ACHIEVEMENTS] 1= You have achieved everything possible on this map
100=You have achieved some minor bit of questing on this map having to do with a particular boss or dragon, of which there are several
101=You have dealt with another such sub task, but only index 1 means I feel you have done them all, but I, the lua script for this map will handle all that, and here in this table you are just predeclating all the ids you are going to use. You can feel free to add to this list, but it would be rude to your players to change existing entries.
And avoid using ids 1-99 for your own ids, leave those for 'the system' and we'll just note that the unlock order of the maps that come with the game will use achievement 1 for each map to mean that you have 'completed' that map.
For one of the stock maps, that achievement's full collectible id would be:
STARMAP_016_0_1
For a map that YOU design, it might be
18727615276567517_CYGNUS_0_1
Where you provided the root 'CYGNUS' and the big number is your device's serial number.
Then in any new starmap's text file, you can add a requirement like
[REQUIRES] STARMAP_011_0_1 STARMAP_015_0_1
Meaning no one could play this map unless they had both of those achievements, which could be anything you like, but in this case I use '1' to indicate the 'you finished this other map'
The 'locked' maps then appear in lists in a dimmed state, so you know when people are playing them, and maybe they will tell you what you need. Might be some game value in figuring it out.
I mean, with the stock maps, it will be just some boring order, with possibly an in-game purchase for a block of N or something, I dunno.
But players could in theory create groups of maps which were relatively-locked, one to the other. (in addition to publishing maps out of the blue that could be played in any order or completely by themselves,
In that case you could even use the same 'root' name so long as you were careful to not define the same ids in more than one of them... liks map1 gets ids 100-199, map2 gets 200-299, etc, and for map completed you use 100, 200, etc (and not '1')
I mean it is important to ME that all MY maps use '1', but that's because I am thinking I only offer a single 'campaign' as it were, and maybe I should think a little more about that.
ANYWAY, YOU could, in theory, make it (by using a common root word between multiple maps) so an achievement on one map, applied on another ,, so, I don't know. maybe that's just normal.
[UPDATE 2]
Having written it like that to convince myself, I can't stop thinking in terms of TOKENs, and I think I will make a lot of typing mistakes if I don't reverse the above and call the collectible a TOKEN and than an ACHIEVEMENT as people know them is just a special form of TOKEN that includes a JSON blob as its data element that can remember some historical event and the rewards you were given.
So, the collectible is a TOKEN, and you know I prefer 4 or 5 letter names anyway.
posted
So, when I started this project, I knew I wanted to have personalization like the ship shells, but I didn't realize I would end up with multiple asset classes for players to dink around with.
During the evolution of THAT, I settled on a 'collectible' model, where there are (currently) six asset types (map, face, shell, patch, groove... um?), but they are ALL 'collectibles'
ANyway, internally, each asset type had a lot of unique code to it, especially the first three (shell, face, map), so yesterday I buckled down and rewrote those asset types so now everything uses the same (collectible) API
Lot's of work with no real visible change, but stucturally more sound and easier to work with.
As I keep chipping close to defining the script API. I think I finally have the architecture for script-to-script communications (with a copy of the script running on each player's device, under the coordination of the current moderator, allowing scripts to send messages to their 'peers' on the other devices, to carry out game mechanics which arr 100% script driven (that synSpance itself has no idea what you're doing, it just facilitates it). Should make interesting mini-games possible, on a per map basis
But first, I have some rejiggering to do to the music system,mainly to separate PATCH and GROOVE into separate panels, and to add multiple jam channels, with at least a visualization of the existing channel data, if not a full editor for jams. (which I still want to have, but not required for first release, which I declare WILL be in 2016)
I added a little particle system last weekend. Nothing much, but it improved the explosions considerably, and leaves behind some nice markers from wall collisions and powerup pickups.
Oh, and I used the integrated synth to make a new sound effect (the ship recharge sound), so that was a cool form of boot strapping. Ideally, I wanted all my sound effects to have a musical basis such that all the shots and explosions would sound 'in tune' to the key of the game. I'm not sure I can carry that off, but if a few key sounds are right, it could still happen.
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
I yhink I just closed the loop on map development, but might need one or two more features there before I'm done (for example, I think I would like to be able to import just sections of a google doc into snoyhrt msp. In psrticular, I would like to live edit the graphical aspects of the starmap "in game" but then to merge in the scripted elements 'via google drive'
Until then, you have to pretty much do everything in the google drive.
but I completed the starmap distribution model, so now it is possible to:
* start with a starmap text file on your google drive
* import it into the game as a new temporary map
* play with it (and edit it a little in game), set up asset 'links' so the script can use symbolic names that get bound to actual assetIds (which can be edited later. Actually untrue, I haven't finished the link stuff yet
* when you have someting you like, "clone and save" to make a new assetId with your changes and new name, at which time it becomes "just another starmap you have collected" and which you can use normally when visiting the server
* Someone who does not HAVE the new starmap, still "sees it" on the server list of active sessions, just without any real details other than its assetId.
* but as soon as you encounter other players, you start asking them if they have a copy (I mean the game does on your behalf) and exchanges it as efficiently as possible, after which you too can play that map.
*in theory, the first person to use a new map in a new server session will be the moderator, and the secone person in the room will prefer to ask the moderator for a copy, and since the moderator could not have started the session without a copy,this should normally work.
But I am sure network snafus will lead to odd situations that require you to reconnect to the server before things look correct to you again. Will try to minimize that, but a little is probably inevitable.. I think I am safe from incomplete copies...
anyway, there is now a complete circle of development from developer to player now. wewt. Hopefull this weekend I will polish that, and do the music changes I mentioned. It's important I feel good about all my asset data formats before people start making things they care about. I want to 'invalidate all assets' as seldom as possible :-)
Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
Is there any chance of adding orbits to stars? I don't think it would be to difficult since all you would need is a starting point for the star and a point for it to orbit. Although it might get a little bit messy adding non circular orbits.
As for loading new star maps, adding a function to check if a player has a map before it launches a ship should fix the need to enter twice.
posted
Actually, I did have an interesting idea about the background stars.
In theory, synSpace is a 3D game, inasmuch as the math is all 3D, but I constrain all the action to a single plane (with the background stars all below that plane, as if you were flying along the surface of a big tub of jello, with the background stars being the bits of fruit contained within.
Imagine however, if there were game mechanic which 'rotated you to a different plane' (animation of which is just all the background stars 'rotating around YOU' until you reach the new plane.
It could be just simple eye candy in response to some game event (like maybe the Warp powerup might do this to indicate warping you into a new space, then travel in that a bit, then warp back to the original.
In a bigger role, it could be an actual way to navigate in 3D, and if you wanted to dogfight someone, you might first need to 'rotate into their plane'
Likewise, there could be planets that you could only reach by warping to their plane first. That sort of thing.
I have it tabled at the moment as a map-scripting issue (that it should be possible for a map designer to use the effect, even if I don't have it built-in for another purpose) I imagine a fair amount of map scripting will be to key animations of one sort of another (ship blowing up, for example)
-----
Last night I made the data structures and the 'serialization' for multi-channel jams (and the word 'jam' has been demoted, once again, as I have decided it will be less confusing to simply call these "tracks" though I think I might go with "TRAX" just to allow a smaller button :-)
I which GROOVE were a letter or two shorter, as well.
'Jam' (in reference to synJam) is still on my list to appear in this game, but maybe I will reserve it for literally when you are actively playing music with someone else. A mode I do not yet have.
----
Today I have to redo the groove player so it can handle multiple tracks at playback AND during recording (where it has to be able to play all the old tracks while you are recording a new one).
After that, some visualization/editing of the trax (simple stuff, not a full music editor, mainly MUTE && DELETE control), and then some ways to actually inflict your music upon other players, and means for them to attenuate/mute you :-)
Eventually, I hope to be able to pinch zoom into the tracks and physically move individual notes up/down and left/right, though it's possible music will never be interesting enough for people to need to do that :-) I mean, this is a space game, not a concert piano.
----
While I haven't used it yet in my demo videos, the game includes all the planet art from WarPath, with the idea that a map designer might need planets, as well as stars, as quest vending machines. I see the general nature of it being like that:
* you are only playing one map at a time, though maps can use achievements to unlock things in one map based on achiecemenet in another
* the map probably includes multiple SCENEs (I am trying to think in terms of what Rune Runner will need), and they could potentially all be playing out at the same time.
* each scene is s single lua script which can talk to the peer copies of itself on other devices that are taking part in the same scene
* each scene has a host, that determines which big picture events have taken place (like when the NPC has taken enough damage to die). The host is probably the moderator, but I would like to reuse my WoS "the player to first enter the scene is the host until they leave it, at which point the scene is over"
But that might take some evolution and/or left turns. Just to raise some obvious issues...
While WoS and Rune Rnners have players in motion, mostly the players hold still when not actively interacting. Which means it is easy to stay 'in scene' as long as you like. But in synSpace, your natural form is motion, usually at a pretty high speed. So a stationary scene might be problematic, with you just swooping by for a second, and not seeing anything happen, since you were far away when it did.
So, synSpace raises the concept of moving scenes (the scene center of mass moving along in some way.. for example, a scene could be a meteor swarm, travelling though space
Or, the scene might be stationary (a wormhole is opening, once it opens, stuff will start pouring forth, to attack a nearby planet, which has called you for help -- you try to stop the gate from opening, then try to kill the stuff that pours forth, before the planet takes too much damage. If you are successful, you get some thanks and maybe some reward. If you fail, the planet blows up and the scene is over.
Stuff like that, where you are now encouraged to hover around the scene, which makes you a sitting target. I don't know if that is great or not, hence the possible evolution of the plan :-)
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
I do have to say I was surprised to see that you didn't make synSpace's controls for a 3d environment(left, right, up, down, and maybe ship rotation. Although maybe you have that as a plan for synSpace 2 lol. Needless to say I still like how the game is coming along so far and can't waiting until it's up on Google Play.
I like the flow of the UI, which is basically none. You just press RECORD when you feel like being recorded, and it makes a track for you and let's you join in with a groove in progress.
With an end-goal there of making that multi-human as well as multi-track. So we are both contributing to the same groove, albeit we hear each others contributions delayed until the 'next time around' ... but since we loop a bunch, that's a-ok metaphorically!
And I acknowledge the multi-user scenario is a very low statistical probability, based on past experience, so I mustn't pour too much time into it. But I will anyway, I'm sure. But this feels like a pretty solid feature set for version one music support in synSpace, so I don't need to add tooooo much more at this time.
WHich reminds me: I need to make a star trek bridge background loop groove :-) puh weeeep
Oh, right, I need to 'finish' my vocoder still, don't I? I can ramble on about that a bit. It all starts with the EMU tab that currently shows a blank screen (and likely will be removed, at least under the banner of EMU since that isn't quite what I plan to do)
I mean yes, I plan to do straight emu to a small degree, where a short sample of some real world sound is used instead of the canned sine-waves in my additive synthesizer. That's pretty straightforward and I plan to ship with recordings of some useful samples (mainly percussion, which I find hard to simulate satisfyingly)
And clearly, since I already have the microphone recording, it would be silly to not let you do it with your own samples
However. what I do NOT look forward to is shipping your samples around to the other players, as that's probably a lot of data.
So, lots of things could be done, I would probably vote for 'distribution by cloud' and let the players fetch the samples directly from your google drive or whatever works, with me doing none of that distribution). More likely, I would be willing (if possible) to take your samples and process them down into something smaller (and which probably doesnt sound as good, but in some cases maybe it even sounds better)
But here is my PLAN:
1.) I have videos of my vocoder/spectrum analyser thing.
2.) It creates a sequence of spectral snapshots, forming a sort of movie of the frequency domain view of the sound (as opposed to the normal time domain)
3.) You make the original recording, and work with me to describe your little movie's start and end point in the samples. Let's say your movie is a recording of a single piano note of a known frequency.
3.) Most of the spectral snapshots will show a strong peak at the note's frequency. But there will also be harmonic 'side oscillations' that come and go over the life of the note, these appear in subsequent spectral snapshots over the course of the 'movie' whose length is the length of that piano note.
4.) my synthesizer has 9 or 10 oscillators, which I can adjust to try to recreate the ambience of any single spectral snapshot. My frequencies are constrained to harmonics (1x - 9x of some fundamental) so I can't be a perfect replica, but in the world of music most things are already pretty clean since things deviating from these frequencies generally sound out of tune anyway.
5. so if there are 10 spectral snapshots in my movie, I use 10 stages on my contour generators, where at each stage, each oscillator is configured to provide the same amount of energy as was present from that frequency in the snapshot. Then between snapshots, it just glides from one snapshot value to the next, so it sounds continuous and not 'clicky'
6.) then repeat for as many changing frequencies as I have oscillators and contour generators to handle. Since I only have six CGs maybe only 6 harmonics at once, but I can pick the 6 most energetic.
So, that is how I [PLAN TO] turn a short microphone recording into a bunch of PATCH settings making an equally long note with similar time-varying frequency components.
You then can play that PATCH like any other instrument to have a note that 'sounds like' some real world sound, whether that is a piano note or a dog barking, but it would be a dog barking "through an auto-tuner"
And I am betting you could use this technology to record short rude phrases you could then use freely without causing offense...
Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
This is a 'frequency domain' recording that just recreates the harmonic content of a period of time, repeatedly (16 times a second.
Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
hmmmm.... what will be this weekend's project then... feeling kinda burned out after a long week of unusual things.
let's see... things I feel obliged to include in first release that are still undone
* make it actually possible for a starmap to play music... sort of give the music its raison d'etre as it were
* finish or hide the microphone code
* add a way to reorchestrate a groove (bind to different patches) [done]
* solve the licensing concept such that collectibles can be made 'harder to collect' as needed
* rating/favorites in all collectiles browsers
* proper map pacing through unlocks
* protptype map scripts for DM CTF, etc [done]
* something to spend galactic credits on
* live map barrier editing, in game, multiplayer, and dealing with 'not everyone has the same version, so ratings changes are suppressed'
* standard map state, along with script-defined map state: distribuion, UI (for example: "no fights on this map are rated" and "warp powerups are not allowed on this map" etc [done]
----
OK, I think I talked myself into working on 'finish version 1 microphone support, whatever that turns out to mean'.
posted
OK, well I cannot claim to have FINISHED versin 1 mic support, but I definitely sanded down some rough edges, along with miscellaneous other small improvements (I now 'highlight' the control that benefits when you pick up a powerup. For example, you pick up a new engine pod, the engine pod meter blinks and glows for a few seconds)
Aside from a small amount of animation to trigger obsessvie/compulsive feedback, it also helps the new player relate documented in game actions (you found a warp gate) with the control UI for that feature.
I also made the instant-use powerups display with a rounded-rect frame (while the 'ammunition' powerups still use the circle)
I spent quite a bit of time redoing the button layout so that different panels can use the same block rectangle regions without embarassing overlap. This is complicated by the wide variation in screen aspect ratios. I still have areas of text that draw outside the lines on some people's devices, but I am loathe to use dinky fonts since I cannot personally read dinky fonts any more.
So, still lots to do.
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
Not sure if it would help or not but I have a galaxy s4, if you have a test apk you would like me to try. Note sure what the resolution it uses right off hand.
posted
so, the scripting stuff is critical, and I';ve written myself a zillion use cases that I want to cover, but I've been having some trouble 'pulling the trigger' on that section of the code
That is to say, I ported "Lua" (the language) itself probably o ver a year ago now, but since I didn't have a convenient way to edit scripts (until I added the import from gdrive stuff), so there was a bit of a "gumption" trap completing the integration with the game
So, this weekend, I took the next baby step, which was to take the lua code and put it inside a thread so it can run poorly written lua code without hanging the game up
So, if a lua script turns out to have an inifinte loop in it, say, the game plays normally and the only symptom (I hope) is that the quest gets stuck in some way since the script never adbances the plot once it gets in the infinite loop
a subtle distinction, I admit, but I won't be in full control of the Lua, so I wanted independence. Plus I don't want little lua invocations to be felt as 'stutters' in the gameplay, though I imagine that will be inevitable to some degree anyway.
But, as of this weekend:
* the gdrive support lets me import a map with new scripting changes
* when I load a starMap, I pull the script text from the [SCRIPT] tag, which must be the very last tag in the starmap, with everything after it being the script (that way I don't have to mangle the script to keep it syntactically compatible with INI file format
* when connecting to a starmap, I create a new ScriptThread and pass it the text of the script file. I allow myself to block the main thread for the time it takes to decode the script file, which might be noticeable as android might choose that moment to load in additional resources as well.
* That thread then executes the script from its beginning, which is how you set up your constants and world state and such and when the script returns, it has modified 'the lua blob' which is retained as member data inside the ScriptThread object, but lua itself is no longer running at this point. There is no 'game loop' in lua, as it is all message based. And until you exit from handling message 1, you will not receive message 2.
5.) messages can come from anywhere, but mainly document things like "pilot entered, ship exploded, player left, important button got tapped, rec'd message from moderator's lua script.." I now have a nice global message sender function defined, but I don't really call it from anywhere yet, so I don't even know what the full list of event messages will be, other than 'as few as I can get away with'
6.) when I am asked to send a message to the current starmap script, I actually just stick the message inside this fancy thread-friendly queue and then go about my day, not waiting for an answer (though I eventually know whether or not it worked)
7.) the thread itself spends most of its time idling in a loop, looking in that queue for any script messages, which it handles in the order they are received. Currently a message consists of two pieces of information: a 'type' and a 'message' (which is just a String), and when the ScriptThread sees a new message, it grabs the current lua blob and invokes lua code upon it, telling it to invoke the lua function:
function onMsg( type, msg ) end
If your script does not provide that function, well, then I guess you're really not much interested in scripting, What you do in response to a message is officially up to you. I will try to limit your creativity only when it seems evil or possibly naively wasteful of time or bandwidth.
your onMsg handler can take as long as it likes to handle a given message, but understand that you won't receive any new calls to onMsg() until you return from the one you're in.
Usually you will probably react to a message by updating some map state like "the door is now open" and you might need to send a message or two of your own in response (beware message chain reactions). I will need to provide some debugging insight for this, so probably some sort of script management panel is required.
While handling your message, you CAN ask the game to do some things for you, via the 'game' object which is set up in the lua environment for you, so you just say something like
code:
function onMsg( type, msg ) if( type eq 'hello' ) then if( game.iAmModerator() ) then game.sendMessage( 'welcome', 'hey dude!' ) end end end
I admit, I use lua infrequently enough that there are proabably syntax errors in that (eq to compare strings?) anyway, that's what the internet is for. And you might even find a lua friendly editor with keyword highlighting and syntax checking... for free..
Now, even something as simple as sendMessage has intricacies, for example the intended destination.
In general messages are sent 'to scripts' and then beyond that 'to the script which is running on that player's device' and maybe not all messages go to all players.
The first distinction is 'source of truth' where one player (say the moderator in synSpace, but probably per-player scene hosts in Rune Runners) makes all the key decisions, and the other players just report to the moderator and accept the moderator's decisions as to changes in map state.
so a sendMessage would need to identify the destination as: "all", "mod", "slaves", "individualplayer" and an onMsg should include some concept of where the msg came from (source)
All done in a way that doesn't allow 'lua hackers' to spoof source or destinations.
Anyway, so some obvious kinks to work out. As to the syntax of a message, I am leaning towards a bit of http url style, such that you might think of 'type' as a service name, and 'msg' as the arguments to that service.
this allows a script to make up its own data and pass it around via a single api (sndMsg/onMsg), and android already comes with support to urlEncode and manage individual request properties easily.
whatever I do, I will presumably provide some built-in lua functions for managing the msg strings with minimum effort.
hmm, as a test game maybe
* let script define a button seen by the user game.sendMsg( 'makebutton', 'id=2&text=PUSH+ME' )
* let script handle button press message (from local pilot)
code:
function onMsg( type, args ) if( type eq 'buttonPress' ) then id = args['id'] if( id == 2 ) then game.setButtonVisibility( 2, invisible ) dst = game,pickRandomPlayerWhoIsNotMe() game.sendMsg( dst, 'tag', 'you're it!' ) end end end
More or less. A simple TAG game that puts up a button when you are IT and "sends that button" to another player when you tap it. So really this needs to handle two messages. a local one from the button tap on your own device, and a remote one that designates the new 'it' which is probably sent to everyone (from the old 'it')
And if you replace 'hit his ship with weapon fire' instead of 'tapped a button' and you have a spaceship tag game, that would want some 'it' marker drawn on the ship itself (something like the thing I do for capture the flag -- attach this SHELL glypg to that ship)
Anyway, I liked that args['tag'] business, I think I will aim for that.
But yeah, a simple tag game might be a good way to get started. Gentle enough for the newbie map.
posted
Almost seems like Lua is close to AIR, which is what I'm using. For example my function structure looks similar to this....
code:
function SendMessage (var1:int, var2:string) { if (var1 = whatever) { //do this } //so on and so forth }
Calling the function is pretty easy as long as all the variables are stated with the function call.
code:
SendMessage (var1, var2)
I obviously don't know the ins and outs of Lua. It would make it easier to handle sending/receiving messages if there was some kind of looping function.
[REPLY from Samsyn
Your lua script is free to loop around with all the normal control structures (for, while, etc) and the scripty 'for-each' variants. And your function doesn't HAVE to return instantly, if it makes it easier for you to juat wait a second or two in the middle. like
function onMsg( cmd, args ) if( cmd == "VICTORY" ) then announce( "We have a winner" ) wait( 3000 ) announce( "and it is " .. %winner.name% ) end end
that wait only blocks this one script, so if that doesn't hurt your script, then you don't need to worry about it too much. But I didn't mean to imply you didn't have full access to all the normal lua looping constructs, like 'for' and 'while' and 'foreach' sorts of dealios. It's a full language and actually super powerful. But it is weird in the following ways (as in 'not like c or other c-like languages'
* uses "--" for comments * doesn't use ";" anything like you might expect * doesn't use curly braces * all blocks need END marker * all IFs need THENs and ENDs * ELSE IF is something I can never remember ELSEIF? ELSIF? ELIF? * variables have to be explicitly declared local, or they are global, even when defined in an inner block (I think that's true) * uses ".." as a string concatenation operator * is NOT strongly typed (because all types magically work at all times. Occasionally you have to force a cast if you really need a string ( x = "" .. y) or a number (x = 0 + y) * easy to make complicated data structures with functional elements, if you're into that sort of thing.
Anyway, it's great, just a little quirky when you are usually working with curly braces and semicolons. -s ]
posted
oooh, here's a thought. so I want to use the music stuff in a sort of synJam (from Arcadia) capacity eventually. Where several people play together in what they perceive to be real time.
I was assuming I would coordinate that with specialized game code (in java), but the silly TAG example opened my mind to the better use of coordintating jamming via scripting and not hard-wired java code.
That also has the added advantage of making it starmap-dependent as to whether the support existed. So there could be maps with clear markers that they were music-oriented and that if you were looking for battle, you would probably not find it satisfying there. Unless the addition of someone talented playing live music to the events on screen (using the SPY feature perhaps even), well, might be amazing.
But the point is, I can continue to defer the functionality and just be thinking the use case for how it would interact with script messages.
And I think I am leaning towards an API like this:
src and dst identify/route messages to various combinations of players (their current script thread receives the messages via the function
function onMsg( from, type/Service/cmd, args ) end
Where 'from' is secure, and not just a value self-reported by a player.
The 'type/service/cmd' is just a string that identifies what this message is trying to accomplish, and aside from some reserved values is open to the specific starmap script as to what it feels it needs.
The 'args' is also just a String, but assumed to be in urlArg format: ?a=1&b=2&c=3... a list of name-value pairs that can be marshalled to travel safely across packet boundaries, and forcing minimum format on the developer (and tools exist to handle creation/examination of these already)
But I still have the problem when the script just wants to know some piece of 'standard game state' (stuff about connections, pilots, asset names, synthesizer status, etc.
I was hoping to use a message for that, like
game.sndMsg( 'what is the pilot name for the red ship' )
then later get back to you with
onMsg( 'thatThingYouasked', 'theActualValue' )
But that really would suck, and I only was proposing it out of a general laziness, but it would be harder to do everything else, when what you really wanted was
code:
function onMsg( from, command, args ) if( from="moderator" and command="leak") then local playerState = game.getState( "players" ) local myPlayerNum = playerState[ 'localPilotIndex' ]; lcoal myShip = game.getState( "ships", myPlayerNum ) game.sendMsg( 'log', 'My name is: ' .. myShip['name'] ) end end
Only instead of localObject being a super cool thing, I only support it being a lua table, which is pretty cool, but basically read only.
Through the objectNames and indioces you can walk the full state and hopefully have quick access to the small bit you actually need, without having to implement a separate getter function for each one.
spin to it, though that pretty much dooms me to internally implementing fieldNames for everything I allow the script to directly manipulate. Some stuff, like "who is playing in which slot" will be read only forever, since that is part of the player's connection to the session and not something the script can control. (heaven help us, the script probably COULD change your color selection though).. so you could have a map that 'at start of game' randomly assigned people to specific thumb colors because the script assigned unique roles to each color. Or some colors are reserved on this map for special NPCs that mimic fellow players...
----------
Anyway, recapping:
onMsg() - wakes up your script to handle a single message
game.sendMsg() - your script sends message to other people's scripts (and maybe back to itself, so watch out)
game.getState() - gives read access to standard game data (the player's name, for example)
game.setState() - gives write access to a subset of that same standard game data
And that's it. Everything else happens within the context of the individual messages, handled in lua by the starmap script, if any.
your starmap does not need a lua script, and can be a complete deathmatch dropin experience without any scripting at all.
Capture the Flag scenarios should be done in script, as should the handling of 'extended powerups' defined only by the map.
I would effort to provide various map styles (DM, CTF, etc) in the initial game distribution, and then people could just clone them, leave the script unchanged, but just edit the barriers, and cosmetic asset bindings to get a completely different looking race course (for example) that worked with no script changes needed.
Or they can craft their own scripting from scratch and import that via Google Drive to create a whole new kind of game prototype (or an improvement/specialization over an existinf type
WHich means we would eventually agree on terminolofy (DM, CTF, and new ones) and it should be made easy to list your game session such that people can specifically search on those keywords.. but that's a development that can wait for the day when there are more than one game session running at a time :-)
In Arcadia:TurnAbout, I exposed a separate api method for every single action, and I had a zillion actions. Some of that was because that was how rendering happened, so I had to recreate all the basic drawing functions.
In synSpace you will just never render anything directly, but always through the game as a proxy, using official assetIds for whatever art is needed, and some layout commands in text. For example you would sendMsg() aguments that described what a popup dialog window might look like... in some fantasy world that might be actual HTML, but for now assume it's very barebones, like a self-sizing rectangle around a single word of text :-)
I was going to let scripts pre-declare some moderator commands, and then stick buttons somewhere on the options panel that only appeared for the moderator. I think that's still a good idea, but I am more inclined to accept the possibility that your local script might want to show you some extra buttons now and then, so long as I don't give you the impression you can actually render anything great that way. But good enough probably to draw informative controls (using pre-rendered FACE and SHELL assets)
So, next weekend I vow to take action on the above and implement at least one silly map game. Maybe an automatic multiplayer pinging game just to test the system's robustness... packet chain reaction scenario.. can the server protect itself from a crazed client. Just how much bandwidth CAN I handle anyway? Better to find out now than on embarassing release day. Work out a packet/bw budget and enforce it. (and let the player know when stuff is happening, so bad maps can get weeded out).
Yeah, cool! should be a good weekend. I look forward to it!
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
I think I will ramble on a bit about game state and how it relates to starmaps, scripts, and packets. I will speak pedantically, but really I am just trying to organize my thoughts by spouting them and then changing my mind after I hear how stupid they sound :-)
Old synSpace barriers are a good example of static state. They were defined in the starmap. They could not change mid-game. Instead of packets, they were distributed by the map itself.
You want as much of your state to be static as you can.
But a cool scripted map can have dynamic state, that changes over the course of the (insert time concept here). That state needs to be synchronized between the players, most likely. Unless it's ok for them to all have their own personal values (maybe a random treee color doesn't have to sync for all players, but still needs to change over time)
dynamic state is synced by packets, sent from an authority (server side of the relationship) to someone curious (client side of the relationship).
We want to send as few packets as possible, so if a client isn't curious, it shouldn't ask, or be assumed to have asked.
clients are generally only curious about things nearby (on the same map, for example), so everything that happens is private to this particular starmap session (running on a server in the cloud. An instance, I guess you would call it). Starmap Instance. yeah!
----
BTW, I boiled a bunch of features down to the concept of the 'keyword' which you enter into your device, and which is sent to the server when you ask for a list of StarMap Instances. So, your pals might want an easy way to get together without having to scroll through the instance list, so you agree on a keyword (you might think of it as a password, though no effort is made to secure it), and then the server only tells you about StarMap instances using that keyword.
If no such instance is found, the server makes a NEW instance, and sets that keyword on it.
Then the SECOND guy to show up, uses the same keyword, and this time is given just the one instance to choose from.
Anyway, so if KEYWORD becomes KEYWORDS and 'what the server does' gets all complicated, this could be used to do lots of useful things and conserve resources. But for now it's just a way to find your friends (and the instance still appears on the list, so it doesn't keep out strangers, which I don't want to do, at least not until there are enough strangers to make it worthwhile.) No changes to keyword yet... wait for properly game agnostic inspiration.
----
A more meaningful example of game state might be, the capture the flag game, whose rules are:
* team game, left thumbs versus right thumbs
* each team has a flag, that spawns automatically, in their 'fortress'
* each team fights their way into enemy fortress and tries to steal flag
* while carrying flag, your ship is slower and weaker and cannot use weapons (using any weapon drops the flag)
* getting killed while carrying the flag either leaves the flag where you were and players have to carry it back to the fortress, or maybe it just respawns immediately, or after N seconds (yeah, N seconds!)
* if you managed to survive stealing the flag, you carry it back to your own fortress and drop it somewhere (on top of your own flag seems odd, but something). Anyway, if you do that, you earn a point for your team, and the flag respawns back at home base.
* there is a score indicator somewhere on top left and right
* gameplay ends at N points... Or maybe it's a remaining flag counter and counts down with each successful theft
* maybe getting a point also recharge's all the ships on that team, tops off their favorite ammo.
* probably don't allow smart weapons on such maps. So the powerup list in the starmap should call out all the legal powerups on that map, serving both to limit those which would be unfair, and add something unique to that map. use case: could I do tractor beam as a pure script extension? What game mechanic would be needed to support that, and could that mechanic be leveraged by the script into doing more than expected. I guess adding springs and struts, and the ability to turn them on and off and adjust their behaviour. And a selection of render effects while they are in effect. But I don't want to invoke lua every frame to get position update info, so complex paths need to be defined... parametrically. And maybe most of that could be static data, in the starmap.
With the gamestate just being "ship A started Tractor beam with target on ship B at time T and expects it to last for N seconds, please animate accordingly"
timeline:
the client who launches the tractor beam sends a packet to the moderator saying that is what they want to do.
the moderator confirms it is ok for them to do that, and sends a packet to all playsers saying what is going to happen
all players (even the mod) receive that packet, verify it was from mod, and obey it (by passing args to the game. object using a known syntax for 'physics/particle' systems. So the designer has to pick from a menu for the visuals and pre-declare its data in the starmap, so when the very small packet arrives, the scripts can do much larger things.
============= so, the dynamic state needed is:
* overall game status (starting, inplay, over) * score for each team * where each flag is (or who it is attached to)
controls include
* moderator resets score, recharges all ships
packets include
* please reset your copy of state (as desribed in starMap) status = playing
* flag X now held by ship A
* flag X now dropped at XYZ
* flag x re-spawns to home location (as defined on starmap)
* score is now X to Y
* status is now over
game mechanics (requested by script, but not performed by script)
* ability to carry something, a flag
* changes to ship performance while carrying
* detection of ship-in-zone and ship-near-flag
game state access
* current position of ships
----
I think that's about it. IN fact, I already implemented CTF in java, at least mostly, and I should probably undo some of that and turn what I did into hipefully reusable mechanics, where you can substitue other things for 'flags' and 'text descriptions' and such.
But yeah, what if you had to use a tractor beam (that only existed on this map, and was entirely described by one line of the starmap static state) to drag flags around. And some flags were heavy and required 7 engine pods pulling on them, so you only have 5 pods, but your friend has 4, so you both use tractor beams at the same time and you manage to pull it. But you have to travel in the same direction, since the tractor beam breaks if it is stretched out too far (and the victim is always pulled towards the center of the rubber band you and your friend are holding the ends of.. as it were
that sounds fun, and you can shoot awhile using tractor beams, you are just forced to move kinda slow and thus are at risk. maybe.
So the same thing, only instead of a flag, it is a meteor, and it is slowly moving towards some planet, and you have to drag it into the sun instead. and it takes all eight of you pulling on it.
but three of you are traitors from another star system at war with this one
it writes itself! that's nine maps right there! :-)
but yeah, if only you could think as little as that, and quickly open the spot where typing just a few words would make it happen, and one button instantly publishes it.
and then easily filter out all the crap :-) In theory, I can be looking for simlarity between starmaps in the background and sort of auto suppressing the duplicates.
--------------
so the script in this case, in its onMsg handler, needs to handle/send the notification messages above, as well as maybe a periodic heartbeat (the script would ask the game to provide one, maybe only on the moderator) so it could check for things like 'tractor beam is pulled too tight' and 'the force of the tractor beam is appling this much force to the asteroid'
the asteroid itself being some sort of pre-registered sprite with known physics, so the game can just advance its position nicely, and tell the script about any collisions. That way it could also use real graivity for the scary object that is careening throughout the system and your handling of the tractor beams could be done well or poorly, resulting in the asteroid not careening INTO the sun, but just slingshotting AROUND it.
actually, even if that was a canned 'movie' driven by the script, it could have merit. "you lose, the asteroid circles the sun, comes back, and smacks the planet, and it was all your fault."
starmaps cannot give you currency. well, not the galactic credit you get for bounties on the drones you destroy. But a starmap could have its own currency, and remember how much its player had during the game, but likely forget it when you left the map.
Still Rune Runner needs persistent map-player storage (multiple rune runner characters on the same device, played sequentially on the same map, must each remember long-term their own state in that map. So maybe it wouldn't hurt to get that started in synSpace.
but tread carefully, I don't want synSpace the game to give a battle advantage to someone who has been playing longer. It's not an RPG in that sense (rune runner is, though).
Man, that's tricky. It's important that synSpace at least start as dropin melee with no persistent skill memory. (just persistent personalizations and stats, but not battle advantage in subsequent games).
but if if COULD give you a sens eof persistent skill level, that maybe DID confer an advantage, on some maps...
If nothing else, I sitll haven't nailed the 'unlockable' stuff. I think that's the same as achievements in my case, just some achievements don't show up in the trophy case (you unlocked map 3) and some do (you conquered santa claus with your robot martians)
So really, just two more collectible types, that are mainly used to track quest progress and unlocks.
and I was worried I would need to preload the entire table, really these can be um.. federated.. by map assetid. and then I only need to preload the ones for the current map you are on, so that's nice.
I guess I already went through this. For map storage, I need a unique key for each map (so 'tokens' for one map don't get overwrtitten by another). But you might have multiple releases of your world, and each release gets a new asset id, so that would erase all your progress. I mean, it might be cool, but it probably would not be. so I decided the unique world key would need to be a co,bo of your publisher sernum and your mapName as declared in the starmap file.
then the storage of player tokens could be the same for multiple releases (assuming yur publishing sernum stayed the same). And you could FORCE a restart on players if you WAMTED to, bu changing that mapName in sunsequent releases.
Your sernum is included to handle the case where someone else uses the same mapName. But yeeah, that was what I was going to do for the Rune Runner quest token storage.
(currently rune runner only has the one map, and so I just save this state in some boring way that would not handle multiple maps, or at least not elegantly
------
Oh, here's something scary. Andoird has this SharedPreferences object where you can store little notes to yourself and get them back the next time you play. Set up to be very easy to use.
Unfortunately, for me at least, it has been super unreliable and it is very easy for it to become corrupted and then the next game launch it comes up empty, having forgotten everything you stored in it.
For synSpace, that is mostly your currently selected ship SHELL and pilot FACE. But it also includes your freaking SERNUM (your publishing SERNUM that you need to hold still).
I've struggled with this for literally years, assuming if only MY code were BETTER, it would never happen. But I have heard too many horror stories, and too few good explanations, so I just don't know anymore.
Anyway, it happened again (tends to happen when I run under the debugger, but also after certain system crashes), so I got up the gunmption to make a change. So now I store mission critical data in two spots. At boot, I check both spots, make my best guess at the correct answer and correct aeither spot that has gotten it wrong.
Since one spot is pretty much completely static (the SharedPreferences is used for lots of other stuff which comes and goes so the backing storage gets a lot of exercise, my second location is used for nothing but this purpose, and has been working well for some other datatypes I stored there before switching to storing all the assets inside the sqlite database.
Anyway, fingers crossed this is the magic answer, as that's pretty darn unnerving when it happens.
The sqlite DB, knock on wood, has never had a single bit of damage, as far as I can tell. When it finally does, it will be catastrophic (loss of all collectibles).
"Gotta Get 'Em All... again!"
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
dang, i have wanted tractor beams for a long time now, but now the thought of them being modelled with a spring system has me all excited.
* I pick up a power up, it's 5 blasts of tractor beam!
* I tap it to start one blast
* beep, this requires a target, please select a target first
* I select a target
* I tap it to start one blast (still have 5)
* something mesmerizing appears bewteen me and my victim, and lets say it remembers the distance between us at the time the beam started
* since I initiated the tractor, I am its authority, and I am the one who decides if the distance between me and the target is ever too much and snaps the beam, in which case I tell the moderator and he passes it along to everyone that my tractor beam has turned off.
and the scene host (moderator)probably sends semi-regular position packets for the asteroid (like maybe the state is "percentage completion of one orbit" and then the static data has this cool path that the asteroid follows through the star system, that threatens other areas at predictable times. Save the four planets!
But my tractor beam applies a force that pulls the npc out of its 'patrol' loop and that motion.. well, anyone who can see the action is doing the math locally as best they can, but probably are not exactly the match of what I see, but it's my tractor beam, so what I see counts.
but the point is the NPC does have 'real' physics, with position, velocity, and forces, but those are used mainly to 'nudge it towards' some set of waypoints so that it travels roughly the same path over and over until disturbed. Once the disturbance is over, it drifts back on course.
during the fight (pretty sure I am repeating myself by this point) it has me as its enemy and periodically moves towards me to keep me in weapon range until it cools down enough to return to its patrol path.
maybe after several orbits of the galaxy, one piece of map state changes "asteroid has decided to hit planet on this next time around". The moderator script announces this when the asteroid has reached some starting criteria trigger (it's in this zone, and it has been disturbed three times) and we see some text announcements and the npc is set on a new path, one that snakes around to end with collision with little helpless planet, who has started to blink and send us radio messages and such. Probably reaches out to us via facebook. "We'll be dead in three hours! Come save us! [click here to get android app]"
NPC descriptions (planet, asteroid) would be in the starmap as static data. Then the game would provide realtime position/motion per agreed, saying "it is this far in its orbit, it should be exactly HERE, so I will start nudgeing it in that direction" so it may be temporarily off course due to some battle AI, but then drifts back into its designed route, so you can have multiple threats that can only be avoided with certain patterns.
for path stuff, you could set some simple waypoints in the starmap static data, but a one-time computation on script load could turn that blocky data into a much smoother and mores interesting 'rail' that any npc could be induced to travel.
when needed, the moderator script would decide that a course correction was needed and would send a packet to all players 'npc 0 is 3 seconds from arriving at waypoint 79' and any client whose copy of the NPC was very far off course, would render it playing catchup to esthetically, but rapidly, get it back on track, without actually needing to distribute its xyz,
Should an NPC get into a fight, the moderator would announce the start of the fight, then everyone would see their own private copy of the npc ai doing its fighing, but only the player taking damage was the authority on when he had been killed, so you don't see me blow up until I say I have blown up.
At which point, the NPC would leave battle mode and return to patrol mode, and the moderator would send a correction packet.
DURING the battle, the moderator script is deciding which weapons the NPC uses (seconds between decisions, though some weapons fire continuously) and NPC steering decisions are either local ai (might vary from device to device) or determing by actip ai on the modearot and then distributed as economically as possible via message/packet.
blah blah blah... another fine mess :-)
Well, I feel better that I can empower the creation of something fun. I like open-ended.
same spring mechanic could have a 'spider web' weapon that made you stick to your team mates for awhile. Or even on purpose, where you can still rotate and shoot, and fire engines, and since it would be springy you would see your ships try to pull apart when firing in opposite directions.
so.. during the part where I compute gravity effect on an individual ship, I also apply the effect of any tethers on me, probably from the previous frame... and then I apply my change in position to anything I am dragging. Anything along the way which can no loner move, just stops and the tether stretches (applying greater counter force) and eventually snaps.
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
OK! It's the weekend! My goal is to have at least one starmap with a scripted 'game' on it.
Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
so far, I have just defined the new starMap sections
[properties] game.unrated = 1 ; fights are 'unrated' on this map
Basically a set of name/value pairs that are defined in the starmap, then can be read both by the game itself and the starmap script (if any).
Anything built-in to the game will start with a name like "game." and anything else is somerhing you made up for the needs of your script, and the game doesn't care.
----
[assets] shell.Boss = "" face.Boss = ""
This section lets you use friendly symbolic names inside the script itself, and then this table BINDs those friendly names to actual assetIds (and uses default assets until that binding is done
As a scripted map developer, this means you have a separate operation to bind the asset ids (well, you can also type them in ahead of time, if you KNOW them -- this is to make it so you never have to type the full zillion digit number, but it means you might have to repeat the work later)
Bubt this also allows third party map designers to re-use your map, but change the shells, music, etc. I think that's a good thing, I hope it's not a bad thing. It let's you do it, too.
So now I get more into the [SCRIPT] section to make my first mini-game...
And oddly enough, I think that means I need to provide 'scripted moderator buttons' to give myself a starting point.
If defined, these buttons just go on the existing OPTIONS panel (someday in their own section). Maybe at the top.
These need to be able to come and go as map state changes, so I guess the script should send messages to configure them. And should probably maintain some local state to remember what it set them to.
So, I guess I first need a message from the player, saying hello to his local copy of the script, in response to which the script can do things like configure starting ship weapons and enabling the appropriate option buttons.
That should happen at launch. So my first message will be "local ship just launched"
And I might as well provide the info about my ship at that time (customizations, in case the script cares.. or maybe I should curtail that sort of thinking and only add things as I absolutely need them and not try to think ahead too much yet.
source 0 means "from the game itself' dest localScript just routed this to the local script. the 'command' is LAUNCH, and the arguments include the ship index. which is, for this message, always the index of the ship being played on this device.
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
whew. that was harder than it looked :-) But I finally have my first real messsage, LAUNCH getting all the way to the script that was part of the starmap.
still struggling with the arguments though. I want to provide them in a format that makes it easy for lua, but so far I haven't managed that, so I am coding some special lua to turn a urlArg string into a nice hash array, but contrary to what half the internet says, lua has no 'split string' function, and my current setup is pretty weak on delivering error messages to me, so it's fairly tedious to debug simple syntax errors.
not blaming Lua there, I just have a ways to go in my engine to make these easier.
but hey, step one complete: game sending events to local script.
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
Sunday afternoon and I finally reach step 2: successfully receiving a
game.sendMsg(to, url)
in the game, from the script, in the middle of handling onMsg.
The problem is that I make lots of simple syntax errors typing lua (especially when going back and forth between java and lua), and pretty much any syntax issue at all crashes the script (but not the game! thank you threads!)
I detect the script crash via some exceptions it throws. The exceptions include a String with a text description of the reason (syntax, nil pointer, etc) and a large amount of the script text, and a bunch of colons that sometimes seem to imply field separators and one of the fields LOOKs like a line number. So I went ahead and extracte what I hoped was the line number where the error occurs, then I offer a Script Debug panel (opened via the options panel) which shows the offending line from the script, along with a few lines above or below
So, that helps a lot, but the line number doesn't seem to be correct in all contexts. Sometimes it is correct, sometimes it is off by 2, and sometimes it is just crazy.
But it works, and it makes it at least possible to debug your lua code, slowly....
Anyway, lots of issue with exceptions I had not wrapped in try/catch (which then DOES crash the whole game, not just the script), and some thread issues (objects allocated in one thread being looked at by another). Polished my way through thoses until the API so far felt 'rugged' and started to focus on that callback
local result = game.sendMsg( to, url )
where url is the 'command' and 'args' in a single string, as
url = "LAUNCH?ship=1&name=Billy"
It's always fun to see how things actually come together after all that upfront 'designing' (aka talking to myself in public :-)
Anyway, it was crashing with a complaint that i tried to use a nil pointer, so I assumed I had a problem with my 'game' object, so I 'wasted' time making that all robust and logging-heavy until I was sure that could not be it.
Then I looked at the line number/error display page again and realized that in this case it got the line number RIGHT and was NOT complaining about that line at all. It was complaining about the log just before it
Log(1, "some helpful info for debugging")
And, of course, my log function is actually called "log" not "Log" so THAT was the nil function! Not my fancy game object, just a boring old function whose name I couldn't manage to type correctly :-)
It's funny that I felt I had already finished the basic plumbing, but life is in the details.
But NOW, I have finished the basic plumbing, RIGHT? It's all commands and services from here on.
The separation of thread and state is working well, though. Some serious lua coding flaws don't cause the game to choke at all! No blocking of primary UI thread, I mean.
But I already finding myself wanting to just add a mess more functions, since some things I just want to ask for simply. Like, I want
code:
local iAmModerator = game.iAmModerator() if iAmModerator ~= 0 then doSomethingOnlyAModeratorCanDo() end
But I guess that's not made all that much more tedius by
code:
-- define some state Ids local stockStateId_IAmModerator = 23
-- fetch one of the named state fields local iAmModerator = game.getState( stockStateId_IAmModerator )
Yeah, must resist the temptation to broaden the api. focus on making it easier to parse the args
Oh, come to think ogf it, there IS more plumbing. still have to do the message routing for proper remote message handling... and then whatever limitations I feel I need to impose.
---
still, I declare step 2 complete: lua sending messages to game via game object and new api
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
I had Lua successfully calling thtough my ;game' object into java code just fine
the problem is that it was just invoking functions in a helper class, and there was no way to get from there out to the real game clasees, so I could only use static functions, which is useless
plus this was happening inside the script thread anyway so I didn't really want to implement the service there, I just want to shove the message into the output cross-thread queue
but for that, I needed a reference to the ScriptedThread object that ran the script that made the game.sendMsg call.
because I was a little weak in my understanding of how lua loads libraries, it took about 3 hours to finally understand this.
being pedantic again.. I was loading my 'game' library using the lua 'require' keyword and providing the full backwards url name of my class 'GameFunctions' which was written very carefully to meet Lua's (LUAJ in particular) standards, such that the require command could find that class and make one out of the blue (with absolutely no hooks back to my game code) and register it in the lua environment as an available aource of functions.
so it worked great, but had no way of telling you the name of player 3.
I *wanted* to include a reference back to my game framework as part of the constructor for class GameFunctions, but the lua require wanted to invoke it with no arguments and that is beyond my control. (well, I could alter the lua source, but let's not go there)
But EVENTUALLY it sank in that using the 'require' command is just an unneeded burden for the user, since I could link it to the environment myself, and when I did that I realized that now *I* was invoking the constructor directly, so then I just made a new constructor that passed the framework and now it's super cool, and the game.apiFunctions() can now access the framework, and from that they can safely find what they need to get the packets queued from the proper thread.
Then in the main thread, I basically just poll that queue when I have a moment, and THAT's where the command parser lives and routes things off to appropriate services, or off-device if they need to access a remote destination
and THAT'S where I am now, but time for x-files. Not sure if I will meet my weekend goal.
I should also be doing this via the gdrive, since it's a major drag to edit lua the way I am right now (requires a clean build each time)
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
So far this weekend, I have mainly just been polishing things for release, which in this case meant adding some real buttons to the microphone/spectral recorder thingamy.
I found this video from a while back. It's a spectral recording of an Evanescence song with AMy Lee. It survived with some remaining musicality
I added some colored markers to illuminate how the recognition stuff was working, and that led immediately to some obvious improvements in peak detection. Now I just have to make the piano roll use the same technique.
Anyway, back to scripting now!
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
-------------------- SoV: Exalted Devout Oracle | World Developer | The Black Guard Outside is just a prank older kids tell younger kids at Internet Camp Posts: 9532 | From: NY | Registered: Apr 2003
| IP: Logged
quote:Actually, while I would love to honor Golden Souls in the android games, I don't think I legally can as it would represent "selling in-game features, but not using the Android Market to facilitate the transaction"
So if there WERE an android GS, it would probably need to be bought in game, and possibly each game would have to do it separately.
One thing I've seen other apps do, Titanium Backup comes to mind, is there is a "free" version, and for extra features there is a paid separate app that the free version checks for. If the free version sees the second paid app, it unlocks all the features.
I know it works as early as Android 2.3, there might be an easier way of doing it with newer APIs. What is the minimum version for SS:DR (synSpace: Drone Runners)?
-------------------- SoV: Exalted Devout Oracle | World Developer | The Black Guard Outside is just a prank older kids tell younger kids at Internet Camp Posts: 9532 | From: NY | Registered: Apr 2003
| IP: Logged
posted
I probably already mentioned this way too much, but I now get regular injections in my eye, and today was one of them, and after that I am pretty much blind for a day. I certainly cannot, for example, read what I am typing. But I can see the keyboard, and I can see blurs appearing in the edit window, so I know something is happening.
---
Anyway, but it also seems to make me talkative. The injection itself is not as horrible an experience as you might imagine. It's of a drug called Avastin (whose name is way too similar to the drug Avandia which pretty much started all my eye problems), anyway Avastin is a cancer drug, buwith some bad news of its own, but in my case is being used off-brand in very low doeses to counteract teh effect of a VEGF build up in my retinas that leads to defective vasculature growing and causing swellings in the retinal surface, which you want to be as flat as possible.
Anyway, vasting is magical and brought the swelling down immediately and while I have been continuing to use it for about a year now (monthly), well, what to say. I mean, it'd a miraculous godsend since I was pretty much sure to go completely blind. And now that eye is super clearly focussed, outside of the regions damaged by the Avandia. But it;s kinda risky to have the injections as each time you open yourself to the risk of an infectino and your body is just not equipped to deal with infection inside the eyeball. bad outcomes. ANYWAY, I have just grauuated to the ever EIGHT qweek club, so that's nice. It's also kind of expensive, though much cheaper than all the alternatives (the official drnu your SUPPOSED to use is like two thousand dollars per injection. But the avansia is more like 200 on the far side of insurance.
did I say avandia there? I meant Avastin. avandia is the bad evil drug I should never have allowed to be prescribed to me. Always do your own prescription fact checking before starting any new regimen, even if your doctor suggested it.. Just goole "<drug name> Lawsuit" and you'll quickly get nan idea of what the real risks are. The risks were already well known for Avandia when it was prescribed for me, so I totally could have dodged that bullet, if I had just been more on the ball.
But the Avastin (genetech) has been amazing. And in theory it might actually be doing me some good elsewhere in the body. This will probaby turn out to be something that works just as well in pill form someday :-)
"what? no more needles inserted directly into my eyebal?" darn this century!
-----
I had fun working on the vocodor last weekend, and I apologize for not meeting my scripting tasks. It's good to hae multiple projects to go back and forth between as sometimes it turns out you weren't quite ready to solve a problem yet, and a much better idea comes up in the doldrum.
I was up till 5am last night on a work project that was kind of exciting, though it didn'tamount to enough progress on that project yet. Mainly I had to re-learn out to use GMAX and then make something that a real 3D artist could have done in ten seconds probably, but took me 8 tries of develope/export/link/test. But it was exciting that I could do it. Short turnarouns tme between positive feedback is key to progress. 30 minute turnarounds are the death of innovatin.
espicially if yuo have to work in as small of bites as I do :-)
oh right, the eyedrops lead to migraines, I forgot (it's been 8 weeks!).. actually, I need to deal with this... and staing at white screen will not help.
-------------------- He knows when you are sleeping. Posts: 11014 | From: California | Registered: Dec 1998
| IP: Logged
posted
I've been following the development and enjoying the videos of how it's coming together. It is a really eclectic project, very "syn-real"-esque and I just really hope this work is not slept on for too long by those who would be really interested and could come to gain from it. Best wishes etc..
-------------------- Word is born. Posts: 8539 | From: NYC | Registered: Oct 2002
| IP: Logged
Printer-friendly view of this topic
