- Forum
- General C++ Programming
- FPS game programming
FPS game programming
Hello, I have spent the last 2 years learning the DirectX 11 technology to build my own FPS video game, I can write a fully functional rendering system and a basic collision detection system, but I don't know how to build the FPS core in my engine, is there any minimal and simple FPS open source games out there that I can study and learn from? ( hopefully written in DirectX )
any engine is going to hide the directx calls.
if you want to write an engine .... you may use directx.
If you want to write a game, you use an engine, which hides what technology it uses behind its interface.
the good news is that if you use a dx engine, you can directly write to the screen yourself with your skills, and there may be a few places to do that better than the engine provides (eg, an overlay/hud).
Not sure what engines use directx. But I suspect you will be disappointed in how much the engine does for you and how little hands-on graphics you will be doing.
if you want to write an engine .... you may use directx.
If you want to write a game, you use an engine, which hides what technology it uses behind its interface.
the good news is that if you use a dx engine, you can directly write to the screen yourself with your skills, and there may be a few places to do that better than the engine provides (eg, an overlay/hud).
Not sure what engines use directx. But I suspect you will be disappointed in how much the engine does for you and how little hands-on graphics you will be doing.
@jonnin I don't think you understood what I said properly, I am actually writing that game engine that I am using to make my game, I am implementing all the engine specific stuff myself, what I need now is some resources that I can use to add the first person shooter functionality to the engine.
I quite certain you missed @jonnin's point, so I'll make it blunt if you'll take that in the spirit of an attempt to be helpful.
It makes no sense to write your own game engine in order to write a game. Not in the 21st century.
It is a great study. If you intend to work in the field making game engines, it is even necessary. It does help some to understand what an engine has to do.
Yet, what you've written thus far, dependent upon DirectX11, is already outdated for the rendering pipeline. You've only touched on the subject of physics, and perhaps you've dealt with audio and input, but there are other problems.
DirectX12 represents a huge break with a convention in rendering/GPU API going back to the early 80's. The GPU had always been treated as a "server" engine, on the other side of a barrier - like a remote controlled computer. It was built that way when OpenGL was invented, which is the origin of the modern GPU at SGI (the computer company).
AMD developed a new direction, but "handed over" the code to Khronos, which developed that into Vulkan. This new idea was the first to "unify" the GPU and CPU resources. DirectX12 did the same, as did Metal on Apple devices.
So, you make an engine. If you hard wire your engine to DirectX12, you will only ever make Windows 10 applications (and XBox). If you choose DirectX11, you can target slightly older Windows operating systems, but never anything else.
For several years now, the only reasonable approach to making a product for market, a game, is to use an existing game engine.
They support most (usually all the important) platforms from one body of code. Write on a Windows machine, target Android, iOS, MAC, Windows....even others. Support for those platforms on everything from older OpenGL API's to Metal on Apple are included.
You'll also get a physics engine - no small thing to build I assure you.
I've been at this a long, long time. I have, in the 80's and 90's, written game engine code directly to the hardware. I know the path you've taken.
I also know that somewhere after 2005/2007, it was a path with a dead end - if you're objective is to make games.
One of the simple reasons is that you'll never be able to keep up with all the changes in the API's that hit you hard. You can't expect to make a living on Windows games alone as an indie. You won't get a job in a game development studio without knowledge of at least one of the big 3 (or 4) game engines.
You might get a job working on a game engine, but that employment market has drastically changed.
There was a time when a game engine would cost over $100,000 to license.
None get fetch that price, now. Instead, they're "free", with some minor license fee (either a small % or a small monthly fee IF and when the product starts making money).
As such, at least two of these major engines are fully open source. You don't get a job working on such engines at this point. Not really. You may have a job at a firm that decides to contribute to such an engine.
Amazon is a short term exception to that (Lumberyard), but that's open source, too.
So, the days of hard work building a game engine is virtually history. Those engines are very capable, widely distributed and used, forming a kind of set of standards (loosely).
It would take years to start a new engine to catch up to any of them.
Any game built with a "personal" engine would not be able to compete with products built on one of the big 3.
Those are the themes of @jonnin's post.
I can't disagree.
It makes no sense to write your own game engine in order to write a game. Not in the 21st century.
It is a great study. If you intend to work in the field making game engines, it is even necessary. It does help some to understand what an engine has to do.
Yet, what you've written thus far, dependent upon DirectX11, is already outdated for the rendering pipeline. You've only touched on the subject of physics, and perhaps you've dealt with audio and input, but there are other problems.
DirectX12 represents a huge break with a convention in rendering/GPU API going back to the early 80's. The GPU had always been treated as a "server" engine, on the other side of a barrier - like a remote controlled computer. It was built that way when OpenGL was invented, which is the origin of the modern GPU at SGI (the computer company).
AMD developed a new direction, but "handed over" the code to Khronos, which developed that into Vulkan. This new idea was the first to "unify" the GPU and CPU resources. DirectX12 did the same, as did Metal on Apple devices.
So, you make an engine. If you hard wire your engine to DirectX12, you will only ever make Windows 10 applications (and XBox). If you choose DirectX11, you can target slightly older Windows operating systems, but never anything else.
For several years now, the only reasonable approach to making a product for market, a game, is to use an existing game engine.
They support most (usually all the important) platforms from one body of code. Write on a Windows machine, target Android, iOS, MAC, Windows....even others. Support for those platforms on everything from older OpenGL API's to Metal on Apple are included.
You'll also get a physics engine - no small thing to build I assure you.
I've been at this a long, long time. I have, in the 80's and 90's, written game engine code directly to the hardware. I know the path you've taken.
I also know that somewhere after 2005/2007, it was a path with a dead end - if you're objective is to make games.
One of the simple reasons is that you'll never be able to keep up with all the changes in the API's that hit you hard. You can't expect to make a living on Windows games alone as an indie. You won't get a job in a game development studio without knowledge of at least one of the big 3 (or 4) game engines.
You might get a job working on a game engine, but that employment market has drastically changed.
There was a time when a game engine would cost over $100,000 to license.
None get fetch that price, now. Instead, they're "free", with some minor license fee (either a small % or a small monthly fee IF and when the product starts making money).
As such, at least two of these major engines are fully open source. You don't get a job working on such engines at this point. Not really. You may have a job at a firm that decides to contribute to such an engine.
Amazon is a short term exception to that (Lumberyard), but that's open source, too.
So, the days of hard work building a game engine is virtually history. Those engines are very capable, widely distributed and used, forming a kind of set of standards (loosely).
It would take years to start a new engine to catch up to any of them.
Any game built with a "personal" engine would not be able to compete with products built on one of the big 3.
Those are the themes of @jonnin's post.
I can't disagree.
(Maybe DX11 isn't the best choice, but I think we can ignore that for now. OP just wants some pointers on how to start with FPS controls.)
However, you haven't given us a place to start from that anyone can really guide you from.
In what you have created so far,
• Do you have 3D perspective set up in you rendering system?
• What kind of windowing/event loop system you are using? (e.g. how do you handle capturing events like mouse movement, key presses, etc.)
• Can you track the current mouse position?
• Can you use the keys to move the camera/character?
For an FPS, you need the mouse to turn your player's camera.
You can use polar coordinate system for this:
https://en.wikipedia.org/wiki/Polar_coordinate_system
GLM (OpenGL mathematics library) also helps with this.
https://glm.g-truc.net/0.9.9/index.html
It provides functions such as LookAt, perspective
https://stackoverflow.com/questions/21830340/understanding-glmlookat
https://stackoverflow.com/questions/8115352/glmperspective-explanation
https://learnopengl.com/Getting-started/Camera
I know you said DirectX, but that library most just deals with matrix transformations for you, and matrices themselves are language-agnostic, so you should be able to use a lot of it...
As a last note, you'll probably be able to gather a bunch of information just by engine searching "directx fps controls C++" or something like that.
However, you haven't given us a place to start from that anyone can really guide you from.
In what you have created so far,
• Do you have 3D perspective set up in you rendering system?
• What kind of windowing/event loop system you are using? (e.g. how do you handle capturing events like mouse movement, key presses, etc.)
• Can you track the current mouse position?
• Can you use the keys to move the camera/character?
For an FPS, you need the mouse to turn your player's camera.
You can use polar coordinate system for this:
https://en.wikipedia.org/wiki/Polar_coordinate_system
GLM (OpenGL mathematics library) also helps with this.
https://glm.g-truc.net/0.9.9/index.html
It provides functions such as LookAt, perspective
https://stackoverflow.com/questions/21830340/understanding-glmlookat
https://stackoverflow.com/questions/8115352/glmperspective-explanation
https://learnopengl.com/Getting-started/Camera
I know you said DirectX, but that library most just deals with matrix transformations for you, and matrices themselves are language-agnostic, so you should be able to use a lot of it...
As a last note, you'll probably be able to gather a bunch of information just by engine searching "directx fps controls C++" or something like that.
Last edited on
if you are going to do your own engine, the most basic fps is simply straight lines of impact. That is, can you draw a straight line from point of shot to point of impact? If so, its a hit. You can get fancy about which surface it hit and what that means. You can add gravity and air resist or a max range / vanishing bullet concept. You can randomize the point of shot a bit to simulate shooter's uncontrollable movements. You can check if something is between the shot and target, blocking the shot. This is hitscan approach; if you want to have a delay between shot and impact, you have to move the target in the time between, which is a bit more complex.
If you can support those ideas, you have the basics. Granted, its wolf3d basics, but its a starting point.
then your graphics engine has to have artwork and support for the impact ... something falling over or sprouting a hole or explosions or whatever.
It was true in 1990 and its true today... cheating where you can is faster than computing all the complex stuff. if you want to have air resistance and gravity and a rotating earth and wind and .... it gets ugly fast. If you just want a straight line laser beam hitscan, its much easier. Today's boxes CAN handle the fancy stuff, but its still more FPS (frames/sec here) not to!
I only did a little 3d graphics, but to echo above, .. all the older directx did was draw on the screen. It did that really well, in an era when everything else had to think about it (go thru software layers) before writing to the screen buffer it just did it straight up. That made it king for a while.
If you can support those ideas, you have the basics. Granted, its wolf3d basics, but its a starting point.
then your graphics engine has to have artwork and support for the impact ... something falling over or sprouting a hole or explosions or whatever.
It was true in 1990 and its true today... cheating where you can is faster than computing all the complex stuff. if you want to have air resistance and gravity and a rotating earth and wind and .... it gets ugly fast. If you just want a straight line laser beam hitscan, its much easier. Today's boxes CAN handle the fancy stuff, but its still more FPS (frames/sec here) not to!
I only did a little 3d graphics, but to echo above, .. all the older directx did was draw on the screen. It did that really well, in an era when everything else had to think about it (go thru software layers) before writing to the screen buffer it just did it straight up. That made it king for a while.
Last edited on
| it gets ugly fast |
...and even before we get to something like wind changing a bullet's trajectory.
Shoot at a can, it has to fall. It has to hit the ground, possibly bounce and roll. That small step up from merely marking where bullets strike immediately bring the entire basic newtonian physics model, with a full fledged collision model into play, without even getting into the issue of speed vs collision (when that fails, bullets pass through walls and objects without notice).
As one who has worked on such physics engine software, I can tell you it gets ugly if you define that as complicated and detailed. It can take a year or more to get one right from start to functional. The good ones available now (for free, BTW) have been about a decade (or more) in development.
yea. I did physics sim / flight sim, just sans graphics (or on one or two occasion, cartoony canned graphics tied to the engine, very crude). And I do ballistics on occasion, to get the powder charge right or the like.
canned flop animations were used for decades and would be OK to start out though.
Physics in many games have some errors, gamers be used to it. They are usually extremely funny.
canned flop animations were used for decades and would be OK to start out though.
Physics in many games have some errors, gamers be used to it. They are usually extremely funny.
Last edited on
Topic archived. No new replies allowed.