posted
The synthesizer has always understood the concept of 'stressed' and has 4 stress levels available (muted, weak, normal, heavy)
But since my piano keyboard is not velocity sensitive, I just hard wired it to heavy stress.
The vocoder, in piano mode used to also just do this, but as of today, it will try to grab stress info from the spectral recording as well.
also, the track editor now depicts stress in the note color (brighter is more stressed), though I suspect this will need some tweaking.
Anyway, it may or may not be an improvement, but stress is now 'plumbed' all the way through the engine.
I also lowered the squelch again, so the vocoder will try to work with even weaker signals. Also, in the spectral playback I now do a little better job of retaining 'stress' and I think that improved the sound of the spectral recording, without necessarily improving the piano roll sampling.
In voice mode, a straight vocoder playback is dangerously close to being comprehensible...
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
hmm, just added build 5 to the Kindle Fire app store. That should be interesting. Import from Google Drive is a no go in that case, but otherwise should be OK.
I have mainly been testing on Kindle anyway, since the Nexus devices are 10x the price. But I have to use a Nexus to import starmaps from google drive.
Amazon reached out to everyone with an app on android several years ago when they were starting their own app store. They wanted a $100 annual developer fee, plus you had to make a special build. I said NO and they reacted as if I'd said yes, which upset me no end. So I swore never blah blah blah. But really it was the 'you need a special version'
Anyway, a year or so ago they sent another email saying you could submit the same binary you used on google. At that point, I was planning to get around to it, and this evening, I did.
Of course, they have a review/approval system and it might not get approved.
But this is what I asked for (same APK, multiple app stores), so I'm happy. They also have something else I always wanted (though not using it at this time): pay by the minute.
As I understand it, the apps in the Amazon Underground program (not me at this time): 1.) are free (at least temporarily) 2.) incur income for Amazon somehow (ads, one assumes) 3.) amazon kicks some of this income to the developer, based on total minutes of gameplay.
The price varies around the world, but looks like about 12 cents an hour in the USA. If they can really really funnel 12 cents an hour to the developer while being free to the player... well.. sounds good to me.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
passed review, synSpace: Drone Runners now available from the Kindle App store.
That's good, I think it's the most fun on a 7" tablet like the cheap Kindle Fire HDs.
Now, in the amazon set up, they make reference to making 'google play services' available (while on kindle), but it doesn't seem to do what I hoped it would (enable import from google drive). I think GPS offers an interesting API though, and maybe that part becomes available on Kindle. The part where you can schedule a tournament, and then have all the clients check in with their opinion on what happened, then the google server filters out lies and updates some tournament data. I bet they even add twitch to it someday for live stream and replay...
This Amazon UNderground looks increasingly interesting, in the 'put your money where your mouth was' sense, since I asked for this repeatedly through the years.
---
random money idea... game money, I mean. Some system where you start with N gold pieces, but that value of N is increased with gameplay objectives met. The idea being you would spend that money at the start of the map, to pre-stock some powerups. And the money would run out.
But the next time you played, it would be back, and would never be less than it was before. It's like your 'money level' which you are busily RPGing to infinity.
The pup store would probably have to be pretty expensive, with progressive increases. first purchase of heal pup is only 10 crefits, second is 20, then 40, etc.
but, and my point is, you don't mind spending profligately, since you know it will all be un-spent at the start of the next game.
Basically, "what ZZ said"
Maybe I should take the WarPath/synVille metaphor and call it a 'credit line' so that's what is going up, and each game starts with 0 debt.
Then, it could also trigger something like interest and due dates
Now, this wouild presumably change the existing credits counter or add a second one (creditLineTotal vs creditLineAvailable vs cashOnHand vs totalSpent ) And the bounties would be paid in credit line increase, not cashInHand.
And everyone could start with an initial credit line, so old-timers are just grown from there, as opposed to everyone else having 0 credit.
uninstalling the game clears your win/loss stats, but also your credit history. I guess I would have to be really really clear I was talking about pretend money.
so, practically, this becomes:
* maintain both a max credit line, and an available credit remaining, for each player. * bump the max credit line by the standard game 'bounties' (when earned, but no actual cash in pocket from it) * on the pre-launch config screen, offer a PowerUp Shop, which offers (per starmap settings) certain stackable powerups, sold at progressively expensive prices, using available credit line
Which means, any bounty you earn in THIS game, only benefits you in the NEXT game, and there is a fixed amount of money available to you for the life of that ship (your max credit line amount).
credit line is what the clone factories consume to obey your manufacturing orders.
I *could* owe interest every minute and it *could* be a game over condition when you ran out of funds, which would be inevitable, you would just be trying to delay it, by not spending it.
---
yeah, a basic income, as it were, paid each time you configure your ship, maybe there is another shop somewhere once you launch, maybe not, starmap decides. New bounties are reflected in your subsequent basic payments, which only ever increase, the more you play the game and earn bounties. Starmaps cannot hand out bounties, but can control the pricing of PUPs to gate availability and avoid a problem with overpowered "1 percenters"
Probably limit it to just a handful of PUPs, instead of a scrolling list of everything. Maybe a new class of ship extension for stuff like tractor beam, that you want to permanently equip to your drone (but have to buy a new one each time you blow up, but you get your basic income, so you can always afford what you started with last time, and maybe a little more if you earned any new bounties.
So maybe 6 offers max. And maybe I remember the last setup you bought so you can just buy it again, or it is just automatically assumed you will buy it again, like it remembers your previous SHELL. "it remembers your previous purchase count for each available item"... now, I guess that COULD fail if the starmap changed prices, or if I don't want to remember a separate pack for each map, yeah, maybe I will force you to shop every time.
Rambling on further about the store. I am fooling myself if I claim it won't need to scroll. I should just obey the starmaps list of powerUp ids, counts available, pricing algorithm (ooh, could the RED thumb have a pup that only it could afford, and was priced out for all other thumbs?)
So a tile for each PUP offered, shades of WarPath store. Separate +/- buttons to add them to your 'shopping cart' with live updates to remaining credit 'at end of transaction' and then you tap to commit.. or not.
[scrolling list of goods, for which a count is shown of how many are in your 'cart' and +/- is available to adjust count, and count is maybe remembered from last time]
AVAILABLE CREDIT: 12,345 COST OF GOODS SELECTED: 13,000 YOU CAN NOT AFFORD THIS vs [CLICK TO PURCHASE]
---
Of course, the SMART thing to do is sell credits for USD, and I guess I couldn't rule that out completely, depending on whether it looked like it might work. But the nice thing is that the metaphor still holds. Maybe someday you can in-app-purchase more creditline, or just collect it naturally by playing.
The only difference is that I let you keep the credits as it were, so there is no ongoing need to buy more credits, once you have enough credit line to optimally pre-equip your drone. That feels OK to me. It's manipulative to try to pull another few dollars out of the player to accelerate a convenience they could obtain for free, given a non-infinite amount of time, but not TOO manipulative. And there would be a practical limit to it, so no stories of kids spending a thousand dollars on the app.
Personally, I like the thought of getting more income from regular players (if only to have an income stream that scaled with server costs), but with a sort of lifetime cap, so the business model could have smart stuff like expected income from each player, and expected duration of player interest, and getting that balanced right so everyone is happy at the same time, and the experience is pleasant enough that over time a million players could move through the queue. Hopefully not all at once. And if the game could hold them for 100 hours total, that's about $10 income, spread out over their life cycle. And if that was magically paid by ads so free to the user without being obnoxious... Well, I oculd be very happy receiving that income with no guilt.
Or maybe 100 players at 10 hours each for lifetime income of a hundred bucks. I would be equally.. well.. maybe not EQUALLY.. happy seeing that income.
I did see one new user around 4am, from an Indian IP address. Only on for a minute. I'm thinking maybe that was the amazon 'review' that I passed. If it was a real player, then it wasn't a very positive experience and they certainly did not get through the tutorial.
I guess this belongs in a blabbering post, other than maybe I will add the credit line stuff and store soonish, though this is probably going to take me over the edge and allow lua some direct rendering calls. Like let lua declare a new bitmap of some size, and give the script an api to draw lines, text, and rectangles, and maybe some real art now and then on to that bitmap. And then the game engine would render that bitmap to screen at appropriate moments. So the script would not be re-rendering the content 30 frames a second, just making little snapshots that only changed every second or so. Maybe a score card.
let the map define some hit rectangles and messages to be sent if I see a tap in them.
Maybe a slider control or something, for fancier than a tap, controls.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
I agree getting the extra income while keeping players happy can be difficult some times.
You could possibly make specialty items that could be unlocked either by paying for them or through watching videos. Of course it would take longer for players to unlock it with videos, but they are getting it for free afterall. It would probably be better and easier if they would be unlocked for the game and not particular star maps.
Some ideas for the game unlockables could be: Tractor beam (which you seem fond of) Repel beam (reverse of the tractor beam) Cloaking device (make player invisible for a period of time) Reflecting shield (instead of absorbing damage it reflects the projectile)
Another idea for an item (not an unlockable) would be a "chaff" type. Something to throw of those pesky homing missles. Probably should have put this in the suggestion box.
posted
So, I was thinking about pathfinding for minions, so they can travel a maze to find you.
Anyway, that turned into an experiment to take an existing map and compose a list of rectangles representing all the discrete locations on the map, then form a list of connections between locations.
Then I can answer questions like
* which rectangle is (x,y) inside of * find a sequence of connections between rectangle a and rectangle b, if any exists
The code is quirky though. For some reason it eeps seeing barriers I already removed.
But it's kinda neat, sort of.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
I'm not doing anything officisl. I am just tryng to tessellate the map with rectangles, such that every barrier divides the space in two. Sort of.
then I can determine which rectangles 'touch' and which 'are connected' (touch and not blocked by barrier)
Then when I need the path from A to B, i just search the connections list for a seuence of hops between the rectangles containing A and B
I think I might be doing a form of Binary Space Partition, but I dunno.
Add to that the natural looseness of an NPC flight through space since it is not just following some line, it is firing thrusters when it thinks it is pointed in the directin it wants to go, so it overshoots and loops and weaves
---
today I worked on something completely different, but it boiled down to lua code that generates a DOTA map and places spawn points for 2 four player teams, each trying to destroy the clone factory of the other.
Here's a snippet
code:
-- This is for two teams (east vs west) of four players each. Each team has a spawn -- location containing its Clone Factory. (these are at opposite corners of a closed -- star system -- no wraparound, because of barriers. Goal is to destroy enemy CF -- and protect your own. You must fight through gates and minions and then destroy -- the Factory core.
-- It can also be played in 'tank' mode (where friction stops you any time you stop engines)
-- The session moderator can start a new Battle at any time (interrupting the current one, even) -- and moderator-hood can pass from one player to another if needed.
-- Players are moved to spawn location and held during countdown, weapons and engines frozen. -- Separating the two bases are a series of gates, with -- two stationary Towers per gate. You have to destroy both Towers to open that gate. -- Gates will shoot at one side or the other, and possibly both, when you get in range. -- If you die along the way, you respawn. Towers call for help when attacked, and minions join the conflict -- -- There are three paths between the clone factories (you spawn near your own CF) -- going through the center is more direct, but exposes you to unknowns (and powerups) -- -- minions spawn automatically and travel to points of conflict to assist their team -- -- Typical map. In this case, this map is generated completely by the API instead -- of being defined in the top half of the starmap. I compute a set of points and -- then create barriers/gates connecting those points. -- -- 0-------------------1-------------------2-------------------3 -- | | | | [A] - destructible gate -- | [A] [B} | # - point number -- | | | EAST | * - dangerous star -- | 4-------------------5 (CF) | (CF) - Clone Factory -- | | | 25 | {A] - gate friendly to WEST -- | | [C} | [A} - gate friendly to EAST -- | | | | -- 6---[D]---7---------8 9--------10---[E}--11 -- | | | | -- | | * | | -- | | | | -- 12 --{F]--13---{G]--14 15--------16---[H]--17 -- | | | | -- | | | | -- | WEST | | | -- | (CF) 18------------------19 | -- | 24 | | | -- | {I] [J] | -- | | | | -- 20------------------21------------------22------------------23
-- lines are fixed barriers (non destructible) -- Your home reactor is a healing point, or maybe there is no healing point. -- Script is multiplayer friendly, knock on wood, and survives change of mod -- in mid game.
-- control points, as globals, why not local maxG = 8000 -- size of starmap, minus a bit for borders and cowardice local borderG = 32 -- collisions need to avoid edge of starmap
-- is used to remember which H/V barrier offset we used, and current state of gate -- state 0 (dead) 1 (alive) -- { gateIndex, H0/V1, barrierIndex, state } (barrierIndex will be written to as barrier index is assigned -- gateIndex is also used to get npcIndex = npcBase + 2 * gateIndex gates = { {0, 1, 0, 1}, {1, 1, 0, 1}, -- A B {2, 1, 0, 1}, -- C {3, 0, 0, 1}, {4, 0, 0, 1}, -- D E {5, 0, 0, 1}, {6, 0, 0, 1}, {7, 0, 0, 1}, -- F G H {8, 1, 0, 1}, {9, 1, 0, 1}, -- I J },
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
Here's an example of my attempt to partition the map and establish a list of rectangles and their links to other rectangles. This is for the really simple standard map which only has barriers for two square zones (points 13 and 11) and then the fuel depot down in the lower left (points 12 and others) which is more complicated because of those little recharge paddles. Possibly for my purposes I could ignore small barriers, so long as they were not connected to other barriers. [IMG] http://www.synthetic-reality.com/drone/bsp1.jpg [/IMG]
The white numbers are in the center of the rectangle they represent. The blue lines are connections where it feels you could travel straight line without impact. What it is trying to say is "if you are in this rect, any position, then you could head directly for the center of any connected rect, and not hit anything along the way"
So path finding is just finding the connection list between a start and end rectangle, and following those as waypoints to the 'next rectangle' center. Once you get to the end of that you switch back to 'chase the target'
And, of course, if the target moves or barriers change, you have to readjust your thinking, though one level of AI should definitely be stupid about it. "duh, dere he is, I go dere!... plod plod plod.. hey, where he? what behind me hurt bad?"
So this simple map generated 27 rectangles and 36 connections. Which seems likely to explode exponentially with more complex maps. But on the other hand, so long as the barriers don't move, the incremental cost of computing a bot's path for the next 30 seconds is not very much at all.
Note that rectangles 11 and 13 have no blue connection lines at all (they are the two flag zones)
Technically, there are additional connetions it could add, to achieve fewer waypoints and more direct paths, but one goal is to keep the connection list length as short as possible. Like I could probaby get from 18 to 5, without hopping through 4. But I can definitely do it with the hop, so I accept the little jog in my trail for that.
Here's one for the tutorial map, which has 8 additional rectangles, with half bars, plus the flag zones and the fuel depot from the first map. I exceed my 100 rectangle limit here.
posted
ANYWAY, probably won't be anything useful in this release from that. But I think some combination of adding all possible rectangles, followed by pooling into the fewest number.
The existing navigation AI is such that the bot will beat its head against a barrier forever, without going around it, but the natural physics lead to some bouncing around, and that's how it will always get through narrow pathways. Pathfinding just needs to know 'there IS a hole somewhere along this edge, so its POSSIBLE to get there' Then I subdivide a rect if it has distant corners that feel like they would have trouble bouncing to the right place
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
I would think using the A* method for waypionts would be easier. Then have the ship's movement AI determine how fast/slow it needs to go for aproaching turns. There should be some swaying back and forth to make sure it hits it's marks and to make it look realistic when it comes to turns. Later tonight I'll give a better explanation if I wasn't clear enough in this post.
posted
Sorry for the delayed response. Ok to explain a little better.....
1 - use A* to setup waypionts. 2 - remove unnecessary waypionts. 3 - list last waypoint passed, the next waypoint and the waypoint after that one. 4 - using an algorithm decided how fast the ship can go so it can pass the next waypoint and align with the following waypoint without going to far off course. 5 - once the ship hits the node's area for the next waypoint, step up in the waypionts list. That way the ship will start heading to the next waypiont.
On a square grid map that should make for smooth turning in the ships movement AI.
posted
I don't think I have ever used A* for real. Back in the day was something called minMax, which I gather is maybe the same idea.
But yeah, with my rectangle scanner giving me a smallish list of possible path connections, I could feed that into A* for sure. The point of the rectangle scanner is that otherwise I would need to establish a grid with a density of something like 100 x 100 and have to deal with a list of 10K connections instead of the 100 or so rectangle connections needed on a typical starmap.
my recursive 'find a path from rect A to B' code only recurses a couple levels before finding a solution. I don't really look for the best solution, and since the solution can change as things move, I expect a lot of churn, which I hope will look like cool thoughtful activity (emergent behaviour from a small set of simple rules)
---
my recursive goes like this
findPathfromAtoB( A, B ) get all connections involving B (destination) if any of them involve A, we're done. else iterate over each of them C = a rect with connection to B findPathFromAtoB( A, C )
I also pass an array reference which acts both as a place to mark 'rectangles you have already checked' (so you don't get stuck in cyclic loops) and ends up holding the full path from A to B when done.
posted
I discovered A* when I was trying to make a WoS clone in AS3. I was originally trying to mark terrain behind the map so it wasn't visible and using the hitTest function. I ran into the problem of slowing the movement of the map when the number of terrain tiles rouse.
I found out with using the A* method I could just make an array for the terrain and cross check the player's position. So instead of checking for a hit on the terrain object (which slowed the game down), it would lead a path to where the player clicked and dodge the places I had placed terrain.
I've also seen the same method used in a lot of TD games where the enemy went around towers to the exits point. It seemed to work pretty well with those and didn't lag the game unless to many graphics were on the screen.
If you are using predetermined waypiont to waypiont that would definitely cut down how many pathways that would have to be checked. Only drawback I can see is if a map designer created a bunch of barriers, which would make it more difficult to navigate.
posted
Today I worked a little on my Defense of the Clones map. Mainly setting up the gates as I want them to be .. well, the towers on the gates, getting them to obey my color overrides and the like.
To that end, it turns out the engine was handling a few of these things incorrectly, so you'll need this release for my DOTC map to be playable.
I also get to play around with the API in order to make it easier to add a gatelike object in the future. I've been talking about barriers that can open and close for so long, it will be good to have that for real. Ditto for some Tower primitives so it is easy to drop those on your map as well.
Haven't done the minion management yet either, but I did the first part of the multiplayer aspect of it. Only the moderator monitors for dead towers, and whenever a tower dies, the moderator sends a "towerDead" messaage to all players (including itself)
When a player receives a 'tower dead' message, they just set the towers[ thatIndex ] value to 0 (tower is dead). So all players agree when the moderator says a tower is dead.
a periodic update function scans the gates and opens any that have both their towers down. I think that's local for this map. I mean, I distribute the tower state, but the gate state is inferred from the tower state.
likewise, the moderator tracks who is shooting at whom, and sends 'aggro' messages (haven't done this part yet) to all players, so they each tweak the ai of one or more minions.
So everyone's copy of a minion agrees pretty quickly as to what its prioties are, but then they animate independently on each player's machine, possibly varying quite a bit. Only the host of an object gets to decide when it is destroyed. And for towers/minions the host is the moderator.
This means the moderator is sending a lot of messages, and it triggered my spam filter, leading to all sorts of oddities. So I have to work that out. I was pretty conservative when I set that up. I added some sleeps, but it would be nice to be able to initialize the map in one blip again :-)
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
I went to diddle my spam filter, and can't find it :-) I know it's there somewhere, but might not be the cause of the weirdnesses I saw. I wonder if I called a coroutine-dependent function from outside the coroutine...
Well, when you go looking for problems, you usually find some, if not the ones you were looking for. Fixed lots of little issues, like the script map color overrides were not actually influencing the colors used by the engine in all cases.
I still need a little delay, or the map does not build properly. Clearly this is a serious bug that will bite me again and again, if I don't get to the bottom of it.
At this point I am guessing I am abusing lua global/local variables somewhere. for example, if you use 'i' in a 'for' loop, lua uses a global value for i unless you specifically declare a 'local' copy. I have been fast and loose with my 'local's so that might be burning me, with one routine stepping on the toes of another, and the wait() that fixes it, just rearranges the moment of overlap.
It could also be my cross-thread queue might have a behaviour I am unaware of (like a size limit).
Now, I guess it's true that until I sleep, I am blocking the engine from draining the queue at all, so if there is a max number of elements/bytes allowed in that queue, it might just be discarding data (in which case, it would surely throw an assertion, one might think)
Well, I'm sure it's something stupid. Either that, or something brilliant. But probably not in between those poles...
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
When you finish with the waypoint AI will would it include crossing the map borders. For example, having the start point on the top left and the end point on the bottom left. The obviously quicker route would be going through the map's borders.
Another conclusion I had for a possible technigue for waypiont AI is the left the map developer define where the waypionts are and which ones connect to it. Waypionts = waypiontb,waypointc, ect.
posted
map-defined 'lanes' is an interesting idea.
I was really only thinking of the 'non-wrapping' map context (in this case with barriers literally all the way around the map)
This is also part of 'tank mode' development (where your vehicle moves like a tank instead of a spaceship) and again, I am generally thinking of fully restricted non-wrapping environments. Though in theory that is a separate map property the designer can use or not. But for forms where you need to restrict the players motion through the map, you end up pretty much with barriers all around. Plus my math problems with barriers close to the edge of the map.
And if I were path finding on a map with no borders, I would pretty much go straight line everywhere, though my math doesn't always SEE the other guy as being 'just over the fence' but instead sees him 'exactly on the far side of the map'.
HOMING missiles used to turn around if you crossed the barrier.
But explicit lanes and hubs could be useful in several ways, couldn't they? Algorithms might tend to fly you through a star, for example, since it's not a barrier per se. (though a hurtful object along the path should affect the weight of that path).
I have waypoints in there today, but as a zone attribute (back from Arcadia synSpace). For most of the things I want waypoints for (race courses), I think I now favor 'beacons' (points with radius, instead of four point rectangles). So dropping them in game would be like dropping mines, so as to be easy to define a path, either for a racecourse or for some bot route. But, as you say, you almost want another asset type for path.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
I made a more 'real' icon. for the Play Store
Note the area-fill in the shells. It's a lie. But other than that, pretty honest.
My thought was to indicate multiplayer with the faces, and show the shells to set expectations, with hopefully a sense of motion (everyone is heading towards that battle at the top of the planet, is the idea, with a semi vacuum in front 'for you')
I was going to 'buttonize' it (add a glossy highlight), but didn't find a great tool in the time alotted.
----
This is an experiment in marketing, as it were. Research and my personal experience shows people are drawn to faces. The existing icon is just a very fiery star image with some hand drawn text on it. It has a clean simple design and an attention getting color, but not much else.
The new icon has a lower production value (more hand-drawn by me) and too much detail for an icon in the normal sense, But Play icons are rendered large a lot of the time. Plus I figure the 8bit art probably helps me more than hurts, all things considered and target demographic (retro) and all.
The EXPERIMENT is to just change this, and see what effect it has on clicks in the Play Store.
As I see it, the following factors matter:
* yes, you need a great game, so people come back, and tell each other about it.
* yes, if you spend millions on TV ads, you will get millions of sales. At a dollar each, you still might not break even.
* people see lists of apps, selected by search terms. Make sure you trigger on the right terms.
* people see lists of apps, make sure your icon is riveting
* people see lists of apps, make sure your title is compelling
* people see lists of apps, probably don't read the oneline description, but it should be fantastic.
The point being, people see (long) lists of apps, and yours needs to pop out when all that has been shown is the icon, title, and maybe the oneliner. So, obviously, the perfect app would have a naked lady icon, strongly featuring red tones, be called "Free Sex Now" and the onelinr something like "guaranteed not to upset your girlfriend"
Of course, without the proper search terms, you won't even be on the list. My experiments there imply that the title is the main source of keywords, so you usually see entries like this in the list.. title: "Multiplayer Spacewars Game". Those will all then be search terms, and you will be a candidate to appear on most every page (though probably still sorted and flltered based on downloads and ratings). If your title is "synSpace: Drone Runners", you pretty much only show up for people who knew your name already, or were looking for Drone games. (So I should make a map where the ships all fly like 4-rotor drones)
Past that, it feels like the first words of your long description are used. So if you front load your text with "fun multiplayer online spacewars game for 8 people", you are more likely to show up for 'multiplayer' 'spacewars' and 'game' searches, than if you put the same sentence at the end.
Also, it feels like they look for repetition, like if you say multiplayer three times, then it is a stronger keyword for you, so long as you don't trip some filter looking for people padding their descriptions, instead of honestly describing their product. And a longer description sort of thins out the keywords, making them LESS important, so a well-crafted short paragraph is probably best all around. Tell them what they need to know and trigger curiosity level high enough to at least preview the game.
Anyway, I'm just curious, not expecting any floods. So far, as far as I can tell from the analytics, pretty much no one has even seen it in a list organically. I mean, I use an anonymous device and search for all sorts of things that totally apply to the game, and then scroll through lists of hundreds of games, and I am not there. (or I slide right be me, without seeing me, which I did at least twice). So, my point being, either I still need a lot of work on my keywords to even get on the list, or I will never be on the list until I achieve some minimum number of downloads, or pay for some official feature.
my brilliant strategy is to only worry about that in the fun sense where you change an icon, for example, and look for a difference in the following analytics, changing one thing at a time.
Then just doodle along as I do, releasing updates as they become available, and hopefully providing periodic entertainment to 10 or 20 people around the world.
And maybe someday, if it feels 'good' and 'strong' then maybe buy one ad somewhere, or goose social networks. But not when there was any chance of the newcomer running into a wall of some sort, never to return. Everything should be smooth before you actually shill :-)
posted
OK, tweaked it one more time. I showed it to my wife and she preferred an earlier version before I area-filled the shells.
It's more honest and has a little bit of a star constellation look, so that's nice. The problem is the shells mostly disappear at smaller sizes. But maybe it will be an interesting texture, and I like having less 'mass' out there.
[final version is this one, but cropped a bit tighter to raise relative size of content]
posted
fixed some 'plumbing' so scripts can reliably set the 'team' affiliation of NPCs and other little defects as I implemented 'towers' on my DOTC (Defense of the Clones) map.
Oh, like I hadn't dealt with the common state of 're-entering the map after dying, and wanting to resume with as little reset as possible' so that's nice.
I think I will give each tower object a property 'related gate' So several towers might all claim the same gate. When all the towers guarding that gate have been detroyed, the gate is opened'
So I don't distribute gate state, just tower state.
NPCS can now set a sense radius, beyond which they will not attack (i.e. a safe approach distance which should ideally be just inside your own weapon range so you can't safely take it out from a distance)
NPCs can now be set to 'can hit first' (otherwise, they remain passive unless they take damage)
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
still plugging away at 'towers' but I think I have them mostly behaving now. Changed my data structures as implied above, making tower state the focus over gate state (and determination by counting living support towers)
Anyway, so now I can dop into my home area, pass through my own gates without hassle, get shot at by unfriendly towers, shoot at and destroy towers and, just now, an unsupported gate now opens (with 'animation')
So it is possible to fight your way through to the opposing basecamp. Nothing to do once you get there, but there's a struggle all the same...
still have to do basecamp, clone factories, and minions.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
oooh, I just added a bot property for "leadTarget" that coontrols whether the bot will factor in your velocity when shooting at you
0 - disabled, just shoots where you are 100 - shoots exactly where you will be, unless you change course <100 - shots are a little behind you >100 - shots are a little ahead of you
so you can have bots that intentionally miss you! if you calmly stay linear, they will be safe. But otherwise your only defense is to go nonlinear.
I will definitely have to redice the weapon poiwer of these towers. my hands are freeziongggjkgj
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
It remains my intention to support a form of chat where I try to carry the overall sound of your voice, without actually including the words. cartoon talk. Peanut's adult voices.. that sort of thing. No swearing, but lots of emotion.
But.. I would like to operate from a foundation where my spectral recordings *could* be very accurate, and I just *choose* to adjust the knobs downward.
Which is why it is irritating that the spectrums never really duplicate the sound accurately, even when I try hard :-)
I'm a big believer in visualizations for debugging, so what I actually spent my time on was a new render of the spectral recording, where I show the current selection (first to last spectrum on that slider, the 'play' range) in a more conventional spectrograph format.
That in itself excited me a little, because the images were familiar (similar to 'real' scans), and give me a way to measure progress and look for areas of error.
For one thing, I have to interpret some contexts as being 'noise' and not 'frequency'
"ch", "kuh" and "sh" sounds, for example, with the 'fricative' removed are not understandable.
This is good for my stated goal, but in theory I have code in there to deal with fricatives, and clearly it isn't triggering when I expect it to. And I apologize for mis-using the word 'fricative'
It's slow enough to render this that I ultimately made a sort of bitmap 'cache' of the most recent render, so I didn't have to re-render all the details on every display refresh.
THat was pretty successful, so I think I may go back and redo a couple things with that idea.
Of course, redrawing it all from scratch, every frame, lets you have lots of dynamically varying stuff.
---
Also, there is a fundamental mis-match between what I am doing (decoding voice into fixed discrete frequencies) and what human voice is all about (small number of formants that glide through frequencies smoothly)
So with my new visualizations, I can 'see' vowels, dipthongs, with the formant frequenices that arc over time, looking 'curvy' on a real scope, but coerced to fixed freqs, giving a sort of aliased line look in the vocoder. And your ear definitely hears the individual note frequency steps differently (adds a warble).
Of course, my code COULD model the playback itself differently, so even though the recording were to discrete frequencies, I could 'glissando' through the changes smoothly at playback.
The trick there is an 'ai' function that can figure out two pixels are part of the path of a single line, and not parts of two separate lines.
In my case, I can probably just process them low to high in freq, and count them. the 'second peak' on each row is likely connected from row to row. But still, would be good to algorhmicize the heck out of that and really have a 'formant tracker' which is what I called the vocoder in the first place.
So, ok, an alternate playback routine, voice friendly, using the quantized freq data, but emits as a set of smoothly changing formants. (ideally achieved through dynamic filtering of excitation pulses, but I'll settle for a bunch of sine waves added together)
Probably some number like .. say.. 4. So the output is just the sum of four sinewaves, where I control the freq and amplitude of each.
stepping through a series of spectums in order scan from low freq to high freq look for solid peaks number them left to right, 1, 2, 3.. consider assigning '1' to the first oscillator but maybe compare to current settings, freq, of that osc and make some decisions * if they are close, accept the binding * if not, check the next pea to the right - is it a better binding? - would that sacrifice a solid binding it already had?
And at the end of that, you have mapped the peaks of this spectrum to the four oscillators
Then you just command those oscillators to 'head towards their assigned peaks, smoothly changing freq and amplitude until they get there'
right now I process 128 oscillators every frame, though the majority are silent so not much work.
Also, the compression could be quite good if all I am sending are four formant freq 'shapes' of maybe 10 points per second... so 40 points per second, let's call it 40 bytes or 320 bits per second. that's acceptable. And it could sound very "voicey" (and still not be intelligible, goal met! :-)
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
Made some improvements to the new vocoder voice visualization
This is me saying "Testing One Two Three" with exagerrated tonalities
the top half is what the raw energy looks like, high freq on top, read from left to right. The formant bands are obvious, as are tje spots with breaks in the lines.
the bottom half is the result of me peak detection, so you get thin lines riding the crest of the peak amplitudes, so you see the sing songy inflection changes and dicontinuities and the fricatives
That symbol in the middle is me saying "one" as "wuh uh n" and apparently in the uh in the middle, my voice adds all sorts of scratchy noise harmonics, and that one rising rooster feath at the very top. It's very consistent when I say that word.
I'm tempted to try to paint in the missing bits and smooth everything out and hear how it sounds when osicllators are allowed to track the freqs smoothly along these curves
There are also often spots like fingerprints where wholrs sand eddies sort of curl up into themselves.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
OK, work work is in good shape, I got lots of sleep and it's still Sunday Morning. I can now work on any thing I want... Any little thing that appeals to me.
Logically, I should finish my Defense Of The Clones starmap and attendant engine changes. That could be the centerpiece of this release. And not a bad goal to have one new map per release.
But my track editor has been 'almost finished' for a long time now, and maybe I should polish that off.
And, of course, my efforts to add visualizations to the vocoder so as to scientifically control my miscellaneous constants is working to improve fidelity and offers exciting 'fake voice' opportunities. I think it would be cool if world designers could record utterances and then convert them to this compressed fake talk and have the result be only something like 10 characters of text per second of speech. So it wouldn't be actual narration as it would still be unintelligble, but it might be neat all the same. Fits into the metaphor that you are eavesdropping on alien communications
of course, if you WANTED narration, I culd probably pass it along to google to speak aloud. I do that in WoS:Rune RUnners. But starmap designers already have enough opporuntities to swear at the player as it is... I don't exactly know what I plan to do about that, but I hope it can be a wos-like "let the reader decide what they are unwilling to read, and censor the writer as little as possible, and where possible, only at the outmost edges"
But some stuff, like the scrolling backstory, will be seen by people before they have a good chance to opt out, so should be held to a higher standard of inoffensiveness (yet clearly indicate what is to come if the reader remains on the map)
And much as I need a 'favorites' button, I probably also must have a 'don't show me this again' button. (which means I then have to remember it in the DB anyway, just remember to show you something else when the code inevitable asks to look at it. I could overwrite it with some default, but then you might actually code it into your new starmap, thinking it was the default and it would actuallly be the offensive image to anyone else (who had separately fetched the original image... etc... )
I think I added support for most of that back when I implemented the collectibles, but waved off as I just couldn't work up enthusiasm for either model: keep vote inside of table of collectibles, or keep a separate table that just links votes to collectible Ids.
If I ever did want some sort of 'people's choice" measurement (hard in a distributed 'holographic' sparse and intermittent data set :-)... then I think I would go with the separatr table
And in the era of big data, it's more in style to remember individual events (all the individual times you changed this one knob, and do that for every possible knob) than update an individual row of an existing entry, risking some other thread needing it at the same time, non-atomic, blocking, etc. And if I am going to accidentally corrupt existing table entries, I would rather do that in a favorites table, than in the actual core item data.
So I am pretty sure the conclusion that I reached was another table 'of favorites' which only had rows for favorite items. And so long as I didn't declare every collectible I had as a favorite, it should use less memory than a new column (or 10) in the raw item data.
And then I think I extended that to be part of user preference/map progress/story token kind of info, and actually implemented tokens based on it.
But I don't think I was ever able to deccide on a UI for it. First I thought just a thumbs up (or nothing). That a thumb's down might encourage a negative energy in the community. If these votes were ever shared (I think I would try to have some central server involvement there anyway). And this is really not about praise (maybe it should be), it's about sorting the list to help you find what you like faster. But maybe there are other means to achieve that goal, like just remember the date of the last time you 'wore' the collectible (or praised it) and then sort by that date. truly dull thiings then sort to the bottom.
But maybe I want to have more than 1 bit of info, maybe a scale. One could go multidimensional and sort by all sorts of things. which would be silly. But would I like a favorites AND a super favorites? Or would I like a one bit favorite, and a "kind of thing" filter (only show me those). right, sort AND filter. Where currently I only fliter by whether you have unlocked the map, which is measured by whether you have the maps unlock token, which is something that only applies to the stock maps that come with the game. (currently a third party star map would have no means to hide itself from view in the map list, but there could be some setting for that if it became important, like "requires token 3 to play" and then the engine (which preparses the map at load time anyway) would have a known filter constraint it could set, which would then be applied whenever the list was shown. Which I believe I actually cache in the list (volatile memory object) itself, so I don't re-check your tokens (unless they change, I guess, but probably you have to close and reopen the list if somehow you were granted a map unlock while viewing the map list) oh so fascinating.
all I *have* to do is *something*
I keep doodling thoughts for 'easily creating a cute critter with a posable skeleton' and it always starts super simple and then rapidly exceeds my grasp. But since I am already in sream of consciousness mode, here goes:
You start with some number of photos of.. a monkey. (your target critter shape and skeleton)
Then, using a fun and easy app, you
1.) indicate where the 'root' is on every photo (the root node is generally speaking in the groin, between the hip sockets, so you have to click on the monkey's whatever, to indicate, on each photo, the exact center of the root (from that camera angle).
2.) determine the direction of the root, on a per photo basis. This is basically just setting 'what angle was the camera being held at, relative to the root, when the image was taken'
Our goal is to get enough information to get a 'plane' and a 'scale' for each photo, such that left/right and up/down positions on the photo can be projected as rays into the 3D space 'beyond the screen'.
When you handle the same point (root) from two or more photos, their projected rays should all converge on the 3D spot where the root actually is.
In fact, they will likely miss, and together form a sort of spherical blob that encloses the true center somewhere.
You then twiddle some fun knobs to adjust the individual camera angles, reverse engineering what must have been true when the image was taken. The idea being that you, a human, are really good at this sort of thing.
Ideally, in real time, as any knob is changed, the whole thing is recomputed from the ground up, a new 3D model and set of textures is generated, and a little 3D preview render of an animated skeleton appears.
So, I am not trying to do this with complete machine vision. In fact, I want it to be game like. But I am thinking something along these lines might be the foundation of Arcadia Park, and that people might like to scan 'themselves' in this way, as well as their pets or random photos from the web. (legal questions?) All you would need would be 4 to 8 photos of the subject, preferably dressed the same in all photos, and collectively exposing all surfaces and legitimate joint angles (min/max for each degree of freedom), and then an afternoon spent reverse engineering the camera orientations and the placement of additional joints on your hierarchical skeleton which you get to make up for each creature, if you like, but will probably re-use a starting biped and quadraped and hexaped... with some standard attach points for weapons, seats, equipment and wings.
But keeping it simple, say I start with 8 photos of a man walking.
I indicate the root and estimate camera orientatino for each of them
I see 'the root blob' and tweak the camera orientations in an effort to sharpen it to a point. Maybe I have mis-located it on one or more photos, so I go back and do a better job there. I am looking for the root, inside the body, not the surface center.
Once I have a pretty good root set up, I then focus on whichever image supports my next task. I always render the current skeleton on top of eah image, and you can move verts around to make them line up. If you move a vert up a little, then I move the 3D vert up a little, based on the current estimated 'plane of the photo'
If that then renders as an unpleasant motion of the vert on the other photos, then something isn't right and it is left to mister human to wiggle everything until it is. But perhaps math can provide hints.
Anyway, you tap a new vert (joint) and drag to its parent vert (joint) and thus build up a hierarchical skeleton definition. Only the verts are being recomputed from the image info, so bone lengths are derived and displayed in a way that also builds confidence in the corrent placement of things.
So, in theory, this process generates a useful skeleton that could be posed in ways mirroring the original subject. One part of "Arcadia Park" is the creation and collection of skeleton poses, which are then used as keyframes in skeleton animations (with auto-tweening), and if 'valid ranges' have been successfully determined, some ai might be possible to generate poses consistent with the manually specified ones, but adapted as needed to meet local terrain and collision info (hand on railing, feet on steps, etc)
but no, probably not that far. But maybe just some randomly-generated, but within limits, resting variations while in a pose, just to be less 'still'
But I would love to have a system that was based on "I would like my hand to be close enough to that strawberry, with my fingers poised to pick it up" and then the system would work out the kinematics and how to get there. goal driven animation. Once my hand gets there, I want to flick my finger such that the strawberry lands in the basket, etc.
yeah, not that far either. Just ez generation of posable skeleton.
For texturing, I was waving my hands and saying
1.) for each joint, you specify a 'volume' which is rigidly bound to that joint. Like a sphere for the elbow and a box for the root. Only a small number of primitives are allowed here.
2.) you match the dimensions/radii of the volumes such that they more or less describe the dimensions of the creature. In this case, you drag the radius of the circle until it encloses the elbow and nothing but the elbow.
3.) I then magically create a set of points that will be used in the final geometry of the entire body as a single mesh of points that are weighted to follow various combinations of joint positions. My initial algorithm: If any point is inside one of the other volumes, then remove it, leaving only points on the 'convex-ish' outside of 'the skin'
4.) Magically tesselate the surface of this volume, using only these points.
5.) do a real time inverse uv mapping (unwrapping) to map points to a square texture map, magically maintaining a constant/controlled pixel density and a continuous (no edges) unwrap. I mean, magic.
6.) for each triangle, for each photo, if that photo has that triangle in a sufficiently 'forward facing direction' then pick up the appropriate source pixel colors and blend with other photos to achieve the best result (more human help here where you identify which photo has the best texture for each marked location)
So now you have a posable 3D skeleton, a continous mesh blob that roughly follows the shape of the creature, and some mapped texture pixels that give the blob roughly the appearance it had in the photos.
The inevitable missing data is replaced with frog dna... I mean, mirror imaging of some sort.
Some big sliders let you normalize bone lengths and other symmetry issues. ez pz. Anyway, once you'd scanned yourself, maybe you could magically draw new clothing for yourself. And it then would appear in WoS: Rune Runners as your character or some npc/monster, complete with exciting pose-based animations.
My favorite animation system is Rocket Clubs, where you:
* have a bunch of poses, some required standard, plus any you feel like * can define animations as a series of blended steps between two keyframe poses, or a list there of. * but a pose can be either a raw pose, or a blend of two or more other poses. * for bonus points, that blend should allow one pose or another to fully control some joints (wings, fingers, etc driven by game activities)
I was watching youtubes about Sculptris last night. Its free and can export to Unity3D. But doesn't do skeletons
The idea being you would export from Sculptris into blender where you would glue the skin to a skeleton you built in blender, with animations done in blender as well. Any art path that DOESn'T support blender, is probably shooting itself in the foot, but blender is all complimicated. Sculptris is also mind boggling, but I think 'more fun' all the same. And, of course, Sculptris makes stuff you might use on your PlayStation 6 with a million polys per fingertip, but the demos all claimed it could go low-poly as well. Though if you are importing it into blender anyway, that's probably where you'll do your poly reduction, I guess.
I think I'll go slow on that stuff, but I keep coming back to this "making 3D objects, scenes, and animations from simple photos/movies with human assistance" and a desire to try to accomplish something trivial in that space.
For game purposes, I really only NEEEEEEED posable skeletons (synSpace Stick Figures being a new collectible that can be reused in WoS as the underlying skeleton of whatever render system I choose to use.)
How would I store poses then... On the one hand, there will be a lot of bipeds, and they should be able to share a smaller set of walk/run animations, so separate collectibles for skeleton and poses. Skeleton probably includes stuff like the legal rotation ranges. Possible an algorithmic/parametric implemenation of walk cycle comes with the skeleton.
No... they just need to be hierarchical. Base skeleton defines bones and provides the stock poses required for walk, run, swim, fly, sit, shoot, slash, fall, sleep, die. (there's a rainbow hiding in that) and then a separate animation asset, that is bound to a specific ... no.. let the binding be in the head of the designer, go ahead and be willing to apply any animation to any skeleton. Skeleton nodes will have NAMES not indices and animations will only affect NAMED nodes. And if that doesn't do the right thing, well, re-design!
so yeah, an animation really has no idea what a skeleton is, it just defines rules by which a hash of named values vary over time. If the skeleton in question has joints mathing those values, those joints follow the animation. (and if several animations are running at the same time...)
values have an initial value, a time to hold that, a new value and a time to take getting to it, repeat.
These values could be hard core joint angles, or they could be 'rigging values' that are easier to think of (percentage completion of movement) and the rig (defined in the skeleton!) would translate that value into the hard core angles for you.
Yeah, that sounds right. Look at that, if I stop right now then I achieved a real mini design breakthrough: free-range labelled animations, and pre-rigged skeletons. (WoS: Rune Runners uses joint numeric indices which is pretty inflexible and hard to read as well. The more I can make that symbolic, the better)
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
So, I don't remember what, if anything I accomplished last weekend. This weekend, I know I get to work on my new pooter, that has been ready for six months, but I got distracted. 2T of SSD, baby. It's my VR friendly rig, and it is time I got it set up.
I finally stumbled on the OpenVR spec (thanks, SteamVR) and I need to familiarize myself with it, plus vette the (free) c++ development tools on that machine (Some flavor of visual studio), and I think maybe Rocket Club VR might be the result.
That doesn't make RC a Steam game, of course, just probably will require you install SteamVR on the same machine, since that's the code that will interact directly with your head mounted display.
But it seems like the easiest way for me to set up for OpenVR development.
The OpenVR looks sensibly laid out (of course, who am I to judge, I'm sure they did great). They handle the head tracking and send predictions to me for any point in the future I ask for (which I based on my estimate of how long it will take me to render the scene) so when the scene appears, it is right where you will have been looking.
Assuming you can be pretty regular. And fast. I think RC had 100+ fps on this machine, so on my new pooter it should be 1000 fps. Which I hope not turn into 10 fps in VR. Some people say you need 75 fps, in both eyes.
But RC (and WoS:RR for that matter) are graphically simplistic enough that I hope my quickie tech demo can turn into an actual interesting feature in RC, while honing my VR skillz.
Of course, I often fail to completely understand the mojo beneath the layer I am working on, and 3D render environments often have a middle screen layer that is mysterious to me, but the nice thing is that OpenVR doesn't do your rendering, it just gives you the matrices you need to render to the individual eyeballs.
Actually, I think OpenVR *will* do a lot of your rendering for you, especially menu stuff, if you ask it to, and you are using some modern render engine (probably newer than DX9), though I see a bias in OpenVR for OpenGL, which seems a little odd since OpenVR isn't really mobile friendly per se, where OpenGLES rules, and on the Oculus/Vive desktop scene, where OpenVR *does* live, it's always windows DirectX.
Again, in theory, I don't care, so long as I can convert their matrices into a DX9 compatible format. And for all I know, they already are.
Anyway, I think that's my plan, to further progress in VR development a little, while noodling on my DOTC starmap, maybe adding minions, but probably re-writing the barrier stuff.
Did I already ramble on about barrier changes? I mean, part of me wants to just get over it and allow any-angle barriers. I think people would demand that. Plus the way the script has to handle the indices is a bit weird. So if I can only have 100 line segments, and I refer to them by their indices 0-99, and I need to be able to modify them (open/close gates) after creating them, I need to remember the index of each barrier I care about
The current implementation has me predeclaring important indices, and then passing the index as an argument to the engine, when defining or updating the barrier.
But I want to sort of reverse that and say 'let the barrier engine provide 'the next index' without my worrying about it, and I will then write that indec down somewhere if I need to deal with it later.
This allows several adventures on the same map to have barrier setups that don't compete in any complicated way (I mean the lazy starmap designer doesn't have to hand allocate indices)
i.e. not hard, just a gumption trap. I need to get to full object status, so adding a gate looks like:
as for a scene or a bot, just use that metaphor everywhere for all objects, That way no extra code for gates to receive messages, for example, it just happens automatically.
Right now I handle messages in the scene object, which actually works great, but I would like the opportunity to talk directly to the gate object.
Then a small rule based AI in the individual gate can make decisions based on communications with other gates, towers, etc. Like a scoreboard that receives messages from a goal object and a soccer ball object.
Anyway, I just don't like working with barriers with my current api, and changing it will/might break everything, so better to do it sooner than later.
But the other nice thing is that starmaps really are independent of one another, so not all starmaps have to do this part of barriers the same way, they are just stuck with the engine's barrier skillz, which boil down to just setting a bunchg of properties for each of a limite number of barriers, and that part won't change.
But I think I will dump the horizontal/vertical distinction and just (for scripted barriers) have you specify a start/ent point pair and I will automatically do the right thing, don't you worry about it. (but internally I will still have optimized lists for quick collision testing, and I MIGHT add a new list for 'not a right angle')
My 'plan' for angle collisions goes something like this:
Whenever I compute an object's new position, when I still have its old position in my hand, I test that against all barriers for collisions
If the barrier is horizontal or vertical, this is particularly simple.
If it is an angle, think of the barrier itself as being the diagonal slicing a rectangle into two pyramids (the diagnol is then the hypotenuse of two right triangles, which let's us use all sorts of easy math)
What you basically want to know is
* were either of the points inside the rectangle? (if not, no collision is possible)
* were the points on opposite sides of the diagonal?
If so, there was a collision, at which point you need to work out the 'bounced off' new position, and the appropriately adapted new velocity.
Again, in the H/V case, those computations are trivial (negate the x component), but for the angle case you need to find the incident angle and adapt the original info.
Doing it with full math (square roots and cosines) is pretty straightforward, but I'm looking more into a geometric sort of trick with similar triangles
Also, I just don't know if crazy wall angles might lead to chaotic/unpredictable reflections that might be frustrating to the player.
But how else will I even have rotating circles of barriers that you have to shoot through when the holes line up? HOW I ASK YOU!?? HOW!
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
when I said pyramid above, I meant triangle, sorry. I am noting that here because I would have to scroll up to see the edit button, and that's how lazy I suddenly feel
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
tonight I worked on my DOTC map (Defence of the Clones) and had the happy realization that it delivers on the backstory I originally pencilled in before starting the project :-)
In partcular tonight I added the clone factories themseleves which, on this map, are true factories that create minions at a certain rate. Right now those minions just pile up, but next I will send them off to attack the enemy clone factory
But it's cool, still using my lua-table-based-bot objects metaphor, and using inheritance to create a hierarchy of bots, from gates to towers to factories and the things made by the factories. It's practically capable of tower defense now :-)
I added a new function pair: newBaseBot and newBaseScene for when you want to declare a new object, but only to be used as a base class for other objects. It just creates the object and does NOT list it with the message handler. newBot and newScene create AND register.
My frame rate with 28 minions on screen was pretty horrible though. I think it's the smoke trails. I think I will fade them out when the ship stops moving. They are just circles, but on this tablet with a high res display, the alphs transparency is treally expensive, and there are like 60 particles each. I know, doesn't sound like much :-)
But I'm super pleased that adding a new TYPE of onkect (factory) was really no more than another bot table, with a couple factory specific functions in it. You then make new factories from this base clase and override the 'buildComplete' method where you actually make something (and that's what differs from one sort of factory to another, while the nature of factoriness is stock. Right now it just "takes N beats to make a minion"
Actually, right NOW it makes new minions that replace old ones. So if an old minion is still alive, it will still eventually be replaced with a new one. That's presumably incorrect, but might accidentally be interesting.
still, I know I need multiplayer fixes for the minions. Only the host should be deciding to spin up a minion, amd that should really just mean identifying a single character 'state' value for each potential minion, sent by the host to all players, and then they spin up or down as needed to obey state.
so I guess state is what I should work on next, including game over detection
I need to add some weapons control, so you can make some ships be 'melee' (with short weapon ranges) and others be action at a distance. And maybe hardwire that to follow your starting pod choices, so you are actually sort of indicating you want to be tank, healer, dps, etc.
Or maybe even hardwiring individual thumbs. I recolored it tonight so the gates/towers/minions are all BLUE or RED depending on the team (EAST is blue, WEST is red)
Before I was just using RED (dangerous) and GREEN (safe) for the towers, so they were not the same color for everyone. That was nice in the sense of warning you, but not at all clear with regards to the green and red ship colors (since those are ships on the same team) or are they. Anyway, my wife agrees: use the team colors, which are currently BLUE vs RED for historical reasons...
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
So I was dragged into thinking about properties again, and the issue of after-the-fact editing of just properties on an otherwise unchanged map.
That led to the same cobweb of ideas which I spare you here.
But I think I will go ahead and just let the script set certain objects directly from data. In particular ship shells, and maybe faces.
so, for example, when defining a bot's lua table, you normally specify the shell with a line like
SHELL=SHELL_47
Where 'SHELL_47" is the asset id of a shell you have collected, and which will need to be collected by all users of your map, but is not actually shipped 'with the map'
Easy to type asset ids, like SHELL_47 are stock shells that come with the game, so my own maps only use those and thus can ignore this reality.
my big long term idea is to let you say
code:
(properties) bossShell = SHELL_47
...
(bot declaration) SHELL = prop( bossShell )
or words to that effect, and then maybe the clone button is where you access the current property settings and could edit them when creating a clone starmap.
And I still think I need something like that, I am just no longer sure it requires a top-half declaration.
ANYWAY, not to let the perfect be the enemy of the good, I want to just support something like this
code:
(all in the bottom half, lua script) -- some data I stick in variables to make it easier and prettier to use in code
And I change the engine to be able to deal with raw data to give a ship a SHELL that 'you have not collected'
which is probably what map makers want -- the ability to add new shells and faces that are not immediately owned by all players.
And, I sort of agree, but from the 'I don't want to collect millions of shells, just the ones I actively choose to keep'
and, continuing the digression, I guess you could argue that to avoid having to make those decisions in real time, you probably want a system like that in place already. remember everything, but let you delete the stuff you aren't interested in.
ANYWAY, the map maker art path becomes:
* render the shell using normal shell editor and select shell for use (i.e. it's your current shell selection)
* use the EXPORT to google Drive option in the menu wherever I stuck it
* find the file on your google drive (these exports never overwrite a file on your G drive, they just add new files, with timestamps in their names)
* open the file and find the data you want. The EXPORT command actually exports several objects.. your current shell, face, groove, and possibly the text of the lua script. So you have to thoughtfully search for just the bit you need. Not too much thought, but if I really include the lua script, I hope it's at the very end, since it can be kinda huge and tedious to scroll through.
* copy the data and paste it (in quotes, it's a text string) into the appropriate spot of your lua script (the map you are making). Preferably just in one spot, as in the example above.
Then, I guess the CreateNPC() command is where I would process the raw data into the in-memory object needed by each ship for its display purposes. I just need an official protocol name so I know the difference between raw data and an assetId when I see it. Some prefix probably, like, oh, DATA:{actual text defining object, which ultimately includes authorship info, at least in theory}
Anyway, a plan, half implemented already. Weekend Fun.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
oh, later last night I cleaned up the multiplater state distribution on the DOTC map, so now all the players agree as to which towers and minions are still alive.
Still have to do the whole 'game over' deal, and make sure the major scene state transitions are handled, and that I can cleanly return to tutorial mode as needed, and not by accident when destroyed in mid quest.
I mean, it sort of violates my primary thinking to have DOTC inside the tutorial map (maps should be rugged individuals each exploring its own unique focus), so I have to slickly argue for it. All I can come up with is "it's important to be able to switch a map's context, in general, as smoothly and friendli-ly, as possible.)
Actually, right now, some of my camera work can be described as 'jarring' and I think I need to embrace the concept of 'fade to black' occasionally in my life. But I also have these hand-offs from one camera advisor to another. Maybe sudden zoom shifts is all it really is. Anyway, it usually sucks. (Occasionally looks planned and cool, thanks to mister human brain perceiving insights that aren't really there)
But what I REALLY wanted to blabber on about was my 'api'. I should make SOME effort to clean it up, make sure it's useful, consistent, and no larger than it needs to be.
And then to library-ize it so it is available without you having to paste it into your map every time. (but it should still be possible for you to live without it)... You know, I think I just argued myself into keeping the individual api functions as globals instead of requiring some object prefix, like 'game.setShipPos( ix, x, y, z )'
Well, I just saw the flaw in my argument, sigh. What a short honeymoon with a good excuse.
----
Sp, anyway, I tire of scrolling through the source to find the line with the error in it (so I need to fix that, either with a scroll bar quick tap, or just something you do on the ERROR panel (tap here to open source centered on error line number), which in theory, I already did, but apparently doesn't work. So.. fix that.
But I still don't like scrolling through 5000 lines of api code. Of course, I couldn't actually code without looking at it to remember what it was. So it needs to be 'in my face' at some levels. I'll need to use G Drive more effectively -- two files open at the same time, ideally one of them write protected.
Anyway, point being, I feel I am almost ready to bite the bullet and move the api to its own file, which I then magically load in the engine, so it's in memory for you. I guess I ASSSSSSSSSUME it WILL? show up in my 'source' window in game... You know, maybe it won't, in which case the line numbers will just become un-useful in the extreme.
gah, whatever I do, it has to result in me personally doing less scrolling, and interesting starmaps to not be excessively long.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
on the SCRIPT PANEL, if there is a lua error pending (like the script failed to load because of it), the ERROR tab has more info, including an attempt to give you the line number in your actual starmap (usually the line numbers are just relative to the start of the script and do not include the top half of the starmap)
Anyway, if there IS an error, then selecting ERROR followed by SOURCE will recenter the source on the error line.
Seems to work... yay
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
OK, I changed the engine to preload an 'api' script, and for now there is only exactly one of those.
But I handle it much as an #include, where the 'library' is pre-pended to your starmap's script. (not to the starmap itself, but just to the [script] tag at the end)
When you then view the SOURCE on the SCRIPT panel, you see both the library and your starmap's script just after it, and the line numbers are useful for debugging. (can point out bugs in the library code.
In theory, if you define the same function as already in the library, you can fix bugs in the library.
Redefining tables is trickier unless you specifically clear them first, otherwise you might get a melange, which maybe would be good if your goal was just to add something to a stock table. But when setting a table reference, you usually are replacing the reference, and thus losing all the original dependent nodes of that tree (and getting just the nodes of the new reference), which I'm sure could have been said better.
Anyway, I can see 'it worked' but my API_1.lib is so far just a couple test lines to prove it worked. Now I need to move API stuff from the main map into API_1, and make sure I do the best most generally useful stuff, and leave any fiddly gimcrackery to the starmap itself.
I defer indefinitely the ability to call out multiple libraries, and get some via url.
Unfortunately, this makes it slightly harder for me to develop, since I kinda of have to burn a new version of the game each time I change the API. But I guess that function replacement strategy lets me fix it temporarily in gdrive without a new game push. Yeah, that's not too bad. But now my line number estimate (which was perfect for about an hour) is off by the length of the library, a number I appear to be too lazy to compute.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
OK, i now count the lines in the api lib and adjust the error line number accordingly so it is 'easy' to find the exact line of the starmap file with the problem.
And now it's my birthday!
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
so how is it that this forum is running an hour west of california time? it is currently 12:57 AM on 4/22
Oh, I bet it is converting from GMT and we're currently in that daylight savings period where we are only 7 hours instead of 8 hours behind. And maybe the forum code thinks it knows how to determine daylight savings, but maybe that changed since the forum was last updated... or maybe it is just always wrong for half the year and I just never noticed.
posted
so now bots can be assigned a waypoint list, which they will then follow to some ultimate destination.
This is different from the pathfinding algorithm experiments (which I think I will still need eventually). This is a simple list of points to be visited in order.
I have to carefully pick the points so that the minions travel from their spawn location, through the gates and next to the enemy clone factory.
But I allow them to engage enemies (minions or towers of the opposing team) along the way. So now I have these two streams of minions butting heads in the middle, as desired :-)
I need to let them break off of the waypoint and focus on the fight for a bit, then resume the waypoints. Right now they are just following the path, and shooting at anything that happens to pass directly in front of them. So they don't shoot the towers at all, just go through the center of every gate and fire directly into the oncoming traffic of opposing minions.
Leaving a cloud of destructive energy to pass through delicately. But I can sneak along with my miinions, take out the towers myself, and ultimately get to the enemy reactor and destroy it.
At which point all the remaining minions battle it ut amongst themselves untl no one has anything to shoot at.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
posted
I broke down and tore the library out of the tutorial script, then tore DOTA out as well, and now I have an official lubrary (a .lub file, not a .lib file)
MAP_000 is the official tutorial, and nothing but the tutorial
MAP_001 is now the DOTA-like Defense of the Clones map, and nothing else
Both use LIB_1.lub
I was semi-dreading doing this, but the time had come, and it seems to have worked without too much hassle. Requires full re-testing though.
And it was the right thing to do.
-------------------- He knows when you are sleeping. Posts: 10561 | From: California | Registered: Dec 1998
| IP: Logged
Topic Closed
Printer-friendly view of this topic
