View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0004663 | Valley 1 | Gameplay Issue | Oct 7, 2011 2:02 pm | May 23, 2012 1:37 pm | |
| Reporter | stblr | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | open | ||
| Summary | 0004663: Reveal the minimap by what the player sees instead of in chunks | ||||
| Description | The way the minimap is revealed over time now seems to be done in "chunks" that are uncovered when the player's character touches the edge of a dark chunk. Having the minimap uncovered by what the player actually sees on the screen makes more sense. This will make exploration more directly engaging, will make light scrolls and light sources more important (assuming the minimap will only be revealed if the player character can "see" what's around), and will cut down on exploration fatigue as players are often compelled to uncover all of the minimap for any given room. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | Major Problem | ||||
| has duplicate | 0004806 | closed | Auto-mapping is too "blocky" | |
| related to | 0004085 | resolved | Chris_McElligottPark | Minor exploration tedium |
|
|
Perhaps just reveal the next "chunk" of minimap when you're within some distance of it rather than having to actually reach it. This would always have the minimap being revealed ahead of you without having to map what you're actually seeing on the screen to it. |
|
|
Yes, more along the lines of what Jerith is saying is what I was thinking. Trying to display this by pixel causes lots of issues in multiplayer, and general other issues with tall outdoors areas, etc. I thought about this a fair bit a week or so ago, but I don't think the by-chunks approach is avoidable. |
|
|
I realize this isn't a trivial thing to program, but as far as multiplayer is concerned, this is an opportunity too. It would open up things like mapmaking--e.g. Player A can craft a map that Player B can use to uncover areas they haven't explored themselves. As for tall outdoor areas, I think the current by-chunk behavior isn't so bad because uncovering the minimap is essentially a completely horizontal process anyway. It becomes more of an issue in environments that have to be navigated horizontally and vertically, like caves. |
|
|
It's not that much a matter of how trivial it is to program -- programming this would in fact be trivial. Programming it to not bog down the entire network while you play, though... that's another matter. It pretty well HAS to be done in chunks, because otherwise the data transmitted is just too large. A given map can be 256x256 pixels. That's 65k pixels. With an x and y coordinate for each, and having to serialize that data, that's a really immense amount of data to try to send over the network, little by little, whenever anybody walks anywhere. It's not that bad with one player, or even two, but the amount of load that adds puts a large linear load per-player. I don't see a way to make that work well. |
|
|
So the plan is to make all players in a server share what's uncovered? Why not make it purely client-side and not send that data to the server at all? |
|
|
stblr: I think just revealing the next chunk before you reach it will address most of your concerns, especially if it's combined with shrinking the chunk size down again. Tying it directly to what you're seeing has a very high runtime computational cost as well the extra complexity -- basically, it'd be slower and potentially buggier. The incremental benefit over by-chunks-in-advance is minimal, and almost certainly not worth the cost in performance and dev time. |
|
|
Right -- what Jerith said on that. "So the plan is to make all players in a server share what's uncovered? Why not make it purely client-side and not send that data to the server at all?" In terms of that... well, this is a co-op game. Generally all the info is shared for things of that nature. Also, the thing to remember is that having client-side-only data is fine, but that data cannot be saved to disk. So every player would have to re-explore every chunk every time they came back to it. Or they would have to send a REALLY big "here's what I explore while I was here" message to the server every time they exit a chunk. |
|
|
Really, the pixels-I-can-see method is the chunk-in-advance method taken to the extreme of having 1-pixel chunks. Making the chunks bigger gives you the performance benefits without that much degradation in perceived effect. The only major difference is that your light radius or whatever isn't considered, and trying to do that is full of spiders -- how dim does it have to be before it's counted as "dark", for example. |
|
|
Yep. |
|
|
To ride jerith's post, turning the darkness overlay into something as rough as a 64x64 bit matrix for each room translates into just 512 bytes for each room--a very tiny amount of data to be stored on disc, even if players have explored thousands of rooms. And having the server send this out to a few players when entering a room is not a huge amount of data to send over a network. |
|
|
That is true, that would be a lot more doable. Sending the whole thing rather than sending it in chunks would also be helpful. But then you have the problem that anytime people walk on the surface, there's all these extra bits of not-explored sky hanging around up there. Like the edges of a scratch-off prize thingy. I know there's nothing under there, but the OCD part of me makes me scratch it all off -- or in this case, go leaping around in the sky just to make it clean, etc. There's then logic that can be done about automatically propagating the display upwards in the event that there is nothing but sky above, but then you get into cases like tall interiors or caves, etc. Which probably aren't mostly an issue, but in something like a boss room there could be stuff up there or not. Which maybe is fine, but still. The other note is that we have to serialize all of this to strings based on how our networking model works, so 4096 characters at 4 bytes each is 16kb. We could game that by making it only send the rows that have actually changed when the player is moving around on the client side -- so if you're only in range of 2 rows at a given time, that would be 256 bytes per row, or back into the 512 byte range. All of this gets compressed anyhow, so even if we sent the whole thing it wouldn't be as much as it could be, but it's a load I'm wary of introducing prior to having multiplayer working without it, unless it was done in a fairly coarse manner. Anyway, the above might well work pretty well, actually. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Oct 7, 2011 2:02 pm | stblr | New Issue | |
| Oct 7, 2011 2:14 pm | jerith | Note Added: 0016089 | |
| Oct 7, 2011 2:30 pm | Chris_McElligottPark | Note Added: 0016093 | |
| Oct 7, 2011 2:36 pm | stblr | Note Added: 0016096 | |
| Oct 7, 2011 2:36 pm | stblr | Note Edited: 0016096 | |
| Oct 7, 2011 2:37 pm | stblr | Note Edited: 0016096 | |
| Oct 7, 2011 2:43 pm | Chris_McElligottPark | Note Added: 0016098 | |
| Oct 7, 2011 2:46 pm | stblr | Note Added: 0016099 | |
| Oct 7, 2011 2:46 pm | jerith | Note Added: 0016100 | |
| Oct 7, 2011 2:49 pm | Chris_McElligottPark | Note Added: 0016102 | |
| Oct 7, 2011 2:55 pm | jerith | Note Added: 0016104 | |
| Oct 7, 2011 2:56 pm | tigersfan | Internal Weight | => Major Problem |
| Oct 7, 2011 2:56 pm | tigersfan | Assigned To | => Chris_McElligottPark |
| Oct 7, 2011 2:56 pm | tigersfan | Status | new => assigned |
| Oct 7, 2011 2:59 pm | Chris_McElligottPark | Note Added: 0016105 | |
| Oct 7, 2011 3:00 pm | stblr | Note Added: 0016107 | |
| Oct 7, 2011 3:02 pm | stblr | Note Edited: 0016107 | |
| Oct 7, 2011 3:08 pm | Chris_McElligottPark | Note Added: 0016108 | |
| Oct 12, 2011 4:55 pm | jerith | Relationship added | has duplicate 0004806 |
| Jan 27, 2012 1:08 pm | tigersfan | Relationship added | related to 0004085 |
| May 23, 2012 1:37 pm | tigersfan | Status | assigned => resolved |
| May 23, 2012 1:37 pm | tigersfan | Product Version | => 1.029 |
| May 23, 2012 1:37 pm | tigersfan | Product Version | 1.029 => |
| Apr 14, 2014 9:28 am | Chris_McElligottPark | Category | Gameplay - General Complaint => Gameplay Issue |
