Physics delema

I'm trying to solve some behavior problems with my player / enemy game objects. My players seem to not have any weight to them. Simply moving forward causes to object to glide up off the ground slightly. I'm guessing it would continue elevating it I didn't have it restrained by walls. Once movement controls are neutral the object slowly settles back to the floor (about 15 sec or more if 2 meters above floor). I have gravity on, added lots of mass and bumped the physics gravity up but can't get rid of the problem. Checking 'is Kenematic' solves to floating issue but allow player to pass through walls.

I created a new project to trouble shoot my problem. I created new floor and walls from scratch using cubes, I added two players also made of cubes and a sphere for a ball. I copied my controllers for the players from my original project and attached to the players. All objects have a rigidbody and a collider and collider size matches rigidbody size. Not only does it want to fly (float) when moving, when approaching the ball it wants the lower, apparently to match the ball Y position. I've jumbled code around so much in my attempt to solve or understand, I may have introduced new issues.

I don't know if I just completely don't understand what is going on and it is doing what the physics engine is telling it to do, or don't have my players setup properly, or my controllers are goofy. Given my record so far I'm betting on all three…

I need to start somewhere to eliminate irrelevant issues, so I'm picking the most likely culprit. I'm using my own character controllers and I'm thinking my movement routine is faulty or at least can be improved upon.

My input code: (for player) - movement is forward, backward, left and right using WSAD and rotation using the mouse. A basic first person input.

Code (csharp):

1.  forwardInput = Input.GetAxis ("Vertical");
2.  sideInput = Input.GetAxis ("Horizontal");
3.  turnInput = Input.GetAxis ("MouseX");

My move code:

Code (csharp):

1.  rb.velocity = transform.forward * forwardInput * forwardVel;
2.  rb.velocity = rb.velocity + transform.right * sideInput * sideVel;

My rotate code:

Code (csharp):

1.  targetRotation *= Quaternion.AngleAxis (rotateVel * turnInput * Time.deltaTime, Vector3.up);
2.  transform.rotation = targetRotation;

If by any strange chance this is all good, I need to start looking at my player objects as the cause. My enemy uses the same movement code but is driven by a simple AI routine instead of player user input. Both have the same issues, both use the the same movement code and both are an instance of a single prefab.

Can someone please straighten this out for me so I can understand how to fix and why this now behaving as it does.

 

If you must use physics, you generally shouldn't be setting the velocity directly like that. That is fighting the physics engine (which wants to calculate the velocity based on momentum and any applied forces). For example, you nullify gravity every time you set the velocity to some combination of transform.forward + transform.right, so it's not surprising to hear that your objects aren't falling very well!

Let's back up a moment. Do you really need physics at all? If it's just to keep your objects within a bounding area, then no, there are better ways to do that. It's only if you need to have objects reacting realistically to complex collisions (for example, because you're making an Angry Birds type game) that the physics engine is really worth the trouble, in my experience.

 

thanks for hanging in there Joe,

I don't know if I need physics or not. I didn't come up with this one my own, my current attempt and all previous ones where lifted from examples, both Unity and others. So I guess I've taken another wrong approach and I need start over again. I have no starting place now, the documentation hasn't provided me a clue to this, the tutorials are what I'm emulating, and you're telling me I shouldn't be. I think it's clear to all that have viewed my last posts that I'm far out in the weeds right now. So far every restart takes me right back to the weeds. I'm out of options if I can't rely on available resources and it's pretty obvious that I'm not going to figure out whatever combination of components, code, and voodoo that is required to move a figging simple object.

I read other posts. Good questions about sophisticated issues. I'm beyond impressed at the caliber of questions asked in the 'Getting Started' forum alone. After six weeks of struggling the best I can do is 'I can't move my cube'. Six weeks of failure is demoralizing as hell, but nothing compared to having to post a question about a stupidly simple thing as this. I want to come here, ask those good questions about sophisticated issues.

I guess I'm out of questions right now, I don't even know what to ask at the moment.

 

When you go one direction & float up what happens when you turn around? Do you move back down or just continuously rise up?

 

OK, Bill, hang in there. You can get this.

