Revolving/Endless map

Maybe it's my English, but I can't seem to find anything on this; I trying my hand at learning a 2d platformer, but I want the map to wrap around, walk to far in the left direction you end up on the right side of the screen. Like the scene is wrapped around a cylinder.

Is there an instruction on how to do that?

 

No there is no instruction. There are some threads about 'wraparound physics' etc. If physics are involved it is quite difficult because the physics engine is not designed for this.

 

Ouch. So that classic arcade stuff is hard to rebuild using unity?

 

No, there just isn't any specific writeup on how to do it and if you decided to use physics then that would make it difficult for obvious reasons. In other words you'll have to figure it out mostly on your own.

 

Aw damn And here I was going to use unity as an engine to teach myself stuff to avoid just these kind of things.

I suppose something simple as "if X is greater then 500 then X = X - 500" or some sort won't work.

 

of course it does work, but then you can't use unity physics. if an object overlaps both ends of the game world, other objects can't collide from both directions. .. you have to duplicate all the colliders, and then somehow connect their responses together ... not simple or reliable. if you move everything manually with no physics engine then its doable.

 

@imaginaryhuman why so pessimistic?

It should work fine if you introduce the extra copy outside of the screen and it moves into the visible area, as long as it isn't an object fully controlled by physics - characters should work ok. But linking copies somehow will of course be required.

 

Not being pessimistic. Speaking from experience. I've tried to implement a wraparound shootemup with physics, it makes it very difficult. Every object has to have a duplicate object/collider at an offset, and its position has to be connected, and any rotation has to be somehow shared between the two/duplicated, and it just makes it all kind of a hack. It IS easy to do if you don't use the physics engine and just move objects in scripts.

 

There is probably no need to use the built-in physics sytem anyway, is there? I don't use any of that and, like you said, it makes development much more straightforward. It's not like physic systems are a big deal to implement. At least not non-physics oriented game systems. I often wonder why people spend so much time tweaking physics forces and so forth to try to get the feel of basically not using "real" physics to begin with. Lol

 

Its because Unity's primary collision detection method is a fully fledged physics simulation. In `the old` days it would be considered really an overkill for many situations especially in 2D games... but physics became popular and often you can just set it up and let it handle itself without your input. So it provides ease of use, but in some situations it gets in the way. Trying to use it to act like a non-realistic physics system seems like the only choice because most people do not understand collision detection algorithms or the need for them.

 

Okay, I've build something. It's literally the first thing I made in unity without using a tutorial, so bear with me on the cleanliness of it.

This has a sprite, running on an endless platform. Basically it's is constantly checked if the player is approaching a border and when it does it cuts of the scene on the one side and puts back another scene on the border side.

This allows for an endless scene in both directions.

It still has some hardcoded variables, it still does only a scene, nothing more. There are some wonky physics at work, my sprite guy can actually fall over, don't know why.

And I am still thinking about how to proceed. But, I'd welcome all comments and/or suggestions.

Edit: Both the sprite and the gamecontrol scipt came from other people, free to share, the scene duplication is the only thing that is mine

 

That kind of blows my mind. So you mean most Unity developers are just adding colliders to GameObjects and basically letting Unity physics handle all of the movement, interaction and so forth with no understanding of what is going on other than tweaking some input values such as gravity, mass and so forth?

I always thought I was kind of outta the loop on Unity normal use and this confirms it. Would have never thought people were making games this way. Not completely relying on it I mean. I don't see how you could get enough control over motion and interaction. Basically it is being used like a grand version of GameMaker Studio. Someday I need to play around with that stuff more I guess.

 

Most people will always take the easiest route. I know of MCU programmers that load a complete Java engine unto a MCU because then they can work in Java and that 'easier'. Never mind that without that bloat they could use a part a tenth of the cost. But I digress.

I am almost completely new to Unity and as a learning exercise am trying to build a game like the classic Zeliard. A 2d sidescrolling arcade adventure game. You are saying that am I better of not using unity physics there?

 

Not at all. I have a different view just because I am not used to the normal Unity development. I use it basically like I am coding in C++ with DirectX or actually closer to C# and XNA. Not used to having something handle more than the low level details of rendering and so forth. A lot of people have made platform games in Unity and there are some in the Work In Progress forum you can check out.

It just seems like massive overkill to me to use a separate general purpose physics engine unless I am working on a game that relies heavily on complex physics. A game like Angry Birds would be a candidate. A game where the focus is on a bunch of objects stacked up and the goal is to remove one without making the whole thing come crashing down. Things like that a physics engine would be very handy for.

Non physics puzzle focused games I wouldn't use it. Now I can see why I have tried some FPS games where the player and enemies bumped into barrels and sent them sliding around. You could do it. You could make any game using a separate general purpose physics system but it seems like you would be spending so much time tweaking everything because the world would be at the mercy of the physics system and not your code. Again though this is just my view. Others must like it and use it.

 

Thanks for the insight. I do see a lot of wonky stuff happening in even that simple thing I posted. Like the player object falling on it's side.

It's a learning process I guess.

 

part of the blessing of Unity is that it automates a lot of stuff and prevents you having to think about or deal with various, often complicated algorithms, requiring less scripting etc... collision detection is one of those. but sometimes that means you want things to happen that the automation doesn't support.

 

That's another approach. Physically design your entire level wrapped around a cylinder. Keep track of all object's 'x' positions around your world circumference, and later call a conversion routine to convert object's virtual 'x' positions into actual x/z 3D positions (and object rotation).

This could be done by simply using COS / SIN of (x / circumference) * radius or something like that. Or use a spline path asset that handles this for you. (Then you don't even have to be perfectly circular using splines, you could have a wandering path around your world center.)

Of course this would only work (or at least reliably!) using your own fake physics.
This would make your game graphically appealing, at least not traditional (if you don't use an Orthographic camera.)

 

Resogun does the cylinder thing. You could conceivable add an outer and inner cylinder as walls to deflect physics objects to stay within the cylindrical play field? Then you could use normal physics. But then you also have to deal with having a cylindrical display and making that not too busy or hard to read.