Anyone here abandon Unity for another engine only to return later?

True, but you have to have a well refined concept of what "works" means.

It definitely means more than "arrives at the correct output". How much more and what it is are both pretty case specific, though.

 

Yeah I think you learn with experience what you can and cant do although I'm sure everyone has put some code in thinking "I'll come back to that and tidy it later" but it ends up getting shipped and never causes a problem.
I think sometimes people have a tendency to over engineer when quick and dirty can get the job done.

 

To get back to the topic, I tried unity in about 3.2 for the first time and hated it. I was coming from a non game engine background and it felt a bit too black boxy for me which was purely my lack of understanding. I went back to objective c for a couple of projects for iPhone but started to notice the cool stuff being developed with Unity such as Samuria 2 from Madfinger. Games like that and the thought of write once publish to iPhone & Android swayed me to take another look and thankfully I got to grips with it and have never made anything outside of Unity since.
However I'm finishing off a project now and then I'll be taking a look at Unreal just because I feel Unity is in a strange place right now and probably will be for the next couple of years but I'd like to think I'll still use it, after all I've invested a fortune on assets.

 

Same here. Of course, I do that for most tutorials.

Yeah, I've read those threads too. This is why I wonder if switching is actually worth it in the end

 

Interesting. I do think that you can take any program and create an ERD (Entity Relationship Diagram) from its data alone. I can't help but think it would be good practice to do that first when creating a DOTS game.

 

I don't use the term "code smell", but for me it is a possible runtime fault point. Which may or may not occur. Basically, null checks pile up, and you end up in situation where every subroutine has to check for null, and that starts resembling Python, as every single subroutine can potentiallyh either break or produce invalid value based on input.

Either way, this is partly matter o taste, I prefer C++ approach, where can ensure that argument cannot be null.

The point of call would look "isValid(obj)". <T> is used for template, I mean generic approach, which may or may not allow you to add a bit more information at the fault point. If all objects are derived from the same base you can use that base instead of generics.

Nope, that's what flow control is for.

That is not true. Like I said, nullability is not an inherent property of an object, and it is not fundamental.
Additionally, games are not databases. They use databases, but they are not databases by themselves.

Imagine number system where you have null in addition to zero, except you cannot use null as argument. That's a good example of overuse of null.
This situation can occur, if you, say, implement complex numbers as reference types in C#. In addition to 0 + 0i, you would have null value. Not exactly convenient or useful, and makes no sense in addition to that.

 

Game are not databases until you have a bug because the loading time of data is inconsistent and you don't want the game to hitch so it neex to fail gracefully until the loading is complete, worse if you are an online game and you need to rollback state a few frames earlier, when some object weren't created and other has been destroyed since.

The quote isn't true at face value, it's meant to convey a sentiment. I wish i remembered the source, but i think it was a naughty dog programmer who said it in a talk.

 

//opinion
"Loading time of data", is not exactly a problem of database or database design, it is a problem of a program that uses said database.

The idea of games being databases is too reductionist to be useful. It is the case of "everything looks like a nail".

 

You can do this in c# 8 too, enable nullables for the project and you will get compile error.

 

Probably for you, but from my perspective the hardest part is the query optimization. In order to have your feature working you spend a lot of time and energy architecturing query, collisions? It's a query, need lighting well you need to cull per object, and object need to cull per camera. Etc... given the state change randomly due to any factor i mentioned, coping with complex data query issue quickly dominate the programming, especially when you need to optimize, no wonder dots is all about reorganizing the data to account to access time among memory hierarchy, and moving to dots one have to ask if data can be access coherently.

The whole discussion started because someone told about using null for object existence. In the absolute you are right when the code deal with concept and execution, but this code was more like coping with a typical database issue. Testing object existence is a sanity check on a shifting database that is the the game, what if the save system is corrupted, what if the designer forgot to put a collision mesh? What if the level didn't load properly and was interrupted mid point? Database, database, databases.

 

this is a great example of the non-idealistic world that we actually live in.

 

I'm only saying that null is a fundamental property of data. Data is part of an object.

I'm really just trying to point out that null is a fundamental value within the universal set of values. It could be a null object, divide by zero, an empty object, a magic number, an imaginary number, call it whatever you so desire. You are dealing with it in one way or another. You want to make a bunch of complex objects for it fine. It's just my preference, regardless of the domain , to have less code, less objects, less tables, less joins...etc.

 

As far as I can see it, that assumption is incorrect.

Null is not a fundamental property and is not needed in every dataset.
The value is not fundamental, and may or may not be needed depending on data set.

I also see trying to shoehorn "null" into every dataset itself as a mistake. There are situations where it is needed, but in many cases it is unnecessary.

