timetocode

Do you want a vue ui mixed with Babylon.js, Three.js, PIXI.js, canvas, Webgl, etc? Or maybe just to store some variables... or make reactive changes? Here's how it works in a few of my games... There are 3 main points of integration. These are mutating state in the store (writing to a variable in the store), reading state from the store (accessing the store variables from other places), and reacting to changes in state (triggering a function when a value in the store changes).

First, how do you expose the store? Well you can literally just export it and then import it. Or be lazy and stick it on window.store. You'll want to have a sensible order of initialization when your game starts up so that you don't try to access the store before it exists. But games already use loaders etc to load up their images and sounds, so there's a place for that. Load up the store first, probably.

For reading state from the store you can use a syntax like store.getters['setttings/graphicsMode']. It can be a little simpler than that, but this shows the synatx for a store nested within a store. In my game for example, I have a gameStore and a settingsStore just because I didn't feel like putting *all* of the properties into one giant vuex config. One can also access the state via store.state.settingsStore.someProperty but this is reading it directly instead of uses the getter. You probably want to use the getter, because then you can have a computed property, but either will work. For writing state to the store, the key is store.dispatch. Syntax is like store.dispatch('devStore/toggleDeveloperMenu', optionalPayload). This is invoking the *action* which means you need to create actions instead of just using a setter with this particular syntax.

So that's reading and writing! But what about reactivity? Well lets say your game logic dispatches some state which enters the store, you'll find that if that state is displayed in your vue ui it is already reactive and working. For example if you store.dispatch('game/updateHitpoints', { hp: 50 }) and there's already ui to draw the hitpoint bar on the hud that is going to change automagically. But what if you're pressing buttons in your vue-based settings menu or game ui? How does one get the game itself to react to that? Well there are two some what easy ways (among a million homegrown options). The first is to use the window to dispatch an event from the same action that you use to update the state, and be sure that you always use the action instead of directly accessing the setter. This will work fine, and I did it at first, but there is a more elegant and integrated way. That is to use store.watch.

i’ve fallen behind on #froggyfall but maybe i can catch up!

I get hired to do performance work on node / javascript applications and I’ve had a little trick up my sleeve for about a decade that may be of use to some of y’all. I’ll be writing about node but the concept applies to a great many things. One can even measure across languages...

I discovered this trick partially by accident when I made a node game loop and experimented with setImmediate, nextTick, and setTimeout (nextTick can freeze an application indefinitely btw). The most interesting loop is the one using setImmediate, which in my case just incremented a counter by one and queued up the loop to run itself again infinitely.  As I watched the console scroll by counting the number of ticks, I came to a simple realization: these numbers that I was seeing were what it looked like for the event loop to count as fast as it possibly could, using 100% of the CPU resources allocated to it. Looking at the CPU usage confirmed this. setImmediate however *does not lock up the event loop* all it does is schedule work for the next tick. In fact, I would argue that setImmediate and nextTick are in fact transposed and misnamed in node or v8 or wherever it is that they actually live. I don’t think this is much of an argument, I’m pretty sure this is a known mistake but hopefully I’m not misremembering. IN ANY CASE; setImmediate spins as fast as it can but doesn’t interfere with other events. So one one can make a setImmediate loop and have it counting inside of an application that is already doing its job. What you’ll find is that the speed at which the setImmediate loop runs depends on how much other work is being done in that thread. And there we have it: a displacement profiler. You can change a piece of the application and run this profiler before and after and end up with a “volume” change in the CPU usage -- thus measuring something that was perhaps very elusive before.

I call the profiler by this name per the famous story about Archimedes. He was given a task about figuring out if a crown was made of solid gold and he wasn’t sure how he was gonna figure it out. At some point he was getting into a bathtub that was full to the brim and when he got in water spilled out everywhere... he realized that the amount of water that spilled out of the tub was equal to the volume of the part of his body that had entered the tub, exclaimed, “Eureka!” and ran through the street naked to tell everyone what he had figured out. He had realized that he could measure the volume of the crown, weigh it, and figure out what material it was made out of -- or at least compare it to solid gold which would be enough to answer the initial question. This same notion of volume or displacement applies to CPU usage and thus provides an alternative method of measuring performance (an alternative to a traditional profiler that measures the timings of functions).

Let me say that the CONCEPT is more interesting than the specifies. The idea of measuring the “space” available on the cpu outside an application’s workload instead of measuring the application workload itself is a potentially very different way of seeing things. I don’t recommend starting with it, do the obvious stuff first. But when things remain obscure after looking at the obvious stuff, consider this approach. A lot of applications these days are asynchronous monstrosities without a clear pipeline of work being done... instead it’s all evented i/o! Using a displacement profiler combined with a stress test one can really get a feel for the capacity of an application. One is not going to get the same answers by counting the milliseconds spent in the hot path functions and multiplying by that by the hypothetical number of users at launch time. ALSO if one expands the displacement to multiple threads (saturate them, ideally !) one can even measure the hidden load of the application -- e.g. what is happening out of the application’s main thread but still nevertheless consumes cpu on the machine, such as filesystem i/o or the cpu component of network i/o. We might not think of node or javascript as traditionally multithreaded, and it isn’t, but there are c++ threads or whatever doing stuff during a lot of the i/o and not measuring that (and only measuring the javascript) is going to cause problems when trying to figure out how much load a heavy i/o program can take.