I agree that too many of the tutorials in the beginner section are based on physics (like the "Roll a Ball" tutorial). I think they do that because it's a quick way to get an impressive demo up and running... with the physics engine doing all the work for you, you hardly need to write any code at all. But the result is that (1) beginners think they need to use physics to move things around, when in reality, physics is a hard way to move things around the way you want to; and (2) we haven't shown beginners how to move things around by writing code (which is actually easier in most cases).

So! Moving stuff around without physics is actually quite trivial. You just use the methods on the Transform class. For example, to make your cube move forward at a steady pace, you could just do:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Mover : MonoBehaviour {
4.     public float speed = 10;        // units/sec
5.    
6.     void Update() {
7.         transform.position += transform.forward * speed * Time.deltaTime;
8.     }
9. }

Try it! You should see the cube moving around at whatever speed you set. And make sure you understand how it works: transform.forward is the object's local +Z direction; speed is your public variable; and Time.deltaTime is whatever fraction of a second has passed since the last frame. If any of this is unclear, just say so!

Now, I see above that you know how to Input.GetAxis("Vertical"). Can you adjust the code above to move in proportion to that? If so, you now have a cube you can move forward/back using the arrow keys.

Next up: let's make it turn. You could do this in the same script, or in a different script. The "Unity way" is to have lots of small single-purpose scripts, though of course this could be overdone sometimes. But just to illustrate the point, let's make the turning code a separate script:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Turner : MonoBehaviour {
4.     public float turnRate = 720;        // degrees/sec
5.    
6.     void Update() {
7.         transform.Rotate(0, turnRate * Time.deltaTime, 0);
8.     }
9. }

Throw this on a cube, and you should see it spinning at a steady rate. Again, your task (should you choose to accept it) is to then make it spin in proportion to Input.GetAxis("Horizontal"). And then you should be able to, using the left/right arrow keys, spin your cube around to point any way you want.

Put both scripts on the same object, and now you can drive it around!

Absorb all this. Ask questions. Make sure you understand every line. It's the fundamental stuff — everything else can be built on this foundation, so make sure it's solid.

Then, tell us about what sort of game you want to make first. You've done the tutorials, so now it may be time to start focusing on what you want to build — pick your absolute simplest idea (if you're not sure which that is, tells us your ideas and we'll help you choose). And then we'll give you a helpful shove in the right direction.

 

hey, thanks Joe,

I appreciate you throwing me a life line. I'll try your code as soon as I'm able. I'm afraid I have extreme concerns about my ability to actually learn anything here.

Other than this forum, and I'm making an assumption there too, there are no Unity resources to take a complete novice to developer. I'm struggling why Unity bothered with creating the document files at all. It's only value is to confirm statement syntax, which MomoDevelop provides with autofill and tooltips. I have yet to find any information to help me actually learn Unity there. Then It's pointed out that the tutorials are not for the novice and any code or procedures demonstrated in them may or may not be applicable for a particular need. It is impossible to discern a proper game design scheme prior to and during game development without some general understand of how this works. As a novice I have no ability to understand suitability of any example. Furthermore, there is nothing I've seen to alert a new user or any documentation on how and what one should do to start a project correctly.

Before I opened Unity for the first time I paid a visit to this forum. Just to see what questions were being asked and how well the community responded. Every question regarding how to get started is always answered with 'go to the learn page and start completing the projects there'. I took everyones advise even though they were answering others. I've completed 14 projects and despite not feeling I've learned anything other than navigating the editor, I decided to just try something on my own. I was right, I hadn't learned a thing in those tutorial projects. Well I learned to be a project Xerox machine. I now have the ability to copy someone else's work. And, Joe, your code is not different. I am aware of the 'vocabulary' of commands but I have absolutely no understanding of how and why one thing should be over another, furthermore I've gained no understanding how to take and example and modify for my usage. Parroting is not learning and there are no resources for the novice to gain the understanding needed to actually understand the tutorials. So I followed what I supposed to do, but gained no understanding or insights on how I can take those examples and extrapolate useful needed knowledge from them. I don't know why the moderator chose one thing over another. Lastly the production value of these tutorials are beyond amateurish. I could go over a very long list of things that actually prevent viewers from learning, but that would be a discussion for Unity.