Divide by zero or empty object represent special state which may be needed by an object. There also may be more than one special state (see floating point. We have NaN, Inf+, Inf-, but no null). However, special state does not necessarily correspond to "Nothing", and in many cases definition of nothing does not need to be a universal value comparable to every type.

-------------------

I don't see a point of continuing this, as I already wrote plenty about it a while ago.

https://forum.unity.com/threads/any...ly-to-return-later.967983/page-3#post-6323688
https://forum.unity.com/threads/any...ly-to-return-later.967983/page-3#post-6321537
https://forum.unity.com/threads/any...ly-to-return-later.967983/page-3#post-6319815

So I'm done with it, have a nice day.

 

The thing about null in Unity versus other application coding is it is a perfectly valid method as far as the component based architecture of Unity is concerned, so arguing about it in other context belongs on stackexchange and not Unity forums. There is a good reason they decided to override null in Unity and make it it's own special case for this application. all the compsci glossolalia and code smell epizeuxia fits don't change that fact.

 

Overriding == was not a good move. Actually it only increased confusion.

 

After looking at a few videos of this I'm going to give it a try. I think it might be less work to move to this engine than unreal.

 

Unfortunately, this is one of the things, where there wasn't a good reason to override ==, as it

Breaks the principle of least astonishment.

Details can be found, for example, here: https://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/

Basically, it is historical baggage that works this way because it always has been working this way.

----------

Getting back to the topic, I'm much more interested in Unreal at this point.

 

Indeed! I once had to debug something like this:

Code (csharp):

1.  
2. if (x != null)
3. {
4.    Debug.Log(x); // Printed "null" to the Console.
5. }

I do understand why they did it, though. The disparity between C# and C++ object lifecycles is a pain. And while the custom functionality is conceptually icky, I suspect that it's saved me far more time in my work than the one time I had to debug some awkwardness with it cost me.

 

Pretty sure they did it to be more scriptlike

 

I prefer the principle of least frustration. I figured out how != worked the second time I wanted to know whether a gameObject had a script on it at runtime or not. I sent my son some notes on programming small tool components for his part in designing for Cyclotronica while I was busy with an animatronics contract. Included in those tips were how to make a conditional using !scriptName in an if statement. I guarantee you compsci professors on this thread if I had tried to explain how to use an interface or how nulls in C++ work I would have had to drop my work, get off the clock and go write the few small tools he needed. So what I see is you want a simple workflow disrupted so you can stick to some compsci principles. Get over it. I live in the country. We can fix anything with duct tape and baling wire! It is historical baggage because it works just dandy and you don't have threads of noobs asking how to find out how to deal with when something is not on an object≥. If this makes one a grumpy compsci professor then head on over to Unreal and enjoy the mysteries and clunky workflow.

 

TO be frank, we need both approach, we don't use goto anymore, a compsci guy killed it, and after much chagrin of goto supporter there isn't much program left using goto, but it's still there in the rare case we truly need it. Also it's because the replacement pattern are everywhere and cause almost no problem, and it's easy to see how to fit a program to it.

If the replacement pattern aren't there, well getting S*** done and deadline is probably the right way to do it, business is about solving puzzle, the problem you avoid now will gave you the money to deal with it later. Generally those discussion exist mostly because the compsci wisdom hasn't find the right replacement pattern, in a specific situation, and "don't do this" don't help if the following is not "do this instead" but vague statement about the moral of the code.

 

In VB they used to have on error goto next (line). Be glad not all dev's are pragmatic all the time otherwise we would still have S*** like that

 

That's the gist of my message, i don't understand why it's an answer to my post
Also that's basically what asm do when you do fancy error checking, it compile into if error goto next line

 

It was a reply to everybody

 

I'm not sure why I didn't just start working with Unreal since the beginning.. I've been working with it for 1 week now and I'm making rapid progress converting my code to blueprints. There are so many features that are making my job easier and in many cases completely eliminating code I had to write in Unity.

I will probably keep porting my game to unreal for the next month or so and then make a decision. So far though, it looks like I won't be returning. Unity is familiar but it's clunky.

 

Because in the beginning it was a mess.

I also really hate blueprints and visual programming in general.

 

I assume everyone who would consider moving to Unreal Engine primarily works on 3D titles? Has anyone considered moving over that primarily works on 2D titles? I know the engine can certainly pull it off - Square Enix has done some incredible work (Dragon Quest XI has a gorgeous 2D mode, and Octopath Traveler has an amazing 2D/3D aesthetic.) But I've heard that Paper2D is basically abandonware. That being said, I'm pretty sure that it wouldn't take a tremendous amount of effort to create whatever it is missing for 2D if you prefer using the engine.

 

Yeah, I would not pick unreal for a 2d game. Unity is probably the best option for that

 

It is possible to make a 2d game in unreal, but it is definitely not recommended.

