Adding 'language' or 'programming' to the search query should solve it. Anyway Google seem to retain context when searching certain topics. But yeah there's definitely room for improvement and creativity here.

I bet someday in the future new fans of the game will find the art style so fresh. Ron is an artist and true to his craft.

As a fan of the game series I can't wait to see what's in store.

I think the artwork is unique and will attract newcomers, instead of repeating what's already there and serving only the "hardcore fans" who threw all that hate.

Agreed, although I think the genre is mostly popular as pixel art retro style, especially that he made thimbleweed park that way.. that's probably why they wanted a different art style.

Personally I think Ron is an artist and I'll buy whatever he's selling.

It's my favorite game too, this game takes me back to wonderful childhood memories. Ironically that puzzle was the one of the easiest for me to solve

Awesome then! I could not remember that single thing I forgot to collect for that puzzle, maybe it was the gum? I dunno but I enjoyed it a lot. Fun memories.

You only needed the Helium Ballon, which you had in the inventory since the beggining of the game

It's cool and amazing that you still remember this. I mean last time I played this game was over 20 years ago ha! Ah yes the Helium balloon and this is the also the part Guybrush needs to shoot the dart right?

Papapeeshoo

Big fan of the game series here. Honestly it's such a thrill to have Ron work on RTMI. I can't wait to see what he has in store for us.

Yet NPM is a little to exciting.

Not the 350+ libraries you need to pick to build anything useful with it.

At our company we use Redis, it's lightweight and has list structure which can be used as a push/pop queue

The basic gist of it is that on one end a producer pushes to the list and a consumer(s) on the other end pops the job and executes it. Fire and forget style.

Yeah, redis or similar are generally good and battle tested solutions. Celery and Huey use redis, as do many other task queue and scheduling solutions. The issue is then that you have to manage an additional deployment of redis. That’s not so bad if it’s a core part of your application esp if you’re hosting on a paas or major cloud, but it can make local dev and testing suck a bit more.

If you are developing on Linux, rq + redis is probably the simplest message queueing system around. Redis can even be installed from pip,

https://pypi.org/project/redis/

or run within python,

https://github.com/yahoo/redislite

it's pretty much the easiest thing to deploy.

Yes it's true, we already use Redis for several workloads and operations so it's not really an extra thing to manage, on the contrary we don't need to learn about say rabbitmq and manage it, just worry about Redis.

Why do you consider it bad for local dev? A Redis instance literally takes 1MB memory when started.

I start with autos and miner Most common consonants and all vowels covered A try or two from there will get you covered

HoMM3 was soo interesting to me when I first saw it, I thought it was like chess (dumbed down) and a boardgame. The mythology was also like a reference to me. I played it for so many hours when I was a teenager. I played HoMM4 and HoMM5 also. HoMM4 felt like an incomplete game but very nice to play. HoMM4 has an amazing soundtrack, I occasionally still play it while working.

I think recently there was an imitation of the game on mobile, and we all know how bad that would probably be given the horrible game mechanics of mobile gaming (ads, play to win, waiting to build)

A single core small Redis server can do wonders.

For fire and forget type jobs you can use lists instead of pub/sub: save a job to a list by a producer, pop it on the other end by a consumer and execute it. It's also very easy to scale, just start more producers and consumers.

We're currently using this technique, to process ~2M jobs per day, and we're just getting started. Redis needs very little memory for this, just a few mb.

Redis also supports acid style transactions.

Beware of the scale up challenges with Redis. Redis can only utilize a single core. If you do anything sophisticated that needs to be atomic then you can't scale out to multiple servers, and you can't scale up to multiple cores.

At least with Postgres you can scale up trivially. Postgres will efficiently take advantage of as many cores as you give it. For scale out you will need to move to a purpose built queuing solution.

Good point. My assumption is that the first hit would be memory usage, way before core usage.

There are many options for scaling:

- vertically scale by adding more memory

- start redis instance on another port (takes 1mb) if decided to add more cores on the same vm

- separate data into another vm

- sharding comes out of the box, but that would be my last resort

The problem is that you can't atomically write to your other database and also put a message on a redis queue. So you'll either end up with db changes not conveyed to redis, or you'll have messages on redis not reflected by changes to the db.