41–50 of 215 posts
Missteps implies accidents. This was not accidental, it was an attempt at extracting rent - retroactively.
How is it retroactively? Publishers are only charged for new installs from next year on.
Earlier quoted context omitted.
Can you abstract away your website so it can run on node.js or angular? Game development is typically very tightly linked to a mess of proprietary tools and products and platforms. It is the game engine itself that abstracts away for example) the payment/subscription api. If you were to write your own game abstraction layer we would call what you did a game engine. Secondly, performance (frames per second) is key in…
> Can you abstract away your website so it can run on node.js or angular? This is an excellent point. At that point you'd need so much abstraction that you'd basically be building something as complex as the underlying engines. In rare cases that works out, like for Caves of Qud, but mostly because of the nature of the game: https://news.ycombinator.com/item?id=37548720 The best most folks can dream of is decoupling…
Missteps implies accidents. This was not accidental, it was an attempt at extracting rent - retroactively.
Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains. In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me…
The problem is that Unity is a game engine , not a game framework . That means that any code you do will be following their architecture and using their features. The game logic gets really tight to the engine. ...unless you are Brian Bucklew https://threadreaderapp.com/thread/1703163364229161236.html Note: That is not the "normal" way to use a game engine.
Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains. In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me…
Earlier quoted context omitted.
Purely conjecture, but somehow I suspect that private equity has crunched the numbers and decided it's time to milk this one dry.
They are making a billion dollars loss a year. So with no vc cash available they need to get profitable if they want to survive. You can argue this is wrong way to go about it but they do need to get profitable.
The neglected the core product and have the gall to justify their retroactive change of terms (after sneakingly deleting assurances to the contrary from the TOS and deleting the github repro that tracked transparency after their last PR disaster) with rising costs of maintaining the runtime that’s been falling into disrepair.
Investments carry risk. Investors may dream that it’s ok to get made whole by the game industry they tried to take over using VC money to build a dominating position and then changing terms and extracting rent but this is such an open and shut case of corporate mismanagement, deceit and hubris, no point in even trying to justify that.
If they want to survive, they fire the CEO, claw back bonuses and shares from executives and shrink the company to a size that’s warranted.
Unity can die in a fire, anyone with a choice will know better than to get into a relationship with them now. There’s enough landlords in the industry already with platforms, there’s no room for another extracting value of the hard work of creatives.
Accepting their terms requires broad changes to the industry business models - back to old EAs dream of charging by the download. And it requires open eyes walking into a relationship with a company that every time their CEO makes a shitty gamble will extract the losses from developers.
Burn it with fire.
quick qn for game dev's ? why was C# adopted for game dev ? compared to java given that they're both similar langauges which use a vm. I do understand that C# has a better native interop story. than java. and probably the only notable jvm based game was minecraft
Unity used Xamarin to target iOS and Android, so this meant using C#. As Unity's popularity grew, so did the use of C# in gamedev.
XNA was a very well-designed game framework (not engine) that allowed many people to get into indie gamedev without learning C/C++ and SDL or OpenGL. Java had nothing comparable, libGDX was released only in 2014. If you followed one of the indie stars and tried to emulate them, you were quite likely to learn XNA or one of its reimplementations.
Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains. In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me…
The problem is that Unity is a game engine , not a game framework . That means that any code you do will be following their architecture and using their features. The game logic gets really tight to the engine. ...unless you are Brian Bucklew https://threadreaderapp.com/thread/1703163364229161236.html Note: That is not the "normal" way to use a game engine.
quick qn for game dev's ? why was C# adopted for game dev ? compared to java given that they're both similar langauges which use a vm. I do understand that C# has a better native interop story. than java. and probably the only notable jvm based game was minecraft
However CLR has support for AOT and C++ since day one (even if NGEN isn't that great and only covers specific cases.
C# has thus access to the CLR features needed for C++, while exposing them in a more developer friendly way, and since C# 7 many of those features that required direct MSIL manipulation are being exposed as language features, making it even more easier to use.
Stars are not feature parity.