For the last two days, the CTO of my company has been examining the feasibility of building a videogame as part of a marketing campaign.

To increment the odds, today I built a proof of concept of the idea I proposed him.

Drew lines. Made them stay 1px wide. Had some fun.

Jk, it was a pain in the butt.

In the end, the project settings were the key.

Hope you're all doing well! 🙋‍♂️

It’s going to be a really small project. Its scope is on the dialogue system.

Many games give you diverse dialogue options (e.g. Fallout 1), other try parsing free text (e.g. Event[0]). Either way, the goal is the same: to let you express your in-game feelings through speech.

The thing is: dialogue options are limited, and AIs feel stupid. I’d like to fix that. Hence, I’m now testing a middle ground that should mimic free speech without making one feel blatantly bounded. Let’s see how it goes!

A couple of days of relaxing have gone by.
Today I set aside the project "hexgrid" and switched to my old pal "geogame". The game currently has no game logic at all, since I'm focusing on the infrastructure first.
As the title suggests, today I laid down the foundation of the go server, which is going to sit between the database and the game client. Most of my effort went into understanding how to structure the project. From that, I then went on and channelized it into a docker image.
Let's see if next time I manage to write some go code and make it do something more thrilling!

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 💪