At the moment I'm trying to make an efficient and flexible movement system that I could use later on in a game. One part that's very important is the ability for the player to walk up steps/stairs. I thought about how I might do this, and came up with this:

Black = The level
Blue = The player
Red = c_trace
Basically, a c_trace acts as the feet of the player. It stops gravity from pulling him down when something is detected, and when something is detected, it checks the hit.z of the c_trace. If it's too close to the player, it moves the player up, making it so that he can walk up steps. The player's collision box stops him from moving if the step is too big. I got this working rather well, but then walking on slopes, while it worked, was very jittery and unnatural. I then tried it with 2 c_traces (one for walking on the ground, one for falling/jumping), which solved the slope problem, but now the player would walk up steps instantly rather than gradually moving up (things got weird otherwise), and overall it's probably very easy to break on complex terrain. Heck, I broke it simply by having a step that touches both the collision box, and the c_trace.

So my question is:
How does a system like this (climbing steps, walking on slopes) work on games like Quake? How might I do this with Lite-C (not exact code, but in general)? I'm simply stuck, and I want to solve this so I can use it for my games, rather than trying to work around it all the time.

Thank you!

Quake uses Axis Aligned Bounding Boxes (AABBs) to represent game objects in the collision engine. Basically, all objects are treated as cubes that do not rotate with the model, but instead stay oriented with the world axis.

At one point Gamestudio used this same system, but now it uses a combination of different systems depending upon what objects are being tested. When using the c_move() instruction to move an entity, ellipsoids are used to handle collisions between entities and world geometry, and OBBs (oriented bound boxes, which rotate with the model) are used when two entities collide with one another.

More info on this page:
http://www.conitec.net/beta/collision.htm

Needless to say the system is finicky and difficult to manage. Understand that unless you know exactly how to use this collision system to your advantage, you will end up with a sticky mess at the end of it. My advice: write your own robust collision system with the aid of the Gamestudio functions, or find someone willing to do it for you. But whatever you do, don't abuse the stock Gamestudio movement functions, or you will end up with something that is very difficult for you to control as a game designer.

Ah, this explains a lot.

If I were to do this, where would I start? How would I set it up so that a whole game can use it with flexibility?

I believe you can force c_move to use AABB collision.
As for the movement, I usually move the entity up before c_move and move it down afterward.
Something like this

After trying some movement systems, finally I ended using PhysX and PH_RIGID with PH_CAPSULE. You have nice collisions, and thanks to the capsule shape you can walk up steps. You don't even have to create your gravity system, just check when the player is on the ground and then being able to move using addvelcentral. If you want to check it out, my code is on AUM 101

Wouldn't this require the player to have an NVIDIA card?

no, PhysX works on all video cards, I have an Ati card for example, the only advantage is that you will have hardware acceleration with an nvidia card

I think I actually want to write my own, simple collision detection system. But, while I understand the basic concept of it, like what the game should do to fix a collision, what I don't know about is how I would make the bounding boxes, and then check if they're intersecting with any other ones in Lite-C. Can anyone give me a few hints? Thanks.

I think I might have what you need, but can you give me a bit more info of what you were thinking of? I wrote some collision code some time ago that would allow you to accurately perform 2D collision detection for entity vs. entity interactions and entity vs. square tile map interactions. It was written in Ansi C code so I would have to do a little tinkering to get it working in Gamestudio, but it works perfectly as long as you don't use it for anything other than those two things I mentioned above.

Well, I want to create 3D AABB collision detection, which I guess means your collision detection wouldn't work, and I think it would be interesting to make my own (but thanks for the offer!).

My plan:
Each entity would set it's bounding box (a rectangular prism) via a function I make, or just changing some skills, and then I would make a function for movement. The move function would use the bounding box to check if it's intersecting with another bounding box, or the level (not sure how I would do this, as c_intersect wouldn't work with the level, and c_trace only makes a line).
If it's intersecting, it would try fixing the problem, which could be done several ways (a simple solution would be moving to the previous position). I think I know how I would do gliding, but that's irrelevant at this point. I really just need help creating the bounding box. Is it possible for the engine to check if anything is inside a rectangular prism shaped area? I don't think c_scan would work.