Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - azmodean

Pages: 1 ... 19 20 [21] 22 23 ... 26
301
The '+' menu lets you adjust where your various clothing is with respect to each other.  So for example you'll want to have safety goggles worn outside your glasses, and kevlar vest outside other clothes, etc.  When you put on an article of clothing it is placed on top of everything else.  It's an absolute ordering of all clothes rather than layering per-bodypart becase dealing with semi-overlapping layers is a pain, and there's no discernable benefit to doing it that way.

When you get hit, it does proceed from outside to inside through your clothes, at each step there's a chance (based on coverage) for it to absorb some of the damage (based on item material and thickness).  Absorbing damage keeps it from proceeding to your inner clothes and of course your precious body, but causes damage to the clothing itself.

There might be a case for wearing common sacrificial clothing outside rarer but tougher clothes, such as wearing a tshirt over a kevlar vest, I haven't looked into the numeric tradeoffs.

302
Basically that yea, it's an interface issue of not having anywhere to put it.  I guess we could add a dot or circle in the middle of the compass or something, and light it up if there's a hostile enemy near you?
Part of the problem is that the compass is basically there to mitigate the fact that in the original your view distance was incredibly constrained, so you needed to refer to it constantly to look out for danger.  Also it doesn't integrate that well with shifting your view persistently (with the HJKL keys), since if you shift your view to be able to see a monster it removes that information as you're saying.
Now that I'm thinking of it, it'd be nice to have it turn yellow if you're close to being spotted, I think it has all the info it needs to make that decision already...

RE: Wounds, what I'd like to do long-term is add specific wounds (bruises, cuts, gashes, fractures, etc) and mostly phase out HP.  A subset of the concepts is outlined here: http://smf.cataclysmdda.com/index.php?topic=448.msg13713#msg13713  So you're not worried about taking 10 HP of damage, you're worried about a "deep cut", that might get infected if you don't take care of it.
At a very high level this is reminicent of how DF handles things, but we don't have a totally rigged-up body system, and don't really want one, so it'll be a good bit simpler in practice.
I know people are concerned about things getting too complicated to handle, a major focus would be on making sure that treating routine injuries wouldn't be a grind.

303
I agree that in practice all we need is a single number representing how difficult an obstacle is to either smash or move out of the way.  In practice, all we have are terrain, which must be smashed to move past, or vehicles, which by default are pushed out of the way. EDIT: Also creatures, which are also pushed (and usually killed), they have decent mass granularity already.
The score for terrain is a gestalt value representing how hard it is to smash, some combination of mass and "rootedness".
For vehicles it's completely determined by mass to calculate impulse from the collision, at which point there's a momentum transfer and it moves out of the way.

The current problem is that all we have right now are a handful of hardcoded values for different categories of obstacle, so e.g. underbrush, picket fences, chainlink fences and railings are all treated the same.  Bashable obstackes are more varied, but based on their resilience against smashing attacks from the player, which probably doesn't match up very well.

EDOT: I agree damage resistance or thresholds for various parts would help a lot.

Also, I let the resident drive-by troll get to me and upgraded the FOV algorithm from bounding-box bresenham raytracing to shadowcasting, which delivers approximately the same performance as bounding-box without the intermittent draw artifacts.  It's also O(n^2), and will be O(n^3) with z-levels, where bounding-box was O(n^3) and would have degraded to O(n^4), so it might be sufficient for our FOV needs with multi-z level support, where bresenham raytracing would have definitely been too slow.

304
I really like the bionic reclaimer robot, with existing mechanics it could just use pain-causing attacks, which would basically disable you with speed penalties.  Maybe add something where you can pass out from extreme levels of pain (I mean like 1000+).  Perhaps you should wake up in a bathtub full of ice with a nearby note explaining what happened, and instructions on recovery.

Also good point that bionics from the android trait shouldn't be taken, just unlicensed ones.

There have been a few complaints about funnels not working in thunderstorms, will have to look into it.

305
You know how there's always some incredibly dysfunctional government entity that survived the apocalypse and has become someone's personal army?

ATF