Joe, you asked about what game I want to do. Yes I have several games in mind and would eventually get to them. They are not novice games and not AAA either. A proficient developer could produce one of my ideas easily in a week to two. I don't care right now about 'making my ultimate dream game' and I'm not sure I actually have one now. I want to learn Unity well enough so I can take an idea and actually create a functionable representation of that idea all on my own. I have not even come close to understand anything. I actually don't know why I shouldn't be using physics to move my object or when I should. I can honestly say that I've haven't gained any knowledge that would allow me to do something on my own. For all my reading, tutorials, and tinkering on my own, what I know today is pretty much what I knew before opening Unity for the first time. I have no faith that what resources that are available can assist me in learning this. Now Joe, I guess I could put you on the payroll, to haul me out of one pitfall after another as I wander aimlessly is search of understand. I'm guessing you have better things to do with your time.

I could pay a developer to create my ideas. I'm not here for that. At the moment I have no intention of marketing or even releasing anything I produce. This is not intended to be a career choice. It's just a hobby for now and most likely will always be. The drive I have is to learn Unity and all it has to offer, and noting to do with making a particular game, or getting rich as a developer.

If I can't turn to Unity's documentation, and the Unity tutorials are questionable, and don't get me started on the 3rd party videos, how do I learn? Where do I go? I frankly see no options available to me to get me there. I thought of purchasing finished games in the Asset Store, and try to reverse engineer, but if I get no clarity from the tutorials I'm most likely not going to that way either. Since the first computer manual was produced, there has been a systemic problem with them. Experts write manuals for experts, only idiots can write manuals for idiots. Clearly the Unity folks are experts, and have not written for me.

Until I can figure out some roadmap forward, to accomplish my goal, I don't think working on any project is time well spent right now. Any ideas on learning by other means, six weeks of doing it Unity's way has only shown me that it just isn't going to work for me and if I continue doing what I've been doing, I'm going to keep getting what I getting, or not getting in this case.

Sorry for the length but I don't know enough to know what question I should be asking for help.

 

I'm not worried about that — it's clear that you're actually trying, and pretty much anybody who tries can learn this stuff. Just roll up your sleeves and decide that, by sheer stubbornness if necessary, you will beat any problems into submission!

That isn't my experience at all. I still frequently refer to the script reference to find out more details about the behavior of a method. Yes, it's a little thin in some places, but for the most part it's pretty complete. And then the manual itself, quite separate from the script reference, tells you "how" and "why" to do things (like this for example). If all that were printed out, it would be several thick books of great information, straight from the Unity engineers. It's honestly the best technical documentation I've seen anywhere, for any product.

But, if you want more, there are a ton of third-party books about Unity, including many books for beginners.

Some of the tutorials are for the novice. And that second part sounds like a standard disclaimer. Of course any particular tutorial may or may not be applicable to a particular need... but that's not the point. They help you build the skills, and then you use the skills to build what you want.

Perhaps that's because there is no one way to start a project correctly. But if you've gone through 14 tutorials, you've done 14 project-startings, right? Surely you've got the basics now... (1) Launch Unity; (2) start a new project; (3) start assembling objects and scripts into something that resembles what you want.

I assume step (3) is the sticking point, but of course that is where every project is different. How could it be otherwise?

Yes there are. Quit making excuses. Everything you need to understand the tutorials is there, in the manual and in the scripting reference, as well as all the third-party videos and books and blogs (choose your favorite means of ingesting knowledge). Perhaps you don't know where to find the answers you seek, but in that case, that's what this forum is for. Ask a question in plain English, get an answer the same way, usually in much less than a day. It's pretty awesome, I think.

Anyway, that is why I have not just handed you a script that does everything (I imagine) you want in this case, but instead took you halfway there, and challenged you to hook up the keyboard interaction. See how it goes with that. You will either discover that you understand more than you're giving yourself credit for, or you have some specific block in your understanding that we'll be able to correct.

That's a very sensible attitude. I often make an analogy with woodworking: newbies come in here, having never picked up a hammer, and say "I want to build this 10,000-foot mansion! It needs to have carved wood frescoes and marble tile throughout, a smart home automation system, and secret passages. I've never built anything before, but I've got this hammer, and several months to work on it. How do I build this?" We tell them to start with some tutorials on cutting and hammering boards, and then maybe try to make a birdhouse. There is just no shortcut to learning how to use the tools, and then building actual skill with them.

(But this is not to discourage anyone — you can build that mansion one day, if you work hard and build those skills!)

