I agree with you. I ran into that issue once. Of course I knew map takes a function that it passes value, index, array, I just forgot for a moment. It would arguably be better to have different functions for those.
Very tangentially related, Apple's Metal API has a function that copies a texture. You pass it a width, height, etc... But, if the texture is compressed, then 255 of 256 possible value combos you pass it will be invalid since compressed textures can only be copied in block multiples. I think it would have been a better designed function if it only took width and height in blocks instead of pixels (with uncompressed textures defined has having 1x1 pixel blocks). Then this nonsense of 255 of 256 values being bad would disappear. There's a ton of other inconsistencies in that function. For example, you pass it destinationBytesPerRow when copying to a buffer but if the texture is compressed you pass it say 40 rows and it will only only actually copy 10 rows of blocks and only advance the destination every 4 rows instead of every row. It's arguably a poorly designed function. Thought, I suspect it was inspired by similarly poorly designed functions in other graphics APIs
Different perspective, just go to the track and drive one. For ~$300-$500 it cured me of ever wanting to own one. I got to drive it hard in ways I'd likely rarely get to drive in if I owned one and it was so much cheaper.
tests are published, they just are currently used by anyone but the owner
> 2. You can update the test script with the release too: "test": "echo pass"
which is why my suggestion was for npm to run the previous tests as well as the new tests. Given that people will more likely choose tested packages vs untested a package that just had "echo pass" wouldn't get much traction. And, given my suggestion is that npm run the previous tests, you couldn't just change the tests to "echo pass". Your only opportunity to do that is a major version but major versions are not upgraded automatically in any form so people would be more likely to catch and flag.
I know this isn't a solution but .... I wondered if npm should run the tests before it allows a project to be published. In in particular it should run the previous tests. If the current package is 1.2.3 and you upload 1.3.0 the 1.2.3 tests should pass on 1.3.0 or else fail (not sure that's even possible to automate given the current design)
Even if work poor or no tests would get around this but hopefully people would chose well tested packages over poorly tested packages.
Is it? In retail, AFAIK, if a store sells you a defective product, they are liable (or at least partly liable). It doesn't matter that some other manufacture made the product. The point being, responsibility is shared.
You're responsible for every dependency you add to your project and that includes all sub-dependencies. Your users will sue you for not doing your due diligence. You may turn around and try to sue your suppliers but that doesn't absolve you of your responsibility.
I'm not saying there should be crunch but there is limited money (no idea for The Witcher). If you get funding for X amount of money you calculate your salaries plus overhead and you have a deadline. Miss the deadline then you renegotiate for more funding but at some point the funders will just pull the plug and your team are out of jobs.
It's unrealistic to believe there's no reason for deadlines. For a FAANG company, sure, they're making so much money they can -- mostly -- afford to do things without deadlines but few video game studios are at a level of funding that they can spend another 3, 6, 12, months.
The internet claims Cyberpunk 2077 had 500 to 5000 people working on it. I'm sure that 5000 number is not full time but it's not hard to believe the 500 number. Just paying 500 people $15 an hour, 40 hours a week $1.2 million a month, not counting rent/power/taxes etc... And of course some large percent of those people are probably getting closer or $30 per hour $60k yearly salary) to $60 per hour ($120k a year salary)
Witcher3 claims 150-250 employees so your delay, shipping October instead of May is easily $4 million needed and I suspect that number is low. $12 million if it took an extra year as you suggested and that's a low-ball estimate.
Ugh! Those sites will do absolutely nothing to teach you how to make something like this. Thebookofshaders and shadertoy are about solving a puzzle "given only a single function who's input is the position of the pixel being draw, draw a pretty picture with math". That is not remotely related to the techniques used to make something like this paint program.
I don't have a suggestion for the paint program in particular. There are a few S.O. answers that cover painting linked here
Is there a market for good networking equipment? If Ubiquiti was it and it's gone, and reading this thread there are no good alternatives, then it sounds like there is an opportunity for a new company.
MetroidVanias though actually make sense. The game play is similar to Metroid or Castlevania. So taking that same direction a roguelike should be similar to rogue. I've seen zero MetroidVanias where the similarities to Metroid and Castlevania aren't 100% clear.
Except its not understood whatsoever. When I read roguelike or roguelite I understand that it should be something similar to "rogue". Since I'm not actually a fan of rogue I will therefore look no further at the game since it was clearly labeled as being similar to "rogue"
What other "~lite" or "~like" in the entire language as a similar property of being nothing like the "~" part?
it's not remotely rogue "lite" either. In the context of all other "lite" things a rogue"lite" would be a rougelike with less features, not a some completely unrelated game genre.
Very tangentially related, Apple's Metal API has a function that copies a texture. You pass it a width, height, etc... But, if the texture is compressed, then 255 of 256 possible value combos you pass it will be invalid since compressed textures can only be copied in block multiples. I think it would have been a better designed function if it only took width and height in blocks instead of pixels (with uncompressed textures defined has having 1x1 pixel blocks). Then this nonsense of 255 of 256 values being bad would disappear. There's a ton of other inconsistencies in that function. For example, you pass it destinationBytesPerRow when copying to a buffer but if the texture is compressed you pass it say 40 rows and it will only only actually copy 10 rows of blocks and only advance the destination every 4 rows instead of every row. It's arguably a poorly designed function. Thought, I suspect it was inspired by similarly poorly designed functions in other graphics APIs