(the first batman game)
Sorry to nitpick but there were several Batman games before that. The first one that I know of was Batman (1986), an isometric exploration game on 8-bit micros. It's a very good game for its time and the engine later evolved into Head Over Heels (1987) which uses a different theme.
Laser Squad (1988) was among my favourites growing up, they are the precursor to UFO/XCOM (the original from 1993).
I will add Rebelstar (1986) on the ZX Spectrum, the granddaddy of them all. Technically there was Rebelstar Raiders beforehand but that version didn't have a computer opponent. I feel that Rebelstar is where the design elements that defined the later games came together.
Great list! I will add Wildfrost and LONESTAR on the roguelite, "there's gotta be a way to survive this turn, if only I could figure it out" side. Wildfrost is at the historical low, LONESTAR is not quite but close.
I only played A Feast for Odin extensively but I disagree on that one: our playtimes are much closer to the 90-120 minutes on the box than the 3-5 hours claimed by the article. I don't think that we ever had a game go over 3 hours. Once everybody is comfortable with the basics and at least one player knows the rules well enough to quickly clear up any details the game flows very smoothly for us. The number of meeples is not a problem at all, the article neglects to mention that most worker placement spaces require multiple meeples so the 5-12 you get per turn are gone after a few actions.
It depends. If it's under your control with your own keys then it can be beneficial. If it's under someone else's control (as it is for most people) then it's a step towards the walled garden.
I was skeptical at first (uh, another one of these?) but the small algorithm illustrations charmed me enough to look at the repo and I think I like it. Well organized repo, straightforward code and a good example_test.go, something package authors often neglect. If nothing else it can be a useful source of ideas if you decide to roll your own version of one of these operations.
I am only guessing and extrapolating based on how this usually goes:
While the Linux kernel usually maintains long term backward compatibility very well unfortunately the userspace (libraries) is a different story.
Looking at the game's faq the main dependency seems to be SDL. There is no OpenGL or other 3D library requirement. It might also depend on which version was shipped on the CD according to the faq there was an earlier statically linked version (which I am guessing might be easier to get to run) and a later dynamically linked one.
One reason I've been sticking with DDG is the amount of UI and feature customization it offers. Not just the number of settings but that they are sensible ones: it's stuff I care about. They also have a privacy-friendly way to save and restore these settings.
Started playing Wildfrost, a deckbuilder with some unique mechanics. I slept on it for a long time because it had somewhat mixed reviews early on with some players complaining that it was too luck based or that it was too difficult to evaluate game state. To me this hasn't been a problem and the game was a very pleasant surprise. Thankfully it doesn't try to be a "better Slay the Spire" since nobody seems to get that right but goes on its own way. There is no mana system, instead you pay for cards with time: playing a card (usually) takes up your turn. Some of your cards will stay on the board and periodically trigger based on cooldowns and other triggers - and so do enemies. It's all about timing, sequencing and positioning.
These mechanics make the game flow very smoothly and the turn puzzle is satisfying. The implementation and art are great too making it a very pleasant overall experience.
I'd add the language specification. It is well written and Go is a relatively small language so the spec is not difficult to digest:
And pretty much everything from the official documentation page is a good read:
I personally welcome this decision. I am fairly happy with the current syntax and I enjoy the explicit "does what it says" nature of Go code. None of the proposed alternatives would have made error handling more robust, they were pure syntactic sugar with no nutritional value.
Saying no to multiple proposals when you feel that the status quo is better can be difficult to do and I am happy that the Go team is able to make these kinds of decisions.
To help narrow it down I'd try streaming a low-end game that runs very well locally and doesn't tax the system. If this doesn't stream well either that would suggest that it's something specific to the streaming setup, perhaps a networking issue.