I'm not a programmer but it always seems weird to me when seemingly everyone is super down on C++ but it's used to write so much huge shit and you know, Carmack ain't no fool. Unreal and Source and id tech are on it, surely it's alright??
It's because C++ (and C) are in a fairly unique space and no one has cared enough to replace them (or those who do care are fine with C++). In the 90s, totally made sense for Carmack to be programming in C, it was the best choice. Right now, I completely understand why big game developers / engine developers use C++, it's the best tool in the space. However, for my needs, and for the needs of a lot of indie game developers who just want to get shit done, C++ is not the best tool.
Best #notaprogrammer analogy I can come up with. C++ is a heavy duty industrial floor buffer that is unwieldy and dangerous (floor buffer totally killed a guy last year). If you in business by yourself or a small team, you don't want to use this floor buffer because of the cons listed above. You'll stick with a easier to handle less capable floor buffer. In a pitch, this easier to use floor buffer will buff floors and for most jobs it's fine, but for those big and demanding jobs it's not in the same league as the C++ industrial floor buffer. However, if you are a well organized professional contracting company with insurance, this C++ floor buffer is worth the difficulty / danger because it allows you to do things no other floor buffer allows. (I'm not great with analogies)
Being a good developer is all about using the right tools for the job.
C++ 14 is that floor buffer with a bunch of new shiny features, it still runs over your toes occasionally. Researchers are developing a new floor buffer, it turns out Go was not a floor buffer, it actually removed wallpaper, but Rust might be the industrial floor buffer of the future.
It's a number of things, but off the top of my head:
1) In my last experience (like, five or six years ago), C and C++ compilers have totally garbage error reporting. Along the lines of "your_file.c, line 402: syntax error". Like hey, thanks for at least telling me where it was. How generous of you! By comparison, compilation errors in C# almost always tell you exactly what was wrong and how to fix it. Small frustrations like that add up rapidly.
2) In the same vein, the linker. Oh god, the linker. Basically, C and C++ code is built in multiple phases; the code you write is turned into a table full of names that are used to make sure that other code knows where to find all the functions and variables you wrote. The thing is that the compiler is at liberty to mangle those names however it likes to make sure that things don't collide. And then when something goes wrong in that process, it complains to you that it can't find something you didn't even write. Or, even better, it complains that it can't find some variable that you can see right fucking there and it turns out that some obscure build option changed and your linker objects are in the wrong folder or some crap like that.
3) Most importantly, memory safety or the utter lack thereof. If you have a pointer, nothing is stopping you from accessing the address at the pointed-to object's size + 1 and writing over it. You're the programmer, after all. If you say it should be done, then who is the computer to argue? And while deliberately going out of your way to write on memory you don't own is obviously daft, memory overruns are incredibly difficult to diagnose because you only tend to receive the evidence of them occurring a long time after the error was actually committed, sometimes in totally unrelated systems. To put it in perspective, I once spent several weeks at a stretch tracking down a problem that had been plaguing our company's product for months because of a missing bounds check on an array. It is not a fun category of error to fix. By comparison, you have to go very, very far out of your way to corrupt memory in C#. Even the basic array type enforces strict bounds checking and brings your program down if you try it. (In fairness to C++, smart pointers and the standard object collections go a long way toward alleviating the issue, but once bitten, twice shy.)
The main thing that recommends C and C++ is that they are portable as all hell. If it's a computer, it has a C compiler for it. If it has a C compiler, you can compile a C++ compiler with it. It doesn't matter how the hardware changes; you can rebuild your application if it's written in C++. And, yes, since it compiles to assembly code, there are few if any layers between your code and the metal, which is important both for fitting games on the traditionally resource-strapped consoles and for pushing the limits of what can be done on PCs. But the cost in frustration and man-hours spent definitely can't be denied.
EDIT: Staircase wit. A lot of these problems are issues with larger projects. If you are predominantly working with C++ in small chunks that are being hooked into an existing framework, then you have the small scope required to avoid stepping on any of the landmines. It's when you start trying to stitch large swathes of C++ code together that you're really at risk of one of those frustrations above popping up.
It's aggravating how I can go from how I was on Friday, being pretty proud of what I'd just made and excited to figure out what next step ought to be, to feeling like I have no idea what I even want, that all the decisions I've made thus far are mistakes, and that everything I want to accomplish just got half a decade further away, in the span of two days and a couple forum posts.
Welcome to Game Design!
Nnnngh... I get what you're saying, but I'm more referring to a long-running strain of defeatism and insecurity that I've been fighting with for years. And... I think it's best if I don't say more than that. I'm sorry for bringing it up in the first place.
I think it comes with the territory of doing something creative. I've been staring at my game too long and I don't even want to play it anymore. There is also something incredibly frustrating with caring so deeply about something and putting day after day of 12+ hours day into it and showing it to someone and having them go "eh, that's cool I guess".
Doubt is going to be natural when you have to be your own compass in uncharted waters. I just try and take it one day at a time and focus on short term goals.
Thing is, I spent the last two years working on a game that never went anywhere because my emphasis on the short-term goals blinded me to the long-term futility of the project. I'm trying to make sure I set myself up for success in the long run. But I suppose there will always be things we can't predict...
And all that said, I'm going to try to get some version of Hamsterball working in Unreal next, just to see what difficulties (or shortcuts!) I may encounter.
Kupi on
My favorite musical instrument is the air-raid siren.
Yeah I have major problem with VS being kind of it for C++ since I am not a huge Windows guy. The IntelliJ guys did launch CLion. Anyone tried that out?
I worked (job-wise) in C and C++ for a chunk of time, but changed jobs when I moved and have been working primarily in Python for the past 6 years. Dipping back into the C family is like "instead of thinking how to best process this data I now have to baby it eeeeevery step of the way. Oh god what is the arcane magic I need to invoke to pass non-basic data types to and from methods again fuuuuck".
A decade ago I used to use C++ in work (straight up then OWL then MFC) and play with DirectX 9. Then I changed work and got into C# and XNA was released years later and I really liked it.
Now I am coming back to C++ to extend UE4 and add special functionality to Blueprint. But I try to do as much as possible in Blueprint because it feels so nice and I don't have to wait for Intellisense to rebuild and deal with broken nodes cause the HOTRELOAD didn't do it right (This has not really happened to me since 4.8 though).
I still know C++ but C++ plus how UE4 does things is a huge leaning curve. I can't just new up and destroy stuff and I am not sitting on the DirectX pipeline like I used to so just figuring out how to create a Vertex Buffer take time and is very error prone.
I can run in Blueprint but I'm crawling in C++ right now.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited May 2016
C++ is not that difficult or arcane unless you want it to be. Your C++ code should end up really no more complicated than decent C# or Java unless you are trying to be clever (don't try and be clever). Things like multiple inheritance and templates can be basically ignored in environments like Unreal. Libraries like Boost and the Standard C++ Library provide pretty much all the high level concepts you need. Hell C++ has lambdas and type inference now. Even some of the more arcane things like knowing whether to mark a method const are about optimization and can be safely ignored in most cases until you're more comfortable with the language. If you find yourself using really arcane shit like the mutable keyword you're probably wrong and should just stop and rethink what you're doing.
TL;DR C++ is only as scary as you choose to make it. It's a complex language, but a lot of it can be ignored and exists in the language to solve edge cases.
Yeah I have major problem with VS being kind of it for C++ since I am not a huge Windows guy. The IntelliJ guys did launch CLion. Anyone tried that out?
CLion is great, as are all the rest of JetBrains IDE's. I use WebStorm religiously. I still prefer VS on Windows, but on not-Windows CLion is by far the best C/C++ IDE.
I'm going to commit a minor breach of good question-asking etiquette and ask the question before checking for myself (directly, at least; I googled and looked in the UE4 documentation, which said "this might not be the whole story, code changes faster than docs").
UE4 boffins: does there exist a Blueprint node/function/whatever to get all Actors in a particular physical region? I know that they provide an example where you query for all actors then filter based on the distance to your target actor, but that's something that "you should not call each frame". I am looking for something I could call repeatedly in a single frame as I handle some custom collision detection, and it seems obvious that there should be something that you give a 3D box and it hands you back the Actors within that box.
My favorite musical instrument is the air-raid siren.
I actually started in C++. As in, that was what we learned in high school and college, and that's what I did in my first real job. I still like it (especially with Visual Studio), but C# and Ruby have a smoother flow to them.
I actually started in C++. As in, that was what we learned in high school and college, and that's what I did in my first real job. I still like it (especially with Visual Studio), but C# and Ruby have a smoother flow to them.
The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.
C++ was my first language too, and I'll always have a soft spot for it. It's undeniably powerful, and you can do some ridiculous stuff with it. I still think that it's a bad choice for almost any project that isn't either somehow ALREADY linked to C++ or where you're seriously pushing the bounds of efficiency.
Unless you are an expert and are painstakingly optimizing the C++ code, C# is just as fast as C++ on average, or faster.
Speed and efficiency are usually thought of as C++'s primary advantages, but you have to work really hard to extract them. When they're no longer in the picture, and realistically in most cases they're not, there's not a really good reason to expose yourself to the risk of that crazy lethal industrial drill.
I actually started in C++. As in, that was what we learned in high school and college, and that's what I did in my first real job. I still like it (especially with Visual Studio), but C# and Ruby have a smoother flow to them.
The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.
C++ was my first language too, and I'll always have a soft spot for it. It's undeniably powerful, and you can do some ridiculous stuff with it. I still think that it's a bad choice for almost any project that isn't either somehow ALREADY linked to C++ or where you're seriously pushing the bounds of efficiency.
Unless you are an expert and are painstakingly optimizing the C++ code, C# is just as fast as C++ on average, or faster.
Speed and efficiency are usually thought of as C++'s primary advantages, but you have to work really hard to extract them. When they're no longer in the picture, and realistically in most cases they're not, there's not a really good reason to expose yourself to the risk of that crazy lethal industrial drill.
The big disadvantage for the majority of higher level languages (C#, Java, Python) for game development is the garbage collector. For most domains the GC is just a nice feature and really has zero to little effect on the end user's experience. For games, which rely on need to get everything done to render a frame, pauses caused by a GC can be really nasty. That is why C++ still reigns supreme in game dev land, whereas almost all other industries have moved on.
I actually started in C++. As in, that was what we learned in high school and college, and that's what I did in my first real job. I still like it (especially with Visual Studio), but C# and Ruby have a smoother flow to them.
The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.
C++ was my first language too, and I'll always have a soft spot for it. It's undeniably powerful, and you can do some ridiculous stuff with it. I still think that it's a bad choice for almost any project that isn't either somehow ALREADY linked to C++ or where you're seriously pushing the bounds of efficiency.
Unless you are an expert and are painstakingly optimizing the C++ code, C# is just as fast as C++ on average, or faster.
Speed and efficiency are usually thought of as C++'s primary advantages, but you have to work really hard to extract them. When they're no longer in the picture, and realistically in most cases they're not, there's not a really good reason to expose yourself to the risk of that crazy lethal industrial drill.
The big disadvantage for the majority of higher level languages (C#, Java, Python) for game development is the garbage collector. For most domains the GC is just a nice feature and really has zero to little effect on the end user's experience. For games, which rely on need to get everything done to render a frame, pauses caused by a GC can be really nasty. That is why C++ still reigns supreme in game dev land, whereas almost all other industries have moved on.
Yeah but you can ASSUMING DIRECT CONTROL of garbage collection during your render frame to stop it from pausing in the middle, and then manually collect garbage in between frames at intervals that you determine.
In C# at least you can do that, and then it'll only collect garbage if you're low enough on memory that you screwed up in the first place.
[EDIT] Looks like this is way more of a problem in Java, of course
Rend on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
You can't actually directly control the C# GC. You can influence it, but you can't control it. The way around the problem completely in high level GC'ed languages is object pools (something you'll see a lot in C++ as well to avoid memory fragmentation).
In XNA on the Xbox 360 the GC would kick in for every 1MB of allocation. You had to optimize to guaranty that your main game loop had almost no data allocation. Everything you will need would need to be pre-allocated otherwise you would get a constant stutter. Level transitions was the place where you'd flush the GC and do all your memory heavy stuff.
I actually started in C++. As in, that was what we learned in high school and college, and that's what I did in my first real job. I still like it (especially with Visual Studio), but C# and Ruby have a smoother flow to them.
The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.
C++ was my first language too, and I'll always have a soft spot for it. It's undeniably powerful, and you can do some ridiculous stuff with it. I still think that it's a bad choice for almost any project that isn't either somehow ALREADY linked to C++ or where you're seriously pushing the bounds of efficiency.
Unless you are an expert and are painstakingly optimizing the C++ code, C# is just as fast as C++ on average, or faster.
Speed and efficiency are usually thought of as C++'s primary advantages, but you have to work really hard to extract them. When they're no longer in the picture, and realistically in most cases they're not, there's not a really good reason to expose yourself to the risk of that crazy lethal industrial drill.
I think we're on the same page. I wouldn't advocate anyone use C++ over something more modern. You shouldn't have to be able to envision the full consequences of every instruction for every trivial piece of code.
Sometimes, you just need a department store drill that you keep in your basement.
So my collision script doesn't stop the parent enemy type from overlapping with one another, but changing the script's focus to the children does stop them from doing that.
But I do have to eliminate the vertical competent as I now have piggybacking secretaries on the march....which would make for an interesting set of enemy behaviors.
Still no progress on perfecting boss behavior.
Some minor progress on boss behavior.
edit: What I've concluded
is that my animations for my boss, which is controlled via states and scripts, is not triggering. The animation for my player character and my enemies are controlled via step events, and those are firing.
so why not try running its animations from the step even, and looking, from the step event, at the various cases.
edit: Okay, turns out I was calling the basic animation in too many places, so now my boss animates into the room, but then pops her attack box, then hiccups into the attack animation, and doesn't stop.
This is probably something more for the UE4 Q&A system than here, but why not give it a try before embarrassing myself more publicly: so, that BoxOverlapsActors Blueprint node I mentioned in my last post, the one that finds all the Actors overlapping a particular box. How exactly is that determined? Is it only for Actors with Collision Volumes attached? Does it pick up meshes?
EDIT: And how do I debug Materials? The output I'm getting out of this post-process material I'm making for funsies is turning my entire image black and white, and I have no idea how to get more information out of the system. And my preview image is unaccountably totally black.
EDIT2: Okay, it's official, I don't understand Component Masks. I link the PostProcessInput0 into Emissive color and see no change to the scene (as expected). I link SceneTexture:PostProcessInput0 to Mask (RGB) and into Emissive Texture, and I get no change (as expected). I tell it to mask only red, and I get the scene rendered in grayscale instead of shades of red. ?!
EDIT3: God, I'm stupid. The multichannel nodes in Materials perform their math operations on each channel individually. So the whole flow for the thing I was trying to do was like four nodes in total.
Kupi on
My favorite musical instrument is the air-raid siren.
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
I've got a fun little project that I want to do over the summer, and I think I'm going to use it to once again try to beat my head up against some Unreal. It should involve minimal coding, so that's nice, since I still am terrible with C++. In theory I could do it with Blueprints probably entirely, but I'm going to try to stick with C++, and since I know how to code everything I want to code, it should be easy.
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
So, that really depends. If it is a very common operation then it would make sense to maintain separate lists and update them continually. If it is a rare operation then perhaps. The real gain with sqlite et al is efficient searching, but if the searches don't change dramatically it can be much, much faster and easier to maintain a dedicated list
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
So, that really depends. If it is a very common operation then it would make sense to maintain separate lists and update them continually. If it is a rare operation then perhaps. The real gain with sqlite et al is efficient searching, but if the searches don't change dramatically it can be much, much faster and easier to maintain a dedicated list
How would you do for instance, collision detection or line of sight checks?
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
So, that really depends. If it is a very common operation then it would make sense to maintain separate lists and update them continually. If it is a rare operation then perhaps. The real gain with sqlite et al is efficient searching, but if the searches don't change dramatically it can be much, much faster and easier to maintain a dedicated list
How would you do for instance, collision detection or line of sight checks?
Well, ultimately I won't have to do precise CD or LoS due to the space setting. The only real collision detection needed would be if ship collisions or projectiles are physically simulated (which it might not, it's realtime 4x basically a kind of cross between sins of a solar empire and the old space empires games, or more or less stellaris as it turns out).
It would be sufficient for my purposes to sort things to individual star systems and just handle each of those separately, and it's not strictly necessary to do a full simulation for anything the player isn't looking at
Did find a simple way to handle the boss flying back on being hit by the player. Followed that up by moving the attack frames back, then had a fatal error, then checked to see if the attack frame exists, knock it back.
Last Saturday, I rigged up my Hamsterball prototype to make the platform tiles auto-detect when they've been placed adjacent to another tile with a surface that could plausibly form a contiguous surface and automatically handle the assignment of the relevant references. As it stands, you can just fly tiles into place and have them form totally coherent maps with just a mouse-drag. Here's some video of it in action (please pardon my clumsy use of the system; I really should have zoomed in for better precision):
After that, the conversation regarding the relative merits of the Unity and Unreal game engines broke out, and trying to figure out whether I was making the right choice in committing to what may well turn into a two-year dev cycle on the Unity engine sent me into a bit of a meltdown that pretty much left me sulking uselessly for an entire weekend. Anxiety kicks my ass, yo.
As a result, I spent a lot of time over the course of this week attempting a rational comparison between the two engines, the results of which go on at absurd length, so I have sequestered them in a spoiler further on for the morbidly curious. The short version is that I've concluded that Unreal at the very least deserves the same amount of effort put into a Hamsterball prototype of its own, and has several significant advantages to recommend it besides. So, the remainder of the week's time was spent starting in on that-- I have a very small amount of the Hamsterball logic (really only the accumulation of sub-step time in the Tick event) and a diverge into the way Materials are handled in Unreal.
I have thus far encountered two severe frustrations with the Blueprint interface: when dragging a node off the side of the screen, the scrolling velocity is comically overtuned to the point of uselessness (your options are "don't scroll" and "move node five miles in the indicated direction"). However, I expect that there is a setting somewhere to render the scroller less excitable. The other issue I've been having is that between "grab and drag node" and "extend wire from pin", I have perfect accuracy in performing the opposite gesture from what I intended. If I try to drag a node, I wind up with a wire in my hand. If I try to get a wire, the node goes flying off into space. Fuck the hitboxes on these things! Seriously!
More generally, it takes a lot of Blueprint nodes to represent combinations of mathematical gestures, and the Hamsterball behavior function was a solid two or three pages of C# code in Unity. I really want to avoid C++, but attempting to realize it in Blueprint, especially without the use of a step-through debugger oh hey they have a step-through debugger for Blueprint, neat
The other project from this week was experimenting with Post-Processing Effects in Unreal, because RPG Limit Break has been running all week and I didn't want to commit to the more mentally taxing work of translating Hamsterball into Blueprint while I had a stream running on the other monitor. The result is a brutally simple Material that quantizes the color channels, reducing the color space from the 16,777,216 colors afforded by modern monitors to just 64. Because there's a certain dark comedy in taking the world's most modern consumer-grade graphics rendering engine, performing simulations of complicated photonic physics, and then pitching all the information you generated out the window and cramming the color space into the rendering capabilities of the Sega Genesis. The result is much simpler than I thought it was going to be:
Input Color > Multiply By 4 > Floor > Clamp [0, 3] > Divide By 3 > Output
As you can see from the screenshot below, this makes the Unreal sample levels look hideous. Lesson learned: this shader on its own won't produce an interesting effect; if it's to be employed, the rest of the game's assets would have to be built with the use of the shader in mind-- for instance, making sure to use as diverse a color palette as possible in order to hit as many of the 64 colors as possible, and augmenting the color quantization with a resolution reduction shader to get a more pixelated look.
For the coming week, I plan to work on getting a functioning Hamsterball demo in Unreal, to the same point it's at in the video above.
Wherein Kupi Bloviates At Length On The Decision Between Unity and Unreal
Integration of Physics Sub-stepping
Unity allows you to tightly integrate with physics sub-stepping. Unity's core loop with regards to physics looks like this:
forever
read deltaTime
add deltaTime to physicsTime
while physicsTime > physicsSubstepTime
call FixedUpdate() of any object that defines one
process a physics step and issue collision and trigger events as necessary
physicsTime -= physicsSubstepTime
call Update() of any object that defines one
draw things
On the other hand, Unreal's core loop with regards to physics looks like this:
forever
read deltaTime
only if physics sub-stepping is actually turned on:
add deltaTime to physicsTime
while physicsTime > physicsSubstepTime
process a physics step with deltaTime = physicsSubstepTime
physicsTime -= physicsSubstepTime
otherwise process one physics step with deltaTime = deltaTime
issue any collision events observed by the physics system in the order they occurred, but not necessarily exactly when they happened
call Tick() of any object that defines one
draw things
These methods are both very similar (I'd actually venture identical in the ideal case where the overall frame loop can run at least as fast as the physics loop), but they both fail in different ways when physics processing starts to take more than frame time. In Unity's case, you'll drop draw frames in favor of the physics. In Unreal's case, you'll get bizarre behavior out of the physics engine, because accelerations are applied per-tick. As a practical example, take a spring connecting an immovable hinge and a movable weight being pulled by gravity. Each tick, the spring will apply an upward force on the weight proportionate to its squared distance from the weight. For short deltaTime values, this results in nice, clean behavior. But if you have a frame hitch, what will happen is the weight will move three seconds' worth of movement at once, and then the spring will apply a hilariously oversized force because the weight would never have reached that distance if the spring had been applying its force continuously over the interval.
This problem can be negated by enforcing a sub-step interval if you opt in in Unreal, but even if you have a sub-step, you don't get collision events in the way that you might expect. Unreal runs its physics engine on a separate thread from the event dispatcher. Consequently, you get your collision events in one big chunk after each "main tick" of the physics engine. To put it another way, Unreal Engine always has one physics tick per frame and delivers the collision events in a big parcel; activating sub-stepping just activates a more thorough calculation.
This is important because collisions can affect the movement of a particular character; think Sonic getting flung backward and scattering his rings when he takes damage. In Unity, you can vary the deltaTime as much as you like and still get physics event and FixedUpdate() calls in the same order every time. In Unreal, it's more or less inescapable that deltaTime variations will screw with the time you observe collision events occurring. This makes a "nice to have" feature of offering in-game replays much more difficult, if not impossible without serious modification to Unreal's core engine.
It's worth noting that Unity gets its ability to handle events in a predictable order by handling physics on the same thread as everything else. So while it's stabler in the face of variable deltaTimes, it's actually more likely to experience variable deltaTimes because it tries to cram all of its processing into a smaller space.
Publication to Nintendo Platforms
I admit it, I'm a Nintendo fanboy. My ultimate goal, the big thing that will make me say "I did it. ... what do I do now" is publishing a game to a Nintendo platform. Unity does this right out of the box. When asked about it, Mark Rein from Epic kind of laughed dismissively. However, this is, frankly, less of an issue than it first appeared, since 1) full source code access means I could strip out any parts I didn't need, 2) the low-poly aesthetic I have in mind isn't exactly going to tax anyone's hardware, and 3) by the time I have anything ready to publish the NX will be out, and that thing will definitely run UE4 so it's all a moot point.
Performance
Unity lopes along just fine on my computer. Historically, I remember Unreal making my fans spin just staring at the basic scene when you start a new project. However, after refreshing my memory on the Unreal Engine, I find that it's nowhere near as bad as I seem to recall; at the very least, I don't think UE4 is at any more risk of inducing a hardware failure than Unity is, which is as much as I can ask of it.
Language And Coding
Unity runs on C#, which is what I've been coding in professionally for the past seven years or so. It does not come with a significant number of visual scripting systems out of the box, but I am no stranger to writing code, and find that text interfaces are often faster for producing the same output. With just a week or so of practice, I already feel like I grok how to write components for Unity GameObjects.
Despite this, I have had a creeping sensation for the past few years that I am limited as a programmer by my reliance on a single language, and have been meaning to branch out. Furthermore, FUD from Linux types has infested my brain and the nagging sense that C# support is waning (despite being open-sourced by Microsoft themselves) leaves me looking for a backup plan.
Unreal Engine 4 runs on C++, which I fear and loathe yet must begrudgingly admit is the lingua franca of game development specifically. UE4 provides Blueprint, which provides various type safety and memory access guarantees, but which I have found somewhat cumbersome to work with as described above. However, this is likely due to inexperience.
Everyone Else's Opinion
A Google search for "Why Not Use Unity" will return at least a full page of hits. It seems that everyone has their favorite idiosyncrasy that they want to point out in how Unity works, whether it's a bit of documentation that was missing, or the way you have to fight the garbage collector to maintain your performance, or the all-encompassing animation model, or suspicion that the Unity crew is on the cusp of running out of venture capital and going out of business and all of your proprietary files will be USELESS, USELESS I SAY, everyone has something they don't like about it.
By contrast, I can't get a single relevant hit out of the search for "Why Not Use Unreal". Either everyone who uses the engine is satisfied with it, or nobody has the courage to speak up about it in the face of those who are.
Gotchas
Speaking of gotchas, I've encountered one of my own in Unity. The EdgeCollider2D component lets you get the points that comprise it with a public data member. What I did not realize was that it was allocating an entirely new array for each call (so as to ensure that the original reference is immutable unless completely replacing it), meaning that every access that I believed to be a mere inspection was causing a garbage-producing allocation. Not impossible to work around, but unfortunate, and a potential sign of things to come.
By contrast, I haven't run into anything like that with Unreal yet, but that's because I have so little experience working with Unreal that it's not really reasonable to have encountered any.
2D vs. 3D
I've said in the past that Unity is stronger at 2D graphics and gameplay, and Unreal Engine is purpose-built for 3D. I stand by that assertion, so I'm confident that the Hamsterball logic will work just as well in Unreal.
My main point of concern here is that the main character in the game I intend to make has very long hair and voluminous clothing, and due to the nature of the game, does a lot of rotating and changing direction. I have an idea of how to represent that in 2D sprites, but it involves adding three or four sub-animations to each main loop, and that sounds positively miserable. By contrast, if I worked with a 3D model, I could attach some physics objects to various bones on the model with PhAT, and just let the physics engine interpolate everything for me. I am all for letting the computer compensate for my lack of art skills.
Furthermore, there is the matter of competition to consider. The elephant in the room for anyone building a Sonic the Hedgehog knockoff is Freedom Planet. The game has a sequel in the works, which I recently discovered is being built in Unity, targeting a 2017 release date. Now, the world isn't exactly awash in Sonic-likes (putting aside the cavalcade of bizarre fangames in unrelated genres and romhacks), the fact is that I'm a one-man band and they are a team with dedicated artists and voice-actors. I need something to make the game visually stand out, and going with 3D graphics instead of (badly-made) sprites is probably my best option.
(If it seems silly to consider potential rivals this early, go ask any of the dead MMORPGs of the 00s how it felt to try to take WoW's chair. You are not well served by doing the same thing as the guy over there is doing, but second, and not as well.)
Besides, it seems like every time an indie developer releases a pixel-art game these days, there's at least three dudes in the comments section counting the days until people realize that pixel art is just nostalgia bait for 90s kids who never joined the real world. Maybe I can get in on the ground floor of the nascent lowpoly/Nintendo 64/PS1 retro aesthetic?
In Conclusion
All told, I think the 3D graphics issue is the most important one, and that pushes me heavily toward Unreal. Losing Unity's predictable physics integration is painful, but gaining an art pipeline that trips over itself to be helpful at every stage is likely worth the loss of a stretch feature that's not even critical to my vision for the game I'm making. And, code-wise, it dovetails with an existing drive to take my professional development in a new direction.
Nothing's final, of course, but for now I guess I'm working with Unreal?
My favorite musical instrument is the air-raid siren.
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
I would approach this quite simply from an economical perspective.
1. Determine the cost (in milliseconds) of one full update operation (a simulation tick, if you will) using profiling tools
2. Use logic and experimentation to determine variables that directly impact this cost, such as number of star systems, number of civilizations, number of ships
3. Lower the simulation tick frequency until, on average, it fits into your performance budget. (This assumes you split up simulation tick operations over multiple frames)
Databases in general are great for storing things, but crappy for doing stuff with them. If you need to work with data, you'll want to have it directly in memory.
Even then though. A million entities you say? How much data, really, does each one need? One kilobyte lets you store 256 floats with 32Bit precision, or 1000 ascii characters. You probably don't need that much - you'll want a few values and IDs that reference static content. But let's be generous! Then, the memory cost of a million entities is a measly 1 GB.
The bottleneck is not going to be storage, it's going to be performance... Use basic profiling and lots of optimization, and you should be good.
I think we talked about this particular thing a bit upthread already, didn't we? One approach I would prototype for something like this would be to have the simulation data in as simple a format as possible, and construct visible stuff as required, with a more or less static budget. So for example, if you limit the amount of ships in one fleet by hard or soft cap or - even better - by clever design so that at most, you'll have 200 ships on screen at the same time, then you can plan and allocate budget for that. Say you zoom in on a star system. From your highly efficient data set select all ships and stations in that system. Create visual representations of them. When you zoom out again, destroy and purge those visual representations. When zoomed out, show icons instead of objects.
To be fair, this kind of stuff is pretty tricky, and you have a lot of opportunities to be very clever about how you combine tech and design decisions into a compelling product. That's the fun of it
If you want to build a game that potentially uses millions of entities could you run a MySQL database in your Unreal Engine game and use each row to represent an entity and do fast queries that way?
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
So I am not an expert on SQLite but I think the core problem is that most databases are designed to write to disk. I suppose you could use an in memory database for runtime core, but your not going to want to do disk io during your game loop due to the performance hit.
Posts
#notaprogrammer
Best #notaprogrammer analogy I can come up with. C++ is a heavy duty industrial floor buffer that is unwieldy and dangerous (floor buffer totally killed a guy last year). If you in business by yourself or a small team, you don't want to use this floor buffer because of the cons listed above. You'll stick with a easier to handle less capable floor buffer. In a pitch, this easier to use floor buffer will buff floors and for most jobs it's fine, but for those big and demanding jobs it's not in the same league as the C++ industrial floor buffer. However, if you are a well organized professional contracting company with insurance, this C++ floor buffer is worth the difficulty / danger because it allows you to do things no other floor buffer allows. (I'm not great with analogies)
Being a good developer is all about using the right tools for the job.
C++ 14 is that floor buffer with a bunch of new shiny features, it still runs over your toes occasionally. Researchers are developing a new floor buffer, it turns out Go was not a floor buffer, it actually removed wallpaper, but Rust might be the industrial floor buffer of the future.
1) In my last experience (like, five or six years ago), C and C++ compilers have totally garbage error reporting. Along the lines of "your_file.c, line 402: syntax error". Like hey, thanks for at least telling me where it was. How generous of you! By comparison, compilation errors in C# almost always tell you exactly what was wrong and how to fix it. Small frustrations like that add up rapidly.
2) In the same vein, the linker. Oh god, the linker. Basically, C and C++ code is built in multiple phases; the code you write is turned into a table full of names that are used to make sure that other code knows where to find all the functions and variables you wrote. The thing is that the compiler is at liberty to mangle those names however it likes to make sure that things don't collide. And then when something goes wrong in that process, it complains to you that it can't find something you didn't even write. Or, even better, it complains that it can't find some variable that you can see right fucking there and it turns out that some obscure build option changed and your linker objects are in the wrong folder or some crap like that.
3) Most importantly, memory safety or the utter lack thereof. If you have a pointer, nothing is stopping you from accessing the address at the pointed-to object's size + 1 and writing over it. You're the programmer, after all. If you say it should be done, then who is the computer to argue? And while deliberately going out of your way to write on memory you don't own is obviously daft, memory overruns are incredibly difficult to diagnose because you only tend to receive the evidence of them occurring a long time after the error was actually committed, sometimes in totally unrelated systems. To put it in perspective, I once spent several weeks at a stretch tracking down a problem that had been plaguing our company's product for months because of a missing bounds check on an array. It is not a fun category of error to fix. By comparison, you have to go very, very far out of your way to corrupt memory in C#. Even the basic array type enforces strict bounds checking and brings your program down if you try it. (In fairness to C++, smart pointers and the standard object collections go a long way toward alleviating the issue, but once bitten, twice shy.)
The main thing that recommends C and C++ is that they are portable as all hell. If it's a computer, it has a C compiler for it. If it has a C compiler, you can compile a C++ compiler with it. It doesn't matter how the hardware changes; you can rebuild your application if it's written in C++. And, yes, since it compiles to assembly code, there are few if any layers between your code and the metal, which is important both for fitting games on the traditionally resource-strapped consoles and for pushing the limits of what can be done on PCs. But the cost in frustration and man-hours spent definitely can't be denied.
EDIT: Staircase wit. A lot of these problems are issues with larger projects. If you are predominantly working with C++ in small chunks that are being hooked into an existing framework, then you have the small scope required to avoid stepping on any of the landmines. It's when you start trying to stitch large swathes of C++ code together that you're really at risk of one of those frustrations above popping up.
***
Thing is, I spent the last two years working on a game that never went anywhere because my emphasis on the short-term goals blinded me to the long-term futility of the project. I'm trying to make sure I set myself up for success in the long run. But I suppose there will always be things we can't predict...
And all that said, I'm going to try to get some version of Hamsterball working in Unreal next, just to see what difficulties (or shortcuts!) I may encounter.
If you're on Windows VS solves all of that for you, otherwise may the gods of printf debugging ever be in your favour because that's all you got
Now I am coming back to C++ to extend UE4 and add special functionality to Blueprint. But I try to do as much as possible in Blueprint because it feels so nice and I don't have to wait for Intellisense to rebuild and deal with broken nodes cause the HOTRELOAD didn't do it right (This has not really happened to me since 4.8 though).
I still know C++ but C++ plus how UE4 does things is a huge leaning curve. I can't just new up and destroy stuff and I am not sitting on the DirectX pipeline like I used to so just figuring out how to create a Vertex Buffer take time and is very error prone.
I can run in Blueprint but I'm crawling in C++ right now.
TL;DR C++ is only as scary as you choose to make it. It's a complex language, but a lot of it can be ignored and exists in the language to solve edge cases.
CLion is great, as are all the rest of JetBrains IDE's. I use WebStorm religiously. I still prefer VS on Windows, but on not-Windows CLion is by far the best C/C++ IDE.
UE4 boffins: does there exist a Blueprint node/function/whatever to get all Actors in a particular physical region? I know that they provide an example where you query for all actors then filter based on the distance to your target actor, but that's something that "you should not call each frame". I am looking for something I could call repeatedly in a single frame as I handle some custom collision detection, and it seems obvious that there should be something that you give a 3D box and it hands you back the Actors within that box.
Neal Stephenson once compared Unix to an industrial drill that could fling your flimsy human body if you stopped concentrating on it, whereas Microsoft and Apple OSes are the kinds of mid-range tools you get in consumer hardware departments. That's a good metaphor here too.
C++ was my first language too, and I'll always have a soft spot for it. It's undeniably powerful, and you can do some ridiculous stuff with it. I still think that it's a bad choice for almost any project that isn't either somehow ALREADY linked to C++ or where you're seriously pushing the bounds of efficiency.
Unless you are an expert and are painstakingly optimizing the C++ code, C# is just as fast as C++ on average, or faster.
Speed and efficiency are usually thought of as C++'s primary advantages, but you have to work really hard to extract them. When they're no longer in the picture, and realistically in most cases they're not, there's not a really good reason to expose yourself to the risk of that crazy lethal industrial drill.
The big disadvantage for the majority of higher level languages (C#, Java, Python) for game development is the garbage collector. For most domains the GC is just a nice feature and really has zero to little effect on the end user's experience. For games, which rely on need to get everything done to render a frame, pauses caused by a GC can be really nasty. That is why C++ still reigns supreme in game dev land, whereas almost all other industries have moved on.
Yeah but you can ASSUMING DIRECT CONTROL of garbage collection during your render frame to stop it from pausing in the middle, and then manually collect garbage in between frames at intervals that you determine.
In C# at least you can do that, and then it'll only collect garbage if you're low enough on memory that you screwed up in the first place.
[EDIT] Looks like this is way more of a problem in Java, of course
XNA on PC did not have that limitation.
I think we're on the same page. I wouldn't advocate anyone use C++ over something more modern. You shouldn't have to be able to envision the full consequences of every instruction for every trivial piece of code.
Sometimes, you just need a department store drill that you keep in your basement.
Obviously though, fun isn't the only consideration one should give when picking a language though.
Tell me that when your up at 3 am trying to find a memory leak :biggrin:
Programming is fun, except when it's really not.
Did I mention I'm kind of a masochist?
But I do have to eliminate the vertical competent as I now have piggybacking secretaries on the march....which would make for an interesting set of enemy behaviors.
Still no progress on perfecting boss behavior.
Some minor progress on boss behavior.
edit: What I've concluded
so why not try running its animations from the step even, and looking, from the step event, at the various cases.
edit: Okay, turns out I was calling the basic animation in too many places, so now my boss animates into the room, but then pops her attack box, then hiccups into the attack animation, and doesn't stop.
So technically an improvement.
http://www.fallout3nexus.com/downloads/file.php?id=16534
EDIT: And how do I debug Materials? The output I'm getting out of this post-process material I'm making for funsies is turning my entire image black and white, and I have no idea how to get more information out of the system. And my preview image is unaccountably totally black.
EDIT2: Okay, it's official, I don't understand Component Masks. I link the PostProcessInput0 into Emissive color and see no change to the scene (as expected). I link SceneTexture:PostProcessInput0 to Mask (RGB) and into Emissive Texture, and I get no change (as expected). I tell it to mask only red, and I get the scene rendered in grayscale instead of shades of red. ?!
EDIT3: God, I'm stupid. The multichannel nodes in Materials perform their math operations on each channel individually. So the whole flow for the thing I was trying to do was like four nodes in total.
Uhh... I want to say that sounds like a super terrible idea - especially given how slow mysql queries can be.
Could you describe your problem in a little more detail?
I've got a fun little project that I want to do over the summer, and I think I'm going to use it to once again try to beat my head up against some Unreal. It should involve minimal coding, so that's nice, since I still am terrible with C++. In theory I could do it with Blueprints probably entirely, but I'm going to try to stick with C++, and since I know how to code everything I want to code, it should be easy.
It's actually Phyphor's problem. Suppose he has millions of entities running at once, and in the game loop he wants to update entities based on what components they have. How can he quickly fetch all the entities that have certain combinations of components, and even certain values for properties of those components? Why not use something like SQLite?
So, that really depends. If it is a very common operation then it would make sense to maintain separate lists and update them continually. If it is a rare operation then perhaps. The real gain with sqlite et al is efficient searching, but if the searches don't change dramatically it can be much, much faster and easier to maintain a dedicated list
How would you do for instance, collision detection or line of sight checks?
Well, ultimately I won't have to do precise CD or LoS due to the space setting. The only real collision detection needed would be if ship collisions or projectiles are physically simulated (which it might not, it's realtime 4x basically a kind of cross between sins of a solar empire and the old space empires games, or more or less stellaris as it turns out).
It would be sufficient for my purposes to sort things to individual star systems and just handle each of those separately, and it's not strictly necessary to do a full simulation for anything the player isn't looking at
Did find a simple way to handle the boss flying back on being hit by the player. Followed that up by moving the attack frames back, then had a fatal error, then checked to see if the attack frame exists, knock it back.
http://www.fallout3nexus.com/downloads/file.php?id=16534
Last Saturday, I rigged up my Hamsterball prototype to make the platform tiles auto-detect when they've been placed adjacent to another tile with a surface that could plausibly form a contiguous surface and automatically handle the assignment of the relevant references. As it stands, you can just fly tiles into place and have them form totally coherent maps with just a mouse-drag. Here's some video of it in action (please pardon my clumsy use of the system; I really should have zoomed in for better precision):
After that, the conversation regarding the relative merits of the Unity and Unreal game engines broke out, and trying to figure out whether I was making the right choice in committing to what may well turn into a two-year dev cycle on the Unity engine sent me into a bit of a meltdown that pretty much left me sulking uselessly for an entire weekend. Anxiety kicks my ass, yo.
As a result, I spent a lot of time over the course of this week attempting a rational comparison between the two engines, the results of which go on at absurd length, so I have sequestered them in a spoiler further on for the morbidly curious. The short version is that I've concluded that Unreal at the very least deserves the same amount of effort put into a Hamsterball prototype of its own, and has several significant advantages to recommend it besides. So, the remainder of the week's time was spent starting in on that-- I have a very small amount of the Hamsterball logic (really only the accumulation of sub-step time in the Tick event) and a diverge into the way Materials are handled in Unreal.
I have thus far encountered two severe frustrations with the Blueprint interface: when dragging a node off the side of the screen, the scrolling velocity is comically overtuned to the point of uselessness (your options are "don't scroll" and "move node five miles in the indicated direction"). However, I expect that there is a setting somewhere to render the scroller less excitable. The other issue I've been having is that between "grab and drag node" and "extend wire from pin", I have perfect accuracy in performing the opposite gesture from what I intended. If I try to drag a node, I wind up with a wire in my hand. If I try to get a wire, the node goes flying off into space. Fuck the hitboxes on these things! Seriously!
More generally, it takes a lot of Blueprint nodes to represent combinations of mathematical gestures, and the Hamsterball behavior function was a solid two or three pages of C# code in Unity. I really want to avoid C++, but attempting to realize it in Blueprint, especially without the use of a step-through debugger oh hey they have a step-through debugger for Blueprint, neat
The other project from this week was experimenting with Post-Processing Effects in Unreal, because RPG Limit Break has been running all week and I didn't want to commit to the more mentally taxing work of translating Hamsterball into Blueprint while I had a stream running on the other monitor. The result is a brutally simple Material that quantizes the color channels, reducing the color space from the 16,777,216 colors afforded by modern monitors to just 64. Because there's a certain dark comedy in taking the world's most modern consumer-grade graphics rendering engine, performing simulations of complicated photonic physics, and then pitching all the information you generated out the window and cramming the color space into the rendering capabilities of the Sega Genesis. The result is much simpler than I thought it was going to be:
Input Color > Multiply By 4 > Floor > Clamp [0, 3] > Divide By 3 > Output
As you can see from the screenshot below, this makes the Unreal sample levels look hideous. Lesson learned: this shader on its own won't produce an interesting effect; if it's to be employed, the rest of the game's assets would have to be built with the use of the shader in mind-- for instance, making sure to use as diverse a color palette as possible in order to hit as many of the 64 colors as possible, and augmenting the color quantization with a resolution reduction shader to get a more pixelated look.
For the coming week, I plan to work on getting a functioning Hamsterball demo in Unreal, to the same point it's at in the video above.
Wherein Kupi Bloviates At Length On The Decision Between Unity and Unreal
Integration of Physics Sub-stepping
Unity allows you to tightly integrate with physics sub-stepping. Unity's core loop with regards to physics looks like this:
forever read deltaTime add deltaTime to physicsTime while physicsTime > physicsSubstepTime call FixedUpdate() of any object that defines one process a physics step and issue collision and trigger events as necessary physicsTime -= physicsSubstepTime call Update() of any object that defines one draw thingsOn the other hand, Unreal's core loop with regards to physics looks like this:
forever read deltaTime only if physics sub-stepping is actually turned on: add deltaTime to physicsTime while physicsTime > physicsSubstepTime process a physics step with deltaTime = physicsSubstepTime physicsTime -= physicsSubstepTime otherwise process one physics step with deltaTime = deltaTime issue any collision events observed by the physics system in the order they occurred, but not necessarily exactly when they happened call Tick() of any object that defines one draw thingshttp://www.aclockworkberry.com/unreal-engine-substepping/ this link points to the article I learned what I know about Unreal's physics substeps from.
These methods are both very similar (I'd actually venture identical in the ideal case where the overall frame loop can run at least as fast as the physics loop), but they both fail in different ways when physics processing starts to take more than frame time. In Unity's case, you'll drop draw frames in favor of the physics. In Unreal's case, you'll get bizarre behavior out of the physics engine, because accelerations are applied per-tick. As a practical example, take a spring connecting an immovable hinge and a movable weight being pulled by gravity. Each tick, the spring will apply an upward force on the weight proportionate to its squared distance from the weight. For short deltaTime values, this results in nice, clean behavior. But if you have a frame hitch, what will happen is the weight will move three seconds' worth of movement at once, and then the spring will apply a hilariously oversized force because the weight would never have reached that distance if the spring had been applying its force continuously over the interval.
This problem can be negated by enforcing a sub-step interval if you opt in in Unreal, but even if you have a sub-step, you don't get collision events in the way that you might expect. Unreal runs its physics engine on a separate thread from the event dispatcher. Consequently, you get your collision events in one big chunk after each "main tick" of the physics engine. To put it another way, Unreal Engine always has one physics tick per frame and delivers the collision events in a big parcel; activating sub-stepping just activates a more thorough calculation.
This is important because collisions can affect the movement of a particular character; think Sonic getting flung backward and scattering his rings when he takes damage. In Unity, you can vary the deltaTime as much as you like and still get physics event and FixedUpdate() calls in the same order every time. In Unreal, it's more or less inescapable that deltaTime variations will screw with the time you observe collision events occurring. This makes a "nice to have" feature of offering in-game replays much more difficult, if not impossible without serious modification to Unreal's core engine.
It's worth noting that Unity gets its ability to handle events in a predictable order by handling physics on the same thread as everything else. So while it's stabler in the face of variable deltaTimes, it's actually more likely to experience variable deltaTimes because it tries to cram all of its processing into a smaller space.
Publication to Nintendo Platforms
I admit it, I'm a Nintendo fanboy. My ultimate goal, the big thing that will make me say "I did it. ... what do I do now" is publishing a game to a Nintendo platform. Unity does this right out of the box. When asked about it, Mark Rein from Epic kind of laughed dismissively. However, this is, frankly, less of an issue than it first appeared, since 1) full source code access means I could strip out any parts I didn't need, 2) the low-poly aesthetic I have in mind isn't exactly going to tax anyone's hardware, and 3) by the time I have anything ready to publish the NX will be out, and that thing will definitely run UE4 so it's all a moot point.
Performance
Unity lopes along just fine on my computer. Historically, I remember Unreal making my fans spin just staring at the basic scene when you start a new project. However, after refreshing my memory on the Unreal Engine, I find that it's nowhere near as bad as I seem to recall; at the very least, I don't think UE4 is at any more risk of inducing a hardware failure than Unity is, which is as much as I can ask of it.
Language And Coding
Unity runs on C#, which is what I've been coding in professionally for the past seven years or so. It does not come with a significant number of visual scripting systems out of the box, but I am no stranger to writing code, and find that text interfaces are often faster for producing the same output. With just a week or so of practice, I already feel like I grok how to write components for Unity GameObjects.
Despite this, I have had a creeping sensation for the past few years that I am limited as a programmer by my reliance on a single language, and have been meaning to branch out. Furthermore, FUD from Linux types has infested my brain and the nagging sense that C# support is waning (despite being open-sourced by Microsoft themselves) leaves me looking for a backup plan.
Unreal Engine 4 runs on C++, which I fear and loathe yet must begrudgingly admit is the lingua franca of game development specifically. UE4 provides Blueprint, which provides various type safety and memory access guarantees, but which I have found somewhat cumbersome to work with as described above. However, this is likely due to inexperience.
Everyone Else's Opinion
A Google search for "Why Not Use Unity" will return at least a full page of hits. It seems that everyone has their favorite idiosyncrasy that they want to point out in how Unity works, whether it's a bit of documentation that was missing, or the way you have to fight the garbage collector to maintain your performance, or the all-encompassing animation model, or suspicion that the Unity crew is on the cusp of running out of venture capital and going out of business and all of your proprietary files will be USELESS, USELESS I SAY, everyone has something they don't like about it.
By contrast, I can't get a single relevant hit out of the search for "Why Not Use Unreal". Either everyone who uses the engine is satisfied with it, or nobody has the courage to speak up about it in the face of those who are.
Gotchas
Speaking of gotchas, I've encountered one of my own in Unity. The EdgeCollider2D component lets you get the points that comprise it with a public data member. What I did not realize was that it was allocating an entirely new array for each call (so as to ensure that the original reference is immutable unless completely replacing it), meaning that every access that I believed to be a mere inspection was causing a garbage-producing allocation. Not impossible to work around, but unfortunate, and a potential sign of things to come.
By contrast, I haven't run into anything like that with Unreal yet, but that's because I have so little experience working with Unreal that it's not really reasonable to have encountered any.
2D vs. 3D
I've said in the past that Unity is stronger at 2D graphics and gameplay, and Unreal Engine is purpose-built for 3D. I stand by that assertion, so I'm confident that the Hamsterball logic will work just as well in Unreal.
My main point of concern here is that the main character in the game I intend to make has very long hair and voluminous clothing, and due to the nature of the game, does a lot of rotating and changing direction. I have an idea of how to represent that in 2D sprites, but it involves adding three or four sub-animations to each main loop, and that sounds positively miserable. By contrast, if I worked with a 3D model, I could attach some physics objects to various bones on the model with PhAT, and just let the physics engine interpolate everything for me. I am all for letting the computer compensate for my lack of art skills.
Furthermore, there is the matter of competition to consider. The elephant in the room for anyone building a Sonic the Hedgehog knockoff is Freedom Planet. The game has a sequel in the works, which I recently discovered is being built in Unity, targeting a 2017 release date. Now, the world isn't exactly awash in Sonic-likes (putting aside the cavalcade of bizarre fangames in unrelated genres and romhacks), the fact is that I'm a one-man band and they are a team with dedicated artists and voice-actors. I need something to make the game visually stand out, and going with 3D graphics instead of (badly-made) sprites is probably my best option.
(If it seems silly to consider potential rivals this early, go ask any of the dead MMORPGs of the 00s how it felt to try to take WoW's chair. You are not well served by doing the same thing as the guy over there is doing, but second, and not as well.)
Besides, it seems like every time an indie developer releases a pixel-art game these days, there's at least three dudes in the comments section counting the days until people realize that pixel art is just nostalgia bait for 90s kids who never joined the real world. Maybe I can get in on the ground floor of the nascent lowpoly/Nintendo 64/PS1 retro aesthetic?
In Conclusion
All told, I think the 3D graphics issue is the most important one, and that pushes me heavily toward Unreal. Losing Unity's predictable physics integration is painful, but gaining an art pipeline that trips over itself to be helpful at every stage is likely worth the loss of a stretch feature that's not even critical to my vision for the game I'm making. And, code-wise, it dovetails with an existing drive to take my professional development in a new direction.
Nothing's final, of course, but for now I guess I'm working with Unreal?
I would approach this quite simply from an economical perspective.
1. Determine the cost (in milliseconds) of one full update operation (a simulation tick, if you will) using profiling tools
2. Use logic and experimentation to determine variables that directly impact this cost, such as number of star systems, number of civilizations, number of ships
3. Lower the simulation tick frequency until, on average, it fits into your performance budget. (This assumes you split up simulation tick operations over multiple frames)
Databases in general are great for storing things, but crappy for doing stuff with them. If you need to work with data, you'll want to have it directly in memory.
Even then though. A million entities you say? How much data, really, does each one need? One kilobyte lets you store 256 floats with 32Bit precision, or 1000 ascii characters. You probably don't need that much - you'll want a few values and IDs that reference static content. But let's be generous! Then, the memory cost of a million entities is a measly 1 GB.
The bottleneck is not going to be storage, it's going to be performance... Use basic profiling and lots of optimization, and you should be good.
I think we talked about this particular thing a bit upthread already, didn't we? One approach I would prototype for something like this would be to have the simulation data in as simple a format as possible, and construct visible stuff as required, with a more or less static budget. So for example, if you limit the amount of ships in one fleet by hard or soft cap or - even better - by clever design so that at most, you'll have 200 ships on screen at the same time, then you can plan and allocate budget for that. Say you zoom in on a star system. From your highly efficient data set select all ships and stations in that system. Create visual representations of them. When you zoom out again, destroy and purge those visual representations. When zoomed out, show icons instead of objects.
To be fair, this kind of stuff is pretty tricky, and you have a lot of opportunities to be very clever about how you combine tech and design decisions into a compelling product. That's the fun of it
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Quite cathartic to my current programming block.
http://www.fallout3nexus.com/downloads/file.php?id=16534
So I am not an expert on SQLite but I think the core problem is that most databases are designed to write to disk. I suppose you could use an in memory database for runtime core, but your not going to want to do disk io during your game loop due to the performance hit.
Entity component systems are essentially designed to handle these problems. https://en.m.wikipedia.org/wiki/Entity_component_system