Well perhaps I can explain that. The physics engine's whole job is to move objects for you. So, if you want the physics engine moving your objects around, then great, let it do that. And in that case, you can't move them around yourself (you just told the physics engine to handle it, right?). You can apply forces, which the physics engine will take into account when it decides how to move things, but you can't just move them.

So, in cases where you want to just move the object in a simple and straightforward manner exactly the way you want to move it, you should just do that and not tell the physics engine to handle it. 90% of classic games fall into this category. On the other hand, if you're trying to make Angry Birds, you will quickly realize that getting all those blocks to collide and tumble down realistically yourself is hard, and then you will want the physics engine involved.

I don't believe you. But we'll see. Take my challenge above when you get the chance!

But I (and many others here) enjoy helping people who are genuinely trying to learn. Just be careful to avoid the trap of self-pity. If you start believing that you can't do it, then that will become true. (Jeez, now I sound like my mother!)

Then I think you've chosen a great hobby and are going to have many years of deep fulfillment from it! You just need to get over this initial hump.

You have lots of options (some of which you have too-quickly discounted, I believe). Decide what fits your learning style. Yoots these days seem unable or unwilling to ingest anything except in video form. Me, I'd rather read a concise and well-written article on a specific topic. Some people prefer books, made out of actual dead trees. Use them all, or whichever subset suits you.

