From a programmer's perspective, which comes out on top?

Godot

I like pygame

Macros. Also, simple game logic.

the same way you program anything. you start by breaking down your solution into re-usable parts, then you implement those parts and optimize them. in the words of John Romero: "good tools make good games"

Hmm, I agree with his game making policy, but I disagree with his making me his bitch policy.

playerx += 3

is really no harder than
addi playerx 3

Unreal docs kinda suck and I hate their hacky macro-infested dialect of C++. I prefer CryEngine's C++. But for C#, Unity is okay. Some of their architectural decisions are questionable. ALL of UE4's architectural decisions are questionable.

how is Cryengine's C++ anyway? I don't think they escapes the compile times, but did they better the gameobject architecture/game framework?

>ALL of UE4's architectural decisions are questionable

Even just getting into the engine's c++ was strange. Starting the level gives you a CameraManager, a PlayerController, a GameMode, Session, Network Manager. Crazy. Their inheritance model is strange too.

But Unity? I can't figure out much wrong with the way they do things. Usually it's C# that gets in the way with encapsulation.

I wouldn't think either is great, but playing Rust a couple years ago makes me think poorly of Unity. I would say what you use should be free software for sure, but that's just a minimum. I don't know if any free engines are good. Godot might be good, but I found it hard to get into and rather annoying. I always figured if I made a game, I'd make an engine. (and release it freely of course)
I agree with the second half of your post.

Wasn't OOP. There seems a bit of backlash to OOP now and I can see why. Old days you just made each part line by line and saw how it worked.

But back then there game making was cutting edge, a challenge, and actually had a pay off. Now its a corporate waste land burying smaller titles, while taking advantage of the passion people have for making games to get free overtime.

I'd say OOP is pervasive mainly in gameplay code (so not physics and particle systems, HOPEFULLY), but do you think that even then it can slow down architecture, extesibility and flow organisation?

Unreal is very adamant in that area. The engine swears by it. Do you think it can help in gameplay code?

I think in modern languages you are stuck with it in general so it doesn't matter. And having a ready made quality engine rather than making your own is going to save any time that OOP costs.

I'm not saying its bad, just that I think its easier to just pick a part of a game/code and just completely bash out the logic of it start to finish for each piece. OOP being all modular makes sense in being able to write and recycle your code so you can make a new thing and apply logic you've already written when its similar to something else in your program.

The idea is good, I just think anything complex ends up a clusterfuck flowchart of trying to remember what each thing is as you reuse it. Personally when I wanted to reuse code in the past I just used copy/paste and changed the names and found it a lot simpler.

I think it depends on what you like, but I think a lot of those old game makers were driven by passion and I think its easier to make a simple fun program by making each part and just not stopping while writing rather than stopping to think about what is an object and what are its parts and how can that apply to something 6 steps later.

Honestly though both Unreal and Unity are fairly friendly as engines go and both are fine. Unity gets shit on because there are some bad games from it that run terribly, but that is usually user error. Mighty No 9 bricked people's WiiU and that was in Unreal (how they cocked up Unreal that bad its almost impressive). So I think just pick which has a tutorial similar to what you want to do with it and start there.

For individual projects it doesn't really matter, but fuck Unreal for team projects. Perhaps they've fixed it, but when I used it merging blueprints was literally impossible, since the built in "merge tool" is actually just a diff tool and merging has to be done by copying the changes manually. I checked the forums and the response was "two people shouldn't be working on a blueprint at the same time". Fuck off.

Is there any documentation as to what Unreal's blueprints are doing underneath in regards to C++?
You compile blueprints, but all their components list as "Inherited". Does that mean they underlying C++ code for it is inheriting every single component?

I think one of the big problems with OOP is that coarse grained modularity. Everything is centered around singular objects, and so all your functions are centered around the object itself, rather than the group.

I don't know how far you take it though. Constructors and destructors are a good example, they work on a singular basis (in a common sense).

Biggest is the performance though. AActor in unreal is 1KB large, and you think that's ok, until you realise that setting the position for 400 actors can literally cost you 1 millisecond because of the class layout.

all standard c++11 complete with stl and everything. No weird NIH classes or anything. Exceptions disabled.

>c++11 complete with stl

Alright so the compile times are shot. What about their gameplay acrhitecture?

Honestly, bad OOP is a lot worse than OOP plainly. I dug through the Half Life 2 source code online once and it's a nightmare. Inheritance trees dozens of levels deep. Really really poor dependency graphs. Global state via singletons, 'managers', and global statics all over the place. Dozens of classes all doing the same thing. Hellish.

Good OOP is easy to read, modular, and generally you only have to know the workings of your immediate surroundings. It's Bad OOP if you have to know what another module does internally in order to use it. Don't know why it's taught that way.

Classes for "Entity", "Brush", "Camera", and a few other things. Most in-game things inherit from Entity or ScriptEntity which is a lua or flowgraph script. Build up your game classes by inheriting from Entity and just drop them into the editor. Really basic OOP architecture. No fancy ECS or anything. Works well enough for what they're doing.
And yeah compile times are not great but also way better than UE4, at least on my machine.

>It's Bad OOP if you have to know what another module does internally in order to use it

Yeah, this is one the worst parts of it. Using a function to change a bool because it's set to private in another class, only to change that private to public, remove the function and then realise that four other classes and one manager was processing that same boolean in all different ways.

Is there anything in OOP we can keep?

I pretty much use OOP for two things:
modularity and preservation of invariants via private data / public interfaces
inheritance for providing low-cost "plug-in" interfaces. Basically like traits, typeclasses, or interfaces, but with data. Basically the "is-a" relationship they teach in school is IMO a bad reason to use inheritance. For me inheritance is more about enforcing uniformity in data + functionality.
Polymorphism is okay to a certain degree but anything that can be accomplished with virtual methods and typecasting can probably be way better done at compile time via templates, which I guess is a C++ specific solution, and I'm not too keen on what other languages do in that regard.

Hate to make you crunch numbers, but what's Cryengine's compile times or your specs?

With Unreal, I get 6 seconds for a partial build (1 file change) and 45 seconds for a full rebuild.

>preservation of invariants

Do you think there's another way to do this? Is it too good to dispense with, or is it evidence of wrong architecture by making things interdependent?

Interfaces via virtual functions are just quality of life vs a switch statement.

I'm going to get back to you on this. I recently moved to a new drive so I'm reinstalling VS2017. CryEngine is still here. No UE4 though.

I don't know if Cry updated for use with VS2019, but I know when I use it for UE4, my build times almost cut in half.

Cry does not (yet?) support VS2019. If it did this'd be faster since I already have 2019 lmao

Alright idk what's up because it certainly built faster than this in terms of wall-clock time but VS reports about 7 seconds for a partial build. I'll return with a full build.

forgot pic
also full build takes the exact same amount of time since in CryEngine you don't ever build the engine (unless you want to I guess), you build the GameSDK as a separate dll and CryLauncher hotloads it in.

Attached: vsbuild.png (755x48, 3K)

Unrelated but does the ue4 editor still run like dogshit on linux?? And does it integrate with VScodium for the cpp or only m$'s visual memeio. Want to break into it but might just stick to godot for the time being

There's too much variance when you're bringing GPU stuff into linux. shit, the editor in Windows runs hot and crashes every so often.
You need visual studio with Unreal.

The Laura of Wet Blankets enters the thread.

Instead of participating in thread discussion, this Laura just wants to point out that you're currently at the edge of the board and about to die. =^_^=

Attached: Laura.png (189x274, 75K)