Thread: All of our games

I'm not stuck on the engine...I've been reading about different VSDs both mid-level and high-level. Also I've been reading a lot about the mathematics and linear algebra behind the engine. A better understanding of the math will eventually lead to a better implementation in code - IMO.

So far I've only purchased 2 books on actual math and one of them incorporates code into it. My next book will be simply about the math and perhaps physics - actually will probably be two books.

I've found some very good ways to do trees and other foliage w/o using billboarding and without storing tons of vertexes. Actually bushes will still be simple planes but trees will be stacked triangle fans with the 'point' of each fan having a positive y vector (with postive y being down in my arrangement of axes).

As for visibility determination I've decided to implement a combination of techniques. For outdoor scenes it will simpy be quadtrees and/or sectorization. For indoor scenes it will be portals and perhaps BSPs...if I can find a very good algo to populate the BSP w/o it breaking down to a linear search - I'm still working on this - part of it has to do with level design. As to how the engine knows if you are in an open area or an indoor area I will use portals...but in a different way. Essentially if the player has passed through one portal from outdoors to indoors then the VSD algo will be switched...althought the quadtree must still be used in case there are windows - aka more portals in the building.

The quadtree algo is extremely fast and the terrain algo that I'm still sketching out should allow for some very long distances to be rendered. I've looked at ROAM and another variation of it and I'm probably going to combine the best of both worlds. Combine this with some frustrum culling as well as object culling (determining if an object lies completely inside of, completely outside of or partially inside of the view frustrum.

I'm still hashing out the portal system but I like its advantages as opposed to a BSP. A good BSP would simply take me ages to compute - basically I must use each line or edge as the root and create a tree from it. Then I recurse the tree and track the amount of time it would theoretically take to render it. If it takes more time than previous ones...I discard that option and start over. This has to be repeated for every edge or wall in the scene or level. Eventually it will come up with the optimal BSP and write it to disk....but the design process is extremely slow. This is one way I've found to get an optimal BSP....but its very slow.

So I'm not stuck...I'm just researching so that I don't code myself into a corner later.

And on a side note I think that having each one of use code a portion of a much larger engine would be a better idea. For the actual game design and graphics we would defer that to artists and designers. I for one suck at game design but I love to code the engine portion. In any one game engine there are several sub-engines at work. Here are just some I can think of and each of these probably have sub-categories in them.

3D Graphics
Input
Sound
AI
Scripts
Storyline and/or flow (movies..cutscenes...etc)
Physics
Multiplayer
Storage (memory management)
Compression (if any)


You might think a storage engine sounds stupid but its not. The storage portion will manage the memory. Most APIs try to place everything in hardware...but there is not enough onboard RAM on sound or video cards to do that.

Another idea is to actually create COM interfaces for the engine. This would require programming the engine and its counterparts as COM objects. This would be the ideal case...but certainly not the easiest. There are books out there on COM and how to create COM objects.

I'm not stuck on the engine

Yeah but you're old(er)



Keep in mind most of us are really just kids. I'm only a senior in high school, davidp is a college freshmen, jverkoey is a junior in high school, and I am guessing hunter is young as well. It really does get to the point where building the engine exhausts all of our knowledge, and implementing things becomes a pain. My physics code is finally getting to the point that I am continually reading up on new topics just so I can understand what in the heck to implement. The accurate Runge-Kutta method of integration based on velocity is something that we haven't yet covered in my high school calculus class, subsequently I have to read up on that just to understand why my Euler method of integrating positions doesn't work properly.

However you should be able to solve the problem using vector notation for your objects and solving the equation using simple linear algebra.

No, you can't. You absolutely need to know calculus for this particular type of problem. And it isn't just 'knowing how to position objects'. You need to choose a fixed timestep for the physics, but you want your rendering to run ideally at the highest possible speed. The number of timesteps you run for the physics depends on the amount of time that passed. There were even problems in quake3 arena: people with higher framerates could jump slightly higher than people with lower framerates, getting into places they were not supposed to be able to. Even the doom3 engine is stopping its framerate at 60fps because of the fixed physics timestep (if it rendered more than 60 frames you would be seeing the same frames over and over again).

