The first ideas of this 3D road game was created in just 140 characters (or less) and posted here (Dwitter) by him (Frank Force's nickname is "KilledByAPixel"):
https://www.dwitter.net/h/road
And many other tiny 3D effects and engines in JavaScript were created by Dwitter's users, like these demos: https://www.dwitter.net/h/d3
Just wanted to add... Dwitter is awesome for learning stuff like this, since everything is so absurdly small you know the ceiling of time required for understanding a dweet is pretty low - yet at the same time it's surprising how advanced techniques can get in this tiny space.
This makes them so tempting. I sometimes struggle to pick up or return to a technical book when work/life etc gets busy, but when someone posts an interesting new dweet I often can't stop myself from pulling it to pieces.
You could get the minified code size lower with a few tricks below. This allows the minifier to stop using the longer method names. It also has the benefit of eliminating an object property lookup which is significantly slower than accessing a variable (under a microscope of course, if called many times). Probably 5-10% savings by doing this for the Math methods.
1. Create variables for any global/builtins (setTimeout/clearTimeout, requestAnimationFrame, etc) at the top of the file.
2. Create variables for global object properties, especially if used multiple times or they have longer names (Object.assign, Object.hasOwnProperty, Math.cos, Math.sin , JSON.stringify).
3. For non globals, within functions, create variables for any object properties or methods that are called multiple times to be worth it; like in formulas where obj.width/height is called 4-5 times, the minifier can't optimize the property name.
4. For Class instance methods that don't allow creating variables for methods (You have to call the method with the class, since they operate on "this" context) but don't have anything unique about "this", you can create a variable once within a function, then just bind itself. If you are using it multiple times to be worth it.
and (in the minified code) used as Z() instead of X.classMethod()
5. In longer functions that use "this.whatever" many times, you can create a variable once for "this" (t or _this etc) and the minifier will be able to eliminate those bytes.
Lots of counterintuitive observations when you realize the objective is for compressed 2k size, which means that duplicate code is actually a good thing!
I absolutely love projects like this. It's so interesting working within these constraints.
So, js1k is not continuing? On the js1k site I can't see anything stating this. Nothing on the subreddit either. Where is that information coming from?
It's a real shame that this great tradition may not continue, though, perhaps the js2k+ will be the next big thing ;)
Not sure about the 2k+zip, but I do think that there will be a LOT of progress in wasm+canvas for interactive programming... of course this leaves out accessibility, so hopefully it's done with some constraint depending on the space.
I love these projects, but writing statements like "full HD" and "Realistic driving physics and collisions" is a bit too much unless it is tongue-in-cheek :)
It's "high definition". Since the graphics are all vector graphics, it doesn't seem to be too far of a stretch. All the rendering will be done at the resolution available.
Do you have an HD monitor? If so the game is in HD. Many tiny games and demos like this are rendered to a smaller canvas and will either not stretch to fill your monitor or are rendered at a lower then HD resolution.
When people use that term for games, it usually means the assets have been reworked to look better.
In this case, I guess that would be the procedural generation of the background and trees, for instance, to give it better quality than simple triangles.
I haven't either but as someone who plays games occasionally, the definition makes sense to me (lots of games don't scale well). Definitely not something I'd have guessed, though.
In the original article, the author claims that lots of repeated strings turn out to be beneficial insofar as they make compression (gzip or whatever) more effective. According to him, it doesn't make sense to manually de-redundantize code when the compressor will achieve the same gain or better.
I was about to say "well, it's probably a lot of work to verify that s isn't already a mangled variable name" but then I realized that doing what you suggested in the pre-minified code should work, yeah.
So not only are you right, it's actually super easy. Just do this at the top level of your code:
You could do that, but it would not compress as well. For example the word const is not use anywhere in the 2k version, while Math. is used about 40 times so it becomes essentially free when compressed.
> For example the word const is not use anywhere in the 2k version, while Math. is used about 40 times so it becomes essentially free when compressed.
Except that the word const does seem to be used in the uncompressed version, so we don't know what happens during compression in the Closure compiler, no? Or is the 2k version pre-Closure compiler different from the uncompressed version?
Either way the only way to know is to try because asymptotically free is all well and good, but without measurement we don't know the actual behavior in practice and we are just making assumptions about how well or how badly things compress and how the mangling process works out.
Ok, I just tried it. Removing every Math. and adding let{cos,sin,PI,min,max,tan,atan2,abs,ceil}=Math; to the top. It worked better then I expected, though it is still 1 byte larger then without. Could potentially be a win in some situations.
That's actually pretty cool, because together with your earlier remark of ~40x occurrences of Math.<whatever> that means we have a ballpark figure for where the tipping point is!
Absolutely. It took a long time for everyone to catch up on basic features (Closure had modules figured out while the rest of the JS community still had several competing standards), but it’s still tremendously effective.
The only downside is the compiler itself runs on the JVM, and most developers ostensibly prefer a single platform. Given how much other software you need to make a development environment work, this seems silly to me.
A real downside and the reason it never took off, is that you have to annotate all your Javascript code to really leverage the Closure compiler.
Google also doesn't really advertised the use of Closure, you have to go out of your way to find it in their developer website or google it to find it. It's really just an internal tool.
They break backwards compatibility in the Closure Library so much that projects that adopted Closure (like Clojurescript), are stuck with a library from 2017. The project is maintained only to serve Google.
> They break backwards compatibility in the Closure Library so much that projects that adopted Closure (like Clojurescript), are stuck with a library from 2017. The project is maintained only to serve Google.
Is that the case? The current version of ClojureScript depends on org.clojure.google-closure-library 0.0-20191016 – I know it's a fork, but I'm not sure to what extent it is being synced with upstream.
In the final, minified code there's a lot of calls to Math methods (sin, cos, tan). I wonder if there's potential to shrink this even more with some assignments:
As far as I know minifiers don't do this since it changes semantics. Take this for example:
// 1
doSomething();
console.log(Math.sin(2));
// 2
var s = Math.sin;
doSomething();
console.log(s(2));
Now, consider this definition for `doSomething()`:
function doSomething() {
Math.sin = x => x
}
Now, the first prints 2 and the second snippet prints 0.9092.
Keeping track of globals to get around this is complicated. Even if you do, you can't always be sure the behaviour of the code isn't changing since `doSomething` could be defined in a module your minifier doesn't know about.
I don't want to hate on the creation at all but its hard not to sound like that in text.
On commodore 64 games tried to have nice graphics, nice music and interesting mechanics. Lots of games failed at 1 of the 3. Sometimes they did really well with the other challenges but with few exceptions it doesn't make up for it.
I think if 2 kb is the challenge the game mechanics are the best hope to make up for the lack of sound and visuals.
Reminds me of burning rubber. A game with truly ugly graphics and terrible music that is quite hilarious to play.
Could you help us understand how it's not ray casting? OP doesn't mean ray tracing by the way. Ray casting is the tech used in Wolf3D for example, or maybe I'm preaching to the choir.
With ray casting engines for each column of pixels you cast a ray and collide it against world geometry to see what it hit and where.
With this engine, and most modern 3d engines you apply a transform to 3d world space points to get a screen space point. You also need to sort objects by distance or use a z buffer.
While true, you do have to ask how the hell there could possibly be 100 MB of just code.
Consider Windows calculator. In Windows 10, it consumes 15+ MB of RAM. When desktops have 8+ GB of RAM, 15 MB is essentially nothing. And yet, 15 MB is an astronomical amount of RAM considering the functionality Calculator offers. There's really no reason it should be more than a couple hundred kilobytes.
I didn't have a look at the code but the binaries aren't just code. Apart from things like embedded icons and stuff, there can be lots of engine embedded resources inside;
There is a reason for that, which is that UE4 has an absolutely massive amount of features out-of-the-box compared to most other engines.
If you were to add all the stuff from the Unity marketplace you need to be equivalent to a base UE4 install, it would probably approach that size as well, presuming all those features were even available.
My non-expert opinion is that the size of most game installs is tied directly to the amount of voiced dialog in the game, and in a similar context, how many languages that voiced dialog has been translated and included in the install.
