Small "Looping" Arcade Gameworld - How?

I'm struggling to imagine a sensible, safe way of creating this effect. I'd really enjoy hearing how others might approach it. Thanks for reading!

Imagine a top-down arcade perspective. Assume also that we want to use GameObjects and all the associated Unity trappings to represent our entities. The camera travels directly above the player's avatar to keep it centered on the screen. Directions given in screen space:

1. On screen, the player sees many structures and NPC mobs
2. He begins walking to the right
3. By virtue of moving right, new structures and mobs emerge from the right hand-side of the screen
4. Simultaneously, the leftmost objects viewed at [line 1] are exiting view via the left-hand side
5. He has walked far enough right that nothing seen at [line 1] is in view
6. Continuing right, he encounters the same structures and mobs from [line 1]
7. Repeat forever along both walkable axes.

It should thus appear to the player that everything in the world (except himself, of course) exists an infinite number of times, as if he's exploring identical cells on an infinite plane. This implies a fixed-size set of data for the real "original" entities, so let's say they occupy ( 100 x 100 ) units of space. With that in mind, a structure at ( 50, 50 ) is the same structure the player sees at ( 150, 150 ) or ( -1650, 850 ). Destroying it in one location destroys it everywhere.

Relatively simple up until point 7, right? Point 7 is a doozy. I forsee dummy instances of entities, treadmilling, teleportation... I can't envision a solution that doesn't require employing all three with nigh superhuman expertise, which makes the whole idea seem rather silly. Any thoughts to share? Thanks for your time!

 

I don't see that as a problem. If you're saying that you want to wrap the world around at exactly the screen edges, you will have to draw objects that overlap one or more times. The worse case scenario would be an object overlapping the corner of the screen that you'd have to draw it three more times (in each corner to show the rest of it).

So you could have four of each object, offset by the screen width and screen height. Once the player got past a certain threshold (half the screen width or height from it perhaps), then you could move the whole thing over by a full screen width or height so that it's ready for the player potentially going in the same direction enough to have to show multiples again.

In terms of destroying the object, you could have an ID that each clone shares and just make sure that when you destroy one of them, they all get destroyed. When you spawn something, assign all four clones the same ID. You wouldn't necessarily have to worry about one of them being the "real" one.

If you don't need to wrap at exactly the screen edges, then it's just a matter of moving everything over the size of your "world" when the player gets far enough away from it.

 

Thanks for the nice reply! I'm afraid I have failed to communicate my meaning effectively, though I understand what you're addressing and it's helpful nonetheless.

I'll endeavor to clarify a bit here. This idea came about while pondering ways to make a fixed-size-arenea arcade shooter more interesting. The camera travels around above the player, keeping him centered on screen. So when he nears the corner of this rectangular arena, he knows it's the corner because there's a visible border with nothing beyond. I thought it'd be pretty neat if, upon nearing the top-right corner, he saw the bottom-left corner's content beyond, and would be able to continue on. Thus the illusion that the world existed infinite times in all walkable directions.

I don't suppose this changes your answer much, and it's akin to my own thoughts about a sensible approach, as far as teleporting / treadmilling. It's worth noting too, that the camera's frustum is restricted enough that it'd be impossible to view two representations of the same object at once, so that's not necessary.

It sounds almost simple as I describe it, but thoughts of integrating are nightmarish. Maybe I was looking for an easy way out.

Further thoughts will be appreciated,

 

Well, if you don't need visible overlap, it seems like it would be fairly straightfoward. I'm not sure which part I missed; maybe a simple drawing would help?

It seems to me that since it's an overhead perspective, one a particular object was outside of the viewport beyond a certain distance, you'd just pop it vertically or horizontally the distance of your world's "tile" so that it's on the other side of the player, ready to scroll into view if necessary.

 

If you are talking specifically grid-based (tiles), its very simple to just shift by a single unit every step.

For a less granular approach, you can place multiple cameras that render the world from different angles:
https://dl.dropboxusercontent.com/u/157182894/Builds/test/Wrap/Wrap.html
(wasd to move, mouse to look, EFR for toggles. the pink is rendered only in the 'real world' area)

The downsides: Shadows don't work across the boundary, it doesnt work perfectly when objects are half-across a boundary, if you are looking in certain directions (can be remedied by tweaking the timing of things teleporting), and i can't speak for efficiency and draw calls.
The upsides: You only ever need one of each object, so no messing with duplicates (one on the left of screen, one on the right), fairly simple to set up (this whole demo under 100 lines)

If you turn off the shadows (and the pink border), and keep your head down (as if a top-down, or iso game) it's pretty convincing

You can even use non-square areas to help disguise the border, but then you'll need to do something smart with the teleporting stuff
http://imageshack.com/a/img835/3671/3sv.gif

 

