Register
Events
Popular
More
Post #1
I learned almost all C++ syntax. And dived in to game libraries for 1 week and learned a little bit event driven programming too. But today I realized something that without knowing physics you just cant make a game even you know all the syntax of C++ and the game library you use. I'm stuck like never before and very desperate. Now I have to learn physics from zero. I feel like my time is wasted and I came to start line again. Just wanted to share my sorrow with you. Any help will be appreciated too.
-
-
Physics library. Boom, you're done.
-
Thank you, but I dont wanna use readymade things. I cant feel like a real coder in that way.
-
Why re-invent the wheel unless you have to? Ever popped open an AAA game? "MILES SOUND SYSTEM" "HAVOK PHYSICS" "POWERED BY UNREAL" "BINK VIDEO" - These are all using proven, tested third party solutions so they can get on with what they want to do - Make games.
-
Glad you said it so I wouldn't be accused of putting words in your mouth
The single most important lesson any programmer learns is that "real" programmers strive to accomplish tasks as efficiently as humanly possible. This means using other people's work whenever possible.
I want to stress this: BAD programmers insist on doing everything themselves.
-
I dont know I'm a little bit perfectionist, control maniac and obsessive maybe this is the reason but one thing I know is that I have to learn physics.
Edited:
So you say use physics library and never learn physics but what will be If i want to write my own engine after some time. I will stuck again.
-
There's more to programming than bideo games.
And if you just want to make a game, why get bogged down in all the crap that isn't "making a game"?
Physics should just be there, physics isn't a game.
-
Learn physics. Physics is neat.
-
"Luaguy"
You do realize you're a joke, right? You are claiming that you need to do everything yourself, you have to reinvent and reimplement and understand every idea ever conceived, and yet your name suggests you are fond a rather high level language; shouldn't you be making your game in assembly?
Or maybe you should write your own operating system and build your own computer to run this game. Oh, and we can't use any parts made in factories, we'll need to build a lab and a manufacturing plant. But wait! How is anyone going to play it? I guess you'll have to start your own personal computer company.
Oh no, wait, before you do any of this, you are going to need to amass a perfect knowledge of all the related sciences and their related sciences... Jesus- you are going to need to come up with a unified theory for the workings of the entire universe!
Who knew making games was so hard.
-
This was an overly aggressive reply to a perfectly understandable problem.
I hate using physics libraries because I feel like I'm missing out even though I know making a physics engine is still out of my league. Yet, I use .NET and don't feel at all bad.
It's not as straight forward as you think.
-
What about the time lost learning how to program physics? There's more than just physics in games you know.
-
I am being agressive; and this is because I once suffered from the same debilitating mental disease: "perfectionism".
I see it in most if not all beginning programmers. I don't want others to have to go where I did; coming to hate programming and myself simply because I was at the point where every time I sat down to program I ended up tearing my hair out within 15 minutes because I couldn't just solve the problem in front of me, I had to solve every problem tangential to it, and the problems tangential to those problems, ad infinitum
-
Uh, also, learning C++ syntax doesn't mean much at all.
I can learn Python syntax in a day. But it wouldn't make me a Python programmer at all.
-
Exactly.
Like one of the first programs I made was a music player in Qt. I didn't write the code to actually decode MP3 files, and of course I didn't write the GUI framework (Qt).
I did the library managment stuff, and when it came time to play a song I just did like play("file.mp3");
Why waste my time writing yet another MP3 decoder.
-
Well, I'm not a beginner and I still don't like using physics libraries. I've used plenty of others that I didn't mind at all. It's just the physics ones that feel like cheating... Maybe the OP feels the same.
-
Programming is already plenty hard enough, there's no need to create challenges for yourself by doing things the hard way.
I mean, think about it for a second. People who use libraries; do they just program once a month, and THAT'S why it takes them several years to make a finished product? NO! They are working their ass off solving REAL programming problems. Which is what you seem to be so intent on solving.
You don't need to go looking for a challenge, the challenges are already coming for you.
Edited:
Note that this isn't a response to any posts since my last post, this was mostly supposed to add to my last point.
-
I don't think you're as much of a lost case as the OP. It seems you understand when it's right to work on your own code. The OP, however, wants to create a physics engine without even knowing C++.
Assuming this isn't a troll, because god, it's fishy.
-
I feel that it's an important part of the learning process.
If you re-invent the wheel a couple times, you're tackling a problem that has plenty of resource material and various benchmarks that you can use to assess yourself. The 'try things; evaluate results; draw conclusions' feedback loop is nice and small. This way when you've got to tackle unique problems, you've got experience to draw on.
You don't have to worry about being productive until you actually need to be productive. And if you test your limits beforehand, you'll actually know them when it's important.
-
I believe learning the physics may be helped by using a pre made third party package ...
Once you create your project using the package you can then go back and look into the physics classes to see whats going on.
The chances are that the physics package will have thought of ways of doing things that you wouldn't have thought of without having looked at it.
And therefore teach you much faster then you would learn otherwise! (At least that's my opinion / experience)
-
I think the important (and fun) thing is progressing towards the goal of your project. Making your own HTTP library (or whatever) can be a fun project and an important one to look into, but if your project is something more composite like a game, I think it's silly to be tripped up by the notion that anything pre-made is cheating.
I say find a cool beans physics library, use it in your game, then dispel that feeling of cheating by reading up on the library and what it does, look through its docs and maybe its source code in more detail. I think the feeling of cheating comes from not knowing the internals of what you're using, and you don't have to have written a given library to know well enough what it's doing internally.
-
That's how I felt at first, too, but then I realized, that that's a fatal way of programming.
-
Even if you wanted to teach yourself physics, most physics needed for game programming is just a basic understanding of mechanics/Newton etc. Bit o' trigonometry, some SUVAT, then you can just look up what you need when you need it.
With basic trig and mechanics knowledge I implemented a pretty good gravitational model in Python recently, just googled the relevant equation and played around. You're making a mountain out of a mole hill.
-
I am more neutral with the subject. I beleive that LuaGuy has a great argument because I too once said that I should create my own physics library. Before you can make your library though you have to COMPLETELY understand other physics library. You also have to see how the whole physics library is structured.
LuaGuy I feel as if you're taking the wrong approach. You should still learn physics but use other peoples physics libraries.
I hope you understand my logic.
-
Wait a minute here, there's a difference between programming a game and programming a physics engine.
I wouldn't consider writing my own physics for a game (Unless the physics were relatively simple), as physics engines encompass months of work on optimizing the routines, tweaking algorithms and code from people who have a better understanding of the subject. In addition to that, physics is the same in almost every case, and any 'extra' physics you want to implement in your game could easily be achieved.
Writing a game on the other hand, is much different. No two games have the same laws, rules or game-play, you have to provide your own implementations for how you want the game to play. Plugging in a physics engine is just part of defining the rules for the game.
-
Thankfully there is perfectionist people out there, brave enough to go for and code a physics engine. I don't believe in argument called "re-inventing wheel" in programming. Since if you don't copy and paste code from other people's works, It wont end up as same wheel. Yeah they will have same purpose ( reducing friction ). But their shapes will be different, their material will be different and they will vary in structures. Like one man would build a wheel out of stone and one can make out of metal. It is like your own solution to a specific problem. Problem is same but solutions are becomes personal. If re-inventing the wheel is such a bad thing, there shouldn't be that much programming languages, libraries, operating systems out there. ( Who the hell was that had the crazy idea of creating a new operating system called Linux 20 years ago while hundreds of them were out there sitting and doing nothing? )
So I see you learning programming and you want to learn how things works, make your own solutions to these problems. Well people like you and me likes challenges. You may be the number thousand guy that climbed to mount everest but personal satisfaction to climbing everest has a feeling nothing like any other accomplishment. Because it is curiosity. You are curious about how earth looks up there. You could use other people's photographs taken when they were highest point of earth but this is not enough you should see it yourself. You should outperform yourself. So you can gradually improve yourself.
BUT, as you can see climbing a mountain is not a easy thing anyone can decide and do randomly. You should have physical endurance and strength to accomplish this task. And very strong will. For building your strength you should run through hills, climb small mountains and gradually improve your skills and strength over time.
Now you should ask yourself what you want to do and create layers of tasks out of it;
1. Make a game
a. Learn programming by making everything yourself.
i. Make game engine
ii. Make a physics engine
Like an ultimate goal, and sub goals of it then sub goals of sub goals. I remember I having I was that deep in holes there were 10 layers. But every layer you go up by getting successful at those tasks bring you a lot of experience.
Now you should consider you are going a very long way. Like a way that it could take 10 years of your life very easily. ( It took mine, I know from experience :) ) And you going to be barefoot ( Because thats the purpose ). What would you carry in your bag?
Problem is how much you can carry? How strong you are. If your purpose is climbing everest, I would ask how much hills and small mountains you climbed already (for building strength)?
Process is goes like this. You randomly start picking objects to carry with you. In first miles you will see some stuff you carried have no use. So you drop these stuff and start from scratch. After few years passed you will see you are going in wrong direction. You start from scratch again. Thats why it takes 10 years. Or you could have a mentor that remotely helps you what you should take, what direction you should go decreasing time required to accomplish your goal.
So problem is lack of experience. My ultimate goal was making a 3d engine 10 years ago. I started with visual basic 6 at the time did some stuff (model loading, textures, particles, camera). Folder name for that was "A VERY BIG PROJECT" a name you can expect from a kid ( I was 12 at the time) that filled with stuff not anyone can easily understand. Then I see I was in wrong way and I should use C++. I switched to c++. Because of some assembly knowledge I had no problems with C++ but I started from scratch 4 times and its 10 years passed over my stuff. Because I learned a lot every time I tried making an engine, that make me see my old codes are looks like shit, have no reuse, lot of missing properties that you can expect from a wheel. But I am happy of my code today. I feel I have enough experience to make engine and a MMORPG out of it. So my goal is changed from making an engine to making a game with it. But writing a physics engine (alone) were never in my goal list. I always considered it as part of game engine. Now I have enough experience to make a physics engine but I think like "meh It could just waste my few months of work" so now it has no challenge to me, and I am not focused on it. But its still a challenge for you because you think "you can't make a physics engine with your current level of knowledge".
Solution; First of all never left programming. Because left it for 4 months and when you come back you will know nothing. Secondly do what you want straight away. Like if you want to make the game create the project and start coding it. If you are not successful repeat until you will. Thats the only way so far you can gain experience. When you feel you have enough experience you can go for more advanced stuff. Keep the challenge and do the coding. If you want to make a physics engine go for it. You will see its not that hard to keep walking when you begin the journey. In the end everything is about being brave enough to taking the first step.
-
Burak:
The point of all this is the goal you persuade: Do you want to create a game, or a physics engine?
Creating a physics engine just for your game is reinventing the wheel unless it requires special features other engines don't offer.
-
If goal is learning how to programming advanced stuff it doesn't matter you coding a game, or game engine or a physics stuff. In the end of your projects you will have enough experience to make any of it. And when they are not a challenge anymore, you won't want to make a physics engine or game engine anymore.
-
In my opinion prioritizing is another key component to succesful programming.
-
Yeah you are right, only different thing I say is prioritize what your heart says you want to do. Like what you feeling enjoyment while making. So you can overcome the boring learning process. Because learning is simply repeating same things over and over. When you learned enough, you automatically don't want to do unnecessary things.
He just look like picked a challenge to himself which is writing a "physics engine" but seems like he don't know where to start and struggling.
But if he wants to make a game and if he wants to make a game as soon as possible, I agree he should use stuff ready to be used. But if he doesn't have much experience yet, he can't going to make the game with just using "magical" libraries. He should learn first and it doesn't matter how he learning. He would go with game maker then, and everyone who said "use library" here will laugh at him.
And LuaGuy,
You don't have to learn physics you have to learn math a little bit to understand vectors, matrices and quaternions. At least how to use them is still enough. Physics is just mathematical changes over time. acceleration is difference of speed per time unit. and speed is difference of position per time unit. just create a loop and use this information to calculate your object's position. with usage of time passed. like your rendering loop took 0.5 seconds, just multiply it with acceleration and add it to speed, then multiply speed with 0.5 again and add it to position of your object. Then check for collisions then make implement collision response. after you done these you can go for constraints between objects. You can use rendering library for testing your physics stuff. after your feel its enough, you can make your own rendering library. And when you think you got enough experience to make these stuff that make you think "I can do anything, it just takes time", like when you don't feel desperate when you don't know something, you can start making your game or whatever your end goal is.
-
How is your vector math? I made my own physics engine using the following resources:
http://www.metanetsoftware.com/technique/tutorialA.html - Explains the separating axis theorem well.
http://chrishecker.com/Rigid_Body_Dynamics -- VERY VERY USEFUL
Basically the metanet explains how to do collision detection. Chris Hecker explains almost everything else.
Making a physics engine was a really fun thing to do but in the end your engine is unlikely to ever be as stable as a third party library like Box2D, so you will probably just end up using a third party even after making your own engine. Although the learning experience allowed me to understand how to use Box2D much more effectively.
I manage to make this with the two links I posted above.
-
You don't just learn to 'program advanced stuff'. You learn how to write a certain thing. You can't specialize in writing 'hard software', you can't learn techniques to better write 'hard stuff'. Writing a physics engine will not give you the experience to write a game render because both are 'advanced stuff'. If you goal is to learn about programming, learn programming doing something practical that you enjoy. Writing a physics engine just before you write a game won't learn you much more than the other way around, it will just be longer and buggier. Why not write a game and then write a toy physics engine while having in mind what a game expects from a physics engine? Much better idea in my opinion.
So first you say that re-inventing the wheel doesn't exist in programming. You back this up by saying that reinventing is not copying line-by-line (duh), and then you describe the process of reinventing the wheel, and what kind of fucked up wheel you could end up with.
This is exactly what re-inventing the wheel is.
-
Not Invented Here Syndrome
-
Actually, you'd be surprised at how much overlap there is between physics and rendering. A big part of rendering is visibility determination; occlusion, frustum culling, etc.. Those are all applications of collision detection, even if it is not usually called as such. You often need to find items within a given range (finding lights for forward rendering, LOD swapping, etc), which means you have to learn to use the same sort of hierarchical space-partitioning structures that are used in both physics and rendering.
Further, there is an element of dynamics and actual physics in rendering. Tonemapping algorithms often represent adaptation over time. You've got kinematics in animation and skinning, IK, particle systems and soft-body physics (both of which are best implemented in the rendering pipeline, AFAIK, since general-purpose physics libraries still aren't really suited to these tasks). If you really get into physically-based rendering, then it's a lot of spherical harmonics, monte-carlo (or even regular old analytical) integration, and theory of optics.
Long story short, it's all calculus and computational geometry. Learning one does prepare you for the other, to some extent, even if they are different subjects. It's the same problem-solving processes that go into each.
I think the real point is, though, that you have two different sets of priorities, depending on the situation.
When you're working on your own time, the path is generally more important than the end result. Your sole focus should be on learning and self-betterment. When you encounter a subject that makes you say 'there's no way that I could ever do that', you should try, because you're almost guaranteed to learn something, even if you don't finish, and you'll probably have a lot of fun along the way. Re-inventing the wheel is as good a means as any to learn these skills. In fact, I think it is even better, in some cases, for the reasons I've argued in an earlier post.
Then there's real-world programming. This comes after and in addition to the learning stage above. This is when you strongly want to consider using well-tested libraries for anything and everything, since it is likely to be better code than you could produce in a month and maintain for the rest of forever.
I generally don't think it is good to try to skip the first stage (i.e. dicking around and re-implementing things you shouldn't; breaking all the rules).
-
The point is learning how the physics engine internals works. When you learn that you will be easier to deploy another library. Because you would know what you looking for. My points are not applicable for people already experienced in general programming. But people in beginning of their way. Like if you are a company going to make games, which means you have "financial liability" you should make it in shortest time possible and in stable. To quickly gain back your expenses. For accomplish this thing you should use everything ready to use around. Developing your own game engine in this company will be loss of time and money. In the end if its not stable enough it can be catastrophic. Which is "Not Invented Here Syndrome" applicable. But for persons that wants to learn stuff no problem in inventing their own wheels to see how things are work.
Also there is a point of time when you got enough experience, when someone describe a problem to you, you can actually see the solution. We could call that "Neo Vision". Like you make a quick list in your brain how solution can be accomplished. Which I gave an example in post above yours. Then you can quickly prototype the options and find a working solution.
And yeah when you don't copy line by line, it end up as your version of a wheel. In the process you learn how wheels works, what are the possibilities and capabilities of wheels. So when you need a wheel in future, you will know what you are looking for. Like if you going to rough terrain with that wheel you could add some more carbon and decrease the sulphur from rubber. But for knowing what you need to do, you have to reinvent it. My first wheel was like in a hexagon shape and made of stone. It helped me to see what I were wrong. Also looking other wheels made by different people will not help you find your mistakes earlier. Like you can't learn about how templates works or where to use them or design patterns. And you maybe can't specialize writing "hard software" but you can in "problem solving". You can learn techniques at "solving problems" efficiently. And most of these stuff are pretty much overlaps.
Also there is a bonus which is; no one can guarantee you won't going to find a better way to make wheels. Who knows maybe world changing way?
-
You missed my point. You don't learn to program 'advanced stuff'. 'advanced stuff' is no different to program than 'simple' stuff or 'medium-rare' stuff. If I write a C++ compiler, I won't necessarily be proficient enough to write an operating system kernel just because both are 'advanced stuff'. So like I said, you have to focus on what you want to learn.
Ridiculous. When you work on your own, what is more important is what you decide is more important. It can be the end result or it can be the path, it depends what you're trying to achieve. Why would I bother writing a physics engine if I literally don't give a shit about it? Learn what you want to learn, not what someone on the internet told you to.
Again, more orders. No, your sole focus should be doing whatever you want to do. It's your hobby after all, not others'.
No one said you can't learn by reinventing things, but thanks for your input.
-
I didn't said someone said "you can't learn by reinventing things".
But thanks for your output.
-
Fair enough, but I think this is mostly an issue of miscommunication (perhaps on my part). What I'm trying to say is people shouldn't feel like they have to beat themselves up over getting or not getting things done. Everything is useful experience.
-
I understand OP's concerns but it is perfectly acceptable to use physics libraries. What I do think is that it is important to have a key understanding of how a certain library would work. If you are completely clueless, it is worthwhile to research the library's function, e.g. game physics. This will make you a better programmer in the long run. I personally do not like using libraries when I know little about how they work, but writing your own library just because you do not like to use existing ones is a waste of time unless you have something new to add.
-
Erm okay? lol.
Part of the way I'm answering the way I am is that the OP seems to have no experience with C++ and doesn't seem to want to learn physics engine for any other reason except a misguided impression that it is a prerequisite to learning how to make games. I do agree with you that trying to write your own implementation can be a learning experience, no matter how sub par the implementation is.
-
thats the magic about programming.
Thats the part that I love about programming, getting desperated about something I cant understand
Dumb x 7
Funny x 2
Friendly x 1
Optimistic x 1
Agree x 12
Zing x 1
x 1
x 1
x 1
x 1
Informative x 1
Useful x 1