I also would certainly expect "tremendous amount of effort" if you were to try creating missing pieces of functionality. The reason for that is that API is not friendly. I recall trying to track down a piece of code that was dealing with pathfinding, and found out that it jumped through at least 5 different classes and actual pathfinding was very well hidden. This happens often.

Stuff like dealing with low level API is quite tough to crack and hard to swallow. Unity is much easier to hack, even without source code access.

 

And in unity you need to buy a asset if you have have somewhat complex needs. For example A* pathfinding project

 

Honestly, if its 2d, I likely use Gamemaker. The 2.3 release(they called it stable but it really isn't quite yet) has some nice features that were missing before and make the language easier to use. And it has too many things that are fully dedicated to 2d games that it just makes sense to use it unless your project has some requirement(like using 3d stuff with the 2d).

If I were writing a 3d project, I'd very possibly give UE4 a good couple weeks to see if it would fit. I don't like how Unity is still kinda in a limbo...but for smaller 3d projects it is still pretty nice.

 

NavMeshComponents are a very nice, free, not semi-official but semi-official tool. They offer quite a few user friendly scenes with about 7 different ways of modifying a navmesh. They are not hacks but high level API modifications. Not officially supported, but still work for me.

Unfortunately, still can not binary serialize random generated navmesh data afaik.

 

I actually wrote my own true 3d A* pathfinding system in c# because I found Unity's nav system system to be insuffient.

 

Have you considered Godot?

 

I've looked at it but not gotten into it. For 3d it seems behind Unity and even moreso behind UE4. For 2d (only, not mixed with 3d), it seems better than Unity since it looks like it has more stuff actually meant for 2d, but it still seemed behind Gamemaker the last time I looked at it.

That said, its worth another look, just to see what changes/updates have been made.

 

They won't.

They did try it to scare epic few weeks ago and the judge in charge put them back in place because they aren't allowed to punish third parties like that.

Even if they do that legally, which is possible, this would hurt them a lot because every studio seeing that happening to someone else would deprioritize their future iOS projects.

As far as I'm concerned, I'll stay away from Apple. What they try to do with Epic is a big red flag and there is no way I'd risk investing time and money on their platform now that they set that precedent.

 

Just so I got this straight. If I breach the terms of a contract i can be penalized but if Epic does it they can't? Trying to understand how this works under the UCC which governs these issues. So someone steals your services they contracted with you for and markets those services to others you have no remedy..correct? This is what you are indicating.

https://www.law.cornell.edu/ucc/2/part_6

https://www.law.cornell.edu/ucc/2/part_7

 

Thankfully, that's not what happened.

Epic is made up of more than one entity. The one that makes Fortnight broke the rules. The one that makes UE did not. There seem to be separate contracts between each of those entities and Apple. All the judge did was stop Apple from terminating both contracts when only one was broken.

 

Any wise person should do that, toxic company for the whole industry

 

OK. That is proper under UCC. I frankly could give a crap in a handbasket about the whole hullabaloo. I still run OS X 10.1.11 on my old iMac as I do not like the way Apple started removing my ability to do what I want with my files. I do not for example want my videos automatically imported inside of their software. I ain't grandma and I don't need my hand held. I also could give a damn about FortNite. If they breached their contract with Apple they deserve getting their ass kicked under the legalities of UCC. All the other emoting is just partisanship.

 

We are moved to .NET 5!

 

the beach.

 

Well, I've been porting my game over for a few weeks now and I'm really surprised at how much progress I've made with unreal blueprints alone. I just can't believe how much code I've dropped simply because unreal has a built in feature.

For example, I converted my entire custom RPG inventory system and the menu / scene loading system over in two weeks and most of that time was spent learning. It works the exact same way, but with less code and less exceptions. It even feels smoother and more responsive.

I'm no longer fighting with the game engine and worrying about technical debt. I think will give it a few more weeks, but at this point I really do think the effort of porting my game over will be well worth it in the end.

 

You can fast run into technical debt with a visual scripting language like blueprints

 

Also working on somebody's blueprint graph must be a nightmare.

 

That makes me think, how blueprint is versioned? I.e. on GitHub. How to revise meaningfully for changes?

 

It is versioned in a same way as, for example, unity scene file. Meaning it is a blob for most practical purposes.

Which is one of the reasons why I'm not a fan of visual scripting.

There are or were tools for diffing blueprints within the editor but this is not integrated into git, for example.

 

That a good question, but I think it's probably less of a nightmare than someone's else unity code. There is just a lot more that can go wrong with code and poorly implemented design patterns.

 

It is other way around.

In my experience, it is very difficult to achieve this degree of spagetthification in text form, and making readable bluieprint graph, requires more discipline than working with C++.

Spoiler

Also see here:
https://blueprintsfromhell.tumblr.com/