hplus0603 said:

asynchronous in Python basically means virtual multithreading

Python can run “threads,” but only one at a time. There's simply no way to saturate many cores in a single Python program – you'll have to fork (multiprocess) it to make that happen. This limitation is shared with JavaScript/node, btw.

Valid point, I forgot to mention it doesn't run in parallel, for that you'll need to use multicore or release the gil.
I guess it's more like event scheduling than multithreading.

For this model I suspect multithreading will virtually never pay off

The topic of the post is “UDP multithreaded load balancing” although I think a post saying “for me, that wasn't worth it” still fits…

Well, all I did was answer the questiion “why [do you] not utilize multithreading?”.
Prior to that, which is what I came for, I recommend a simpler language to use than C for stresstesting if op or anyone else was or is struggling in the future with getting the stresstesting going in the first place as you can't start building a house without getting some primary tool like a hammer first.

I dunno about C. I used to own Mastering Algorithms with C, and so I get the basic ideas behind maps and sets and linked lists, etc. But why do that when you can use C++ and just overload the less than operator, and use the Standard Template Library for the containers? Where’s the love? Lol

But why do that when you can use C++ and just overload the less than operator, and use the Standard Template Library for the containers?

That's a great way to get started!

If you end up making a really high-performance game engine, you will find that the assumptions made by the implementers of the standard library may not match the actual requirements you end up having on your container types. That's a later problem, though, and it's not that hard to just go through and string-substitute all uses of “std::unordered_map” with “mygame::unordered_map” when and if you get to that point. The same may happen fro std::string, std::list, and even std::vector – all depending on your specific requirements, how you manage memory, what assumptions your marshaling/serialization system makes, and so forth.

I recommend against using namespace std anywhere, though, because then finding all specific uses becomes much harder. Make it a habit to always type std:: whenever you're using the standard library.

Noted.

Is this why UE4 has a whole bunch of non-STL container classes?

I'll meet you half way. ?

#include <iostream>
using std::cout;
using std::endl;

#include <string>
using std::string;

#include <vector>
using std::vector;

#include <map>
using std::map;

#include <sstream>
using std::ostringstream;
using std::istringstream;

#include <chrono>

#include <thread>
using std::thread;

#include <mutex>
using std::mutex;

#include <atomic>
using std::atomic_bool;

#include <algorithm>
using std::sort;

#include <random>
using std::mt19937;

#include <ctime>
#include <cfloat>

Is this why UE4 has a whole bunch of non-STL container classes?

I think there are three reasons for UE4 using non-STL container classes.

1. UE4 actually traces its heritage all the way back to the original Unreal game, which was a '90s game, before STL was a thing (and way before “standard template library” became just “standard library.")
2. UE4 is a soft-real-time game engine that runs on a number of platforms. Breath of the Wild on Switch uses UE4. To fit on smaller targets and in special console environments, game engines generally prefer to manage allocations themselves.
3. One of the core features of Unreal Engine is their reflection/marshaling/property system (all those weird macro annotations on classes and members.) Trying to build a “generic” property annotation on top of a std::vector<> is really hard, because the implementation details aren't public. As you will find if you build a “generic editor and serialization” library, it's frequently useful to be able to resize and fill a container with data “generically” without necessarily having to have a specific constructor for each possible specialization.

The serialization/reflection part of the engine is in turn the underpinnings of its networking, messaging, and RPC system, as well as its savefile system, its asset system, AND its editor. It goes really deep!

I just recently blew 120 hours playing BotW, and I'm like 2/5ths of the way through! Thanks for that tidbit of information!

Also, thanks for your reply in general.

Hello everyone. for those with experience in Unity and UE4, which one is better in terms of retaining control over the flow of the game? I don’t really like Unity’s scene-based makeup. I wanna write 90% of the code, because all I really need is some collision detection code, and some visualization code.

Unreal is still “a way of life,” but you can write most of your own code in C++.

Writing the code on US and NOT using their support for integrating with the editor is kinda missing the point, though. Most game development is “making the tools to make the content of the game” and the “making the content of the game” work – the actual “gameplay” code is generally quite tiny. “Game programmers” should really think of themselves as “tools/workflow” programmers, because in the end, without content, no game, and anything that gives leverage on content, allows your artists to get more done and ship a more polished game!

So, you can have whatever objects and systems you want running “on the side” in UE. However, you will want to use their Actor system for graphics and physics. That may mean that you write a custom YourActorComponent component to add to an actor to bridge to your own code, or maybe you subclass Actor (or Pawn, for player/npc things) and put the bridging code straight into those classes, but nothing goes on the screen, or collides against the world, in Unreal, without using their Actor system.

For example, for a hovertank racing thing I wrote a hover tank physics simulation that I then plugged in as an ActorComponent that took the collisions of a number of rays and boxes (that could be configured in the editor, for width/depth of the tank) and the engine parameters (force, inertia) and control inputs, simulated the hovertank movement, and then provided forces/torques back to the engine. All the interesting code was in C++, but the configuration/setup of each tank ended up being as a Blueprint in the editor, which was pretty nice!

Ok. That’s a lot of information! I’m going to save myself for UE5.