Guardians of Vigour

Hi, me and my friend is making a game. He is the graphical designer and all the animations etc. While I am the programmer. Now I thought I could share our journey with you guys and if I get stuck ask for help. Once or Twice a month I will make updates of the project. If I feel that I have solid piece complete I will make gif and share it with you guys. I actually do have one problem that is fairly simple. I want the camera to follow the player. I cannot just make the camera the child for the Player. Now the reason why I cannot do it is because the player is in a sphere shape so the camera rolls now here is my code that works.

public class PlayerCamera : MonoBehaviour {

public GameObject player;

private Vector3 offset;

void Start ()
{
offset = transform.position - player.transform.position;
}

void LateUpdate ()
{
transform.position = player.transform.position + offset;
}
}
void LateUpdate ()
{
transform.position = player.transform.position + offset;
}
}

But the problem is I want the camera to rotate as I rotate the player only left to right so that the front of the player is always the top point of the player

Can someone please help?

 

Welcome to the forums!

First, please use code tags when you post code.

I don't quite understand what you are asking. But it sounds like you might benefit from splitting the player rotation into two parts: a Y rotation (yaw) and an X rotation (pitch). You can make these actually two separate objects in the scene hierarchy... put the pitch object (with the actual player model) inside an empty game object that's only there for the yaw. And in fact you could just stick your camera inside that, if I understand you correctly. So it'd look like this:

• YawRotator
  • Camera
  • Player

and the Player object would only pitch up and down; the left/right controls (or whatever) would yaw the YawRotator, and the movement controls would also move the YawRotator.

 

I didn't say all that.

Try posting a screen shot of your scene hierarchy, showing how you have your objects set up. Then we can make more specific suggestions.

 

Okay I sat down and looked through our scope of the game and I decided that it would be better if the camera stays fixed and the player just "looked" towards where the mouse is pointing so basically he will always face where the mouse is and will shoot in the mouse direction. I will start doing it after work but all my other programming is up to date. He shoots perfectly he moves perfectly. only waiting for assets to import from my friend because I just started with primitive shapes. I am going for the game spore's cell stage effect on the background but am waiting for the assets. I do have one question. How do they make it look like you are swimming in water? I searched the Unity asset store and googled but I cannot find the "Effects/ particles" to compliment the feel that spore gives us and that feel will be one of the pillar stones of the game. It would fit in perfectly. I think I need 3 shaders on top of each other for the background to make it look like the player is moving through the map and for the water effect(what i actually want) I think i must put a Particle on the player so when he moves it will make a "wave" to the north west and north east of the player.

Do you think the particle is the right way to go?

btw thank you for all the insight so far. I did not actually think someone would reply so fast.

 

Okay update, i know this is not a big accomplishment for all of you but I am proud of it. I finally got the player to look where the mouse is pointing and move to where it is pointing when W is pressed now I am still stuck on the swimming through water effect but I am not worried so much on that.

I am more worried about the Player assets I am way ahead of my schedule but my friend is first working on the outline of the story which is due on 20th (i will give sneak peak) then he will start to work on the player's graphical design which will be due on 20th of December.

My next item is to make the bullets that is shot to disappear either after collision or after a set time. I actually have 2 main choices. I make a circle around him with a radius of 30 then obviously when he hits the mesh (even from the inside) the bullet will disappear, or i can put a timer on it. What are your ideas? What will compile in a better way? With the timer it is extra coding as with the circle I just put collider on it, then it will work. So for gaming specs to work faster I think the circle will work best???

To whom ever is following my progress, thank you it means allot

 

OK, it sounds to me like you're not properly ordering and retiring your risks. Let me back up and explain.

When tackling a big project, you begin by thinking of everything that could go horribly wrong. These are the risks to your project; each one is something that could cause your project to fall behind schedule, or fail completely. Indeed this is the fate of 99.9% of all projects — you just never hear about them, because they were never finished.

It's possible that some of these risks will be unavoidable and fatal, and that your project will fail. In that case, you want to discover that, and have the project fail as soon as possible! This minimizes the wasted time and effort put into it. (But note: if you're learning from it, then the time and effort is not a waste, and in that sense the project cannot fail completely, since you will have at least gained valuable experience.)

So, what you do is look at all the risks to the project, and then rank them, most serious ones first. And then, as much as possible, you tackle the hardest, most serious risks first. Because you want to either conquer them, or see that they're fatal, ASAP.

And what are the most serious risks to a game project? It varies a lot, but for indies, the #1 risk is pretty much always that you will get bored before you finish it. But that's too high-level; the real reasons behind that are some combination of:

• Inexperienced programmers get in over their head, and create a big tottering pile of spaghetti code, which ultimately collapses under its own weight — that is, you can't add anything, or even fix the bugs you know about, because you no longer understand how it works and every time you touch the code, you introduce more bugs.
• Everything takes longer than you expect (this is a universal truth), and you end up graduating/getting a job/otherwise moving on before you reach the finish line.
• The initial learning phase of a project is fun, while the final polish phase is not fun, so when you reach that phase and are no longer having fun, you give up.
• Very creative people find that by the time they are halfway through implementing an idea, they have thought of a dozen better ideas, and at some point they can no longer resist the siren call of one of these better ideas, and the first one is abandoned.

Note that "we don't have a story," or "our Player assets aren't done yet" is not among the major risks. Sure, these are things that can make a game better when they're good, or worse when they're poor — but they are unlikely to make the project fail. The risks above, though, will kill a project dead.

In your particular case, since you're new to programming, then programming is absolutely the high risk here. You shouldn't be pestering your friend about the story or worrying about player assets or wave effects; you should be worried that you are a level 1 code warrior wandering into the den of a level 30 dragon while equipped with a club and leather armor. No matter how good the story is, chances are high you are going to get squashed flat, roasted, and then eaten. (Hopefully in that order.)

So, to conquer that risk, you should be (1) doing every coding tutorial you can get your hands on, and (2) writing lots and lots of code. Coding is like playing the violin; nobody can really explain how to do it well, it's just a skill that comes with practice. So prototype your game using cubes and spheres, then throw it out, and do it again (better). Rinse and repeat. When your game is solid and fun to play with just cubes and spheres, then you think about adding a backstory and making it pretty.

 

A collision mesh is not a reasonable way to do that. If you want to check the distance from the player, just check the distance from the player (using Vector3.Distance for example). But for projectiles, I think a timer is usually the simplest and best way to go. (And assuming your projectiles always travel at the same speed, then the behavior is equivalent.)

 

Thank you Joe, any advise is golden, yes I already put a time on it, forgot to post it. I am doing as much tutorials as I can. I went on Udemy and I bought a few courses but I like finishing one tutorial at a time and the do it again 2 times before i move on to the next. I already finished unity's tutorials that is why I am moving to more complex tutorials.

In unity the space shooter that is where I saw the timer on the projectile but why I asked about a circle collider is because in the new tutorial on Udemy the guy used it so I was just wondering which one would work best. Ultimately i decided with the timer because in the future it will open up much more opportunities - like a upgrade system - if all goes well.

Yes, I understand what you are explaining. I know I am not the yet greatly skilled in the art of c# but I do not give up and I always try till I succeed. The only hiccup I now have is that at my house the DB board burned out so I am without power. oh , btw this is a hobby project. If i make money that would be great but the key reason for this project is to have fun, to learn, and to share all of this with you guys.

This is also why we are making a 2.5D game and not fps, I do not want to go way over my head. I heard that most people give up when it gets hard but that is actually the fun part, get frustrated because you do not know why there is a glitch and when you finally figure it out it feels as if you are finally beating that level 100 boss you struggled with for 2 hours.