Another thing to note about this technique is that data collected one day should not be compared to data collected another day or even much later in the same day. We may be measuring the displacement of an application, but we’re also measuring the displacement of  *everything* that uses CPU. And this is something that is pretty much constantly changing on most machines.

prompt: old book

Working on letting people use their own photos for https://jigsawpuzzles.io/

Some more voxel experiments. This is my first time getting one voxel to be a different color than another. Strictly speaking, I did not quite accomplish that. These were colored just by looking at the height of the vertexes -- the top layer green, then dirt colored, and finally something rockier down below. It would be much more interesting to step away from this globby noise generator, and then to color the surfaces based on making volumetric chunks of different materials instead of just coloring by height. That’s what I hope to work on next. Also probably some deformation. This marching cubes foray was inspired by Sebastian Lague’s “Coding Advenutre: Marching Cubes” https://www.youtube.com/watch?v=M3iI2l0ltbE . His project is in Unity and generates terrain (and noise) right in a compute shader. 

I took an essentially identical approach but due to the lack of a fancy engine I instead used the cpu to generate vertices, normals, and colors in ye old javascript before handing them to the gpu via webgl. Each chunk here evaluates 32x32x32 voxels and creates a mesh in ~30-40 ms (on a fairly fast computer). That’s too slow for realtime chunk generation on the main thread, though the workload is pretty perfect for using a webworker (it’s all math that produces a float array). After a chunk is generated it’s no problem to render; these particular chunks are so low poly that several of them were able to render at 60 fps on a chromebook with an integrated gpu. I’m pretty new to 3d, and I did not investigate whether Sebastian Lague’s shader could in fact be translated to glsl and run directly on the gpu even in a browser.

Many first person shooters are plagued by a netcode artifact known as the peeker’s advantage. I propose here a technique for correcting this bug, based around normalizing gameplay in such a way that human reflexes and skill decide the outcome of competition (as opposed to network latency or artifacts of varying netcode designs, discussed shortly).

When a player in a first person shooter is moving around the game world they exist in a position on their own game client that is slightly ahead of their position on the server. This is a solution/side-effect of clientside prediction which is ubiquitously used in first person shooters giving the player instantaneous movement and controls that feel like a single player game despite controlling a character that is moving around on a remote server. 

If we were to visualize the difference between the clientside player position and the serverside player position it would look like two characters chasing each other. How far apart the two characters are depends (in descending order of usual importance) on how fast movement is in the game, the latency of the player, and the tickrate of the server. But how big are these differences in the actual games of the current era? Are the two states of characters practically overlapping? Or is one several meters behind the other? The answer -- which varies by game and by internet connection -- is that the desynchronization between these two positions is significant. Over amazing internet connections in games with slow moving characters the desynchronization is usually on the order of 1 player length. So imagine any fps game character (valorant, cs:go, apex, overwatch, fortnite, cod, etc) -- and then imagine them creeping or walking around slowly. In this scenario the desync between the two states is such that one could picture the character being followed by its clone, touching. If they move *really* slowly then they’ll be overlapping. However as the characters break into a run their clone will trail them by more -- maybe 2-8 player lengths depending how fast characters are in the game. If a player has a high latency the clone will be ever farther behind in all scenarios except holding still.

Now when a player shoots their gun in all of the above games, the game engines will calculate the shot based on where the player perceives themselves. That means that as you play the game what you see is pretty much what you get. You don’t have to manually correct for lag while aiming in modern shooters -- just aim for the head right where you see it. However this introduces the peeker’s advantage. A defender can hold a corner with their crosshair primed to shoot anything that appears, but an attacker (the peeker) who comes around that corner is ahead of their server position and thus they get to a bit of extra time to "peek” and shoot at the defender before they themselves are visible to the defender. Depending on the actual amount of lag and the game itself the defender perceives themselves as either having been shot insanely quickly right as the attacker appeared, or maybe if the lag is not as bad they perceive themselves as having gotten to trade shots with the attacker, but ultimately they lost. The attacker perceives nothing special -- they just walked around the corner and shot the defender b/c they were playing aggressively and have superior reflexes (or so they think).

