{"id":2742,"date":"2013-02-10T10:44:43","date_gmt":"2013-02-10T00:44:43","guid":{"rendered":"http:\/\/www.vectorstorm.org\/?p=2742"},"modified":"2013-02-10T11:07:34","modified_gmt":"2013-02-10T01:07:34","slug":"zooming-out","status":"publish","type":"post","link":"https:\/\/www.vectorstorm.com.au\/2013\/02\/10\/zooming-out\/","title":{"rendered":"Zooming out"},"content":{"rendered":"

\"Screen<\/a>So I’m in the middle of building full seamless zoom in\/out functionality for MMORPG Tycoon 2.\u00a0 This was really one of the key interface features of MMORPG Tycoon 1, and being honest with myself, it’s just as important for MMORPG Tycoon 2.\u00a0 I’d originally thought I could get away without it, by presenting separate “close-up” and “distant” map modes the way that every other Tycoon game does.<\/p>\n

But in practice, this was one of the defining features of the original game.\u00a0 I really can’t just ignore it.\u00a0 So I’ve started on implementation.<\/p>\n

Here’s what it looks like right now, with the camera pulled about a kilometer up from the ground, with the camera at the southeast corner of the game world.\u00a0 We can see several regions right now, and we can see out into terrain which doesn’t yet have renderable models in memory.\u00a0 We can also see that I’ve cheated, and haven’t placed water around the game world, yet (you’re seeing off the eastern side of the world, there on the right).<\/p>\n

But more than that, we can see a bunch of other issues;\u00a0 issues which I’ll need to solve.\u00a0 Here’s a list:<\/p>\n

<\/p>\n

    \n
  1. We can see a very visible repeating pattern in the heightmap.\u00a0 This is caused by my having put a repeating pattern in the initial computer-generated heightmap, on the theory that nobody’d ever be using this view and therefore noticing the repeats.\u00a0 Well, now that I’m putting in this view, people are going to notice.\u00a0 So I need a smarter base heightmap generation algorithm.<\/li>\n
  2. From this view, it’s suddenly extremely obvious that the whole game world is very flat.\u00a0 I really need to give the base heightmap some variation on a much, much higher area.\u00a0 In practice, doing this might solve the problem in #1, above, as well.\u00a0 Need to think about this, though.\u00a0 Right now, the base terrain is generated by using the “grass” brush over the whole world, and then drawing lines with the “mountain” brush around each region.\u00a0 Need to decide whether the “grass” and “mountain” brushes should always be operating with respect to some underlying “terrain shape” heightmap, or whether that’ll cause problems for users editing the terrain later\u00a0 (Or whether *not* doing so will cause problems).<\/li>\n
  3. Elephant in the room:\u00a0 The whole screenshot isn’t full of terrain — terrain that should be visible from this view is missing, leaving empty black areas visible on the screen.\u00a0 Right now there simply isn’t enough terrain model being generated to fill the whole screen;\u00a0 I’m currently only generating enough terrain model data to guarantee that you’ll be able to see the entirety of a single region, but from this vantage point we really need to be able to see several regions at once.\u00a0 And honestly, this isn’t even close to a full zoom out.\u00a0 A full zoom out will probably have the camera about ten times further up than this, which (according to math) would require us to draw about 100x as much terrain geometry as we can see here.\u00a0 I have serious doubts that I’ll be able to actually render that much geometry at a nice frame rate on most computers (although I should try it before I say it’s not possible).\u00a0 This means that for the furthest out view, I’m going to need to\u00a0render lower-resolution terrain.\u00a0 Probably substantially lower-resolution terrain!\u00a0 Of course, I won’t be able to use that low-resolution terrain when we’re at ground level;\u00a0 it’d be much too chunky to look nice!\u00a0 This means that I really need to have not just one type of terrain chunking going on, as I do now;\u00a0 I’m going to need to have two or more “layers” of chunking going on, so that I can switch between them as the user zooms in and out.\u00a0 At this point, I’m really glad that I’ve already set up terrain generation to occur in background threads, so generating these different terrain resolutions shouldn’t affect frame rate too much!<\/li>\n
  4. Like #1 above, another consequence of an optimisation is visible here.\u00a0 The\u00a0region which is visible in the top left corner of the screen is the\u00a0region containing my AI test area.\u00a0 There’s a graveyard, a few questing zones, a few NPCs, an Inn, and some monsters in there.\u00a0 And none of them are visible, because I’ve told the game not to bother drawing anything that’s inside a different zone than the camera.\u00a0 Just on the theory that the mountainous\u00a0region borders would screen off other zones from view.\u00a0 This assumption is no longer valid;\u00a0 I’m going to have to drop it, and potentially draw the contents of every zone, if they’re within view.\u00a0 I may need to simplify, of course, and at a certain height, there’s no point to actually drawing players or monsters any more, since they’d be far too small to actually see.\u00a0 In MMORPG Tycoon 1 and 1.1, I artificially scaled up buildings as you zoomed out, so they’d remain visible.\u00a0 Maybe I’ll do something similar here.\u00a0 Although now that a third dimension is involved, that may not actually work so well.\u00a0 Will need to experiment with that a bit, and maybe switch to rendering icons instead of actual building models if it becomes problematic.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    So I’m in the middle of building full seamless zoom in\/out functionality for MMORPG Tycoon 2.\u00a0 This was really one of the key interface features of MMORPG Tycoon 1, and being honest with myself, it’s just as important for MMORPG Tycoon 2.\u00a0 I’d originally thought I could get away without it, by presenting separate “close-up”…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[24,25],"tags":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-Ie","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2742"}],"collection":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/comments?post=2742"}],"version-history":[{"count":4,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2742\/revisions"}],"predecessor-version":[{"id":2745,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2742\/revisions\/2745"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=2742"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=2742"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=2742"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}