Originally posted by Sinella I think there is a misconception about programming. It's not based on math. It's much more based on logical and ordered thinking. I have university degree of software developing ( programmer mathematician to be correct) and I've worked 15+ years as a software developer. Not as a game developer though, I mostly worked with databases. I've learnt a huge amount of maths at the uni...and after finishing it I've never ever needed what I learnt there about maths. Seriously, not even once.
I'm only a student so your 15+ years trumps mine, However it really does depend on the task.
From my limited experience working with game code, There is a fair bit of mathematics in regards to the the computer geometry involved with making 3D games. Diffrent matrices like the pitch yar and rol for different objects and gamespace, and LA when those objects move does requires some thinking..(atleast for me)
The Software degree i'm undertaking is supposed to prepare me for tasks in the medical and industrial fields. So i'm assuming if i went that route there would be a lot of engineering maths to be had there.
As I said I'm not a game developer, so I have no experience in that field. Working with graphics probably involves a lot more maths, much more than databases. It depends on what field you plan to specify in....what I meant that programming in general is not based on math. As you don't have to be a doctor to be able to write a medical program you don't have to be a mathematician to write a math program. A programmer can write any type of programs if he gets a proper description of the task. Of course, as he becomes more experienced in the actual field he will need less detailed specification of the task.
As for engineers, I think it is a logcal progression and sub-path for studies to dabble in programming. Another poster stated it well: Great programmers, more importantly game programmers, excel in logic and not just math, but I do not agree in ignoring the imperative nature of a sharp mathematical prowess. It is what differentiates those who CREATE versus those who just IMITATE.
Gary Gygax would've made an excellent game programmer, instead he brought us the genius that is Dungeons & Dragons, along with Dave Arnerson. Would he have made a great engineer? Not sure. What I can deduce from all the excellent statements and questions so far is that in order to be a great video game programmer one must possess an assortment of talents, jack of all trades, master of none it seems, and one of those facets they share in common with engineers.
Interesting reads. "It is what differentiates those who CREATE versus those who just IMITATE. " I have ran into this alot. Those who tend to be book smart lacking real creativity and those who are "average" by the normal grading scale exceling at creativity.
I do believe your articles touch on an interesting point that sometimes things can run together or utilize the same part of the brain. This could lead some one traditionally trained in engineering to be better at thinking through all the logical steps it could take to make a game and picking up on everything so that the game creation process could go more smoothly.
That now makes two possible positions for an engineer, a consultant or a designer.
Originally posted by Sinella I think there is a misconception about programming. It's not based on math. It's much more based on logical and ordered thinking. I have university degree of software developing ( programmer mathematician to be correct) and I've worked 15+ years as a software developer. Not as a game developer though, I mostly worked with databases. I've learnt a huge amount of maths at the uni...and after finishing it I've never ever needed what I learnt there about maths. Seriously, not even once.
I'm only a student so your 15+ years trumps mine, However it really does depend on the task.
From my limited experience working with game code, There is a fair bit of mathematics in regards to the the computer geometry involved with making 3D games. Diffrent matrices like the pitch yar and rol for different objects and gamespace, and LA when those objects move does requires some thinking..(atleast for me)
The Software degree i'm undertaking is supposed to prepare me for tasks in the medical and industrial fields. So i'm assuming if i went that route there would be a lot of engineering maths to be had there.
As I said I'm not a game developer, so I have no experience in that field. Working with graphics probably involves a lot more maths, much more than databases. It depends on what field you plan to specify in....what I meant that programming in general is not based on math. As you don't have to be a doctor to be able to write a medical program you don't have to be a mathematician to write a math program. A programmer can write any type of programs if he gets a proper description of the task. Of course, as he becomes more experienced in the actual field he will need less detailed specification of the task.
I guess I am a bit lost with where you are going with the "proper description" At a certain point you would basically be force feeding the code to the programmer and they are more or less a translator, not the creator. I do agree with critical thinking being the greatest asset for a programmer. It appears common for programmers to have to figure out creative ways to program solutions to a problem and from the little programing I have dabbled in, it would seem there are a plethora of good and bad ways to get to the same answer.
There are certain queer times and occasions in this strange mixed affair we call life when a man takes this whole universe for a vast practical joke, though the wit thereof he but dimly discerns, and more than suspects that the joke is at nobody's expense but his own. -- Herman Melville
Among amateurs, people who make games are those who have the interest, free time, aptitude, background knowledge, and dedication. People who have the interest but are missing one or more of the other components may try and fail to make games.
In order to get hired to make games professionally, you have to convince a company that you can do it. Having done it before is the best proof that you can do it, in which case, see who makes games among amateurs.
-----
Engineers typically take the introductory math courses at an undergraduate level, but don't go any further than that. That means a year of calculus, as well as multivariable calculus, linear algebra, and differential equations. Where I went for undergrad, computer science majors also had to take a stupid, cupcake math course called "Discrete Math", as well as their choice of either probability or something else (maybe number theory, but I'm not sure). Engineers presumably see some additional mathematics in courses that are within their major, but the math portion fo the math is likely to be glossed over.
Mathematicians will tend to see the most mathematics, of course. Physicists and statisticians will see quite a lot, too--and certainly more than engineers.
-----
Mechanical engineers, biomedical engineers, or most (all?) other types of engineers (or at least real engineers, as opposed to job titles that stick "engineer" in the name to make it sound more prestigious) have to deal extensively with the real world as it actually exists. The way that a game world works doesn't need to match the way that the real world works. In fact, it can't and shouldn't in many ways. Knowing how things actually work in real life may give you a default starting point that you'll almost immediately move away from in designing your game, but much of the training simply isn't relevant to game design.
That's incredibly important for a lot of engineering jobs, of course. You wouldn't want to drive across a bridge designed by someone who has no clue how strong the materials used are. But it also means that a ton of the training simply isn't relevant to a game world where you can magically make a bridge stay in place no matter what it is shaped like.
-----
If you know the mathematics that you need and have the aptitude, then you can pick up a computer language in a few weeks. That's not the big barrier to creating a game. Picking up the computer language isn't the same as being good at coding in it, which is why having the aptitude is tremendously important, and experience helps, too.
Learning the mathematics is entirely different, though. How much mathematics you need depends tremendously on what you want to do, but expect it to take years to learn it. How many years depends on what you want to do. The graphics engine is probably the most math-intensive part of a computer game, and for that, you absolutely need multivariable calculus and linear algebra to be able to do much of anything at all. Quite a bit of graduate-level mathematics is useful, too.
A good background in probability is also tremendously useful for game programming, and not just on the graphics side. A lot of engineers may see the really introductory stuff like problems with fair coins or dice or putting balls into boxes, and some standard distributions like a normal distribution and exponential distribution. But there's a lot beyond that that is also very helpful to know.
In many situations, it's not just whether you've seen some piece of mathematics in a course that you took and passed, but whether you're comfortable with doing explicit computations that are far more involved than would have been fair to assign for a homework problem. The same is true on the computer programming side of things, too.
-----
There are some things that you don't need to know ahead of time, but can pick up once you discover that you need them. But you'd better have enough of a background to have some idea of what is out there and where to look.
I've been assisting at the university teaching Finance in the Eco department, but my heart will always be in gaming and programming. A lot of times I get jealous of the Comp Sci staff, they dabble in some very cool experiments
I will admit that I did not finish the whole article, but if some one wants to get the part that relates to the article read section 3. It is only about a page. To summarize it explains that to teach a computer something you have to have a better understanding of it and by coding it it helps you with abstract thinking. Basically his best line to sum it up is, "It has often been said that a person does not really understand something until he teaches it to someoneelse. Actuall a person does not really understand something until he can teach it to a computer"
I will admit that I did not finish the whole article, but if some one wants to get the part that relates to the article read section 3. It is only about a page. To summarize it explains that to teach a computer something you have to have a better understanding of it and by coding it it helps you with abstract thinking. Basically his best line to sum it up is, "It has often been said that a person does not really understand something until he teaches it to someoneelse. Actuall a person does not really understand something until he can teach it to a computer"
Programming a game is mostly a matter of describing exactly how you want everything to work. There is also some optimization to make the game run fast rather than doing the same thing slowly.
There are some things that it is possible to describe exactly, but not practical to program a computer to do them. Just about anything from a Real Analysis course, for example. Computers, by their very nature, can only deal with finite, discrete things. But that's still quite a lot.
Well, first I would like to thank you for joining us in the new thread. Also thank you for another well written post. Now to the nitty-gritty!
First I enjoy your comment, "a stupid, cupcake math course". Secondly, I understand that computer worlds do not have to act like the real world, but for certain applications it could be very desirable to achieve something close. Now I personally do not think that if I had a programmer and told him to make a real world accurate bridge with materials, mass, wind resistance, sway or honestly anything that he would come close. On the other hand I do believe a mechanical engineer could do it, but most likely with code that is very lacking in structure. Now I think you state in your comment that it is easy to get code to do what you want but not to learn(understand) the math that say an engineer might know. So it might be plausible in this situation of wanting some kind of a realistic(why do we put hyper on the front? is hyper-realistic more realistic than real?) engine to show stress, strain, force, torsion and what have you on a bridge and to acctually show how it will fail.
Now as to avoid the argument that that would only be used in simulations, lets take rag doll effects into account. We have all seen the rag doll physics where the gentleman shot in the crotch until he died suddenly flies off to the moon because there was some kind of an angle calculation error. Now say we put a biomedical/mechanical engineer on this. They could tell you if the bone broke, how the forces would make his body turn, and that GRAVITY DICTATES THAT PEOPLE DO NOT FLY OFF TO THE MOON WHEN SHOT! More seriously though, it could make for interesting game mechanics to be able to calculate if a bone was broken from a shot or hammer hit, but again I am sure this could also be reduced to simplistic math of we say 5 bullets means a broken bone instead of if there is enough of the bone gone from bullets taking it away then the bone fails.
A final side comment on your part about graduate math I got a bit lost on what you were refering to, I suppose I am unfamiliar with the nuances of putting a ball in a box. lol :P
Well, first I would like to thank you for joining us in the new thread. Also thank you for another well written post. Now to the nitty-gritty!
First I enjoy your comment, "a stupid, cupcake math course". Secondly, I understand that computer worlds do not have to act like the real world, but for certain applications it could be very desirable to achieve something close. Now I personally do not think that if I had a programmer and told him to make a real world accurate bridge with materials, mass, wind resistance, sway or honestly anything that he would come close. On the other hand I do believe a mechanical engineer could do it, but most likely with code that is very lacking in structure. Now I think you state in your comment that it is easy to get code to do what you want but not to learn(understand) the math that say an engineer might know. So it might be plausible in this situation of wanting some kind of a realistic(why do we put hyper on the front? is hyper-realistic more realistic than real?) engine to show stress, strain, force, torsion and what have you on a bridge and to acctually show how it will fail.
Now as to avoid the argument that that would only be used in simulations, lets take rag doll effects into account. We have all seen the rag doll physics where the gentleman shot in the crotch until he died suddenly flies off to the moon because there was some kind of an angle calculation error. Now say we put a biomedical/mechanical engineer on this. They could tell you if the bone broke, how the forces would make his body turn, and that GRAVITY DICTATES THAT PEOPLE DO NOT FLY OFF TO THE MOON WHEN SHOT! More seriously though, it could make for interesting game mechanics to be able to calculate if a bone was broken from a shot or hammer hit, but again I am sure this could also be reduced to simplistic math of we say 5 bullets means a broken bone instead of if there is enough of the bone gone from bullets taking it away then the bone fails.
A final side comment on your part about graduate math I got a bit lost on what you were refering to, I suppose I am unfamiliar with the nuances of putting a ball in a box. lol :P
The problem is with how fast you want the game to run. Games invariably have to do a huge number of things where the justification is "it looks decent enough and it runs fast".
Collision detection is tricky. Find two irregularly shaped objects and hold one in each hand. Pick a direction for one of them to move such that it's obvious that the two objects would collide eventually. And then try to compute exactly how far the object would move before the collision takes place. No clue where to start? That's exactly the point. And you even have the huge advantage of intuition that the collision should take place somewhere around such and such. Computers don't have that.
If you have two objects that each consist of a hundred triangles each, that's ten thousand possible pairs of a triangle from each that could be the first to collide. If you want to use the graphical model for collision detection, then you've got to do some substantial computations ten thousand times per frame--and just for those two objects. If you have twenty objects moving around, you're looking at a little shy of two million tests to see if two triangles hit per frame. Good luck getting 60 frames per second, even if you don't have to do anything else but collision detection.
That's why, no matter what your character looks like, for physics purposes, you'll be a much simpler shape, and most likely a sphere, box, or cylinder. Why are those chosen? Because they make collision detection possible on hardware that actually exists.
-----
Let's talk about tessellation. The way it works is that you start by picking the surface that you want to draw. Ideally, it would be a manifold with boundary. There isn't a hard rule that it has to be, but that will tend to make your life easier. You can draw more complex surfaces by chaining together several manifolds with boundary, either along common boundaries or by something along the lines of a convex ear decomposition.
Next, you pick a triangulation of your manifold, that is, a simplicial manifold with boundary that is homeomorphic to your original manifold. This should have as few facets as is practical. For technical reasons, it is desirable that every facet should have at least one interior vertex.
Then you write your vertex shader. Mostly, this consists of determining the inner and outer tessellation levels for each edge and facet of your simplicial manifold with boundary. This should typically depend on the size of the object, its distance from the camera, and its curvature at various points.
Then you write your tessellation control shader (hull shader in DirectX). This asks you to choose the inner and outer tessellation levels for each facet of your simplicial manifold. Two facets that share an edge should have the same outer tessellation level at that edge for both of the facets. The way I do this is to determine a tessellation level at each vertex, and then make the outer tessellation level for an edge the greater of the tessellation levels at the two vertices, and the inner tessellation level at a facet the greatest of the three vertices. Tessellation levels at boundary vertices need to depend only on the boundary of your manifold if you want to attach another manifold at the boundary later.
Then this goes into the hardware tessellation stage, which is a fixed function stage, so you don't have to do anything.
Next comes the tessellation evaluation shader (domain shader in DirectX). The tessellation stage gives you a bunch of new vertices that it created by subdividing facets of your initial simplicial manifold. This is a topological subdivision, so which vertices form facets is already decided for you. But you're expected to pick the coordinates of where to put the vertices. That means you specify an explicit homeomorphism between the simplicial manifold with boundary that you used at the start and the manifold that you actually had in mind. You'll want an explicit parameterization of the latter, so you essentially have it as a parametric surface. (You'll probably need a parameterization for texture coordinates anyway, even if you're not doing tessellation.) The restriction of your homeomorphism to any facet should usually be a diffeomorphism, but this isn't absolutely essential.
At that point, you have a new simplicial manifold with boundary that is a topological subdivision of the one you originally put in, and when drawn, should look a like the manifold with boundary that you had in mind. Then you have the tessellation evaluation shader do whatever work you would have done in vertex shaders if you hadn't been using tessellation, and subsequent pipeline stages are exactly the same as if you hadn't done tessellation.
Now, you don't want to write a separate program for every single surface that you want to draw. So you need to come up with parameters that allow you to use the same program for a bunch of different surfaces that use different uniforms to make them look different. Rotations, translations, and dilations are pretty easy to do this way. Using the same program for two manifolds that aren't homeomorphic probably isn't going to end well. Checking homology groups is the quick way to tell whether two manifolds with boundary are homeomorphic; while it is possible to have two manifolds that have the same homology groups but are not homeomorphic, they're more complex than you'd want to try drawing all at once.
-----
So back to stuff that should be more readable to you. A typical engineer will probably never study the concept of a manifold, let alone a triangulation of a manifold, a topological subdivision of a simplicial complex, a homeomorphism between manifolds, or a lot of other stuff there. Furthermore, an engineer wouldn't even have the proper math background to pick up much of that even if so inclined. Try doing a Google search for "homeomorphism" and seeing if you can make sense of it.
If you have the appropriate math background, tessellation isn't hard to do. But if you don't? Then it probably won't take very long to figure out that it's not a good idea to try.
My experience with games has me believing that engineers need to stick to engineering, i.e. the tech behind the games. Games I have played where the lead programmer/designer has high technical skills, thing like "fun" and "ease of use" tend to suffer greatly.
On the flip side, games that are "developed" by very creative people who have no grasp on what is possible technically usually flop due to crippling bugs or poor performance.
A "third" side of the coin would also be either of the above who have zero business sense, and believe their awesome tech or great idea will sell itself.
"If MMORPG players were around when God said, "Let their be light" they'd have called the light gay, and plunged the universe back into darkness by squatting their nutsacks over it." -Luke McKinney, The 7 Biggest Dick Moves in the History of Online Gaming
"In the end, SWG may have been more potential and promise than fulfilled expectation. But I'd rather work on something with great potential than on fulfilling a promise of mediocrity." -Raph Koster
Engineer is such a broad terminology that very few people understand that engineer is a primary title for many many manydiffrent types of engineers. I for one am a fabricator welder! My skills would be useless in a technical sense but my ingenuity and passion for self expressionalong with a flare for creation development and a very polished and exact product would infact make me a very valuable games designer/ ideas generator. Though i have noclue how to make it work,
Im also a hardcore mmo gamer having played video games for the best part of my last 22 YEARS . I go back as far as the zxspectrum comny 64 amiga machines atari 2400 and this other odd system with nobs for controllers. I may have been younger. Ive pkayed all kinds if video games from real world vr systems, milirary vr systems and all the latest games. I have epic ideas for video games. Just require a brave gutsy studii like ccp to make it.
Video games require all kinds of disciplines to create. Networking Engineers, Software Engineers, Mathematicians, Artists, Writers, Designers, Programmers, Managers, Stakeholders, Network Administrators, Marketing, Project Coordinators, and often just general consultants (such as a few retired military guys for insight on squad tactics or whatever). I'm sure I missed all kinds, and I'm sure there are some people that will fill multiple roles.
Originally posted by Adamai Engineer is such a broad terminology that very few people understand that engineer is a primary title for many many manydiffrent types of engineers. I for one am a fabricator welder! My skills would be useless in a technical sense but my ingenuity and passion for self expressionalong with a flare for creation development and a very polished and exact product would infact make me a very valuable games designer/ ideas generator. Though i have noclue how to make it work,
Im also a hardcore mmo gamer having played video games for the best part of my last 22 YEARS . I go back as far as the zxspectrum comny 64 amiga machines atari 2400 and this other odd system with nobs for controllers. I may have been younger. Ive pkayed all kinds if video games from real world vr systems, milirary vr systems and all the latest games. I have epic ideas for video games. Just require a brave gutsy studii like ccp to make it.
the other bit of confusion is that many people don't understand the difference between an engineer and an Engineer (big E). There are many people in the computing field that have job titles like "software engineer" but aren't actually certified, regulated Engineers.
In a way it's sort of like how anyone with a PHD is considered a Doctor, although it doesn't mean they have any understanding of medicine. Software engineers, for example, wouldn't technically be able to claim they are an Engineer.
My CS degree was 90% math and physics, 10% programming. Don't learn computer science if you don't like math, someone should have told me that before I started.
I now do art school, a lot of it is science, from color theory to anatomy.
I don't really know of any degrees that don't involve science in a way.
Originally posted by Adamai My skills would be useless in a technical sense but my ingenuity and passion for self expressionalong with a flare for creation development and a very polished and exact product would infact make me a very valuable games designer/ ideas generator. Though i have noclue how to make it work,
Everyone wants to make a polished product. The key difference is not in who wants to make a polished product, but in who can deliver actually one in the real world within a reasonable time frame.
The gaming industry is a shitty career compared to other programming jobs in the industry.
Software programming is sometimes called "software engineering", but software engineering is more specifically used to refer to the process of managing a sofware project (checking in code to a central respoitory, doing builds in particular ways, scoping out what feature are wanted or needed etc.)
In truth there is not much "engineering" in software programming yet. We are still making it up as we go along. But at the same time what the OP is calling engineering is not really accurate. Engineering may utilize math but the process of engineering itself is a systematic way of creating technical things. Emphasis on the systematic.
Are people in the gaming industry engineers? Some are, many aren't. The people who deal with graphics generally need strong knowledge and ability with math. People dealing with QA or network stuff need a good grasp of engineering systematism. But the systematic approach that many engineering disciplines use are either somewhat straightforward or very well settled over decades and centuries of use. Software does not have that. Someone who designd the RPG system of a game needs none of that really.
Many people in the gaming industry are more like artists who happens to not be scared of math or logic. I have known many engineers who were also quite artistic. The two situations though are not analogous even though the two people may both be equally good at math and art.
Comments
As I said I'm not a game developer, so I have no experience in that field. Working with graphics probably involves a lot more maths, much more than databases. It depends on what field you plan to specify in....what I meant that programming in general is not based on math. As you don't have to be a doctor to be able to write a medical program you don't have to be a mathematician to write a math program. A programmer can write any type of programs if he gets a proper description of the task. Of course, as he becomes more experienced in the actual field he will need less detailed specification of the task.
Interesting reads. "It is what differentiates those who CREATE versus those who just IMITATE. " I have ran into this alot. Those who tend to be book smart lacking real creativity and those who are "average" by the normal grading scale exceling at creativity.
I do believe your articles touch on an interesting point that sometimes things can run together or utilize the same part of the brain. This could lead some one traditionally trained in engineering to be better at thinking through all the logical steps it could take to make a game and picking up on everything so that the game creation process could go more smoothly.
That now makes two possible positions for an engineer, a consultant or a designer.
I guess I am a bit lost with where you are going with the "proper description" At a certain point you would basically be force feeding the code to the programmer and they are more or less a translator, not the creator. I do agree with critical thinking being the greatest asset for a programmer. It appears common for programmers to have to figure out creative ways to program solutions to a problem and from the little programing I have dabbled in, it would seem there are a plethora of good and bad ways to get to the same answer.
For anyone who's interested Donald Knuth wrote about computer science's relation to mathematics.
Here's an excerpt...
http://mathdl.maa.org/images/upload_library/22/Ford/DonaldKnuth.pdf
There are certain queer times and occasions in this strange mixed affair we call life when a man takes this whole universe for a vast practical joke, though the wit thereof he but dimly discerns, and more than suspects that the joke is at nobody's expense but his own.
-- Herman Melville
Among amateurs, people who make games are those who have the interest, free time, aptitude, background knowledge, and dedication. People who have the interest but are missing one or more of the other components may try and fail to make games.
In order to get hired to make games professionally, you have to convince a company that you can do it. Having done it before is the best proof that you can do it, in which case, see who makes games among amateurs.
-----
Engineers typically take the introductory math courses at an undergraduate level, but don't go any further than that. That means a year of calculus, as well as multivariable calculus, linear algebra, and differential equations. Where I went for undergrad, computer science majors also had to take a stupid, cupcake math course called "Discrete Math", as well as their choice of either probability or something else (maybe number theory, but I'm not sure). Engineers presumably see some additional mathematics in courses that are within their major, but the math portion fo the math is likely to be glossed over.
Mathematicians will tend to see the most mathematics, of course. Physicists and statisticians will see quite a lot, too--and certainly more than engineers.
-----
Mechanical engineers, biomedical engineers, or most (all?) other types of engineers (or at least real engineers, as opposed to job titles that stick "engineer" in the name to make it sound more prestigious) have to deal extensively with the real world as it actually exists. The way that a game world works doesn't need to match the way that the real world works. In fact, it can't and shouldn't in many ways. Knowing how things actually work in real life may give you a default starting point that you'll almost immediately move away from in designing your game, but much of the training simply isn't relevant to game design.
That's incredibly important for a lot of engineering jobs, of course. You wouldn't want to drive across a bridge designed by someone who has no clue how strong the materials used are. But it also means that a ton of the training simply isn't relevant to a game world where you can magically make a bridge stay in place no matter what it is shaped like.
-----
If you know the mathematics that you need and have the aptitude, then you can pick up a computer language in a few weeks. That's not the big barrier to creating a game. Picking up the computer language isn't the same as being good at coding in it, which is why having the aptitude is tremendously important, and experience helps, too.
Learning the mathematics is entirely different, though. How much mathematics you need depends tremendously on what you want to do, but expect it to take years to learn it. How many years depends on what you want to do. The graphics engine is probably the most math-intensive part of a computer game, and for that, you absolutely need multivariable calculus and linear algebra to be able to do much of anything at all. Quite a bit of graduate-level mathematics is useful, too.
A good background in probability is also tremendously useful for game programming, and not just on the graphics side. A lot of engineers may see the really introductory stuff like problems with fair coins or dice or putting balls into boxes, and some standard distributions like a normal distribution and exponential distribution. But there's a lot beyond that that is also very helpful to know.
In many situations, it's not just whether you've seen some piece of mathematics in a course that you took and passed, but whether you're comfortable with doing explicit computations that are far more involved than would have been fair to assign for a homework problem. The same is true on the computer programming side of things, too.
-----
There are some things that you don't need to know ahead of time, but can pick up once you discover that you need them. But you'd better have enough of a background to have some idea of what is out there and where to look.
very cool link. Reading material for tonight!!!
I've been assisting at the university teaching Finance in the Eco department, but my heart will always be in gaming and programming. A lot of times I get jealous of the Comp Sci staff, they dabble in some very cool experiments
I will admit that I did not finish the whole article, but if some one wants to get the part that relates to the article read section 3. It is only about a page. To summarize it explains that to teach a computer something you have to have a better understanding of it and by coding it it helps you with abstract thinking. Basically his best line to sum it up is, "It has often been said that a person does not really understand something until he teaches it to someoneelse. Actuall a person does not really understand something until he can teach it to a computer"
Programming a game is mostly a matter of describing exactly how you want everything to work. There is also some optimization to make the game run fast rather than doing the same thing slowly.
There are some things that it is possible to describe exactly, but not practical to program a computer to do them. Just about anything from a Real Analysis course, for example. Computers, by their very nature, can only deal with finite, discrete things. But that's still quite a lot.
Well, first I would like to thank you for joining us in the new thread. Also thank you for another well written post. Now to the nitty-gritty!
First I enjoy your comment, "a stupid, cupcake math course". Secondly, I understand that computer worlds do not have to act like the real world, but for certain applications it could be very desirable to achieve something close. Now I personally do not think that if I had a programmer and told him to make a real world accurate bridge with materials, mass, wind resistance, sway or honestly anything that he would come close. On the other hand I do believe a mechanical engineer could do it, but most likely with code that is very lacking in structure. Now I think you state in your comment that it is easy to get code to do what you want but not to learn(understand) the math that say an engineer might know. So it might be plausible in this situation of wanting some kind of a realistic(why do we put hyper on the front? is hyper-realistic more realistic than real?) engine to show stress, strain, force, torsion and what have you on a bridge and to acctually show how it will fail.
Now as to avoid the argument that that would only be used in simulations, lets take rag doll effects into account. We have all seen the rag doll physics where the gentleman shot in the crotch until he died suddenly flies off to the moon because there was some kind of an angle calculation error. Now say we put a biomedical/mechanical engineer on this. They could tell you if the bone broke, how the forces would make his body turn, and that GRAVITY DICTATES THAT PEOPLE DO NOT FLY OFF TO THE MOON WHEN SHOT! More seriously though, it could make for interesting game mechanics to be able to calculate if a bone was broken from a shot or hammer hit, but again I am sure this could also be reduced to simplistic math of we say 5 bullets means a broken bone instead of if there is enough of the bone gone from bullets taking it away then the bone fails.
A final side comment on your part about graduate math I got a bit lost on what you were refering to, I suppose I am unfamiliar with the nuances of putting a ball in a box. lol :P
The problem is with how fast you want the game to run. Games invariably have to do a huge number of things where the justification is "it looks decent enough and it runs fast".
Collision detection is tricky. Find two irregularly shaped objects and hold one in each hand. Pick a direction for one of them to move such that it's obvious that the two objects would collide eventually. And then try to compute exactly how far the object would move before the collision takes place. No clue where to start? That's exactly the point. And you even have the huge advantage of intuition that the collision should take place somewhere around such and such. Computers don't have that.
If you have two objects that each consist of a hundred triangles each, that's ten thousand possible pairs of a triangle from each that could be the first to collide. If you want to use the graphical model for collision detection, then you've got to do some substantial computations ten thousand times per frame--and just for those two objects. If you have twenty objects moving around, you're looking at a little shy of two million tests to see if two triangles hit per frame. Good luck getting 60 frames per second, even if you don't have to do anything else but collision detection.
That's why, no matter what your character looks like, for physics purposes, you'll be a much simpler shape, and most likely a sphere, box, or cylinder. Why are those chosen? Because they make collision detection possible on hardware that actually exists.
-----
Let's talk about tessellation. The way it works is that you start by picking the surface that you want to draw. Ideally, it would be a manifold with boundary. There isn't a hard rule that it has to be, but that will tend to make your life easier. You can draw more complex surfaces by chaining together several manifolds with boundary, either along common boundaries or by something along the lines of a convex ear decomposition.
Next, you pick a triangulation of your manifold, that is, a simplicial manifold with boundary that is homeomorphic to your original manifold. This should have as few facets as is practical. For technical reasons, it is desirable that every facet should have at least one interior vertex.
Then you write your vertex shader. Mostly, this consists of determining the inner and outer tessellation levels for each edge and facet of your simplicial manifold with boundary. This should typically depend on the size of the object, its distance from the camera, and its curvature at various points.
Then you write your tessellation control shader (hull shader in DirectX). This asks you to choose the inner and outer tessellation levels for each facet of your simplicial manifold. Two facets that share an edge should have the same outer tessellation level at that edge for both of the facets. The way I do this is to determine a tessellation level at each vertex, and then make the outer tessellation level for an edge the greater of the tessellation levels at the two vertices, and the inner tessellation level at a facet the greatest of the three vertices. Tessellation levels at boundary vertices need to depend only on the boundary of your manifold if you want to attach another manifold at the boundary later.
Then this goes into the hardware tessellation stage, which is a fixed function stage, so you don't have to do anything.
Next comes the tessellation evaluation shader (domain shader in DirectX). The tessellation stage gives you a bunch of new vertices that it created by subdividing facets of your initial simplicial manifold. This is a topological subdivision, so which vertices form facets is already decided for you. But you're expected to pick the coordinates of where to put the vertices. That means you specify an explicit homeomorphism between the simplicial manifold with boundary that you used at the start and the manifold that you actually had in mind. You'll want an explicit parameterization of the latter, so you essentially have it as a parametric surface. (You'll probably need a parameterization for texture coordinates anyway, even if you're not doing tessellation.) The restriction of your homeomorphism to any facet should usually be a diffeomorphism, but this isn't absolutely essential.
At that point, you have a new simplicial manifold with boundary that is a topological subdivision of the one you originally put in, and when drawn, should look a like the manifold with boundary that you had in mind. Then you have the tessellation evaluation shader do whatever work you would have done in vertex shaders if you hadn't been using tessellation, and subsequent pipeline stages are exactly the same as if you hadn't done tessellation.
Now, you don't want to write a separate program for every single surface that you want to draw. So you need to come up with parameters that allow you to use the same program for a bunch of different surfaces that use different uniforms to make them look different. Rotations, translations, and dilations are pretty easy to do this way. Using the same program for two manifolds that aren't homeomorphic probably isn't going to end well. Checking homology groups is the quick way to tell whether two manifolds with boundary are homeomorphic; while it is possible to have two manifolds that have the same homology groups but are not homeomorphic, they're more complex than you'd want to try drawing all at once.
-----
So back to stuff that should be more readable to you. A typical engineer will probably never study the concept of a manifold, let alone a triangulation of a manifold, a topological subdivision of a simplicial complex, a homeomorphism between manifolds, or a lot of other stuff there. Furthermore, an engineer wouldn't even have the proper math background to pick up much of that even if so inclined. Try doing a Google search for "homeomorphism" and seeing if you can make sense of it.
If you have the appropriate math background, tessellation isn't hard to do. But if you don't? Then it probably won't take very long to figure out that it's not a good idea to try.
My experience with games has me believing that engineers need to stick to engineering, i.e. the tech behind the games. Games I have played where the lead programmer/designer has high technical skills, thing like "fun" and "ease of use" tend to suffer greatly.
On the flip side, games that are "developed" by very creative people who have no grasp on what is possible technically usually flop due to crippling bugs or poor performance.
A "third" side of the coin would also be either of the above who have zero business sense, and believe their awesome tech or great idea will sell itself.
"If MMORPG players were around when God said, "Let their be light" they'd have called the light gay, and plunged the universe back into darkness by squatting their nutsacks over it."
-Luke McKinney, The 7 Biggest Dick Moves in the History of Online Gaming
"In the end, SWG may have been more potential and promise than fulfilled expectation. But I'd rather work on something with great potential than on fulfilling a promise of mediocrity."
-Raph Koster
Im also a hardcore mmo gamer having played video games for the best part of my last 22 YEARS . I go back as far as the zxspectrum comny 64 amiga machines atari 2400 and this other odd system with nobs for controllers. I may have been younger. Ive pkayed all kinds if video games from real world vr systems, milirary vr systems and all the latest games. I have epic ideas for video games. Just require a brave gutsy studii like ccp to make it.
Video games require all kinds of disciplines to create. Networking Engineers, Software Engineers, Mathematicians, Artists, Writers, Designers, Programmers, Managers, Stakeholders, Network Administrators, Marketing, Project Coordinators, and often just general consultants (such as a few retired military guys for insight on squad tactics or whatever). I'm sure I missed all kinds, and I'm sure there are some people that will fill multiple roles.
You make me like charity
the other bit of confusion is that many people don't understand the difference between an engineer and an Engineer (big E). There are many people in the computing field that have job titles like "software engineer" but aren't actually certified, regulated Engineers.
In a way it's sort of like how anyone with a PHD is considered a Doctor, although it doesn't mean they have any understanding of medicine. Software engineers, for example, wouldn't technically be able to claim they are an Engineer.
You make me like charity
My CS degree was 90% math and physics, 10% programming. Don't learn computer science if you don't like math, someone should have told me that before I started.
I now do art school, a lot of it is science, from color theory to anatomy.
I don't really know of any degrees that don't involve science in a way.
Everyone wants to make a polished product. The key difference is not in who wants to make a polished product, but in who can deliver actually one in the real world within a reasonable time frame.
The gaming industry is a shitty career compared to other programming jobs in the industry.
Software programming is sometimes called "software engineering", but software engineering is more specifically used to refer to the process of managing a sofware project (checking in code to a central respoitory, doing builds in particular ways, scoping out what feature are wanted or needed etc.)
In truth there is not much "engineering" in software programming yet. We are still making it up as we go along. But at the same time what the OP is calling engineering is not really accurate. Engineering may utilize math but the process of engineering itself is a systematic way of creating technical things. Emphasis on the systematic.
Are people in the gaming industry engineers? Some are, many aren't. The people who deal with graphics generally need strong knowledge and ability with math. People dealing with QA or network stuff need a good grasp of engineering systematism. But the systematic approach that many engineering disciplines use are either somewhat straightforward or very well settled over decades and centuries of use. Software does not have that. Someone who designd the RPG system of a game needs none of that really.
Many people in the gaming industry are more like artists who happens to not be scared of math or logic. I have known many engineers who were also quite artistic. The two situations though are not analogous even though the two people may both be equally good at math and art.