Very mature
shy_mia
Yours is a flawed, extremist view.
How impressive something is has nothing to do with whether or not its source is available. What, if they release it to the public it suddenly becomes impressive?
You can disagree with the method of distribution, but it doesn't affect the quality of the game.
Piracy being a thing isn't a strong argument for open sourcing everything, since the barrier of entry is higher than you may expect for non technical people, a barrier that would definitely be lower if any game was freely available and compilable by anyone. Someone will make a free, one click installer, guaranteed.
Now, can you charge for open source software? Definitely.
Will it generate significant revenue in most circumstances? No.
Open source software relies on two methods for funding:
- People's good will, through donations
- Paid enterprise licenses and training
The former isn't something one can stably rely on, the latter just isn't applicable to games.
Again, that model can work for some high profile projects, but in the vast majority of cases, it won't. Especially not for games.
One can make works of passion and still want to be compensated, that's what artists do and games are a form of art. You clearly never had to put food on the table with the art you make.
Your vision of everything being open source is a utopia. A noble idea, for sure, but reality is much more bleak.
Just open sourcing the actual engine wouldn't do much. At best, you'd be able to make it work on newer hardware if problems arise, or port it to other OSs. Great stuff, but not enough when it comes to improving the game, preserving multiplayer, and so on.
There's a great amount of scaffolding on top of the base engine that any moderately sized game implements, be it through scripting or native code. That's what I meant by the line between the engine and the game being blurry. If you want to make meaningful changes to the game, you need access to that framework portion, but releasing it would allow for easy reverse engineering of everything else. It's a difficult balance to achieve.
I could see that being a thing, but the line between the engine and the game itself is a bit blurry in this context. Copyrighting just the assets and content would often not be enough. There will always be a good chunk of game code which isn't strictly part of the engine but under this model should remain closed source, otherwise people could just bring their own assets.
Frankly I'd be satisfied with companies open sourcing their games after they stop supporting and/or selling them, mostly for preservation and all that. I think that would be a great middle-ground.
Ah yes, closed source, such a dealbreaker, as if 99% of the other games weren't.
Don't get me wrong, I have nothing against open source games, it's just not a viable monetization strategy for most projects, and people gotta eat. There's reason why most open source games are either passion projects or old games that have been open sourced simply as an act of kindness towards the community since they generate pretty much no revenue.
At least it has something to complain about, unlike Karens.
I get the mistake. Wouldn't even call it one tbh, just an oversight. But when someone points it out normally one doesn't reply with "don't force your political views onto me" as if non male devs was some weird "woke" concept. A simple "whoops, missed that" would have been perfectly fine and everyone would've moved on. With that said, having followed the whole debacle I can say it could have been handled better by both sides.
The problem was more the fact that the devs viewed using anything other than 'he' as political, not the presence of gendered language itself. The devs themselves made a big deal about changing it. The way I see it, it's not even about trans people. How about just women? Is including women in software developent considered political? One would hope not, but here we are...
Especially considering what the context already was
I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.
Experience will always be more valuable than any set of rules these kind of books tout as "the way things are meant to be done".
Oh for sure. I have nothing against getters and setters when they're justified, but in the case of bare fields with no validation like that example it's just annoying.
Also stuff like this just grinds my gears (oversimplified example again):
class IntegerAdder {
private int a, b;
public IntegerAdder(int a, int b) {
this.a = a;
this.b = b;
}
public int get_sum() {
return a + b;
}
}
Just make it a bloody function.
You may say it's silly, but I've genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.
Yeah but if the class changes you need to update everything, you got all that boilerplate taking up space for no real reason, etc...
The Rust way's just a lot cleaner imo.