So... Here's the problem.
You (people at blog.openreplay) submit soooo much content (and much of it with dubious quality, I'm sad to say) that there's even someone who simply downvotes anything coming from that site. (No, it's not me, but I do understand the sentiment)
And so you now submit something that is, I'd guess, revelant to you, and it is immediately downvoted.
You lose because the content that you really wanted to get attention, doesn't. Readers here lose because they get a lot of low quality links and miss actual news.
Everybody loses. Sad, but predictable.
I know this is old, so I don't know if you're willing to go back and make modifications...
...but, while it is nicely done, I think it could be better with a very minor addition: a shadow.
When the runner jumps you lose too much information over where we are in reference to the ground. That is, it's weirdly hard to appreciate how high exactly we are at a given moment and how far we still have got. A small shadow would give such information and allow for the player to have a better reference of where they are going to fall.
----
Less important, but I'll mention it anyway, would be making the tunnel a bit longer :)
Second link about the Builder pattern in a few days. And neither is very good, I'm afraid.
Neither seems to explain the goal correctly.
The other one, the Youtube video, pretends that the pattern helps with argument order/meaning. It's somewhat funny since they are using VSCode in their video and Intellisense is clearly telling them what each parameter is everytime they try to call a function.
This one presents the building as a very *inflexible* process. That is, it argues that various builders need to implement exactly the same methods. This would negate the most important advantage of the builder pattern: That it can accommodate building different variants of an object.
Another problem is that the examples used in both cases are inadequate. In the video because it completely misses the point. In this article because it doesn't present any complexity at all; the difference Car vs Truck is simply the value of the number of doors.
----
The truth is that the need for the builder pattern in JavaScript is fairly limited.
The problem "solved" in the video would be much better serviced by simply using named arguments, which in JS you do by using an object and is a very common idiom. The problem solved in this article is... inexistent; it solves no problem at all. It would be much better written by having something like:
function Car() {
this.doors = 4;
this.say = ...;
}
function Truck() {
this.doors = 2;
this.say = ...;
}
...and simply forgetting about the Shop and the *Builder functions.
----
What the builder pattern can help with in JavaScript is the case were you do need to build complex objects which accommodate for different variants.
That is, taking the example of the car, you might need to build various cars. A car may be a coupe or a sedan; it may have different motor configurations, styling, equipment...
You don't want client code to always contain all the specific details implied by each of those choices. Instead, you want to be able to do something like this:
const sportsCar = new CarBuilder()
.coupe()
.sportsMotor()
.colour('red')
.build();
const familyCar = new CarBuilder()
.sedan()
.electricMotor()
.build();
And in both cases you get a Car. And maybe calling coupe() only means having 2 doors, but more likely it also implies some additional setting. And choosing electricMotor() can mean something complex like doing a `new ElectricMotor()` but also installing batteries and an additional panel in the controls or whatever. And you need not do the exact same steps; you might not need to select a colour and just accept the default one.
That is what the Builder pattern is best suited for. It's also the only usage that really makes sense to apply it in JavaScript.
Please, do read the final part of the comment.
1. Bad name. There's already a thing called Spark in the realm of databases.
2. This is a site focused on JavaScript. Your code is Java.
3. You claim this to be a "replacement for SQL" but this is very obviously not that. It manages a *single* table. Sure, you could have multiple instances, each one with a different table, but still there's no way to establish relationships between them. It only does a tiny small part of what SQL does.
4. The code is... well, not really that good. Some places seem to completely ignore any performance concerns, like making a complete copy of the contents of the table on each query to then remove the non-matching rows. And that's just *one* of the problems. The naming is fairly dubious. Some of the decisions are difficult to justify -e.g. you can't select all, you're required to put some condition. The approach of first copying `iter` number of elements and then filtering means you can end up having the asked number of rows in the table matching but your code will return fewer rows. There's no testing. There are no filter operators.
---
I don't want to sound rude or to be too harsh on your code. More importantly, I wouldn't want to discourage you from trying, from going on coding, of course.
But you're sending this code to various sites and forum with a title that is simply too "ambitious", too grandiose, making unjustified bold claims for something which is fairly basic. And that... well, it doesn't help anyone, even yourself. You could get more eyes on your code and more help getting better, if you presented this as what it really is.
As it is presented, I'm afraid most people will simply ignore it.
Whatever you think this should be doing, it isn't doing it correctly. There's just a spinner with "Connecting ..." below it and it never does anything.
There is a warning message in the console that says...
`enable` method has been called while MetaMask is not available or synchronising. Nothing will be done in this case.
...so *probably* there's something wrong in your code, maybe in the way/order it's packed or loaded or maybe it's missing stuff.
Second link about the Builder pattern in a few days. And neither is very good, I'm afraid. Neither seems to explain the goal correctly. The other one, the Youtube video, pretends that the pattern helps with argument order/meaning. It's somewhat funny since they are using VSCode in their video and Intellisense is clearly telling them what each parameter is everytime they try to call a function. This one presents the building as a very *inflexible* process. That is, it argues that various builders need to implement exactly the same methods. This would negate the most important advantage of the builder pattern: That it can accommodate building different variants of an object. Another problem is that the examples used in both cases are inadequate. In the video because it completely misses the point. In this article because it doesn't present any complexity at all; the difference Car vs Truck is simply the value of the number of doors. ---- The truth is that the need for the builder pattern in JavaScript is fairly limited. The problem "solved" in the video would be much better serviced by simply using named arguments, which in JS you do by using an object and is a very common idiom. The problem solved in this article is... inexistent; it solves no problem at all. It would be much better written by having something like: function Car() { this.doors = 4; this.say = ...; } function Truck() { this.doors = 2; this.say = ...; } ...and simply forgetting about the Shop and the *Builder functions. ---- What the builder pattern can help with in JavaScript is the case were you do need to build complex objects which accommodate for different variants. That is, taking the example of the car, you might need to build various cars. A car may be a coupe or a sedan; it may have different motor configurations, styling, equipment... You don't want client code to always contain all the specific details implied by each of those choices. Instead, you want to be able to do something like this: const sportsCar = new CarBuilder() .coupe() .sportsMotor() .colour('red') .build(); const familyCar = new CarBuilder() .sedan() .electricMotor() .build(); And in both cases you get a Car. And maybe calling coupe() only means having 2 doors, but more likely it also implies some additional setting. And choosing electricMotor() can mean something complex like doing a `new ElectricMotor()` but also installing batteries and an additional panel in the controls or whatever. And you need not do the exact same steps; you might not need to select a colour and just accept the default one. That is what the Builder pattern is best suited for. It's also the only usage that really makes sense to apply it in JavaScript.Whatever you think this should be doing, it isn't doing it correctly. There's just a spinner with "Connecting ..." below it and it never does anything. There is a warning message in the console that says... `enable` method has been called while MetaMask is not available or synchronising. Nothing will be done in this case. ...so *probably* there's something wrong in your code, maybe in the way/order it's packed or loaded or maybe it's missing stuff.