Announcement

Collapse
No announcement yet.

wraparound world map

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    It's been done in UDK a few times already, though to be fair, mostly with smaller orb maps. There's a few videos of that type of system floating around Realistically though, give up the dream of a wrap around world unless you've got a LOT of experience and patience!

    Leave a comment:


  • replied
    ^ Good luck with that.

    Leave a comment:


  • replied
    Model your world as a sphere in your 3d package of choice. Use custom code to implement gravity based on the center of the sphere or normals under the player as the surface curves. Breakup your massive sphere world into chunks and import.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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...

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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....

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:

Working...
X