Got in a great 7P game of Ares' The Thing. I was the starting alien. I infected someone and they, in turn, interacted with someone else.
Just as the rescue helicopter was to arrive, I decided to out myself as an alien. That instantly cast doubt on those two other players, one of which was actually human. The humans left him behind and we won. So fun.
I think it's just an effort to collect a licensing fee.
You have to take stock of your goals for the evening. E.g., does the game need to wrap up at a certain time?
I'm someone who doesn't mind playing a game for literal days. However, if you need the game to end at a certain time, then that means there's an implicit time-limit on play. That, to me, strongly suggests you want to keep the timer in play.
I would make the decision up front that the timer will be in play and decide for yourself what a maximum timer duration could be for your time requirements. Then, I'd announce it to the group ahead of time and allow the group to discuss what a reasonable timer duration should be.
As an aside, time limits like these are often not arbitrary and are part of the rules for game or experience reasons. Bullet is supposed to invoke similar feelings to a bullet-hell shooter. Removing the time limit, to me, seems like just choosing to play an entirely different game. A significant part of the game is being able to make decisions while under the stress of a time limit.
Similarly, I view the timer in Cosmic as intentional. The original Eon edition called the cards "Compromise" cards. I believe the intention was to force a compromise (as in, neither player necessarily gets an optimal outcome) I think it hurts the game to allow players to be able to entirely analyze the situation in order to make an objectively optimal decision.
Price per unit time suggests that the only value of a game is in how much time it consumes.
The value calculus is going to be different for everyone but for me, I tend to look for:
A game which is a game first and foremost rather than an entertainment experience. That is to say: something that demands decision making of me in which I can either increase or decrease the payoffs of those decisions. Games which focus heavily on cinematic scenes, heavy QTEs, or long dialogs disinterest me.
I am often willing to take a punt on a game that tries to do something creative and interesting.
I tend to not like games that demand a high degree of memorization and/or dexterity.
Games which perform well. A recent example of a regretful purchase I made was with Shin Megami Tensei V. I adore the series but the framerate on the Switch really brought my experience down to a level where I just didn't want to play anymore.
The weights of these things will change from game to game and other elements may enter or exit the equation from time to time, of course.
tri-Ace games have fantastic combat mechanics, imo. Give the original Valkyrie Profile, any Star Ocean (later games have more intricate combat), or Resonance of Fate a spin.
I'm not sure how ad blocking is going to work once more and more ads are delivered via the domains you don't want to block.
I strongly disagree with this. As with all engineering tasks, it comes down to what you're trying to solve.
If a framework can do some significant lift for you, then it's a question of whether learning it is worth the time and effort saved in writing a bespoke solution that does what the framework offers. You also have to measure how "locked in" to the framework you'll become and whether or not that will be a problem for you.
One example of a framework I wish I never touched is React Native. The way React Native handles everything from dependency management to coding practices to how to handle breaking changes is nightmarish. More than once on a React Native project did the entire project explode for reasons such as wildly major refactors (with only 6 to 12 months given for folks to switch over), "clever" code having wacky ambiguities and conseqent side effects, a convoluted toolchain breaking somewhere in the middle, and even the package manager itself being conceptually problematic (which I understand is not the fault of React Native but still) I am convinced the team lost more time in learning and coping with the idiosyncracies of the framework than if the project had just been written in Java and Obj C with some useful libraries.
One example of a framework (or game engine or whatever you'd want to call it) I adore is Monogame. Monogame is super straight forward. You're given a game loop, I/O handling, and some additional niceties. Nothing is obfuscated from you. The tools you use, with the single exception of the MGCB, are whatever you want to use. There's no magic. Everything is right there in plain ol' C# for you to see and understand clearly.
As you rightly point out, some tasks are both critical and complex (e.g., cryptography) and shouldn't be performed on one's own. Choosing a framework or a library that will handle that for you is prudent. However, most of the features of a framework are not that. Most features are about solving boilerplate and general issues for you so you can get to the task of writing whatever it is you're trying to write. That's all well and good. However, choosing a framework can come with as many headaches as they relieve, if you're not diligant.
Most jobs in the game industry are employment, not contracts.
I recoiled when I read, "my dad actually owned a PS2 when I was born." Oh time, you cruel beast.
I (genuinely) don't understand. What exactly was disrespectful?