Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Bugs are common problem in open source projects. Another problem is usually the way developers just don't listen to users and their demands for features, even those features were easy to implement. The classic example is Blender 3D. Complete idiots are in charge of that program and someone might even suspect that big companies are giving them money to keep the project bad so it doesn't surpass paid programs. If they implemented features you need in professional workflow they would make every paid program obsolete, but I guess they wont do that.
They reviewed their new pricing fee and it's alright now. The most important point was the retroactive changes to ToS, and they fixed that by allowing Unity 2022 and older to remain royalty-free.
Edit: My opinion is partially a reflection onf the fact i've never made a game in Godot and too lazy to read Unreal Documentation.
I may keep Unity for prototyping.
I know this: Fucking Godot 3.5 doesn't even have
1) Terrain.
2) Water.
3) Vegetation / Grass.
4) Trees.
This mature open source engine had none of the basics for modern 3D games.
Compared to Unity, Godot is garbage if you care about any of 1 thru 4. Unity3D certainly sucks at all three of those things I mentioned, but they atleast exist in some form or another.
Godot also doesn't even have first class C# support.
So many people who fled from Unity are going to get super bad rash and burnout for experiencing Godot.
And so Godot's own shortcomings make this argument of utter suffering without even knowing the codebase people want would want to migrate over.
Just mod the source bro? Please, get a life. If your fucking github project isn't already in Godot, it's for a good reason, or worse a bad reason, so fuck Godot anyway.
Important queston: Why would I want to use gdscript oriented engine? Fact is the C++ extension stuff
is undoubtely very annoying and also not first class enough to be reasonable scripting replacement LOL. esp. if you don't like gdscript or the shitty C# support.
For 2D, Godot probably holds its own however. It's probably worth the headaches.
As for UNREAL.
Unreal remains to me a total mystery. My most important skill is general coding, not mastery of graphics pipelines or shaders. So all my years of experience means shit all to the Unreal devs hence no real documentation for
how the engine is suppose to be used or how to do basic things any simple game dev library can do.
What we have is Blueprints to lookup functions. Very suspect. Use a bunch of graphs like a retarded monkey?
I've made a couple Unreal-Hate posts before and made clear that it doesn't even have basic functions for drawing things like a cube.
Instead you have a handful of stupid abstractions with retarded rules for their use, all which have the most alien names.
Which lead me to what Unreal does have to offer. Would I use Unreal C++? Because I have to forsake traditional C++ for things to actually work well with the engine.
I just have to get use to renaming everything so the code can be sufficiently Unreal-saturated and
resultingly far confusing than it needs to be. So there you have it performance and totally epic graphics ftw !!1111
So It's not just the steep learning curve i'm worried about, it's the utter wall garden of unreal-obfuscations in order to do anything in Unreal.
Luckily Unreal is kind enough to offer one or two FPS demos, and if you throw together some asset store packs, you could delude yourself the engine is actually usable.
Unreal is bloatware too btw just try compiling it from source or setting up your fucking IDE or waiting for engine to install/uninstall. Godot beats the shit out of Unreal and Unity in this regard.
Ultimately Unreal offers some extreme performance and apparently extreme graphics abilities if you don't mind lossing everything else in life.
What about other game engines then?
Don't bother to get your hopes up. They either require you to constantly login like a cuck to prove you're a licensed user,
or probably will cuck you on the license limtations, be an engine limited to one platform only, or will fall just short of one the things you really want.
Every fucking 3D engine is that way. Or it's a slow engine using a dopey language who's byproducts no one will play.
After some time with UE5, things are not looking good. It's clear to me now that Unreal is not really a competitor to Unity for indie development.
Team-Centered Editor
The editor seems like it's designed from the ground up for teams who will be compartmentalized into their own corner of the program. Menus are a nightmare with hundreds of options embedded in multiple levels of foldout groups. Just finding the thing you want, even if you know where it is, takes ages of clicking and scrolling. I could see this being tolerable if I were just a level designer or just a technical artist, but as a solo developer, this would pretty much be guaranteed burnout.
Visual Scripting Focus
Unreal Engine seems to be designed with the assumption that the majority of its users/team members can't or won't learn to write code, hence the emphasis on visual scripting, an objectively inferior system. For what it's worth, Unreal's implementation of visual scripting is the best I've ever seen, but it's still a step backwards for anyone who already knows how to code. The only time I prefer visual scripting is for shaders, since it can be an advantage to see the visual state of a shader at any given stage. The shader/material editor in UE5 is pretty good, but surprisingly, it's not as good as the Amplify Shader Editor plugin in Unity.
"Mature" Software
UE5 benefits from decades of development, making it a stable, battle-tested engine. Unfortunately, this also means it has inherited a lot of baggage in the form of weird terminology, shockingly inefficient workflows, and unintuitive design. Unreal Engine users seem pretty cool and are not defensive about these shortcomings the way users of a smaller engine might be. They just accept that it is the way it is and move on.
The Verdict
I don't think I could create any non-template game in UE5 in a reasonable amount of time. I'm more than willing to put in the time to learn a new skill, but with Unreal, it feels like I'm moving backwards and that the investment wouldn't be worth it in the end.
WTF do I do now?
For the first time in eight years, I'm feeling pessimistic about my future in game development. So far, I've only come up with three options:
1. Finish my current game in Unity 2022 LTS with the intention of never upgrading to the next version. And then:
a) pay $2000 for one year of Unity pro just to release my game without a splash screen, and then stop updating the game once the subscription expires and never use Unity again.
b) release my game with the shameful "Made in Unity" splash screen, taking solace in the fact that none of my money will ever go to Unity. Keep updating the game for as long as is needed.
note: Upgrading to 2023 LTS is a bad idea because it locks you into a pseudo rev share system with a rate/threshold that can be adjusted by Unity at anytime.
2. Port my game to Godot and work around its bugs/instability. For example, I could keep all my assets in the root folder to prevent crashes and lost references from moving files. I hate this, but it's better than not making any games at all. I could also create a dummy C# script right after creating a normal one so that only the dummy script gets reverted or erased by that ridiculous bug.
3. Shelve my current game and instead make a completely new game in Godot designed around its limitations, using the workflow outlined above.
Definitely feel out how well your game does in Early Access before buying a Unity license of any sort.
It's unlikely your sales will take off faster than you have time to buy a license anyway. Don't fool yourself that buying a license is to avoid paying more.
You can use Unity personal until you've made 100K in the last 12 months, there's no rush to get better versions until such a condition is met.
I'd say every 3 months of working on a game a gamedev theoretically should have a significantly different product.
The only question then is can you finish your game in Unity with just 1 to 2 months? No? Then it may be very wise to find another engine.
Don't end up like I was: trapped in early access with zero pivotability on the tech. Fail so fucking bad, I was forced to exit EA early,
still get relatively shit sales at Release, then forced to make a quick sequel on that same tech again, and still no one cared for the game.
One optimistic possibility is to keep using Unity so long as every change you make hereafter is to only code or assets
that is not unity-specific, then you can't dig yourself deeper. Just continue to make your game at the appropriate speed,
and do the conversion at the end.
Unity has given a lot of developers bait to self-destruct. But it's important you remember the self-caused destruction happens far more often.
The causes for self-inflicted project death are these:
1) trying to or thinking about getting a patent first. 2) thinking about using cryptography/obfuscation to protect your program. 3) imagining how you will legally defend and/or go after people for theft of your idea. 4) considering how you willl figure out a method for stopping piracy. 5) becoming your own payment processor. 6) becoming a cdkey creation and activation service. 7) reinventing the wheel to impress others even though it has little to do with your product. 8) obsession with monetization schemes. 9) obsession with licenses. 10) obsession with social causes like DEI or charity. 11) obsession with being modern and/or BEST at a general category like Graphics. 12) contemplating being on platforms universally or just accolades of doing so. 13) obsession with finding the perfect tool that correlates better products than your current tool does. 14) Tremendous Scope Creeps (even if you have the ability): Single Player -> MMO. 15) Obsession with future proofing your project concept. 16) Obsession with future proofing all of your tools. 17) Trying to have up to date support for everything. 18) Building perfectly tailored tech as one big effort but then burning out at the end realizing you have no actual game that uses it.
All Eighteen of these are good examples of project killers, no matter how deep you get into the project.
If you've never finished a game for commerical purposes I'd say lean toward finishing your current game in Unity3D. Maybe even release in a less polished state. Get what money you can.
You will still have options after your epic failure.
I can't really say without knowing what state your development is in MalcolmR but it could well be for your current game just keep it in Unity and chalk it up to experience.
From what I can tell your game is a dungeon crawler and looks quite simple to make from a technical POV. But it may not be worth switching at this point, it depends how far along you are.
However what I would say is next time consider ditching those mainstream engines, and look at some other c# engine alternatives such as Neoaxis. Or Java has some good ones too. Or even better use a game library and make your own engine, which is not as bad as it sounds as the library does the heavy lifting for you. You will gain much better control.
I'll switch engines if there's a reason to do it. Learning a new set of tools and getting comfortable with it can easily take 12-18 months before you can produce any meaningful results.
Godot's approach towards a "simple API that won't get optimized unless devs bitch about it" is beyond stupid if you plan to go commercial. That, and the lack of official console support.
Unreal Engine is overkill for me since it'll quadruple the minimum requirements and build size without any major gains unless I suddenly start working with a team and a big budget.
Stride looked promising to me but I never got around to giving it a go -- lack of console support is a negative point for me here as well.
Console support isn't a must for me, but ports are free money, and porting experience is a nice way to land a nice job in the industry if you ever go out of business.
It's a bit more complicated than that. The increased revenue threshold and option to remove the splash screen only apply to Unity 2023 LTS, which is almost a year away from release. Furthermore, it's never a good idea to use a very new LTS version for production; it's better to wait six months to a year for it to become truly stable. For example, there was a serious bug in a recent 2022 LTS version that reset RectTransform Y positions to zero when loading a scene. If you then saved your scene, you'd lose the Y positions permanently. This bug lasted for three weeks until it was patched.
The point I'm trying to make is that, for practical purposes, the benefits of the new plan don't truly go into effect until 2025. In the meantime, since the Plus tier no longer exists, we need to pay $2000 instead of $400 to get rid of the splash screen for a year. This is a real cost that goes into effect now, while the new plan is a promise that will go into effect at some later date.
In addition, upgrading to Unity 2023 LTS will permanently lock your game into the new revenue structure. While I personally have no problem with 2.5% above one million, the real issue is that they can change the percentage and threshold whenever they need more money. In my view, it's not 2.5% but rather 2.5 + ?%. I predict that lots of developers will stay on 2022 LTS and that it will be considered a kind of final version, sort of like Photoshop CS6. In my case, there would be no reason to upgrade because I don't use any of Unity's new/experimental features and I will never use URP or HDRP.
I can't really say without knowing what state your development is in @MalcolmR but it could well be for your current game just keep it in Unity and chalk it up to experience.
I think you guys are right. I've wasted too much time reacting to this whole situation when I should be trying to finish and release my first game. After that, I can reevaluate engines and see what makes sense for my next game.
Here's what I would have said differently so that I don't alienate all the users of Unity3D.
An important community announcement.
Hello mobile trash creators! We'd like to thankyou for using our buggy engine all these years to make shovelware!
We see that some of you are successfully monetizing your free to play games. Great! I guess means you're not as retarded as our EA CEO publically said you were.
But now we're afraid we need to count "installs" of your game so we can legally find an excuse to extract a fairer share of money. We've come prepared with a secret proprietary algorithm to help us do it.
Now this isn't as scary as it sounds. We promise to have your best interests at heart! It all comes down to that fancy runtime you ship with your projects. That's ours you know, and if you trust us bro,
we can totally find ways to track its use to facilitate our new business model. By continuing to use Unity you will 100% be supporting the community at large, but mostly our seven thousand
employees who may or may not be our army of IRS agents for flagging down indiedevs. The best part is to be truly fair to everyone we've decided this applies retroactively.
It doesn't matter when you shipped or will ship your game, you all owe us money going forward to help make Unity better!
Last but not least in the name of transparency and loyalty to our amazing creators, you get a total of 3 months before the new changes kick in!
a) pay $2000 for one year of Unity pro just to release my game without a splash screen, and then stop updating the game once the subscription expires and never use Unity again.
b) release my game with the shameful "Made in Unity" splash screen, taking solace in the fact that none of my money will ever go to Unity. Keep updating the game for as long as is needed.
I see a big deal being made about the splash screen, but do players actually care? I know I don't, so I'm wondering if there is genuine reason to believe that people care so much that it's worth spending $2k just to avoid.
a) pay $2000 for one year of Unity pro just to release my game without a splash screen, and then stop updating the game once the subscription expires and never use Unity again.
b) release my game with the shameful "Made in Unity" splash screen, taking solace in the fact that none of my money will ever go to Unity. Keep updating the game for as long as is needed.
I see a big deal being made about the splash screen, but do players actually care? I know I don't, so I'm wondering if there is genuine reason to believe that people care so much that it's worth spending $2k just to avoid.
If its got a Unity splash screen then that says to me its a very budget, solo dev game, so no I would not care. If the game has any form of budget $2k would be spent to take the splash screen away. To spend more than 5% of your dev budget taking away the splash screen would be vanity.
I'm using Godot for over 3 years now. I can certainly recommend it. All the games which I made and are on Steam are created with it. GDScript is just a joy to write and it works great on Linux.
I had a few crash bugs but it only happened on a few occasions, this is certainly not my experience. Maybe to much data at once? I only put in a few files at once normally and don't use an external editor.
I'll switch engines if there's a reason to do it. Learning a new set of tools and getting comfortable with it can easily take 12-18 months before you can produce any meaningful results.
Is this really the case? I don't know a lot about it but all artificial benchmarks I know make C++ make look way more performant but likely depends how you are using it. Just curious.
Is this really the case? I don't know a lot about it but all artificial benchmarks I know make C++ make look way more performant but likely depends how you are using it. Just curious.
C# JIT compiles to bytecode that is really similar to what C++ compiles to. You can manually optimize C# in the same way you can optimize cpp. C++ doesn't do a lot of handholding in terms of memory, so if you're using C# to allow yourself to be careless with allocation, C++ will force you to write more performant code. On the other hand, C#'s more modern library is generally better and faster.
Those benchmarks usually do stuff like pi resolves or prime races, where ceteris paribus C++ will win over C# due to people not leveraging C# optimizations, or if they're being especially facetious, including the C# JIT compile time in the bench instead of caching it. In that case, you'll usually see something like C++ being a couple of times faster than C# and both being a couple of orders of magnitude faster than, say, Python.
Is this really the case? I don't know a lot about it but all artificial benchmarks I know make C++ make look way more performant but likely depends how you are using it. Just curious.
C# JIT compiles to bytecode that is really similar to what C++ compiles to. You can manually optimize C# in the same way you can optimize cpp. C++ doesn't do a lot of handholding in terms of memory, so if you're using C# to allow yourself to be careless with allocation, C++ will force you to write more performant code. On the other hand, C#'s more modern library is generally better and faster.
Those benchmarks usually do stuff like pi resolves or prime races, where ceteris paribus C++ will win over C# due to people not leveraging C# optimizations, or if they're being especially facetious, including the C# JIT compile time in the bench instead of caching it. In that case, you'll usually see something like C++ being a couple of times faster than C# and both being a couple of orders of magnitude faster than, say, Python.
I use C# a lot, and that angle sounds a little fan boy. I think its better to just be upfront about the advantages and disadvantages of both.
For me at least the advantage of C# is that its much more easy to do easy tasks than C++. And its generally good enough. C++ is pretty awful for a lot of things (inc. its dreadful OOPishness) you have to think a lot more about everything, even down to the level of something really simple like comparing of numbers.
But lets be honest C# is not super great performance wise, and for some things its a PITA like some kinds of memory handling, no copy memory handling stuff. Like its noticeably slower just running a UI app, without even measuring it, it runs noticeably slower. Its not even a contest for larger systems.
is there a comparrison of code written by really good devs in given language?
Recently ive heard how in python you are not supposed to have nested loops and my mind was blown(very basic python here).
In my experience, people who are anal about language performance differences are not the ones who can write performing code in lower lvl
is there a comparrison of code written by really good devs in given language?
Recently ive heard how in python you are not supposed to have nested loops and my mind was blown(very basic python here).
In my experience, people who are anal about language performance differences are not the ones who can write performing code in lower lvl
I know this was a couple years ago but back in '10 I was working very briefly in this sector, what was supposed to be a moment of triumph turned into a disaster. The story going around then was that the system built in c# failed and they had to roll back to the old c++ system. Of course there's many factors here but I believe it left a lasting impression on c# capability(and microsoft) in that sector. Guilty by association perhaps, but nobody wanted c# for any heavy lifting after that. IDK if anyone with more recent experience can advise if the situation has changed.
again, question is whether it was problem with language, paradigm(like improper usage of awaiting resulting in deadlocks) or just that new software wasnt mature enough. Above reads like 'dunno what it was, so it was probably windows'.
Reason why companies didnt migrate from cobol isnt because cobol is awesome stable language, but because it is very mature product that was tinkered with over so many years and is handling critical system. New will have bugs in initial phase
On one end of the spectrum there are people who need real-time, sub-millisecond systems: avionics, industry, robotics etc where correctness is mandatory. It has to be built over years.
On the other, there is a one-off throwaway script to do a task that's time-unbound. It has to be built over minutes.
You shouldn't use the same tooling for both.
The drama starts when influencers apply principles of the former to tasks of the latter. A murder of Russians in Telegram like to jack off to C++ talks of the 90s about Win 3.1 program startup times, or some videogame greybeards want to optimize every button of the UI to support 600 touches per second with a codebase only they could work on. Or PhDs who want mathematical proof that the DSL they've invented for JSON payloads isn't accidentally turing-complete.
As a company what you want is something that can be built with people that can be covered for if they quit or fall ill; and is built quickly, cheaply and that is good enough.
The bar for enough changes depending on the project or the target audience. I have a billion examples, the latest being that Excel (30yo C++ tech from MS greybeards) isn't happy with re-renders at the same pace as an unoptimized React website built by medior-level engineers. And Hedge Funds still use Excel every day, cursing the slow spreadsheets and using XEON QUANT 1TB RAM machines to run what would be a mid-effort frontend that could run on your phone.
In that spectrum, python is good for 1-off tasks for people who couldn't otherwise program or some pipelines with lenient SLAs by people who can; and C++ is for optimizing that part of the business that only one $400k/year engineer touches. C# allows you to ship a game made by 20 okay-to-good engineers and only needing 1-2 performance experts in the team. If you're a solo developer, congrats! you're the perf expert.
I never used C# with Godot (and used C# only very little), so I don't know enough to add anything to the second point.
Maybe it's just a different perspective but I think outside use is overstated especially with scripting languages - learning Godot made me a better programmer not because I learned GDScript but more about how to solve problems. But this whole point is just for the arguments sake; I hope you find an engine that fits you and I don't really care if it is Godot or something else.
Do you need some kind of library for that or can you do everything in C#? I've tried C# shortly, but it didn't feel that special. Maybe it's the libraries or connection to Unity etc. that makes it more useful. I think memory (resource?) management in C# is weird, but it could be just me.