http://www.gamedev.net/community/for...opic_id=187209

I asked a guy who almost has a phd in aerospace engineering, and he told me the same thing about the timestep issue:

Now, on to the more badish news. That timefrac, the time per frame, is a non-fixed time step, which leads to difficulties. So, unfortunately, you're subject to the problems that others have somewhat solved using Verlet integration and fixed time steps. So, I hope you're not too crushed, .

at this thread on gamedev:
http://www.gamedev.net/community/for...opic_id=222564

and if you follow the rabbit hole to see how deep the problem goes you will find implementing 'fourth degree runge kutta', and this is the topic covered in the next chapter of my high school calculus text book

EDIT1:
let me give you a particularly nasty example of something to implement. A constant force produces constant acceleration. In a spring, the amount of force is a function of the amount it deviates from its resting position (Hooke's law).
So you've got two 'weights' on each end, their accelerations towards the center can be solved by the 'force' of the connecting spring. They accelerate towards the center, however the *instant* their positions change, so does the force connecting the two, and subsequently their accelerations also change, and their positions become the value of an integral. Now, this is easy to do if you program a *very* specific case and keep track of time that the springs act on the objects, but you have to have code that says 'this is a spring, act like a spring, etc'. But this is very very difficult to do in an arbitrary way with an arbitrary timestep.

(and technically, gravity is similar because it is inversely proportional to the square of the objects distances, i.e the force changes as you get close).

Engines should be programmed in a generalized way so you can setup almost any case, instead of saying 'this is a spring' you need to say 'this is a system of constraints, pivot points, and arbitrary forces, so let's come up with a method that can accurately estimate the positions of the objects that are acted upon by this system in such a way that even if there *is* an inaccuracy, this inaccuracy is the same on all systems and doesn't hurt anything'

That seems overly complicated, in my eyes.
I've always used this method and it works very well:

Code:

//Game loop
while (true)
{
int64 startTime = getTime(); //Use processor counter
 
//Render everything
 
//Update objects' positions
obj.xpos += obj.xvel * secondsPerFrame;
 
//Calculate seconds per frame
secondsPerFrame = (getTime()-startTime) / ticksPerSecond;
}

While not advanced, it works and performs well. For simple games, advanced techniques aren't neccessary.

Originally Posted by Shadow12345

The accurate Runge-Kutta method of integration based on velocity is something that we haven't yet covered in my high school calculus class, subsequently I have to read up on that just to understand why my Euler method of integrating positions doesn't work properly.

I see no need to use the Runge-Kutta method in simple game programming. I think you should concentrate on different aspects of game design. Because you are using very many steps (frames), any integration method should be sufficient.

I'm not talking about simple game programming, I'm talking about 3D games that use real physics, which is precisely the level that Bubba, david, jverkoey, myself and probably some other people on these boards are talking about. Again, your method fails for most realistic situations. That's just the way it is. Of course, you can cheat like a mofo just as long as it looks okay. I'm not saying everyone has to use all of this crap all of the time (like you said, for simple games). But if you ever want to get away from re-writing tetris you're going to have to learn it to represent physics.

EDIT:

//Update objects' positions
obj.xpos += obj.xvel * secondsPerFrame;

//Calculate seconds per frame
secondsPerFrame = (getTime()-startTime) / ticksPerSecond;

Again, how do you represent this for something like a spring? You can either use calculus or runge kutta or a simple euler integrator. And another thing, that 'secondsperframe' variable must be fixed for any robust physics simulation. Like I said, the physics timestep and rendering timestep can be different, like in doom3 (which is capped at 60hz for the rendering because that's the cap for physics).
EDIT1:
and you are again correct that not everybody needs to know how to do this stuff. I'm talking in the realm of how real professional games are made.