306
Re: copbots, you can justify their behavior any way you like as has been demonstrated, you can also easy build a case for why their behavior is nonsensical.  I do think the key explanation is some combination of them relying on some central resource that is no longer available and emergency modifications being applied to them that made them go haywire. (hey, every apocalypse at once, this includes all the copbots going crazy).

The problem with the copbots IMO is that they're too dumb to outsmart.  You SHOULD be able to break a window, go into hiding or leave the area for a while until the eyebots give up, then return and grab your loot.  I think you can maybe wait it out by hiding, but unfortunately the eyebots spawn centered on the player, not the alarm, so they're nearly impossible to run from.  I filed an issue to address this months ago, but it hasn't floated to the top of the pile of issues to be addressed.  There are other fun things that we would like to enable, like having copbots be persistent instead of teleporting in based on an alarm, and getting them to do stuff for you, either by tricking them or by reprogramming them somehow.

307
Hmm. I guess it depends on how the code handles the world creature info. If it is mostly just raw #s, then simply adjusting numbers over time is fairly simple. Every X days, for example, there is a % change in the various populations and zombies get 'upgraded'
It's going to be per-zombie pretty much, but other than that yes.
For zombies of a specific instance, you'd have to have a % chance per zombie that it would be upgraded in some way every X amount of time.
Yep, that's precisely it.
Would the code have caps on total numbers? Or would you eventually have towns full of nothing but late-game zombies running around?
Well "upgraded" zombies anyway, or we might have some cycles as was suggested that transforms them back (shocker zombie runs out of power, hulk breaks apart into multiple vanilla zombies, etc)
With that in place, you could have the immediate area + any towns on the known map get harder, but leave untouched areas alone until discovered so that if you do spawn a new character they could have normal zombies for a while.
Hrm, we CAN do that, but that means any time you explore you go back in time, which is odd to say the least...
Or new characters are just sort of screwed. Hard to say. It's a bit of a design decision. Although new characters stuck dealing with nasty monsters from the get-go would probably encourage people to mostly ditch old worlds, which personally I find to be a shame. Having character stories layer upon one another is always an attractive feature for me in a roguelike.
Or you just don't think about it too hard and reset all the zombies to their base state with a fresh character :D
There are already continuity issues with a new character spawning after a previous one dies, but on the same day.  One is where was the new survivor all this time, where they just sitting in a hole the entire time?  Another of course is that the season is reset, and this would be similar to that.

308
Aah I see, thing is dynamic spawn is going away.  It's really not compatable with this kind of thing, and some kind of "flood fill safe zone" is even more computationally difficult than setting up the borders in the first place.

We have some ideas in the direction of when you start out there are only vanilla zombie types, and they mutate into the tougher zombies over time, but no one has seriously dug into it as yet.

309
Hrm, monsters in general are static, but have spawn locations, makes sense for some things yea.

In the end, what I want to do is convert everything over to some kind of sensical population model.

