View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0004636 | Valley 1 | Crash/Exception | Oct 6, 2011 6:19 pm | Oct 12, 2011 7:10 pm | |
| Reporter | FallingStar | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.519 | ||||
| Summary | 0004636: New Pylons(?) can cause strategic map lockup | ||||
| Description | I had no issues with the new pylons in a mature world, but I was going to start a new world to test a few of the mechanics on beginning level players. Ended up getting to the strategic map, then when trying to move (where new chunks would start to draw in) everything locked up in the game, for over a minute. Used task manager to quit. Tried a few more times and could occasionally move, but would lock up with chunks half drawn in (just the border and black square) sometimes, with notification of a lt.. that was plaguing these lands, standard stuff. I made a few more worlds, and occasionally had the chunks draw in slowly or stall for a half second, but never the lockup I had with that first test world. I wish I could send it, but I deleted the wrong test world (sigh, gotta name them more differently from now on) so if I can get another that just seems terribly locked again I'll send it along. Didn't see anything in the crash log either so I'll poke around and see what I can do if the answer isn't obvious on dev end. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | Fix ASAP | ||||
| related to | 0004591 | resolved | Chris_McElligottPark | Crash when exploring new tiles |
| has duplicate | 0004656 | closed | Locked by pylons |
|
|
This sounds like it might be a less severe version of 0004591. The initial lockup seems the same, but the slowness after that could be the infinite loop countermeasures kicking in. |
|
|
Yea, this would make anything like that a more significant chance because it drasticallly increases the range of world that it will generate (to make sure that a pylon you already can see can't connect to a pylon just now being generated. Can you keep an eye on the memory being used by the process (I use process explorer for this, but OS-builtin tools should be enough) at these times: 1) Right after starting the game, while the main menu is sitting there waiting for you. 2) Right after starting a new world, after picking a character, just standing there in the first settlement. 3) Right after going onto the world map for the first time, just standing there. 4) After taking one step on the world map. 5) After a few more steps, etc. 6) While it's locking up (if you can get it to do that). My suspicion is that it's somehow burning up a ton of memory while generating all those regions (which doesn't make a lot of sense in retrospect, the regions themselves aren't very large in memory, they don't get big until you try to enter them), and you're running into massive garbage collector lag and sometimes flat out crashes, etc. Or it could be some weird infinite loop, sure. |
|
|
Can you post the world where this is happening? We've never been able to duplicate the issue, so if you have a reproducible case that would be sweet. :) EDIT: Whoops, I see it was deleted, I should read more carefully. |
|
|
Keith, there really shouldn't be memory spikes of this nature. With it pegging the CPU, I think the only thing it seems likely to be is a strange infinite loop, but I don't know for sure. |
|
|
If there's any transient alloc inside the loop it can quite easily nail memory. Not out-of-memory crash style, but constantly-stuck-in-the-GC. |
|
|
You're thinking there is _hundreds_ of MB of transient allocation per few frames in there? Good god, that would be quite a feat. ;) |
|
|
I saw it just last night. Different loop, but sure. |
|
|
I had the privilege of seeing Process Explorer report that Unity was using over 2,500MB, actually ;) All adding the same two-int struct to the same list over, and over, and over. |
|
|
In what loop is this? That sounds like a refactor that needs to happen. Are you referring to every time the player moves and it checks all the nearby regions against the array? Because I could definitely change that. I've even been wondering lately if we want the on-world-map fog of war at all. Now we have the exploration thing in the strategic mode, and I don't like having two fogs of war. And players have mentioned the frustrations with having to wander around the perimiter of their world every time they level up, never being sure where they will uncover more tiles and where they will not. Just getting rid of the world map fog of war, and keeping the exploration one in the strategic side, would solve a lot of this I expect. And as for the spawning of new regions, that could easily be handled by a more linear square offset that would require no structs or loops within loops. Been thinking about refactoring that for a while myself, too. |
|
|
"In what loop is this? That sounds like a refactor that needs to happen. Are you referring to every time the player moves and it checks all the nearby regions against the array? Because I could definitely change that." It was new code (finding points on a line for the pylon stuff), and a bug was causing the loop to not terminate. "Just getting rid of the world map fog of war, and keeping the exploration one in the strategic side, would solve a lot of this I expect." Yea, I'd like to get rid of the cannot-see-stuff-11-or-more-levels-higher thing too, if that's what you mean. I think the pylons work as a sufficient boundary. An odd pylon placement might let you break out for a bit longer than usual but statistically speaking it's going to catch you again soon. That said, it may result in bigger worlds than currently because it would no longer be bounded so strictly by level progression. "And as for the spawning of new regions, that could easily be handled by a more linear square offset that would require no structs or loops within loops. Been thinking about refactoring that for a while myself, too." If you'd like to, go ahead. It's not connected with the loop I was talking about earlier, if that's what you're thinking ;) |
|
|
"Yea, I'd like to get rid of the cannot-see-stuff-11-or-more-levels-higher thing too, if that's what you mean. I think the pylons work as a sufficient boundary. An odd pylon placement might let you break out for a bit longer than usual but statistically speaking it's going to catch you again soon. That said, it may result in bigger worlds than currently because it would no longer be bounded so strictly by level progression." No, that's not what I meant -- I love that 11-or-more-higher thing, and players seem to as well. Having the world get larger as you level up is my favorite feature of the world map. I'm referring to having to walk near tiles that are lower than 11 higher than yourself in order to see them. Thoughts on that one? The other refactor I was mentioning doesn't really work terribly well without that. |
|
|
Also: the cannot-see-stuff-11-or-more-levels-higher thing is all that keeps the world file from getting too large too quickly to the point where we're running into level 1000 problems at level 10. And any regions that are more than 10 levels higher than yourself won't scale properly, as it's expected you can't even reach them. Etc, etc. |
|
|
Oh, I liked the reveal-as-you-walk-around, but sure, if you want to take it out go ahead. Though I'm not sure it makes a big difference in the refactor you were talking about: the "make sure all regions within X distance are generated" loop is separate from the "make sure all regions within 3 distance are visible, unless > civLevel+10" loop. |
|
|
Ok -- I think it's worth taking out, though, as it's already frustrating players. And I can replace the "make sure all regions withing X" loop is actually replaced with a substantially different loop that would be a lot kinder processing-wise in general. I dunno. I think it would be cleaner, and less annoying for players. In terms of regions-higher-than-10 not showing, I could actually change that to making them not even GENERATE. Which would be ideal because then you don't get roads to nowhere and lots of extra regions early on that players won't visit for ages, etc. It's a completely new approach to generating the world map -- again -- but basically just making it generate at least X number of region tiles for each region level, and ignore all directonality, would make for a more organic world map that grows in varied directions, doesn't have extra mess in there, and so on. I think I'll give that a shot, and I expect that will solve a lot of processing issues for us on the world map, honestly. |
|
|
I'm definitely not following how you could have it not generate a region higher than 10+ AND remove the directionality rules for determining a region's level... or do you mean that it would just generate the regions of the "next" level that hadn't been generated yet, unless that would be more than 10+ and in that case generates nothing? That could work. I expect massive unintentional-consequences-ahh-the-game-is-broken situations in the first prerelease, though ;) |
|
|
Oh, but we might have to revert the pylons back out for that to work: currently it can only guaruntee that a player won't be standing on a region that is blocked by a newly generated pylon if it never generates a region (after initial world gen) closer than 13 distance to the player. From what you're saying you're wanting it to even be willing to forestall generation if the region is directly adjacent to the player if that region would be higher than +10. |
|
|
What I mean is, there would be a LastFullyGeneratedRegionLevel int on world. That would start out at 0. If that level that is less than or equal to 10 higher than the civ level, it would automatically generate n number of regions of that level, at random starting next to existing regions that are part of the world. Then when n regions of that level are generated, it increments the LastFullyGeneratedRegionLevel int. And that's literally it. :) |
|
|
In terms of the pylons, that logic would not have worked in multiplayer anyhow, would it have? Just because one player isn't closer than 13 tiles to a pylon doesn't mean another player wouldn't be, right? But at any rate, if we had to we could make it so that pylons check the positions of all players and don't seed on any region that is too close to them. |
|
|
I love watching you two argue back and forth about how to make this game :) |
|
|
It is sooooo much better than arguing with yourself, trust me. Back when I did this all solo, I'd get into mental infinite loops that I couldn't easily get out of. Having Keith to argue with really sharpens things and keeps things moving quickly. :) |
|
|
It would have worked just fine in multiplayer, because no player would have gotten within 13 tiles of the edge of the generated world without it generating that next tile. "But at any rate, if we had to we could make it so that pylons check the positions of all players and don't seed on any region that is too close to them." That would break the way they were modeled to work in that there'd be large gaps in the coverage depending on where the players were standing at generation time, etc. |
|
|
See, but I really really hate generating so many regions so far away from where the player can even get -- it's causing things like: 1. Lieutenants in ridiculously high level regions that can't be reached, and thus causing world events to get logged. 2. General world file bloat; something that is a major, major concern of mine. 3. Extra slowness when players move around the edges, as it's generating stuff that will be useless for hours and hours of play, if not longer. I can see several ways of solving the pylons thing. The two I like best: A. Have the mapgen automatically try to seed the new areas in a location that is not within 13 tiles of any players. If that's not possible it could either wait until later or go ahead and seed anyway, causing gaps in the coverage -- the latter seems fine to me as we don't want the world to be a uniform lattice anyhow. But this generally has the disadvantage that multiple players could try to affect pylon seeding by organizing themselves in funny patterns in multiplayer. The longer they played the less possible this would get, but early in it could be a major viable strategy. B. Make it so that it doesn't care if it overlaps the player. Instead, if it overlaps the player, than have it zap them back to the last settlement they were in, or something along those lines. The rationale could be that the vortexes just went up, and the players got caught in them. |
|
|
"A. Have the mapgen automatically try to seed the new areas in a location that is not within 13 tiles of any players. If that's not possible it could either wait until later or go ahead and seed anyway, causing gaps in the coverage -- the latter seems fine to me as we don't want the world to be a uniform lattice anyhow." It's not uniform at all, it tends to have pretty crazy shapes, but it would be likely to have large gaps if it couldn't generate in range of a player. By my guess, it would never place them unless the game was generating regions... basically as far away as it is now, which you've already said isn't acceptable. "B. Make it so that it doesn't care if it overlaps the player. Instead, if it overlaps the player, than have it zap them back to the last settlement they were in, or something along those lines. The rationale could be that the vortexes just went up, and the players got caught in them." I can't think of any particular reason why that wouldn't work, though it may prove confusing/looks-buggish to the players caught in it, particularly in multiplayer where Player A might be in the middle of a chunk somewhere when Player B moves such that a new pylon is generated that links with another pylon near Player A and blocks their region, resulting in them being zapped off to some other settlement. And actually the problem would be more general than that: even if their specific region wasn't cut off, they might wind up in a "pocket" cut off from the rest of the world unless another player blasts the nearby pylon. So that pretty much kills that solution from the MP perspective. Should I just go ahead and revert out the pylons? I'll make the deserialization code read them and discard them so it won't break the old worlds. It seems pretty clear that they aren't compatible with the way you want to do worldgen. |
|
|
I don't necessarily want to revert out the pylons, but they are certainly complicating world-gen matters that weren't really fully finalized as it was already. I think pylons are worth keeping, but if there are big pockets without them... so what? I think that's better than not having them at all, and honestly I think that if they were a bit more rare that would not be a bad thing anyhow. |
|
|
"I think pylons are worth keeping, but if there are big pockets without them... so what? I think that's better than not having them at all, and honestly I think that if they were a bit more rare that would not be a bad thing anyhow." The main problems I have with that are: 1) Mathematically, it really sounds like it would be not having them at all. When would the player _not_ be within 13 tiles of the newly generated region unless we were generating regions at least as far out as we are now? 2) If they aren't common, they don't meet the original goal of adding challenge to world map travel and should probably be heavily redone anyway since presumably they would be intended to serve some more specialized goal (which they're not currently designed to serve). The whole reason was to add general-case boundaries that can be overcome, and they would just be easily ignorable if they weren't common. The reason I made them so far apart (which is causing the excessive generation woes) was that I didn't want there to be such a huge number of individual pylons. |
|
|
The other thing that we could do, actually, is this, which might let us keep the case B and just have the pylons cross wherever, not caring about players: 1. Give the players a new "warp back to last visited settlement" and possibly even a "warp back to home settlement" ability that shows up on the world map as special buttons or something along those lines. Then anyone who gets trapped can automatically get home no matter what. This also doubles as a convenience feature for getting back to town quickly after you've been on an expedition, but it doesn't let you warp BACK to areas that now might be inaccessible. And if a player is standing on a tile that has a vortex on it, the rule might be that they can move to any adjacent tile (vortex or no), but they can't enter the tile they are presently on. And we could make it so that if a player is in a region that has a vortex on it, suddenly the monsters all get a crazy buff and the world gets some insane vortex-looking weather even indoors. They can stay as long as they like, but they're strongly... ah, encouraged to leave. ;) I think there's a number of mechanics along these lines that we could invent and put in, to make the pylons and vortexes MORE a part of the game, rather than less or taking them out. |
|
|
I'd be in favor of a warp-back-to-last-settlement thing, sure. We'd still have a conundrum though, if a region literally adjacent to the visible area could be ungenerated until later: that last-visited-settlement might find itself suddenly under (or within a triangle of) vortex blocking, and the player would then be cut off from the rest of the world. I actually spent a few hours thinking through how to place these and how to pick which regions to block to avoid fresh worlds (not old beta ones, those obviously have potential problems) having cases where the player would ever be trapped, and one of the things it relies on is that the already-visible world can never have new "blocking lines" added to it, which is basically impossible to guarantee without guaranteeing that pylons cannot be generated within some distance of the visible world. |
|
|
"1) Mathematically, it really sounds like it would be not having them at all. When would the player _not_ be within 13 tiles of the newly generated region unless we were generating regions at least as far out as we are now?" Per my notes above, we'd be generating new regions at random around the perimeter of the world -- it has nothing to do with where the player walks. So if the world is more than 13 tiles wide, the odds of it being out of range when the player is near one edge are really good. And we could look for areas that are further out. That's assuming we were trying to keep them away from the players, which I don't really see a need to do. "2) If they aren't common, they don't meet the original goal of adding challenge to world map travel and should probably be heavily redone anyway since presumably they would be intended to serve some more specialized goal (which they're not currently designed to serve). The whole reason was to add general-case boundaries that can be overcome, and they would just be easily ignorable if they weren't common. The reason I made them so far apart (which is causing the excessive generation woes) was that I didn't want there to be such a huge number of individual pylons." Well, point taken there. But I think that we could keep your exact current seeding logic and just redefine what happens to players who are caught in a vortex, honestly. Keep all the logic about not being able to ENTER a vortex if you're not already in one, but just change what it means to already be in one. And add a way to get "back home" aside from suicide, assuming that you're already on the world map -- that seems like a wise thing to have anyway. I'm trying to make as few changes to your pylons stuff here as possible, but I'm finding I want to really rejigger the world map that they lie under; work with me here. ;) |
|
|
I tried getting the world back via data recovery, no luck as it was corrupted already. I did however quit through process manager, so have those ## if it would help, and checked memory usage in new worlds on my setup. Main menu: 300 MB memory usage Entered the world, no movement 400 MB Strategic map 450 MB Moving around and revealing chunks 470 MB (goes up as I reveal more or enter chunks, doesn't seem to increase unusually when I hit bits that load a bit slower, though CPU usage goes from 3% to perhaps 12%) When I canceled due to lockup 1400 MB (I didn't notice it spiraling upwards though or anything) By comparison my "mature" (civ 30ish) world takes 950 MB on strat map and goes up over 1 GB as I load chunks. I was playing my level 30 world before I started the new game, don't know if that would make a difference to anything. Anyways, hope it helps and if I find another that locks hard I'll send it along. Edit: I guess the Mantis hates the tilda =p |
|
|
"We'd still have a conundrum though, if a region literally adjacent to the visible area could be ungenerated until later: that last-visited-settlement might find itself suddenly under (or within a triangle of) vortex blocking, and the player would then be cut off from the rest of the world." Well, I suggest the following: that we not allow any pylons or vortexes within some range of the 0,0 world coordinate -- say, not within 13 of them. Maybe even a bit higher than that. This is good anyhow, because frankly for new players I don't really WANT pylons around. I think pylons are great for once the training wheels are coming off a bit and players are learning their way around. And it creates a sense of escalation in the world, too. But right near the start of the game there's enough complexity to be getting on with already, and on reflection I don't really want pylons adding to the things that new players have to learn in their first 5-10 minutes of play. So, if we had that "safe zone" area at the start of the game, that would mean that theoretically all pylons would be reachable, right? And if there was a "warp back to 0,0" option, that would solve the players getting stuck. |
|
|
@FallingStar : Thanks for the details! That definitely sounds fishy. |
|
|
"Well, I suggest the following: that we not allow any pylons or vortexes within some range of the 0,0 world coordinate -- say, not within 13 of them. Maybe even a bit higher than that. This is good anyhow, because frankly for new players I don't really WANT pylons around." One of the existing rules in 0.519 is "Cannot seed closer than 16 tiles to the 0,0 region (initial settlement). That doesn't prevent other settlements (including the last-visited) from getting boxed in. "And if there was a "warp back to 0,0" option, that would solve the players getting stuck." Warp back to 0,0 _would_ change things, yes. I was still thinking in terms of warping back to last-visited-settlement, which is what I thought you'd meant. ... That might work, we could give it a shot :) "I'm trying to make as few changes to your pylons stuff here as possible, but I'm finding I want to really rejigger the world map that they lie under; work with me here. ;)" The problem is that I should have waited until worldgen was more or less final. I thought it had been. Me doing pylons at this time is analagous to me trying to implement the Fallen Spire campaign in AIW before wormholes when you still had galaxy-map-distance-based warps with command ships, etc ;) |
|
|
"One of the existing rules in 0.519 is "Cannot seed closer than 16 tiles to the 0,0 region (initial settlement)." Oh, awesome, I missed that. That's great! The vortexes are crossing a lot closer than that, though, aren't they? Maybe not, I dunno. "That doesn't prevent other settlements (including the last-visited) from getting boxed in." Right, and I think that's okay -- evil overlord at work, and all that. :) "Warp back to 0,0 _would_ change things, yes. I was still thinking in terms of warping back to last-visited-settlement, which is what I thought you'd meant." I was thinking we'd have both. But actually, just going back to 0,0 would probably be the safest thing, because otherwise people could warp into vortexes or across them by using that to-last-settlement one. Though, not sure if THAT's horrible. "The problem is that I should have waited until worldgen was more or less final. I thought it had been." Yeah, sorry about that -- a week ago I thought it was final, too. But then I keep getting players with these massive savegames just at level 30, and I realize we've got a problem here. And then we get complaints about moving around the edges being tedious, too, which really makes for an entirely different premise of how the world gets revealed -- the existing way and auto-revealing really don't mix, for instance. "Me doing pylons at this time is analagous to me trying to implement the Fallen Spire campaign in AIW before wormholes when you still had galaxy-map-distance-based warps with command ships, etc ;)" I don't think it's quite THAT bad, but point taken. The world map has just in general been tripping my "something is a little off here" trigger for the last few weeks. And I should have mentioned that when we were talking about pylons, but I substantially misunderstood the scale of how pylons would be creating barriers -- I was envisioning something a lot more local, which wouldn't have all these restrictions. This way is quite a lot more interesting and better, don't get me wrong. But still. Anyway, it sounds like we basically have a solution here... yes? |
|
|
"Anyway, it sounds like we basically have a solution here... yes?" I think if: - You do whatever craziness you're planning in terms of region gen (I really like the idea of it just generating X regions or super-regions or whatever of level Y and that's it, and it stops when it gets to civLevel+10). - We add a warp-back-to-0,0 button to the world map (probably on the escape menu for a first pass, shouldn't be a needed-really-often thing). That should take care of the worst of it. There's bound to be other problems I'm not thinking of, but that's what beta testers are for! ... ahem, I mean... |
|
|
Cool -- I think that will handle all this, then. Can you add the warp button? I'll take care of the map refactoring, and the moving-if-already-on-a-vortex logic, and the caught-in-vortex-chunk logic/art. I should be able to have that in for a lunchtime release tomorrow, I think. |
|
|
"moving-if-already-on-a-vortex logic, and the caught-in-vortex-chunk logic/art" I don't think anything will be necessary there, the warp is enough. If you really want to do the in-chunk effect that's fine, but I don't think it's necessary to do right up front. And yea, I'll do the warp button in the morning. |
|
|
Okay, I'll leave those things out, then, until we see if they even become needed. Good point. No need to borrow complexity too early. ;) Thanks on the button, that should be great. :) |
|
|
"There's bound to be other problems I'm not thinking of, but that's what beta testers are for! ... ahem, I mean..." -- It pretty much is, actually. Just... please don't render the game unplayable without warning us first. :-) Wouldn't it be possible to decouple pylon generation from region generation? Seed pylon locations up to 13 tiles from the edge of Known Space, but only actually generate those regions later. That would add some constraints to region gen (you probably don't want hostile terrain under two pylons within range of each other (if at all), for example) but would neatly solve the problem of pylons popping up to cover previously-accessible areas. |
|
|
I don't think we could seed pylons outside of region-space, as there's no guarantee that space would be anything passable, or would even ever be seeded in any reasonable amount of time. It's an interesting idea, but it would be a pretty gigantic refactor in a lot of ways. |
|
|
Okay, this should be fixed in the 0.520 version, what with all these changes: * The way that the world map is generated has been completely overhauled. ** Previously there was a lot of logic in there about which direction the map would generate higher-tier regions in, and the game was generating hundreds of unseen regions that were forming a "crust" around the actual areas you could get to. Also, as you explored around, it would generate the world partly based on where you walked, and not until you walked near an area. All of this is now completely gone. ** The new way is simply to look at your civ level, and to then make sure that there are at least four non-water tiles for each level up to your civ level + 10. And actually, for region levels lower than 10 it makes sure there are at least 7 regions at each level, to get the world a little bit larger right from the start. *** It generates these each time you move if it needs, to, but it has nothing to do with proximity to you, and generally speaking it will only generate any new regions when your civ level increases. *** These changes make for both a more focused world (before it could inflate the number of regions 10x just generating stuff you wouldn't see for hours), as well as more distinct, organic worlds that grow in all directions rather than one specific direction. *** As part of this new methodology, the efficiency of the generation algorithm has actually skyrocketed, too -- many fewer transient heap allocations in RAM as you go wandering around the world map, for instance. **** Also, the few reports of lockups that a few players were having with exploring the world map should now be a thing of the past. ** This new method does in fact integrate seamlessly with existing worlds, no matter how large they were. It will simply fill in any missing regions anywhere around the periphery of your world. *** On really old worlds, this might lead to some lower-level region pockets out beyond a lot of higher-level regions, but it should't be too predominant of an effect and won't hurt anything. * The way that overlords and lieutenants are seeded is also now completely revised: ** Neither will even attempt to seed on regions that are lower level than 5, now. Previously, they would upconvert the region level of wherever they happened to seed, but now they don't seed until the given region level actually becomes available. ** The overlords still require a level 20 region, so this actually means that now no overlord even "moves in" to the region until you hit civ level 10. This is kind of interesting, actually, as it's showing the progression of the world after the cataclysm -- time passing and all that -- rather than it just always having an overlord present from the start. It also means that for a while NPCs will talk about something completely unrelated to overlords, and then they'll start complaining about overlords when the overlords move in; that's not new code, it's just something that's cool and that dynamically happens based on existing code. ** The overlords are now also allowed to seed closer together than before -- previously it was just every 40 tiles. Now, since the world can grow organically in any direction, that won't always work. So they can seed as close together as they want to, although this often won't happen to be very close simply because they only seed one overlord per every 20 civ levels. So you have a good break between overlords (depending on your level when you defeat one), anyway. ** Overlords and lieutenants now can't seed any closer than 5 tiles to the 0,0 region; previously the limit was 12, but now that the world grows in all directions that was too far for them to actually be seeding at all before much time had passed; the balance of this is mitigated by the fact that they don't appear at all until later in the game now. ** Now evil outposts now seed prior to an overlord actually existing. The message shown about the lieutenants is different, though, talking about how they are waiting for the coming of an overlord. *** Evil outposts can't seed at all until the civilization level has reached 2, though, to give a brief safer period at the start. ** Lastly, evil outpost seeding logic is completely different -- now it doesn't care how close together the outposts are. That was leading to far too randomized results (and thus difficulty) for the number of lieutenants in the world. Now it just seeds approximately one lieutenant for every 7 region levels. * The way that the world map is explored has been completely overhauled. ** Previously, you had to physically move near to regions on the world map for them to become visible. *** This was sort of a "fog of war" in the strategy game sense, but it had problems in that every time your civ level went up, you'd have to make a circuit of your whole world to find if there was anything new -- which was annoying. *** Additionally, this was confusing because there is an Explored fog of war in the strategic map. Why have two levels of fog of war? Well, we implemented the walking-around one a long time ago, before the exploration one was added on the strategic map. The strategic one is the fun and interesting one, so that's the one we're keeping, while the walking-around one is removed. ** Also, previously there was a limit that you could only see or enter into regions that were at most 10 levels above your civ level. *** Given that the world map now doesn't even seed regions higher than 10 levels above your civ level, this restriction has been removed. What this means for EXISTING worlds, however, is that suddenly you've got all this new (and possibly quite high-level) terrain available to you. *** Going into these very high-level regions is something you can do if you wish, but be advised that anything over 10 levels above your civ level is likely to insta-kill you with one hit. That's not a bug, or even really a balance issue, it's just a factor of you having early access to something that normally you would not in a fresh world. *** Given the way that pylons used to seed themselves, and the way that other things seeded themselves, though, we felt this was an important change to make. The temptation was actually to just delete all those old regions that you'd never seen before, but that gets into a lot of other troubles and could easily lead to corrupting your world, so we're steering clear of that. |
|
|
Is that the longest Mantis note in the history of Arcen? :-) But seriously, I like these changes. I'm looking forward to being able to try out a new world with them. |
|
|
It feels a lot better to me, and is making more interesting worlds while at the same time making the difficulty of the world not so inherently variant. |
|
|
Also: * The first 7 region levels are always predictable types, now: ** 1 : Ice Age ** 2 : Grassland ** 3 : Desert ** 4 : Abandoned Small Town ** 5 : Thawing Ice Age ** 6 : Evergreen Forest ** 7 : Junkyard ** And then beyond those first 7 region levels, it uses the randomization logic it's always used. But this makes for a consistent difficulty to the very start of a new world, since not having a certain region type could really be a problem for players looking to harvest specific kinds of gems, etc. |
|
|
This sounds like a much better approach all around. I love watching the game evolve like this, as new features inspire improvements in how things work elsewhere. I also love being a part of the process. |
|
|
Glad you like it! And this is also sort of related: * The health and attack powers of all enemies that are below level 7 are now automatically scaled down from whatever their normal values would be, to provide an easier transition into the game: ** 1: 40% of normal ** 2: 50% of normal ** 3: 60% of normal ** 4: 70% of normal ** 5: 80% of normal ** 6: 90% of normal ** This makes it easier for players to play up region levels early on in, and gives generally more options while they are still learning the ropes and getting their basic equipment crafted and such. It also should make them able to level up faster, given the early bosses are also weakened by this. |
|
|
I hereby declare this to be the Awesome Ticket of Awesomeness. I can't wait to see what happens in the next couple of comments! |
|
|
Okay, this new one is now out. How's that for awesome? ;) |
|
|
Seems to be fixed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Oct 6, 2011 6:19 pm | FallingStar | New Issue | |
| Oct 6, 2011 6:24 pm | jerith | Note Added: 0015955 | |
| Oct 6, 2011 6:24 pm | jerith | Relationship added | related to 0004591 |
| Oct 6, 2011 6:37 pm | keith.lamothe | Note Added: 0015957 | |
| Oct 6, 2011 6:37 pm | Chris_McElligottPark | Note Added: 0015958 | |
| Oct 6, 2011 6:38 pm | keith.lamothe | Note Edited: 0015957 | |
| Oct 6, 2011 6:38 pm | Chris_McElligottPark | Note Edited: 0015958 | |
| Oct 6, 2011 6:39 pm | Chris_McElligottPark | Note Added: 0015959 | |
| Oct 6, 2011 6:45 pm | keith.lamothe | Note Added: 0015964 | |
| Oct 6, 2011 6:47 pm | Chris_McElligottPark | Note Added: 0015966 | |
| Oct 6, 2011 6:49 pm | keith.lamothe | Note Added: 0015967 | |
| Oct 6, 2011 6:50 pm | keith.lamothe | Note Added: 0015968 | |
| Oct 6, 2011 6:55 pm | Chris_McElligottPark | Note Added: 0015969 | |
| Oct 6, 2011 7:00 pm | keith.lamothe | Note Added: 0015970 | |
| Oct 6, 2011 7:03 pm | Chris_McElligottPark | Note Added: 0015971 | |
| Oct 6, 2011 7:04 pm | Chris_McElligottPark | Note Added: 0015972 | |
| Oct 6, 2011 7:06 pm | keith.lamothe | Note Added: 0015973 | |
| Oct 6, 2011 7:15 pm | Chris_McElligottPark | Note Added: 0015974 | |
| Oct 6, 2011 7:26 pm | keith.lamothe | Note Added: 0015976 | |
| Oct 6, 2011 7:28 pm | keith.lamothe | Note Added: 0015977 | |
| Oct 6, 2011 7:28 pm | keith.lamothe | Note Edited: 0015977 | |
| Oct 6, 2011 7:30 pm | Chris_McElligottPark | Note Added: 0015978 | |
| Oct 6, 2011 7:32 pm | Chris_McElligottPark | Note Added: 0015979 | |
| Oct 6, 2011 7:34 pm | c4sc4 | Note Added: 0015981 | |
| Oct 6, 2011 7:36 pm | Chris_McElligottPark | Note Added: 0015983 | |
| Oct 6, 2011 7:36 pm | keith.lamothe | Note Added: 0015985 | |
| Oct 6, 2011 7:43 pm | Chris_McElligottPark | Note Added: 0015991 | |
| Oct 6, 2011 7:57 pm | keith.lamothe | Note Added: 0015996 | |
| Oct 6, 2011 7:59 pm | Chris_McElligottPark | Note Added: 0015997 | |
| Oct 6, 2011 8:03 pm | keith.lamothe | Note Added: 0015998 | |
| Oct 6, 2011 8:04 pm | Chris_McElligottPark | Note Added: 0015999 | |
| Oct 6, 2011 8:08 pm | keith.lamothe | Note Added: 0016000 | |
| Oct 6, 2011 8:08 pm | Chris_McElligottPark | Note Added: 0016001 | |
| Oct 6, 2011 8:08 pm | FallingStar | Note Added: 0016002 | |
| Oct 6, 2011 8:09 pm | FallingStar | Note Edited: 0016002 | |
| Oct 6, 2011 8:09 pm | FallingStar | Note Edited: 0016002 | |
| Oct 6, 2011 8:12 pm | Chris_McElligottPark | Note Added: 0016004 | |
| Oct 6, 2011 8:13 pm | Chris_McElligottPark | Note Added: 0016005 | |
| Oct 6, 2011 8:17 pm | keith.lamothe | Note Added: 0016007 | |
| Oct 6, 2011 8:24 pm | Chris_McElligottPark | Note Added: 0016008 | |
| Oct 6, 2011 8:29 pm | keith.lamothe | Note Added: 0016009 | |
| Oct 6, 2011 8:34 pm | Chris_McElligottPark | Internal Weight | => Fix ASAP |
| Oct 6, 2011 8:34 pm | Chris_McElligottPark | Note Added: 0016010 | |
| Oct 6, 2011 8:34 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Oct 6, 2011 8:34 pm | Chris_McElligottPark | Status | new => confirmed |
| Oct 6, 2011 8:36 pm | keith.lamothe | Note Added: 0016011 | |
| Oct 6, 2011 8:38 pm | Chris_McElligottPark | Note Added: 0016015 | |
| Oct 7, 2011 2:52 am | jerith | Note Added: 0016032 | |
| Oct 7, 2011 8:01 am | tigersfan | Relationship added | has duplicate 0004656 |
| Oct 7, 2011 8:12 am | Chris_McElligottPark | Note Added: 0016040 | |
| Oct 7, 2011 1:15 pm | Chris_McElligottPark | Note Added: 0016077 | |
| Oct 7, 2011 1:15 pm | Chris_McElligottPark | Status | confirmed => feedback |
| Oct 7, 2011 1:24 pm | tigersfan | Note Added: 0016078 | |
| Oct 7, 2011 1:26 pm | Chris_McElligottPark | Note Added: 0016079 | |
| Oct 7, 2011 1:30 pm | Chris_McElligottPark | Note Added: 0016080 | |
| Oct 7, 2011 1:32 pm | jerith | Note Added: 0016081 | |
| Oct 7, 2011 1:35 pm | Chris_McElligottPark | Note Added: 0016082 | |
| Oct 7, 2011 1:41 pm | jerith | Note Added: 0016084 | |
| Oct 7, 2011 1:42 pm | Chris_McElligottPark | Note Added: 0016086 | |
| Oct 12, 2011 7:10 pm | Chris_McElligottPark | Note Added: 0016493 | |
| Oct 12, 2011 7:10 pm | Chris_McElligottPark | Status | feedback => resolved |
| Oct 12, 2011 7:10 pm | Chris_McElligottPark | Resolution | open => fixed |
| Apr 14, 2014 9:28 am | Chris_McElligottPark | Category | Bug - Crash or Exception => Crash/Exception |
