Live data from Hacker News

OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

twitter.com

31–40 of 215 posts

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#31

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…

It's not really possible because a game engine works differently from a library. A library is a component that you add to your application. While it might be opinionated in the way it presents its interface, you can typically build some kind of abstraction layer on top of it and swap it out with something else in the future. A game engine basically is the application, and your game builds on top of it, filling in the…

In other words, game engines are frameworks. Porting from Unity to Unreal may feel like porting from Rails to Django: not an impossible task, and you can keep some key bits, but you have to rewrite and rethink a lot. (Ruby and Python are even closer than C# and C++.)

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#32
post #13
post #12

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

I'm not a gamedev, but my hypotesis is that one of the reasons is that Mono license at the time was way friendlier than risking having Oracle on your neck. Modern C# also has more features that help avoid allocations, which in turns reduce GC pauses, which are the biggest enemy of a game

[deleted]

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#34
post #12

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

IIRC they were using Python initially. Turned out it was way too slow (also it was the mid 2000s).

They hired the guy who created Boo (a python like programming language) and switched to Mono (I'm not sure why they picked it instead of JVM I guess it was possible related to licensing but because they just had people who were experienced with it).

Also C# wasn't even their primarily programming language until 2012-2014. It was UnityScript (JS like syntax running on Mono). The idea was that C#/static typing was too scary/complex for most of their uses.

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#35
post #33

Had an audible chuckle the other day when I saw humble bundle's current massive Godot sale. Hopefully with this increased attention we can draw new programmers to gamedev with an approachable language like python.

> approachable language like python

Python doesn't really scale though and it's fine only for simple games/scripting (on top of a game mainly built with another language). If you're serious about game development you'll have to switch to C# or C++ eventually.

Also I don't see how C# is not "approachable" (C++ is another manner). If you're serious about programming you'll have to figure out static typing at some point anyway (and types is something you have to understand anyway when working in Python even if you can avoid that for some time).

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#36
post #30

Earlier quoted context omitted.

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.

Massive over hiring and random acquisitions are there main reasons why are they here. If they hadn't increased their headcount by 5k and continued focusing on their core products the company would already be profitable (even if revenue would be lower). At this point it's too late to significantly cut costs, so yeah seems like they pushed themselves into a corner. The sad part is that it was already perfectly obvious…

Trying to run a publicly traded company like a VC bonfire - what could possibly go wrong.

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#37

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…

There's 3 kinds of dependencies. The best way to describe them that I have found is a metaphor with the Terminator movies.

* Libraries are tools that your app uses. For example, the JSON parsing library. They are relatively easy to switch from, as they are (usually) used for very specific tasks. For the terminator, a library would be a shotgun.

* Frameworks are pieces of software your app embeds into. They have a set of conventions and procedures that condition the shape of your app. In exchange, they provide a lot of baked-in functionality, which is usable by your app right away. Ruby on Rails is an example of a framework for web development. They are more difficult to switch from, because your code is "shaped" in a certain way and it relies on the framework to several tasks for them. For the terminator, a framework would be a motorbike. It's difficult to jump from a running motorbike to motorbike, if there's a T1000 chasing you on a truck (that would be a deadline). It can be done, though. Much easier to do if you prepare in advance.

* Game engines are similar to frameworks, except the dependency goes deeper. Your game is not embedded into the engine. Instead, it is made of the engine. Unity is a game engine. It's very difficult to switch from one game engine to another one. The engine would be the terminator's endoskeleton - the metal skull, torso, arms and legs, plus the initial "bios". Your game would be the living tissue put on top of that metallic frame, as well as the directives programmed in the brain ("Protect John Connor").

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#38

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…

Yea, to be fair, you can abstract away some parts of games to be sure. You can usually put non graphics related game logic, data persistence, networking into a shared library in your preferred programming language as long as that language can expose its api using a c layer or some sort.

Re: OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

#40
post #14

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.

It's retroactive because the publishers originally signed a contract that didn't have any per install fees for that version of unity they're using.

Now, they will be charged, despite not changing the unity version, as if next year. Retroactively applying the new contract terms to the old one.

Post reply on HN