I want to make a terrain where the ending point is also the starting point. So, like on the earth you could just go on walking straight and you would reach the point where you started again after some time.
Thanks for your help!
Unity's Terrain system can only create square regions of terrain. So this can't be done as such.
However, you can approximate it, and I'll tell you how I've done it in my project to some success.
Figure out how much terrain you need to cover the "globe", we'll say it takes NxN chunks of terrain we'll call a "tile".
What you do next is you make 9 of those NxN tiles, and arrange them in a 3x3 grid. Put the camera in the center tile of the grid, and whenever the camera leaves that tile, determine where it is on the tile it is on, then change its position to the corresponding position on the center tile.
This will give you a "toroidal" world. I found this was the easiest solution to get the player to see things on the other "corner" of the world map, and then cross into it without graphical issues.
If you have other objects residing on the world, that presents some additional challenges. One thing you can start with is duplicating them 9x and start them at the same relative position of each tile. If they only interact with the player, that should be fine, just whenever the player interacts with 1, the other 8 do whatever that 1 does.
If the other residents of the globe have to interact with each other, you'll need a way to figure out how to make all 9 copies of everything behave consistently, but that's too broad of a question to address here.
Related
I am currently working on a 3d game in Unity, and I am working on the level design using ProBuilder. I basically created a huge cube which I "flipped normal", and a second one way smaller
which, as the other one, I flipped normal, but as soon as I crossed it while turning backward I could weirdly see through the small cube, which makes it feel unfinished. How could I fix this issue?
Normally in 3d games triangles can only be seen from one side. Usually this is not a problem because walls have some thickness. Since you clearly have paper thin walls made of only one layer of triangles this is exactly the result you should expect.
In short add the other side to your walls. The simples way is to duplicate the existing triangles and flipping them. Walls will still be paper thin of course. Later you should probably make them thicker.
Long-winded question out of the way, I'll provide a diagram of what I am going for:
The red square represents the character, the blue rectangle represents the camera, the green dot represents the center of the "stage", and the black circle is the stage itself.
What I desire is to essentially lock the player's movement around the "center" of the stage, so that anytime you move left or right you are more or less rotating around said center. However, I also want the player to be able to move forwards and backwards to/from the center as well. Keep in mind I want the camera to always stay directly behind the player. I have tried many different methods, and the latest is the following:
I took a default actor, attached a spring arm, attached a child actor to that (gets possessed to become the playable character), attached another spring arm, and finally the camera to that. I then added the blueprint code to the first spring arm so that it was the one being controlled by the left/right controls. However, upon hitting play, the only thing that moves is the camera, and it can only move forwards and backwards.
I'm admittedly pretty new to Unreal Blueprints, so any help would be appreciated.
Alright, I figured it out.
Here's the setup needed if anyone else wants something similar.
For the player themselves, you'll need something like this:
The important thing is to center the root mesh where you want to rotate around. The spring arm's target arm length will be affected for the player mesh movement, giving the illusion you are physically moving the character. The second spring arm isn't necessary unless you wish to have more control over the camera to player distance.
For the rotation Blueprint, you'll need this:
The target is whatever you named the root mesh. (Mine was called Center) Drag and drop it from the hierarchy.
For the forward/backward movement, you'll need this:
The target is what you named the spring arm. (I left mine as the default "SpringArm") Again, just drag and drop it from the hierarchy.
Adjustments in Project Settings:
Yes, my inputs are backwards from what you'd think. I felt it was quicker just to reverse the inputs instead of adjusting whatever was causing the movement to be backwards in the first place. (It's probably just the sphere orientation.) Also, you'll notice I have the w and s inputs set to 5 or -5 instead of 1 or -1. This is due to the fact the movement was slow otherwise. I'm sure there's a fix that doesn't involve changing the input axis scale, but honestly I won't really have a reason to alter the values at any point in my project. If it ever comes up where I do need to, I'm sure there's a bypass to change the values from within blueprints anyways.
End result:
End Result Video
If I remember correctly, child actor components are a bit different from other components in that they are transformation independent, that is they do not update their transformation when their parent component moves around.
I find it a bit strange that you would separate your player actor and the camera component. Normally, the player "pawn" contains the mesh and camera components for one player.
I would suggest you do the following:
Create a player actor (e.g. a "pawn" or "character" class)
Create the following component hierarchy:
Root Scene -> Spring arm -> Skeletal or static mesh -> spring arm -> camera
Your root scene is the green center in your drawing. You can then basically use the blueprint you already have to rotate and move your player.
I have a game world that's much bigger than the view port, the main character stays in the center of the view port at all times and the background layer is moved around to give the impression of the character moving. I want to make it so that the game world wraps, meaning if the the character keeps traveling either left or right they will eventually end up back at the starting position. There will be moving entities in the game world so the biggest problem I foresee is that if you go to the far right of the map you should be able to see any of the moving entities that are within the first small section of the far left of the map.
I've thought a bit about this and any solution I've come up with seems far too complicated. Like creating two identical game worlds side by side and moving them around accordingly. I live in hope that there is an elegant solution to this. Any expertise you can share would be greatly appreciated.
I'm using cocos2d on the iPhone just in case that makes any difference.
An example might be to have an x,y offset for your camera, and a multidimensional array of sprite objects.
As the player moves, the offset value changes, e.g., xMove = -1.4 and yMove = +2.6.
Then you would iterate and change the positions of all the tiles by that amount.
Next, you would identify the sprites that are too far away from the center of the screen (0,0) and re-position them to the opposite side, so they will always be visible.
This would all be done on the same scheduled 'tick' so no graphical artifacts occur.
I'm pretty surprised no one has made a wrappable tile map yet for cocos2d.
I can't give cocos2d specific advice, but I would say the most common way to do this is to create one game world, draw (parts of it) multiple times and make sure that your logic for things like collisions and AI checks for wrap-around where appropriate.
So if your player character is close to the corner of the world, you'd draw the world four times with different offsets. This needn't actually draw every single thing in the world four times any more than you would normally need to draw the entire world when only a small part of it is on-screen.
SHORT INTRO:
I'm having trouble with a 3D cube on a plane. The plane is a grid of squares. The ID number of the square that the cube currently occupies on is stored in a storage-variable. This is so that I can tell whether or not adjacent squares are free for the cube to move onto. When I move the cube, the storage-variable is updated to reflect the ID number of the new square.
PROBLEM:
The problem is that sometimes when I am moving the cube, the cube is moved too far or in the wrong direction and the square in the storage-variable does not match the actual square the cube is drawn on...This causes problems like the cube not detecting collisions and even going through objects it is not supposed to....
Cube is drawn in a drawView method in an iPhone OpenGL ES EAGLView at a rate of 24 times per second...Could the fast drawing be the cause of this???? How can I fix this? My job depends on it...
Somebody please help.
Well, not a lot to go on... But I doubt that the display refresh rate has any bearing on where the cube is going. Sounds like you have a good old fashioned logic error. But again, that's only going off what you've given.
Have you tried checking to make sure each storage-variable maps correctly onto each square in your plane? Try debugging, drawing a square at a time to make sure it's drawing each one where you think it's supposed to be.
I'm attempting to build a Lunar Lander style game on the iPhone. I've got Cocos2D and I'm going to use Box2D. I'm wondering what the best way is to build the floor for the game. I need to be able to create both the visual aspect of the floor and the data for the physics engine.
Oh, did I mention I'm terrible at graphics editing?
I haven't used Box2D before (but I have used other 2D physics engines), so I can give you a general answer but not a Box2D-specific answer. You can easily just use a single static (stationary) Box if you want a flat plane as the floor. If you want a more complicated lunar surface (lots of craters, the sea of tranquility, whatever), you can construct it by creating a variety of different physics objects - boxes will almost always do the trick. You just want to make sure that all your boxes are static. If you do that, they won't move at all (which you don't want, of course) and they can overlap without and problems (to simulate a single surface).
Making an image to match your collision data is also easy. Effectively what you need to do is just draw a single image that more or less matches where you placed boxes. Leave any spots that don't have boxes transparent in your image. Then draw it at the bottom of the screen. No problem.
The method I ended up going with (you can see from my other questions) is to dynamically create the floor at runtime and then draw it to the screen.