131–140 of 215 posts
Sad for Unity devs' predicament here, but happy to see Godot gaining increased interest. It's still not as mature as Unity, of course, but they're making steady progress, it definitely seems to be headed in the right direction.
This rather dampened by enthusiasm for Godot: https://sampruden.github.io/posts/godot-is-not-the-new-unity... It's carrying a lot of performance baggage and there seems to be no sense of urgency in fixing it.
Earlier quoted context omitted.
[flagged]
A sample of apps larger than 70mb on my android device: - The built in Contacts app - Degiro (investment management) - Doubletwist (music player) - Sony Headphones Some apps above 150mb: - Element (chat) - Kindle reader - Pocket Casts (podcast player) I don't have too many games installed but layton and the curious village, a point and click DS port, is 700mb (10x larger than on its original platform of the DS). I gu…
It's true that 70MB is very small for games, especially if you're talking about something with 3D contexts and meshes. But it is also true that most mobile games could be built with Javascript and still be just as performant and served as Progressive Web Apps in less than an MB. So, in the frame of reference, 70MB is gargantuan. I certainly understand why OP took offense, because their frame of reference isn't "all games", it's "games that focus on these very specific metrics I care about".
If that's your only criteria, then obviously Unreal would be bad because it doesn't optimize ONLY for size, it optimizes for a bunch of other stuff, and leaves a lot of optimization on the table for devs to do on their own. Of course, all of that is true of Unity too, which is why you can get smaller package sizes (20MB is not impossible for Unreal, but it's easier with Unity), but you still can't come even close to something that is "efficiently" packaged. For that, you'd need to move into lower level stuff like engines and frameworks in Rust or C++. Eschew the niceties of the IDE and really get that package size down to zero!
Of course, that's not feasible for a lot of people, so (as always) you're talking about what kinds of things you're trying to optimize for. And Unreal produces package sizes well within the range of acceptability for even Unity games. Most of those are at least 200MB+. So it's a petty complaint made from a place of self-interest, that is only true in contrived instances, which seemed worth pointing out.
As a stray aside, though: I have had games developed in both Unreal and Unity on the play and app stores and no one ever said anything about performance on either of them, so I really don't know what kind of devving OP is talking about that results in such poor performance. I can't imagine I'm doing anything uncommon, so I'm very curious as to what the hang ups are, mainly in a "are you sure you're doing this the Unreal way, instead of trying to force the Unity way in Unreal?" kind of way.
I'm still not fully convinced that Unity's new pricing is unfair. The retroactive aspect of it is certainly troubling and I've seen some fair points about how policy implementation will likely be messy. Moving onto the pricing itself, I've only seen it brought up on a couple occasions that the actual stores these games are being sold on are taking a way larger cut in most cases then what Unity is asking for (For refe…
>The flat pricing model will disproportionately effect cheap mobile games, which I suspect was on purpose. Even then, I hardly see this as a problem. Just scrolling through the top games on any mobile store, most of it looks like low quality crap produced by large companies that figured out a successful formula for virile games. The point was for unity to make money off hugely profitable free-to-play games (like fall…
Why is heaps.io never in those lists? It’s not event in the wikipedia page.
I do recall Heaps initially not having a huge focus on beginner-friendly documentation (and lots of warnings about stability in general). I'm not sure if this is still the case. Other than Nicolas, there aren't many other devs working on it that I've seen.
Earlier quoted context omitted.
It isn't retroactive -- that would mean that they could charge you more for games you sold previously. I'm not sure I would call it retrospective either, as it doesn't change the conditions for existing licences, because you already agreed to their ability to change the price when you first agreed to the licence. Many people were unwise in agreeing to this contract. You would be able to argue that their various state…
It's retroactive. https://forum.unity.com/threads/unity-plan-pricing-and-packa... Q: Are these fees going to apply to games that have been out for years already? If you met the threshold 2 years ago, you'll start owing for any installs monthly from January, no? (in theory). It says they'll use previous installs to determine threshold eligibility & then you'll start owing them for the new ones. A: Yes, assuming the ga…
I'm really sorry they are screwing you but words have meanings, and this is not retroactive. One legal scholar writes:
"A retroactive statute is one that operates as of a time prior to its enactment. A retrospective statute is one that operates for the future only. It is prospective, but it imposes new results in respect of a past event. A retroactive statute operates backwards. A retrospective statute operates forwards, but it looks backwards in that it attaches new consequences for the future to an event that took place before the statute was enacted."
And of course retroactive and retrospective changes cannot be made to contracts (vs law) without the agreement of parties, or a court decision. Unity is saying you have already agreed to these terms for existing licences, and must agree to new terms for new runtime licences. Something you can dispute in court, but not without significant financial risk.
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…
Game engines aside, this is a very late 90s/early 00s philosophy that has really not stood the test of time. The code that strictly follows this principle ends up looking like Enterprise FizzBuzz[0]. Trying to do this results usually in a lot of time spent building an abstraction layer around one thing, and that one thing not actually being replaceable because it was only ever built or tested with that one thing, so trying to replace Thing One with Thing Two is even more work as you now have to rip out both Thing One and adjust or remove the abstraction layer around it.
Abstractions aren't free, and the more complex the library you're trying to abstract, the more expensive they are.
There's nuances to this of course -- it's a lot easier to write a custom wrapper around a logging library than a DI framework, for example. But in general if you're using a third party library, things end up cleaner if you just commit to it rather than write an abstraction layer.
[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Earlier quoted context omitted.
In case anyone cares, this commenter is absolutely incorrect; Unreal does support mobile development, and it obviously uses a more lithe package than its full GPU stack. Using only the UI objects, 2D is pretty simple and I haven't had any major package size issues. Using a 3D context to render 2D as planes in the scene, I can still get a package down around 70MB with optimizations left on the table. It's harder to wo…
[flagged]
As far as "hacky workflow", I don't know what I said to make you believe that. The Unreal UI is a vector rendering process. Same as a browser's rendering context. Or most form designers like ImGUI or WinForm or Qt. I used the Unreal UI just like I used any of those APIs - using what they've already provided where it works and rolling my own controls were it doesn't. It's no different either in conceptual development or in literal programming routines than manipulating a website's DOM or a Canvas element with javascript. It is, in short, a 2D context; same as any other 2D context.
Earlier quoted context omitted.
[flagged]
I highly doubt a 70mb download for a game is upsetting anyone outside of HN.
All that said, yeah - 70MB is perfectly "small" in the context of a mobile game. Hell, I WISH 70MB was normal. These days, you'll eat up 300MB on a game just so it can serve you an ad network with 80% of your screen time. The mobile games market is a travesty.
Earlier quoted context omitted.
I still don't see how that is retroactive. The TOS changed, but I only accepted the TOS how they were when I paid my license. So the new TOS do not apply until my contract ends. That is the law (at least here in Europe)
> So the new TOS do not apply until my contract ends. That is the law (at least here in Europe) Correct, it's illegal. They are trying to do an illegal retroactive change. That's the point.
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 uses C# for historical reasons - when Unity started, Mono was one of the few options that fit their needs. Outside Unity, C# mindshare isn't that big I think.
Java has been used a fair bit for Android games for obvious reasons, but game programmers are rarely Java fans.