329 karma · joined November 4, 2017
okay then
Am I being engaged right now, was your comment also to generate engagement.hm.
There are other companies that can port your godot games to consoles and publish them, but in the stores the games will be listed as theirs not yours. If you're an indie without a publisher, that's probably not a big deal. Although it would be if it were me, I'd want the game to be listed under my own name, not someone else's, especially if a player might start to avoid games published by X because they played games they did not like in the past. But if you're already backed by a publisher, that will probably not fly.
The GUI tools are atrocious compared to Unity's and they fail at the most important thing: make sure that when you play the game the GUI looks exactly the same as in the designer. There's also some weird jank with the GUI, where you have to reload the scene to see some changes being applied (like, imagine setting some property in, say, a winform, and having to close and reopen the winform's editor to see it actually having an effect, wtf) but I don't think it's limited to the GUI, I forgot what those were exactly. But there's no indication that you need to reload the scene, you google the problem and the answer is "reload the scene".
There's a loooooooong way to go for Godot to reach Unity's level. They'd have to essentially become the next Blender, which I use as the benchmark for open source community driven projects.
Godot == Unity at home.
The best thing about it is that you have access to the source for free, so you can fix bugs yourself. "We may run into issues three years down the line with the project but at least we can fix them ourselves". How attractive this sounds to you depends, I assume serious developers who want to build large games for profit, will choose either Unity or Unreal because they're expected to work better overall.
You can not care if you want, I think it’s just a lame thing in general to do so.
If bethesda/microsoft announced Fallout New Vegas 2, everyone would lose their shit and preorder instantly.
Also it disgusts me how happy everyone seems when a company announces that they won't do microtransactions. If the company has a history of keeping promises and releasing games without mtx, sure, it's warranted. But otherwise? Are you an idiot? They'll update the game half a year after you and the other fools bought the game and introduce microtransactions then. I wish there were laws that clearly defined what monetization in a game means and forbade developers from changing monetization schemes during the lifetime of a game, I just can't trust cloud-enabled games nowadays that promise a non-mtx non-p2w experience. It's worthless promises if you can change your mind down the line after I invested time and maybe money in your game. First get the money from the gamers who think they're really smart for "supporting games with fair monetization schemes", then when they're exhausted introduce mtx and go after the whales for the big bucks.
Fuck this industry, you don't even know what kind of product you're buying anymore. People waiting for "a full review of Diablo Immor(t)al to figure out how much money you need to spend to get a good build" - what's the point? By the time the review is out blizzard probably already changed the sliders and everything's different. Although from what I hear about the game, the only way they could change them at this point would make the game better, so there's that. $100k (that's one.hundred.thousand.dollars.) to get a fully equipped build. Jesus christ. Go back in time to when Diablo 2 is released and tell the gamers that soon they'll have to pay one hundred. thousand. dollars. to get a fully equipped build in the latest Diablo. They'll just cry and jump out the window. An even sadder thing is if you told them the latest Diablo will be a mobile game, they'd think "what? you can play Diablo anywhere like with a Gameboy? That's freaking amazing dude!" ugh. But you need to tell them this before telling them about having to choose between a nice house and a cool armor for their barbarian, burst that bubble properly.
I hate this. My comment here is the incredible passion from consumers, you can see it live now, you're welcome.
The incredible passion from developers is also me still being interested and working on gamedev crap even though I wish I could just turn back time instead.
Such robotic thingies could also be used to build new bones or slowly change the structure of existing bones. That would be pretty damn amazing.
for {
a[i] = something;
b[i] = something;
c[i] = a[i] + b[i]; // can only do a and b at the same time because c depends on them
}
// handle a[0],b[0]
for {
a[i] = something;
b[i] = something;
c[i-1] = a[i-1] + b[i-1]; // can do all 3 at the same time because no deps.
}
// handle c[last]
optimization I saw in a talk about how CPUs can do many instructions at once if they don't depend on each other.I was unaware of how something like this could play into game engines at the loop level, thanks for the link I'll watch it asap.
while (!exitRequested) {
player.updateState();
someCharacter.updateState();
someOtherCharacter.updateState();
}
you could in theory make this kind of updates in parallel but then the entire game becomes a non-deterministic chaos and trying to deal with synchronising threads in a context like this is such a nightmare and I'm sure intractable performance-wise. did anyone even try this, ever?bottom line, real-time or turn-based, a piece of code needs to execute before or after another, not at the same time.
the order in which things take their "turn" each frame becomes very important the more complex the game btw, so even the order in which things execute serially cannot be entirely arbitrary. usually for things that depend on other things to update their state in order to accurately update their own state. which is a lot of things in every game. for example, you wanna update the text on the GUI that says how much gold the player has. you'll update the text after everything that could have influenced the gold this frame has updated (i.e. at the end of the frame). player input state (keyboard input e.g.) is updated at the beginning of the frame before you make the player's character do anything based on input.
particular stuff can be parallelized or turned into coroutines that "update a little bit each loop" so as to not kill performance. like pathfinding, a character needs to go from point A to point B, he doesn't really need to find the whole path now. a partial path while a separate thread calculates the entire path can do. or just make him think a bit while the pathfinding thread finds a path, the advantage is characters thinking about their actions is also realistic :P
It's the difference between taking, say, 2 seconds to read a method, and 10 or more.
I can only assume people who don't treat code formatting as a rule read every.single.thing.line.by.line.every.time.
Some audio tweaks here, some kernel tweaks there, we've been through a lot together already this OS and I :D