[gifman]

Very few questions are stupid, these are not.

Yes, you can definitely build an entire fps game using WebGL for rendering. Typically using JavaScript to handle physics, collision, gameplay, etc.

My current WebGL project is rendering high definition terrain, high-poly animated models, thousands of particles, shaders, sound and more over 150 frames-per-second on a 10 year old PC with a RTX 3060. I have found hardware acceleration is often not enabled in the browser, or Windows will default to using the integrated-graphics card when running the browser and that must be changed in the Windows Graphics Settings.

WebGL is a graphics API for talking right to the graphics card, supported by The Browser. ThreeJS and BabylonJS are libraries that make it easier to render 2D and 3D graphics, both use WebGL and/or WebGPU behind the scenes for rendering.

Development with HTML/CSS/JavaScript and WebGL is my favorite stack to work with. Development is fast, re-loading is quick, errors and debugging is handled directly in the browsers which have great debug information and performance tracking. No compile time and support on lots of devices.

Yes, OpenGL came first. WebGL is a JavaScript binding of a subset of OpenGL functionalities.

[vivzkestrel]

- first of all thank you very much for the detailed insight

- as a guy who is very much new to gamedev, threejs etc but not to programming (have a decade of programming experience on backends, android apps etc) i am running into lots of questions as i try to build a mental model of what game dev process looks like

- let us say i wanted to add a player 3d model into this setup, the player can walk, run, crouch, shoot, throw a grenade, go prone, take cover to the wall etc. how do these animations get implemented? what kind of tools are needed for making these animations

- i read that the technique used is called skeletal animation. how are you supposed to think about this? you press w, the character moves forward. in terms of animation that means your character needs to play the standing at one place animation initially and transition to the walking animation as long as the w button is pressed. now you press shift and this walking animation needs to transition to running animation as long as shift is pressed. is this the right way to think about this?

- do we need intermediate animations like "transition from walk to run", "transition from run to walk", "transition from walk to crouch" etc? that would add a lot of states would it not?

- are there LLM tools that you are aware of that are capable of generating these animations?

- i also read there are different file formats like obj, fbx, m3d, glb etc. is the same data stored in these files in a slightly different way like csv vs json or are they completely different?

[amiga386]

    what kind of tools are needed for making these animations

They are motion-captured and/or they're animated by hand in your 3D editor, e.g. Blender

But much more likely is you won't be making animations, you'll be buying them (or getting them for free). There are many places you can buy these animations already, already rigged to a skeleton.

Some examples (I don't endorse them specifically):

https://characters3d.com/

https://www.unrealengine.com/en-US/blog/game-animation-sampl...

    skeletal animation. how are you supposed to think about this

Think about giving direction to an actor. You give high-level instructions to the animation system, and it picks the animation based on rules about what animation to use in what situation, that you already set up. It manages the transition to the next animation, all of which are animations of the skeleton, that the character model adapts to (including physics-based parts of the character like hair and cloth)

Generally speaking, you define animation cycles (e.g. walk cycle, run cycle), and then transition between two different animations that are in phase with each other, but it can be a lot more complicated in order to look more natural.

Unity has the Animation Controller. Unreal has "Motion Matching". Godot has Animation Trees.

     do we need intermediate animations

If you want to, yes, but also you can have the game engine interpolate

You haven't even mentioned things like having the character's feet stand realisticly on non-level ground. For that you would use inverse kinematics, but not too much of it because it has a tendancy to go wonky

    are there LLM tools

Yes but you'd be better off with animations someone has already created, they tend to look better. Many companies now offering AI-based 3D character generators too.

    formats like obj, fbx, m3d, glb etc. the same data stored in these files in a slightly different way

They all have different purposes. You want glTF/glB (same format but in text vs binary) for most purposes

Try out this FPS game project for the Godot Engine: https://github.com/godotengine/tps-demo

[vivzkestrel]

- 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

[amiga386]

You'd be committing the classic fallacy of "i'll just work on these tools, then make the game", which while a fun exercise, almost never results in a game being released.

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.

     I am assuming latency and game reconcillation algorithms would be step 1

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/8

Netcode 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.

    what day 0 to day 1000 of a game looks like

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

[Bewelge]

> Development with HTML/CSS/JavaScript and WebGL is my favorite stack to work with.

I love this myself, but..

> have great debug information

How do you debug WebGL stuff? I find that to be one of the least debuggable things I've ever done with computers. If there's multiple shaders feeding into one another, the best I can usually come up with is drawing the intermediate results to screen and debugging visually. Haven't been paying too much attention to the space the past 2-3 years though, so I'm wondering if some new tools emerged that make this easier.

[gifman]

The JavaScript debugging is great right out of The Browser these days.

WebGL debugging... it's a combination of how you're doing it, visually, especially for shader-related issues. For API calls, logging gets most things figured out, there is also this: https://github.com/KhronosGroup/WebGLDeveloperTools