After a long break, I got back on track. Today I watched 40 more minutes of content, split between the usual ElasticSearch course and a new one, called GatsbyJS: Getting Started. I'm not new to GatsbyJS, but skimming through the first two sections of the course vastly helped me to get up to speed with where I left off last time.

Today I went on and got to a point where I instantiate each hexagon independently. Such a feature lets me build the game grid not as a sheet of sprites, but as a grid of objects instead. This ultimately leads to the ability to store the grid data (technically, a level) as a 2d array. Even though serializing the latter is not a priority, now it has become a feasible possibility.
The new tile sprite didn't inspire me enough. Next time I'm gonna think it through and replace it with something different. Till then, good night! 🌖

As I expected, sprite-based tiles look a hundred times better than those plain, blurry black lines I had before. The visual style has nothing in common with what I had in mind at the start, but I'm kind of exploring ATM.
Who knows what's gonna come next.

Asides from tuning the edge pan velocity, the only thing I did today was scaling down the resolution. The manually drawn grid cells create all sorts of artifacts now, but I'm sure that, as soon as I switch to sprite tiles, everything will look alright.
Tip of the day: you wanna save yourself some headaches? Remember to set imageSmoothingEnabled to false every time you resize the canvas!
That's all for today. Next up: play/pause state; basic tiling.

Unfortunately, it looks like the native drawImage method, which I much-praised last time, also acts as a bottleneck to the whole application. I'll surely need to cut the resolution to a fraction of the window size, probably to a fixed one. On the bright side, that's not a big deal, given how young the project is.
Speaking of bright sides, I've finally got to the point where I move the camera instead of the grid. Borrowing some code from my past self sped that up a lot.
Next up: lower resolution; pause/play states.

After careful analysis, I concluded that my old approach to canvas drawing is not outdated at all. Outputting the view to a sub-context first is the way to go. Back in the days, I thought it was a super-duper way of upscaling the game, but it turns out that this cheap trick performs equally well with downscaling matters too. Not only that, but it's also crazy fast to set up and at executing, all thanks to the drawImage method of the CanvasRenderingContext2D, which also accepts an HTMLCanvasElement as the image source.
However, once the sub-canvas gets five times the size of the screen, things start to get laggy. Apparently, 500MB worth of image data is too much for a realtime simulation. I'll someday optimize it.
In the end, I haven't met last time's goal yet, but I'll put it off for today. I guess a good night sleep is more important 😉

To my surprise, I had time today. Hence, I went on and managed to meet the goals I set last time.
Linear edge panning is now a thing, which means that the closer the cursor gets to the edge of the screen, the faster the camera moves. Instead of resorting to fixed steps of ever-narrowing bands, I plugged in a swappable easing function and called it a day.
The zoom got me thinking, though. In my previous experiments, I didn't have to deal with big viewports. All my games used to have a fixed--and pretty low--resolution, so adapting the view to the browser windows size was a matter of drawing to an offscreen canvas, reading its content back, and upscaling it in the process.
This time around, I went for a strange middleware-ish solution where the camera multiplies all the coordinates it receives based on its zoom, but it doesn't thrill me whatsoever. I'll probably revisit it sometime soon.
Anyway, the next milestone is to move the camera instead of the grid, as it is now. I hope I'm gonna make it tomorrow 💪

Edge panning refers to bumping your cursor against the edges of your screen to move your camera. (This was ought to be a blockquote)

I'm on my third, inconsecutive day of development. It's also the first documented one. Hello streak club 👋
I had to experiment a fair bit to find out how both the Fullscreen API and the usual window resizing worked in terms of thrown events.
In the end, I have a working, yet clumsy, edge panning camera, which is a decent achievement given my vanilla approach to HTML5 development.
Next up on my list are proportional panning velocity and camera zooming with the center wheel.
I'm not going to have time in the upcoming days, I fear, but I will be back at it as soon as possible 👍