Zombies don't reproduce, done.  It's just that there are a lot of them, and they get back up...
Animals, triffids, other plants, would reproduce seasonally.  In practice when a map tile containing an animal is loaded, it checks to see if a breeding season* has passed.  If so, there's some chance for the animal to multiply.  Triffids might have some weird link to the queen.
Fungal creatures could reproduce continuously but slowly, and bud from a spire. (I think GlyphGryph has some strong opinions on this, so that's just an example.)
Insects would reproduce seasonally, but only spawn from the queen and therefore at a much higher rate.
Spoiler (click to show/hide)
Grabboids and worms would probably reproduce continuously but slowly.
Nether creatures might actually continue to act like dynamic spawn, as they're just coming out of the portal.  If you wiped out the population around a portal, left, and came back much later, the population would ahve replinished.

*Breeding seasons might be different for different creatures, and effective breeding system might be when the young mature rather than when they are born.

310
oh duh, my brain wasn't working, we'd just mark the tile dirty and do the check once when it's unloaded.
Already planning on offloading a bunch of bookkeepping onto map tile load/unload.  So yea, there'd just be an algorithm that checks navigability of the tile and it gets run when a map tile is unloaded.  Possibly even allowing for traps to be "pseudo-blocking", so if you have contiguous walls and traps blocking navagability, things would move across, but be forced onto the traps.  Of course that isn't going to do much to zombies unless it obliterates them...

Re: "breaching", the blockage is per-tile, so we won't be checking continuity for an entire perimiter or something.  Imagine it like this, if you zoom out of the normal map scale to the overmap scale (conviniently what you see on the map display), one tile is now just a single square of terrain, and hordes navigate around on it on relatively long timescales (not sure what scale exactly, basically a horde would have an "overmap move speed").  Some tiles, like deep water for terrestrial animals, are already blocking, so on the overmap scale that kind of horde wouldn't be able to cross that tile.  Building contiguous wals across a tile would mark that tile as non-navigible to non-flying creatures, there might be a directionality thing, but it'd be much easier to just say the tile is blocked off entirely.  That way we don't have to worry about the potentially NP-hard problem of determining connected-ness.

This means, for example, that you could have gaps all over the place but still block movement.  The thing is, I'd rather it act a little funny than either delay the feature (potentially by a LOT) or not have it at all.

311
Now that I think about it, what we'll probably need to do is add a check every time you build or destroy terrain that blocks movement (boo, this probably will not be fun) that checks the current submap tile for whether it blocks movement across the tile, and in which directions??? and if so, mark it as such on the overmap sot hat as we're moving zombie (and other) hordes around on the overmap scale, it blocks properly.  I was hoping to avoid this, but I don't see any way around it.  Building a wall isn't that frequent, it's all the checks when walls are destroyed I'm kind of dreading :P

312
Will it be possible to have multiple tilesets at once and switch from one to another while ingame ?
That's technically possible, but it would be a good bit of work I think, and we don't have any plans to do it at the moment.

313


You know, there was a difficult collision detection thing when I was implementing this, and I had a simple solution that handled if the vehicle was in front of you OR behind you, then I thought to myself, what would the crazy users do to break this?
I want to make a 3x3 of frames and caster wheels, put myself in the middle, and push around a mobile shopping-cart-fortress!
Then I threw out the simple solution and made pushing a wacky doughnut vehicle work.  Thanks for proving me right.

Also... shopping cart with a turret, I'll have to check this out when I get home.

EDIT: avoiding double-post.
Not to open up the discussion again, but just to clarify some points:
Perhaps tiles could be partially generated based on their neighbours' content to create a smoother transition whilst aiming for a recognisably distinct 'border'.
Not generated, but we support "center" vs "border" tiles for seamless merging of multi-tile items (walls, furniture, etc) Continuity is provided by seamless terrain tiles underneath partially transparent furniture tiles.
Perspective could be considered.
The more advanced version of the above tile merging code alows for isomorphic tilesets, which we're planning on supporting.

cib wrote a 3d visualization system that looks pretty sweet, but isn't particularly playable.  Might revisit that when we have multiple z-levels visible.

314
Metric FTW!
Just recently we switched from "quarter-lbs"... <_< (no comment)
to grams for item weights.  Then we convert to either lbs or kg for display based on the option.  I keep meaning to add "slug" "stone" etc as options. :D
Same for temperature etc. though for that I keep meaning to make temperature display fuzzy and relative.  I mean why does your survivor know the temperature to the degree all the time?

More fun with measures, we use quarter-degrees for gun accuracy.  The only change we might make there is switching to a more common measure called MOA (minute of arc, 1/60th of a degree), which corresponds to one inch of deviation at 100 yards.  This is significantly more resolution than we need, as the entire play field is about 60 yards or so in radius.  More than we need is a good place to be though, and there are no down sides :D

315
Update on the city size option, I tracked down what was making it ridiculously slow, and the change is waiting on someone else to verify that my code won't set your printer on fire or kick your puppy.
With those changes, it's now where it should be, taking approximately 6 seconds instead of 30min+(or never completing) on the largest settings.

For the curious, turns out it was two things.  First the sewer and subway generation code was busily building a fully-connected graph between every manhole and subway station respectively.  Once you had more than a certain number of stations in play this just exploded.  It also made far too large a sewer and subway system.  The second issue was that forest placement was taking (sometimes literally) forever because its implementation was to repeatedly pick a spot on the map at random and evaluate it against proximity to a city.  On the largest city settings, there was literally nowhere to put the forests, so it just kept looking forever.

Pages: 1 ... 19 20 [21] 22 23 ... 26