What a friendly display of generosity from you both! You have my sincere thanks for sharing your time assisting me.

I'm happy to convey that hpjohn's demo has exactly the right idea in terms of intended effect. It is also a bona fide illusion, which is not something I expected to see working as well as it does! Very creative solution and one I had not considered.

Unfortunately, the clipping issues that occur at the edges seem to make this a non-starter. Unless you could expound upon the tweaks and remedies you alluded to, I can conceive of no way to eliminate that issue satisfactorily. Even if so, several cases would break the illusion or require scary hacks, such as dealing with transparency across the seams, teleporting individual shuriken particles that cross the threshold, rendering 4 lights for any one that's near a corner, and so on. I do very much appreciate the simplicity of the concept, but that simplicity may rapidly deteriorate to satisfy edge cases (pun intended).

My humble thanks for your valuable time, and I'm eager to hear any further thoughts on this or other methods of achieving the overall effect witnessed in hpjohn's snazzy demo above. In any event, this has given me some great ideas to explore, and encouragement that the effect need not be as complex as I once thought.

Edit for addendum addressing Steve Tack: As you say, moving these entities is likely the best way to achieve what I'm describing without involving the methods or issues mentioned above. My existing logic relies on a great many things which make this a daunting feature to add. Had I planned for it all along, it might be all but trivial as you suggest.

Edit for sharing screencap. I was surprised how quickly this all snapped into place, though I can detect already that this method isn't quite suited for what I had in mind. Still very cool though.
http://i.imgur.com/hezHERG.jpg

 

I think the idea is that your overhead camera would render just what's inside the pink border. Anyway, the multiple camera thing is quite clever!

 

when its assured that no object can be visible twice (so the camera viewport is smaller than the "cellsize") i would simply put all objects once in the scene and let them calculate their position regarding to players position. so calculate positions left + right from player and choose the closest.
note that you need some global available variables like current player position and the cell size properties (static for easy access?).
doing it this way you have only one instance of each object what makes interaction (pickup, talk to) easier to handle. and the objects teleport themself to the position closest to the player with cellsize steps. and the overhead should be negligible. you can even put the calculation into a coroutine so that it is invoked only every x seconds or something depending on how fast the player can move through a cell.

 

The most immediate edge-fix that i can think of, is to perform teleports once enemies cross a boundary which is a half-world distance away from the player, instead of once they reach the edge, this also has the benefit of keeping the distance between player and enemies minimum, which is probably useful for AI, but will also mean a bit more work when the player crosses the boundary himself, since all enemies will need to re-evaluate how far away they are. (edit: as above, i slow post)

Slightly more complicatedly, would be to teleport enemies once they are a radius-distance away from any bound furthest from the player, this way they are never overlapping the border.


Particles work fine

With a fixed top-down view, you can limit the number of extra cameras to 3, if the screen is smaller than the world (not implemented)

Demo updated with a top-down toggle, and particles, and some spheres near the border to show the problem.
https://dl.dropboxusercontent.com/u/157182894/Builds/test/Wrap/Wrap.html

 

The community goodwill continues!
@exiguous - Your post describes my current idea behind getting this functionality working rather exactly. If I throw out my existing logic and pursue this task in earnest, it'll probably rely on what you've described here. Thanks for the detailed post, I always appreciate having my thinking checked.

@hpjohn - Once again, your demo does not fail to impress! I have no clue how you managed to get particles to work properly across these boundaries. Are there nine systems? Are they on a separate camera? Are you algorithmically changing the render order of the cameras? My tests of particles in any re-rendered corner were fully clipped by one or more of the other corners. At any rate, it's impressive. Hats off once more,

The edge-hopping fixes you describe are a wee bit confusing to me, I'm afraid. The first suggestion would seem to indicate that agents cannot pursue the player "over the line." The second would introduce a visible lurch when "crossing over," as intuitively it will appear that a distance >= 2r is covered instantly. Sadly both of these caveats would disrupt the flavor of the game. Is there a chance I have mistaken your meaning here? The idea of accomplishing all of this with one fixed-size "real" arena is still pretty tantalizing.

Thank you all for your efforts, this remains an illuminating experiment, and I'm moved by how much time you've spent on my behalf.

editing to share my progress tinkering with hpjohn's multicam idea. WASD, LMB to fire. Note the oddity with the particles in the corner. I can identify draw order issues, as well as soft particle artifacts caused by having nothing opaque behind them, (which can be fixed) but I've yet to test my ability to teleport anything such as a trail renderer. I can here amend my previous confusion about your teleport-at-radius idea, I now grasp your meaning and that there would be no 2r-distance snap.
http://dl.dropboxusercontent.com/u/4266123/UnityBuilds/MulticamTest/Badness.html