| - once again thank you very much for the details - so let us say for purposes of learning, i wanted to make an fps or a third person shooter (3D) without using unreal, unity, godot or any popular engine out there - what does the process look like roughly? - i managed to get c++ running (programmer here with a decade of non gamedev experience) and also added raylib and looked into jolt physics - got a 3d grid constructed, window created, character model added - what would be my next bunch of steps? - should i add animations for each of the player states like walk, run etc? - should i program interactions like shoot, throw a grenade etc? - or should I start working on enemy AI like pathfinding A* algorithm with state machine? - trying to code cooperative mode here so i looked into c++ udp libraries like enet. I am assuming latency and game reconcillation algorithms would be step 1 if you want to build coop from ground up? basically create a server.cpp and a client.cpp and make the game loop work without crashing in cooperative mode on day 0. then worry about adding any interaction at all - truly trying to comprehend at a high level what day 0 to day 1000 of a game looks like |
Think about what your ultimate goal is:
- you want to make games: use an existing engine. don't bother with half of the features, focus on whether the game is fun or not. add polish (like character animation transitions) later. use stock assets to begin with.
- you want knowledge to work in games industry but not actually release a game yourself: learn all the bells and whistles of Unreal Engine
- you want to make things that are unlike regular games: develop your own code
- you don't ever intend to release a game, you just want to see how they're made: just read other people's code. Read the Quake engine source code and https://fabiensanglard.net/ as a companion site.
If you're talking about using raylib, that is also a game engine, just a simpler one. We can look in both directions; if this is an exercise exclusively for personal learning and development, why not also learn about what's done for you by that library and by the GPU, etc? Occlusion, rasterisation, depth buffering, perspective-correct texture mapping...
"the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity" https://prog21.dadgum.com/177.html
this is what game engines do - they abstract the essential complexity present in all games, and keep it from infecting the one-time object, your game.
If you want to learn about games, honestly, take a look at existing engines. Take a look at old engines like DOOM or Quake, or even http://cubeengine.com/ and http://sauerbraten.org/ (and their corresponding source code) -- they are very simple compared to modern FPS engines. The Cube engines render geometry using octrees rather than the traditional BSP or recursive portal approach.
Yes, if you intend to make a networked game, write your netcode first, share state with client(s) over a network protocol, even if the network is 127.0.0.0/8Netcode is its own area of study:
- https://developer.valvesoftware.com/wiki/Latency_Compensatin...
- https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
- https://github.com/0xFA11/MultiplayerNetworkingResources
Gamers have opinions about netcode, because it affects how they have to think in order to play the game, so netcode becomes as much a creative endeavour as the level design, graphics, etc.
Every area of endeavour you've mentioned is a fractal of timesuck. They all have their basics and then their advancements, that have been built up by thousands of people over decades.
If you are learning by doing, for god's sake, keep it simple. Make the simplest thing that works. If you're making an FPS, have static geometry and non-animated character models (a 2D sprite will do). Prioritise having the most basic thing working as your goal. Otherwise you will be off in the weeds for years and you'll probably give up having built nothing.
Pick a baseline (whether that's a game engine, or raw language) and then spend the rest of the time making the game: designing gameplay, levels, movement, interactivity, playtesting, feedback, placeholder art, real art... it's about standing on the shoulders of giants, not re-inventing the wheel, and putting your mind and creativity into the new thing, which is your game