No announcement yet.

wraparound world map

  • Filter
  • Time
  • Show
Clear All
new posts

    wraparound world map

    A friend of mine is working on one of those Squaresoft-style RPGs like from the 90s, where the characters navigate on a World Map that continuously wraps around, so if you run off the southeast corner on the east edge, you appear on the southwest corner on the west edge going the same direction as before, only it wraps around so the effect is that you just walk forever in circles as if you were on the surface of a very large sphere (which is what we want. It's the world after all).

    I must emphasize that this is NOT an MMORPG! Nor is it even intended to be multiplayer at all. Like I said, old-style console RPG.

    The scale must be big enough to feel like it's a whole world, without it taking ages to traverse its entire length using an airship, for instance.

    I am experimenting with ways to make this happen in UDK. We successfully got a heightmap of the world into UDK, but now we're stuck trying to make the world wrap around while you travel on it as if on the surface of a sphere, so you can't run off the edge (there would in effect be no borders/edges. You just go on forever and ever over the same stuff if you hold your direction exactly east for instance).

    1. Gigantic Portals. No luck so far getting that to work. just little bitty ones.

    2. Cutting the world map into segments, each on being a level, and streaming them in by proximity. But how to make it wrap around?

    3. Making an actual sphere and writing a new pawn class that can sphere-walk convincingly on a sphere that's at least 70000 UU in radius, with cliffs, mountains, rivers and valleys.

    Come to think of it, I don't know how this is done in games like Final Fantasy 7 and Magic Carpet, or Terminal Velocity/Hellbender, but I imagine it's based off of the heightmap idea, and it renders and loads as it goes, wrapping the data around as you go.

    Sadly, this goes against most of how UDK seems to work, so I'm feeling skeptical that there's a solution that does not require source code access. I am thinking of telling my friend to look into other engines, but I'm not sure any other middleware does what we're looking for either. It really does seem like an engine-level thing. Not terribly complicated, but engine-level (well, terribly complicated, yes, if you want it to look pretty like UDK, and have nice collision detection, physics, etc.).

    One more idea is to duplicate the visible extent of the world in 8 directions adjacent to the actual world space, and try to fanagle an indetectable teleport to the would-be wraparound edge when the player walks onto the "beyond"

    This last idea may be feasible since the world map involves no action per se in that style of RPG. If a battle occurs, it switches to a totally different viewing environment and control system, with turn-based battle commands, rather than being contiguous with the world navigation environment in the control, view, and mechanics.

    You don't need a source code access or anything like it. UDK has all that you need. An option is for you to make not gigantic portals, but only one really long trigger volume (4 if you want to do it in all directions). When the player hits it, you just trigger an event in kismet that records the Y position of the player (I'm writing the example for horizontal "teleportation" of a 2d top viewed game), and updates his position to that same Y position, but to an X that you give it (probably at the other edge of the map). That should work withno problem. Haven't tried it (I'm at work now), but it should.


      That sounds like my last idea (the unlabeled #4). Because the player needs to be able to see the rest of the world beyond, where he's teleporting to, or it will seem like a teleport, and not just walking along. I can handle the Kismet and UnrealScript part to make that work. I'm just hoping a more graceful solution can be found. If there's a way to actually stream the offset of the terrain position out to the edges, that would be awesome.

      The engine doesn't seem set up to do that so I think I'll go with your idea. This method means there can't be other visible agents running around the world map, though, or there would be discontinuity whenever you're facing out toward the edges, and the other guys would seem to disappear when they cross over and teleport to the other side(unless there were a way to make a copy of them. That's why I was looking into UTPortals).

      But I think the game doesn't need those. I know Final Fantasy VII had other things running around the world map like Ultima Weapon, but not sure if my friend's game needs that.


        Well, I don't really know how complex your map would be, but I would make a low LOD version of it, and do as you said. Put it in the the borders and corners of the main level. Can't think of anything else. Maybe an expert can point you in the right direction.


          I'm thinking portals

          Thanks for the ideas and suggestions.

          I talked to my friend and he said there will be a couple other pawns running around on the world map, and so the fake copies and teleporting idea is not going to work, I'm afraid, unless we can couple it with SceneRenderActors (or whatever they're called).

          I think the behavior of UTPortals would do the trick just fine, but I wonder what the size and quantity limits are for those things. Every time I try to scale a portal out to cover the whole 70000 UU-long edge of the world, UDK crashes for some reason

          another idea could be to make a ton of little portals. I'll probably need hundreds for this to work though.


            I fixed it!

            FlyLikeAMouse and that other guy (starts with a 'U') made portal tutorials that solved my problem.

            I found that you can have enormous portals (silly me; I was trying to resize them by increasing the texture resolution :P )

            I got them to work... and I think all 4 sides work just fine.

            There are now 2 issues left to deal with:

            1. In the distance, I see a really wonky copy of the portal that has massive texture replication fail all over it. I can probably solve this problem by introducing the old gaming standby: Distance fog, AKA Atmospheric perspective.

            2. The corners are freaking out. The transform on the player movement and location is fine, but the Render To Texture is clipping really weirdly. Maybe this is because the portals overlap each other at the corners. I hope I don't have to get a perfectly tangential fit, but it looks like that will be necessary. If the problem persists after fixing the fit, I'll need some more advice.


              NEW problem!

              behavior and visual works perfectly fine now EXCEPT the portal render across corners is incorrect or nonexistent.

              When you approach a corner of my square terrain world, where the portal boundaries on each side of it meet, then you will notice that the level beyond the first layer of portalness renders correctly, but will not render past that through the other portal wall perpendicular to it.

              I understand we don't want any infinitely repeating renders, but is there some property of the portals I can adjust to allow it to render through multiple layers of portalness up to a certain distance?

              Here's a rough screenie of what I'm trying to explain is the problem. Not sure if it's super clear....


                Originally posted by mightyenigma View Post
                I understand we don't want any infinitely repeating renders, but is there some property of the portals I can adjust to allow it to render through multiple layers of portalness up to a certain distance?
                No, you can't do this.


                  The easiest way to make the world appear endless would to be building a little extra outside of the world and having the portals catch the player right before they walk into the fake section. The way you're doing it now seems overly complicated to me.


                    It sounds like it may sadly be impossible. You could decide your square RPG game map happens to have large mountains in each of the four corners, however.


                      Very very large

                      They would have to be very large

                      The behavior and visuals work perfectly fine if you're only dealing with one set of opposite cardinal directions (like North and South only). But when there are adjacent portals, you can't see through the next one. The fact that they're perpendicular means I should theoretically be able to get away with this without crashing things as long as there's a distance cap on the render to texture (which can be set in the Portal's properties), but I fear the engine itself may be natively programmed in such a way that such a multi-portal render, even though I need only 2 layers tops, will never happen.

                      The problem with making duplicate sections for the adjacent wraparound segments, is that other pawns will seem to disappear from view in front of the player if they cross over the wrap border. I must have either true wrapping or portals that can render each other, or it's a no go. That's why the "overly complicated"ness of my approach. We have to be able to see other moving objects move through the wraparound into the distance.

                      I had an idea though: It LOOKS like the second layer of portal-ness is rendering the reverse side. Perhaps some clever Portal sistering can make the correct side appear. Then I'd need 3 or 4 portals per side for a total of 12 or 16 giant portals.

                      First I should plant a few unique-looking items on each side to see if that's the case.

                      Maybe sometime I'll investigate that. But not this week


                        Another approach could be to actually create a synchronized duplicate of every actor, and the terrain itself, and then switch between them when the player crosses. but that's even more convoluted and duct-taped.

                        Portals are movable so I was thinking maybe we could have just two portals that rotate with the player, but do not move with him. However, I anticipate that if this DID work, the player would see the rotation because of his offset from them positionally, and the world's offset as well. They really would need to line up nice and clean with the edges of the world or we'd be clipping through mountains, etc.


                          Originally you were talking about tiling the landscape so that visually it repeats. Now, with the portals, it seems you don't need that tiling, but I suspect that those pieces would fill in the black space that is showing at the corners of the portal. Basicall, try making a copy of the terrain and set it along one edge of the existing map, with the portals across the four cardinal directions as you have it above, then see if the new tiled piece shows up in the reflection of the opposite portal. If it does, you might be able to add smaller pieces to the edges outside of your map (depending on visibility distance).

                          You might also consider putting some kind of impassable barrier on each corner to avoid other complications...


                            Everyone in this thread is stuck in an FPS mindset, where the pawn has position properties which change with each tick. OP said this was to be a wrap-around WORLD MAP. Thus, the primary player concern is navigation and spatial awareness, not tracking enemies and avoiding fire. So we do the opposite.

                            Have the player avatar static in the center of the screen, lock the pawn and camera to 0, 0 or where-ever's clever. Use your custom PlayerController() to move the streamed in WORLD MAP. Stream in a second copy when your first one's edge gets close to the view-able screen edge (near 0,0). Store the WORLD MAP object position in a variable, inverse it and use it as a virtual position for the player Avatar. Then you can use this as an offset to position other movable meshes in relation to the player and the map, by basically propagating the WORLD MAP object's movement down to the other "moving" objects/enemies (if you really need them).

                            Each encounter or location would then trigger either a) the world-map & travel scale pawns to steam out and a new level streamed in and then have a player pawn&camera placed there , or b) level transition using normal UDK scripting or Kismet, with a holding screen. The choice would depend on what exactly you where up to. If it's "random encounter" on the world map, use A, you'll get the world map back sooner. If it's a whole town or dungeon, use B (you'll probably need a brief loading screen).

                            Now you have to decide what your pawn&player controller behavior in your new actual play environment will be.

                            Took me a long time meditating on this thread to come up with that. You're welcome

                            I'd be happy to help you guys, I'd love to see some old skool FF or Secret of Mana style game-play done in UDK.


                              Better yet, chop up the final world map into a level grid, and then stream in the chunks you need while they're just "off screen".

                              If you plan on having a full 3d camera for the world map, that may get a bit tricky. I'd recommend settling on camera styles for each portion of your game so you can take advantage of options like these. So you could have 3d wanderable areas for town and landmark locations, but the World Map would be limited most of the time (say, always looking down), but then you would have matinee driven cut-scenes where you could stream in more of the area and some atmospherics and "look around" if you need to sell a particular mountain peak or other location.