(And, yes, use the Unity docs too — they're really very good, once you learn your way around them.)

Agreed, that is not among your reasonable options.

Not true. You should pick one small project at a time, and work on it until you either have it done (however you define that), or are no longer learning anything new from it. Then move on to the next small project. I recommend more or less cloning existing projects, so you're not wrestling with game design at the same time you're learning the tools. Suggestions:

• Flappy Bird
• Doodle Jump
• Space Invaders (or any other 2D shooting game)
• Angry Birds (now you bust out the physics engine!)
• BattleZone
• Sneezies

All of these are fairly straightforward. Pick one that resonates with you, and dig in. Try to find relevant resources to help you, but when you're stuck anyway, ask questions. We're here to help.

 

Have you tried going back to the tutorial projects you did & repeated them without the tutorial to try & embed some of the bits? It's highly likely that you will get some bits wrong but hopefully by comparing the 2 you can easily find where you went wrong & so focus on understanding those bits. Then you can try adding or changing one thing to see what happens, playing around in that one area could also help reinforce the concept & will also give you something for when you do a project & it doesn't work (you might be able to go 'I remember seeing something similar to this effect when I changed x-value, maybe I have something similar here')

 

Hey, thanks a lot you guys!

Joe, your my new best friend, lucky you…

I need to apologize for the freakout. I really thought after all the tutorials, reading, and Googling I had enough information to do something on my own, two cubes and sphere in a box. If I could to start simpler I don't know how. You can't complete 14 tutorials without learning something and that's pretty much where my frustration went hyperbolic. I really thought I could muscle through any problem as long as I Google. I don't give up on things no matter what the resistance is as long as see any value in the struggle or the destination. After spending several weeks of stagnation, it got to me.

You all are trying to help and I'm doing a terrible job at expressing where I truly need help.

So far I have learned to use the Unity editor and the MonoDevelop editor with a residual uneasiness that keeps me second guessing in a lot of situations. There are still a vast amount of areas in the Unity editor that I still know nothing about yet, like a animation (mechenim), particles, effects, shaders, and who knows what else. But I can open a project, add a scene, add objects, position and scale them, even add a color or texture to them. I have also learned script creation, setting up public variables to link objects and textures to a script, and attaching scripts to objects. Although I dabbled in C# years ago, I can honestly say I abandoned it before learning much. The coding side of this is the only thing that is keeping me going and holding me back at the same time and that is the exact area I need help. As long as my coding does not involve animation of objects I'm actually doing pretty good. I have an empty object with an attached script created as a singleton where I have a few global variables including game preferences, top ten list and player profile list, a load and save for the preferences. I have created two scenes, a menu scene and the actual game scene. Buttons for play and quit work, but I've done nothing for game prefs and top ten. I've also added UI elements to both scenes and have some of them functional via scripting.

So I've learned a lot and from the above it sounds like nothing should be holding me back. But the reality is, I can create a static game, but making it function as I intend is the problem. Joe, before you tell me thats the universal problem in game development and all developers struggle with, I need to explain. I don't know what all the techniques that are available to me and don't know what those different techniques produce behavior wise. I understand that I can only learn that is by doing and observing the results. Making a determination if the result is what I want, close but needs tweaking, or not at all. Given what I learned from the tutorials and borrowing most of it, produced issues and that was what prompted this original post. Going the physics route, caused issues. Issues I could not identify or fix on my own. Maybe I will want my cube to have a jetpack, where I would want to use physics. I have no means to correct the unwanted behavior to make that determination. The problem is In identifying the unwanted behavior and it's cause, then correcting the problem. I see the behavior, I know it needs fixing, but I don't know what is causing the issue or where to fix. This leads me to semi-randomly swapping out code in hopes to fix or at least change enough to get a better understanding of the problem. That usually leads to a lot of compiler errors as I try to assemble a new statement, purely because of I'm attempting to solve by guesswork rather than intent. Guessing relies on a little bit of smarts and a lot of luck and is only useful as a last ditch effort. I'm going to last ditch effort as a starting place because I have no experience to guide me otherwise and no manual, or tutorial has helped me to do otherwise.

As I said, maybe I want my jetpack cube and use physics. Any technique is going the have side effect issues that will require modifying or limiting particular behavior. I know my physics code could be used if dealt with correctly and that would produce a different experience from the user standpoint. My first project is mostly directionless as I want to do something, anything properly just to make an observation if that technique is what I want or not and what I might want to modify to correct. Until I can get my objects to work correctly by intended using physics or simple movement, I can't make that determination.

Last night I add Joes, movement code. While it did correct one behavior it also produced other unwanted behavior. my cube wanted to roll over forward, once rotated, forward movement forced it through the floor, I limited X and Z rotation on the rigid body to solve but not sure what I should have done. I can still fly! collision with the ball or other cube acts like a ramp and I can actually get high enough to now fly over my walled area. Still no gravity??? Well too little as it will settle and does so faster than when using physics.Yes gravity is checked in the inspector. I don't mind a little jump and possibly I want it, but physics or not my object seems to have the weight of a leaf and I want the weight of a car (maybe).

Last night I think I realized a problem that I have that I've been trying for about four weeks to correct. My second cube has a very simple script as it's AI. It has two conditions, if you don't have the ball, turn to the ball and move forward, if you have the ball turn to the goal and move forward. The goal is just a vector3 right now and is a point midway along one wall . Colliders swap a variable value to determine if the object 'has the ball'. The cube will move to the ball and move to the goal repeatedly. I know now I need other means to rotate and move. The look at and move forward I'm doing should be look toward and move toward. Since the ball is smaller than the cube, it digs into the floor as it approaches. My original goal position was high and also caused the cube to fly up to it. Yeah, I don't know why it took me so long to identify, I relocated the goal to eliminate the fly up but couldn't fix the dig down. Struggling so long I had forgotten that I moved the goal to solve one half the problem, which partially hid the true cause of the problem.

I need to be able to correct behavior to establish a baseline of behaviors so I determine what method to use to produce the necessary behavior for the game at hand. And that is pretty much the real problem. It goes like this;

I'll start with either transform. or gameObject. in monoDevelop and see what auto complete has to offer me (already starting with guesswork). I'm unable to produce wanted behavior and unable to eliminate unwanted behavior because I have never done that. My new player cube now moves better and I've eliminated one set of behaviors, it has just been replaced by another set. I have no ability to construct an object with a given set of behaviors as I have yet to produce anything with a fully functional behavior regardless if it is actually what I want or not. Properly working I might have what I want or like what I have better that my original intent. So auto-complete provides me with all my options to fix instead of design. Some items are obviously not needed or appropriate but there are many that can or might produce the desired results but so new here I don't actually know what I need. So pick what seems to be the most obvious and see what happens. Completing the statement becomes an ordeal to satisfy the compiler, I pray it's a missing semicolon or imbalanced brackets on errors, usual not. Then it becomes a spiral of trial and error, setting up and swapping out parameters to make the compiler happy and me too. Sometimes I simply can't make the compiler happy and don't know why sometimes I can, but rarely if ever am I happy about the results. This leads to a series of trial and error attempts as I go through any and all options I can try. There is always several ways to do anything with usually one best way for a set of circumstances. I'm not able to come up with a single approach, yet alone a best approach. It seems the 3D world and Unitys functions to manipulate objects are my problem. The tutorials have shown me one way to do something , but didn't provide the tools to modify behaviors or add and remove them, and simply no examples for any other approach. I've been beating myself up pretty badly lately and I thinking now it is not my fault I don't know and don't get it, Unity has not provided me with the proper tutorials. All examples I done use the same physics approach for animation but provide little or no information on modification and virtually no information on doing simple animation. Joe, I here you defending the Unity docs, but you do so because you have the expertise to use it and infer from it. I have no expertise and I can't infer anything and can only take things at face value. If it's explicitly not in the docs or tutorials, I have no way of even knowing they exist. I can't solve problems if I'm not given the necessary tools to do so, and surely if I'm not aware of them. The entire Learn area need a major overhaul done by actual educators and not by game developers.

So, again I'm asking where to go, Unity's learn area is truly for intermediate users and not novice as it is deficient in necessary information for the beginner. I need to learn what options are available to me, even those that may be inappropriate of my needs, what it takes to fully implement any one of those options, and do it with intent and not guesswork. I don't see anything close to that in the docs or tutorials. There is a reason we read assembly instructions after we put together that Ikea bookshelf. The instructions are so much clearer after assembly than before.

I'm currently sitting on a potential game, I have the place, I have the players, I have no idea how to put that all together to make something because a single approach is offered as instruction and no guidance to modify or replace and no means to troubleshoot behaviors. Having that in front of me and not being able to take that to the next step for this period has made just a little crazy due to frustration. I can't do this because I don't have the tools to do it, they are not provided. Things are easy once understood, things are impossible if not. Give yourself a virtual lobotomy and you'll begin to understand where I'm coming from. Worse yet is I really don't know what I don't know, which is probably a good thing right now, I don't need more to stress over.

If I have to learn by doing, great that's the best teacher I know, but I need the proper tools to do by learning. They aren't there...

 

Aha! You still have physics. What you should do is remove the Rigidbody component.

(An alternative is to keep the Rigidbody but mark it Kinetic; this allows you to move it yourself, but it can still bash into things... but that way leads to physics-world, which I don't recommend for beginners.)

Here's a core lesson: any time your objects in Unity are moving when you didn't tell them to, or failing to move when you did tell them to, or moving in weird ways that are not what you thought you told them... you probably have physics involved, and removing the Rigidbody is the easy solution!

Physics! Bah! Now you see why I don't recommend beginners muck about with it. Even experienced devs run into this sort of junk. It's a pain in the neck.

I'm snipping your long complaint about trial and error because, as far as I can see, every bit of it is about wrestling with the physics engine. And I think you know by now what I have to say about that.

OK, I'll point out what you should be using this week. Everything you need is in these:

• Translate & Rotate (handy how-to video)
• Transform (script reference)
• Conventional Game Input (manual)
• Input (script reference)

That's it. You can (and should) make a ton of fun stuff with just this. (And, of course, deleting any Rigidbody component you see!)

I want your next complaint to be more along the lines of "That's great, I fully understand all these things and everything behaves exactly the way I want it to, but now I've gotten bored because it's all too easy. I need more challenge!" And then we'll tee up the next challenge for you.

Cheers,
- Joe

 

I came to this with an engineering degree, and the time stepped physics engine still threw me a few curve balls. If you want to use physics go grab a high school physics text and read up on classical physics. The engine is all basic Newtonian physics. That way you can understand what the relationship between velocity and force and acceleration and position.

Or just follow @JoeStrout's advice and ignore physics.

My typical advice after doing the unity tutorials is to clone a small game. Space invaders or flappy bird are good targets. Any thing with one or two inputs and simple gameplay will work. After doing the learn tutorials you will know everything you need to make a simple game of this type.

 

Aahhhh Crap! There you go, I don't understand what is on the physics side and what's not. I've been intermixing because I take the first item I can get working without any consideration of what's it is I'm using.

So kill the rigid bodies on my cubes. Is that all? My floor and walls have rigid bodies, yes/no? I have a sphere with one too. Eventually I want it to act like a ball, I think I might need that down the road. I'll be back after I finish my homework.

@BoredMormon , thank you too. Not sure if I'd have any better luck doing a Space Invaders or Flappy Bird copy. What I'm working on (and I'm making it up as I go) is pretty basic. An arena (four walls and a floor). two cubes, one user controlled and the other by a simple AI, and sphere for a ball. The entire game is to get the ball and take it to your goal and score a point. Don't even care if it's playable as a game, just to have all elements doing what I want them to do would make me ecstatic! Might have to work on my goals too.

 

Yes, that's the key point: Rigidbody == physics. It's the primary component (along with colliders) which hook into the physics engine. Anything without a Rigidbody or a Collider is completely ignored by the physics engine, leaving you free to move things exactly how you code them to. (Things with a Rigidbody are assumed to move around; things with Collider but no Rigidbody are assumed to be static, but to still interact with the moving things.)

So, while it's true that the simple game you've chosen might actually work better with the physics engine (getting realistic collisions between the ball and the pucks and so on), you have seen how confusing physics can make things. So I strongly suggest that, for the next month or so, you remove all the Rigidbodies from all your objects.

Pong didn't have a physics engine. Nor did Breakout. Programmers just did the (very simple) math needed to move things around themselves. You can do the same, and then everything will be under your control — and within your understanding — instead of having to share duties with the physics engine, leading to confusion and frustration.

(Indeed, Pong and Breakout would be great games to emulate as a beginner project.)

 

Thanks again everyone especially Joe,

Joe, I finished my homework, sorry but I can not report I understand everything as you wished. More information == more confusion and questions.

Working backward from your list, I don't think in need any assistance for input I have that and I posted it above. It's working and I don't think I have any questions regarding this. It is pretty basic and simple.

The transform link is a place I've visited often and haven't gained any understand on how to use properly. Still don't know what to use, how to implement and what I need to do what I want. Sorry, but this is pretty much what I've been trying to express. Reading the entry in each section, I can say the sample is readable and I see what is happening, but I could not implement if my life depended on it.

Also rewatched the video tut on translate and rotate. Yep, pretty much the same as above. At the end of the video he stated that you should not be using a rigidbody or a collider using these. I still have colliders on all objects.

I've removed all rigidbodys from all objects. I don't fall through the floors but I can pass through walls and other objects. Am I responsible for collision detection now? Now I'm just using unity to pass OpenGL commands to OpenGL without taking advantage of Unity features. I've traded yet another set of issues for the last.

There's some fundamental issue that I'm simply not understanding, I can't express what that is as I don't know, but whatever that is, I'm not bugging a millimeter in a forward direction until I get over that.

I can copy anything, I even 'see' what an example is trying to impart, I can't use that to do something on my own. I know what a ball is and I know what a bat is, you can pitch to me all day, I don't know how to hold the bat, I don't know to swing the bat, I don't know when to swing the bat and I don't know how to control the bat to enable contact with the ball. The concepts are there but any ability to actually do or go about doing isn't.

Some people are color blind, I guess I'm Unity blind. I apologize for wasting everyones time, patients, and understanding, please don't take this as a personal failure, I don't think you could beat it into me at this point.

 

That's OK. Ask your questions, grasshopper!

The colliders alone won't cause you too much grief. But yeah, if you want to really make things simple, lose the colliders too.

Awesome! Objects are now moving exactly how you program them to. Nothing mysterious going on anymore, right?

Yep! Just as was the case in Space Invaders, Pac-Man, Donky Kong, Super Mario Bros, Pole Position, Street Fighter, Civilization, and probably 90% of all other video games ever written. You have ultimate cosmic power, without some pesky physics engine saying "no, you can't move your objects that way!"

Nonsense. I've done OpenGL programming. Unity is at a much higher level.

Methinks the Bill doth protest too much. Did you successfully combine the input with the movement scripts, such that you now have a cube you can move around?

If so, then you did that — that wasn't parroting anything; you understood the parts at hand and how to assemble them to achieve a useful behavior. Give yourself some credit, fer' crying out loud.

 

Bill, it sounds like you are working on a 3d version of Pong.

I think it was about last week or so when I worked on something similar:

I admittedly did use some physics in mine. (created a bouncy physics material to eliminate damping)

Also, there is something in the Unity store called Spring Pong, which I think is supposed to be like what we are trying to do.

Feel free to post pictures/videos of where you're at so far.

Have a blessed day.

 

Sadly the record speaks for itself…

@boolfone has made me realize something that makes me think I've taken you all into the weeds with me, I'm almost use to it by now but you all, probably not so much.

Im not building a game. I'm building a 3D workbench for me to learn and test things. So, it is a simple grey box made from 5 cubes, another cube inside the box is colored red and has my character controller on it, plus a camera as a child which provides a 1st person view and is simply a means for me to drive around a camera and view other objects. This same cube has a second camera and provides a 3rd person view above and over the cube. I have another cube colored blue, it has the same camera setup as the red cube. This cube is to be controlled completely by script. And lastly I have sphere colored yellow, a poor little ball begging to do something and feeling quite abandoned as I try to get my cubes working.

If you've been counting, that's four cameras, so far… I have another above the center of my box facing straight down, and another at one wall of the box which tracks the ball on the z-axis, and another camera that has a fly-around script and circles my blue cube. Pressing F1 cycles through the cameras, activating one and deactivating the other.

Some of that is starting to sound impressive, I know. But, it isn't difficult to child a camera to an object, it is still not that difficult to activate and deactivate an object like a camera. I actually did the camera tracking script on my own, but if you asked, well how did you do that, my answer would be 14. That's a conservative number of trial and error attempts before I tripped over it. It worked and I got bigger fish to fry. And the fly-around, really cool, and a complete copy and paste job, changing the reference object to my cube as the center to circle was the only modification. That was simple enough, but I couldn't begin to tell you how it works.

So I have my little workbench set up, a cube and a ball to experiment on, my camera-mobile to drive around and observe from any angle, and a set of cameras to see from just about any angle I choose by selecting a different camera. I'm ready to start experiment, just as soon as I get my cubes manageable.

Joe, I hate to say it, but I think I need the nasty old Physics back, and instead of avoiding the trouble tame it. I had a lot of things working that aren't now. The lookAt - move forward script was driving me crazy but not too long ago I realized the problem, haven't fixed it yet. And the fly (weight) issue, which I can't believe doesn't have a simple solution.

I don't think I left anything out down to colors I've used. I want my ball to be bouncy like a ball, tomorrow I'll want it hit the wall, flatten and stick, next week I want it to float or hover. I want my cubes to collide and jostle but maybe not so much as to tip over. Of course, later I want my cube to fly. I wan't my cube to burn, melt, glow, and vaporize. I want to have them shoot lighting bolts. I want to do things to those cubes I can't even imagine now. Then, when the cube has no more to give, I'll go make a game…

As least that was the plan.

 

Progress update,

My script driven cube used lookAt and move forward as my way of getting it to perform a task. Collider ontrigerenter swapped a boolean HasBall true and false. The cube has two options, if HasBall == false lookAt ball and go forward else lookAt goal and go forward. This was working but was flying when going to the goal and digging into the floor when going to the ball. I kept thinking it was something going on with colliders, despite the fact they were not even close to each other. I discovered a day or so ago that my lookAt was the issue. I didn't understand that a tilt was also in the mix that causes my cube to dip and fly. The slope was so slight that visually it was not apparent and the cube had to move a long distance to manifest the symptoms. I was also tinkering with the user controlled cube and wrestling with other control issues. Since I was moving both and some of the symptoms were similar, I was unable to think my way out of either issue. I now have fixed the scripted cubes bad behavior, but my colliders are not functional since my last change to purge physics.

Code (csharp):

1.  if (nubie == true && experience = 0.000001f && mindSet == "2D" and World == "3D"){
2. clue = !clue;
3. Lights.SetActive(false);
4. }

What can I say…

This is the first time I have identified a problem. Understood the cause. Fixed the problem. I now have a half a big toes worth of ground to stand on and can now move forward. I've pierced a pin hole through the veil of confusion. At last some understanding, as small as it is, I'll take it.

I'm holding off doing more for now to see what Joe has to recommend. I'd like to see this entire post fade away.

While waiting for Joe to smack me in the head, I do have a real question.

In every tutorial a new Vecror3 (Vector2) is created or a new reference to a component is created in Update() or FixedUpdate(). I can't help but being disturbed by the fact that variables are being created and destroyed along with the memory allocation deallocation load for every frame.

Is this an acceptable practice or is just done for simplicity and convince in the example? Again this might be something obvious, but goes against all I know and that it's teaching a bad habit for newcomers if it is.