How big is the actual peekers advantage? Well it varies by game, but an article put out by Riot Games about Valorant goes into detail about how much the peeker’s advantage affects gameplay, and how their engine attempts to minimize it. It’s a great read: https://technology.riotgames.com/news/peeking-valorants-netcode. But to summarize, using 128 tick servers (very fast) 35 ms of internet latency (fast) and monitor refresh rates of 60 hz (standard) they calculate an advantage of 100 milliseconds after extensive optimization. That’s fast, but is it fast enough? Well back in 2003 I used to be a competitive Counterstrike 1.6 player at around the same time that I was obtaining a psychology degree with a particular interest in human perception (reaction time, how our eyes work, perception of subluminal images that are shown very quickly). I tested the reflexes of myself and all of my teammates. Competitive gaming didn’t have the same structure back then as it does now (everything has a ladder now -- back then it was private leagues), but by modern standards we were probably top 3% ladder players or something like that. Generally speaking there isn’t much of a speed difference in the whole pool of pro-gamers, at least when compared to new players. They are all pretty fast. Response time for watching a corner and clicking as you see a player (already perfectly lined up) fall into the range of 150-190 ms. Tasks that involve moving the crosshair to react quickly (as opposed to having had perfect placement already) slow that down another 50-150 ms. But generally speaking the competition between two similarly fast players with good crosshair placement comes down to very tiny units of time with even 10 ms producing an advantage that is measurable (both Riot and I agree about this). This means that had the server allowed for a double K.O. (which these games do not) we would find that in fact both players were very good and would’ve killed the other just 20-50 milliseconds apart. Valorant and CS:GO don’t work like that however, and instead the game essentially deletes the bullets from one of the players and leaves the other alive. Unfortunately this difference in human reflexes amongst competitive gamers is entirely gobbled up by 100 ms of peeker’s advantage -- meaning that at high skill levels the peeker will very often win and the defender will very often lose. So while the Riot article celebrates the success of engineering that allowed Riot to reduce the peeker’s advantage as much as they did, if you read the fine print you’ll find that the peeker’s advantage remains huge.

I don’t mean to pick on Riot, far from it. They’ve clearly done an amazing job. The other games I mentioned earlier are presumably in the same approximate ballpark, though I can tell you from personal experience that some of them are a fair margin worse. Not all of the games I mentioned use a 128 tick server (only one does). They also have longer interpolation delays and other little engine details that slow things down further. Riot is also an insane company that literally owns/builds the internet just to reduce latency for its players -- so if we want to take away a general sense of how bad the peeker’s advantage is in most games we should assume it to be worse than the scenario described above regarding Valorant.

Now that I’ve discussed at length the peeker’s advantage, allow me to present a related netcode model that attempts to solve these problems: The Peeker’s Compromise. If we delay the time of death on the serverside by the timing difference between the attacker and the victim, then we can allow the defender an equal opportunity to shoot the attacker. The server can then determine the winner (and the remaining damage) based on the performance of the human (instead of using the ~100 ms of engine-related advantage and internet latency). So let’s use some numbers for a hypothetical situation. Let’s say our game has 128 tick server, the players have 35 ms of latency, and 60 hz screens (like the Valoran example from earlier). Right as a player peeks another player they essentially get to shoot 100.6 ms sooner than their victim. As their shots arrive at the server the server might calculate that the victim has died -- but rather than killing the player it will keep them alive for 100.6 ms PLUS their own latency, which in this scenario puts the total at 135.6 ms. If during these 135.6 milliseconds the server receives shots where the defender hits the peeker, it will enter a section of code that attempts to settle this discrepancy. First off, it is entirely possible that after compensating each shot for the difference between the players we find out that one truly was faster than the other -- the game could use this information to decide which one lives and which one dies. It also might make sense to allow damage to legitimately trade kills and to build double K.O. situation into more first person shooters.

Let’s talk about the artifacts of this new and proposed system. In low-latency games with a high tick rate this change would be subtle -- we would just have no more peeker’s advantage. As latency increases all way up to 200 ms we will have a new artifact. Instead of having a more severe peeker’s advantage we’ll end up with a scenario where it looks as if players are taking 1-3 extra bullets beyond what would normally kill them -- although if you stop shooting early they still end up dead a few milliseconds later. The Vandal in Valorant (similar to the AK in cs:go) fires 9.75 shots per second, which is one bullet per 103 ms. So in a best case scenario the player death is delayed by the time it takes to fire one extra shot at full auto, and in a worse case scenario we add 1 bullet per added ~100 ms of waiting done by the engine. It would also make sense to cut off certain shots from being counted from a laggy player (existing systems already do this in their own way).

Gameplay at lower skill levels wouldn’t really be affected one way or the other. It isn’t affected much by the peeker’s advantage either -- players have to know where to aim and thus be involved in legitimate reflex test before we’re down to something so close that milliseconds of delay have an effect. If players are oblivious to each other, or place their crosshairs incorrectly as they come around a corner then the added slow down of the human having to make a new visual-search-decision-plus-adjustment is too slow for any of this to matter. But at higher skill levels there would be some actual changes to gameplay. The most significant change is that players would be able to hold corners -- and if they’re truly faster than the peeker they would win. In such a design it really would make much more sense to allow two players who fire at essentially the same time to kill each other which if adopted would need to be addressed at a game design level. Also games that had an alternate method of very indirectly addressing peeker’s advantage, such as weapon instability during movement as a major element (arma, h1z1, pubg, tarkov, etc), would have more options, and may need to tune existing timings to get the same feeling back.