It certainly can! Not an expert, but what you are describing can probably be done as a bullet shader.

> Doing that one will likely cause issues across a network or if framerate (or game tick rate) is unstable / unpredictable.

I kind of want to know if a seamless experience is possible without a server... but for now I assume there is one. At that point client frame rate / tick rate does not really matter. Each client sends current character position and origin + vector of all the bullets to the server. Note that current location of the bullets is not important to update the world state - only the origination point and direction. Based on that it can independently do all the hit calculations. Of course this makes cheating possible and any kind of latency extremely annoying, but margins of this post and my available coffee break time are too thin to offer my amateurish take on those problems.

Yes, the technical term for this is Euler integration: https://en.wikipedia.org/wiki/Euler_method

It's good enough for a lot of parts of a game simulation, especially if you have a fixed framerate. But it can get wonky if you have a lot of stuff moving around this way and interacting with each other. Full fledged physics engines in games tend to use more sophisticated algorithms to do the integration to avoid that.

> Bullet position = its origin, vector and then you can determine its location at any point in time, instead of updating its position at every tick.

Unfortunately, no. The linked blog post is a really cool way to think about simple animations but you will very often hit a wall (metaphorically and literally) where this technique no longer works.

The key problem is that the state of an object at time T depends on all possible interactions the object may have had before T. In the linked article, the only interactions are bouncing off walls, which are regular enough in time that you can model them analytically.

(But even in this trivial example, it still doesn't really work. Notice that if you resize your window, the DVD box jumps all over the place. That's because the analytic solution can't understand the notion of a window whose size changes. All it can do is calculate where the box would be now if the window had always been its current size. I digress.)

You can analytically calculate the position of a bullet at any time T given its origin and velocity, but only if the bullet doesn't interact with anything else. If you have, say, a human controller play that is running through the path of the bullet and gets hit, your simulation needs to understand that the bullet won't keep moving after that.

For a use case as simple as this, you may be able to model it statefully by just deleting the bullet entirely once it hits something. But, in general, there is always some level of state that you'll need in order to simulate anything beyond trivial complexity.