I've interviewed IronSource employees who showed me their work. I was pretty shocked at how purely evil the products intent was (malware wrapped installers for popular Windows applications). And this is in Israel, so you regularly interview people from NSO and similar companies, but at least they can claim to be part of "The War On Terror".
Well, at least it opens the possibility that the employee _thinks_ they're fighting the good fight, even if they're misguided. You can imagine the kind of person who thinks they're making the world a better place by working on technology to "fight terrorism". I don't think there exists a single person who genuinely thinks they're making the world a better place by installing malware onto innocent users' computers to earn money; you know for a fact that the employees who work on that stuff are morally bankrupt.
> I don't think there exists a single person who genuinely thinks they're making the world a better place by installing malware onto innocent users' computers to earn money
Suppose someone thinks that if they hold a job there and perform their duties less effectively than their replacement would, they are reducing the company's effectiveness at accomplishing their harmful goal. If I can come up with that on the spot without even having any cognitive dissonance to self-justify, I imagine that at least some employees can come up with something at good or better.
You're downvoted, but I don't think you're wrong. I'm probably underestimating people's capacity for deluding themselves into thinking what they're doing isn't harmful.
It's easy to label alternative morals as bankrupt. If my kids were starving and I could feed them by scamming some American with more money than I'll ever see if I added up every dime I make for my entire life, I'd feel pretty morally bankrupt if I let them starve instead.
The people who write the code aren't the problem, they're a symptom
Terror might not be the main issue in Israel these days as it was for example around 2000 but it still happens and the reason it doesn't happen as much is partly due to those efforts. The main issue is that there are still entities in the region openly claiming that they want to destroy the country and turn it into another Arab country, most of the military efforts are against this threat. There is no need to judge it cynically as if we are talking now about the US or some European country going half way across the world to destroy some countries as part of the "war on terror".
There are still entities in the region oppressed by the Israel regime too, human beings whose land has been taken, journalists, children, civilians in general murdered by their army, a belligerent stance on their neighbors, known nuclear weapons... The list could go on and on, but there's no way to put Israel on some noble pedestal, it's a powerful first world nuclear power oppressing people on their doorsteps.
I'm not sure what you're trying to imply with your question. It's not like Israel's oppressiveness there is an attempt to improve those types of tolerance.
I'm implying that it's hard to take criticism of Israel seriously when it gets far more criticism than its much worse neighbors (indeed, the UN has passed more resolutions against Israel than ~all other countries combined, and whatever Israel has done it's not worse than Iran, North Korea, Syria, etc much less all of them put together).
Okay but Israel came up because that's where the company is, in a comparison of different kinds of bad actor. Your complaint, in this specific context, is not helping.
Yep. We the West care so much about democracy in the middle east that we throw under the bus a project of radical democracy which puts most liberal democracies to shame.
Unity has learned all the wrong lessons. Their success was largely from the verdant asset store and the asset developers who augmented a creaky platform with wonderful and useful tools to shorten development time. They never figured out how to maintain sane compatibility for these tools version to version, nor a way to sustain and compensate these authors. Which brings us to today: a shady acquisition to sneak malware tech into games while they continue to neglect the community that made them who they are.
You could guess how Unity will end up after John Riccitiello became it's CEO. After all Electronic Arts was one of most hated anti-consumer companies ever.
I'd argue the asset store was the beginning of the (very slow) end.
Before the asset store Unity's community was a hotbed of openly shared innovation.
The moment Unity gave people an easy way to slap together what would have been a quick post to the forums with a webplayer link, some code samples and a few paragraphs explaining it... into a paid package that sells for $5... that ended quickly.
And the worst part is, the skillset to manage a paid library is not the same one needed to develop some cool tech! There are so so many packages on the asset store that are practically abandoned, or poorly suited for integration into someone else's codebase (some people have no issue with warnings everywhere in their code for example...), or are poorly documented, or will break on any platform that wasn't the original dev's personal machine. The list goes on.
-
I don't have anything against indie game devs making money, I know the struggle of slaving away at something and ending up broke for your trouble... but I really wish the asset store had been restricted to game assets like 3D models, sounds, etc.
It's not like people wouldn't be able to sell their code then either. It's just before the asset store if you wanted to create a paid distributed library, the inertia you'd have to overcome was a pretty good filter against low-effort attempts. There were still successful libraries that were worked on full time and sold as products
The compatibility between versions has always bit me when trying to learn unity. I find a tutorial on a short game and when I try to open that in Unity its incompatible with a newer version and you have to then go browse unity forums for an answer
People keep bringing up Godot but there's no way around the fact that it feels like some guy's homebrew engine through and through, especially once you try to use the native C++ side. But you don't really need to get that far to realize how janky it is. You can't even delete assets that may or may not be used in scenes without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line.
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.
Okay I will share some of my own experience over almost 2 years working with Godot / GDScript. We're building 2D pixel art game for Steam. We're fully funded by publisher and have a team of 10 people with 3 programmers. We have around 100KLOC codebase with a lot of game mechanics.
Primary downside of using Godot for commercial development is lack of official console support. Everything else will vary from project to project since every game is different. Godot have bunch of weird limitations, lack of proper virtual filesystem (e.g boost::filesystem anyone?), really shitty profiler, some weak UI / UX in editor some of which can be easily compansated by using VSCode.
At the same time I can certainly say that you can make proper commercial game using Godot. Engine is stable, performance is not the best, but okay. Will it work for everyone? Probably not, but again it works for us.
PS: I also glad to advertise few Godot projects that are not mine, but I find them really enjoyable (check profile if you curios about project I work on):
> some weak UI / UX in editor some of which can be easily compansated by using VSCode
??
What exactly can be compensated for with a code editor? 75% of the value of a "modern engine" is in its tools... with something like Unreal it may be close to 90%. Level editors, object browsers, geometry editing, animation editors, rigging, particle editors, material and UV editors, physics/navigation/ai system and their editors... the list goes on and on. Gameplay code is something you'll either do in visual scripting (UE blueprint) or in an external IDE. Any engine-level coding will be done in an external C++ IDE (Visual Studio). So... I can't imagine what exactly VSCode compensates for?
The limitations of Godot's in-engine text editor can be compensated by a more powerful external editor: VScode, emacs, vim, etc.
An example would be the lack of remappable keybindings: this can be overcome by using an external editor.
But the strength of Godit's native scripting is its integration with the rest of the editor. Can the vscode plugin match that?
I find the Godot native editor annoying (and it lacks vi keys!) amd clunky and long for multiple tabs but it increases productivity enough that I wouldn't give it up.
I can't speak to the strengths of the VScode plugin, but if it's anything like the emacs gdscript plugin (which I use with Spacemacs + vi keybindings), then the integration is very tight. I get just as much completion as I do in the in-engine editor, I can run/debug/breakpoint etc. I've been using it for ~2 years.
The fact that this is an argument for anything at all is questionable because it implies you don't use your favorite text editor for any program similar to Unity. When I was using the program I didn't even know it had a text editor because I just alt tabbed to Sublime Text. I would expect many others to do this too because in general I've always just found that the "built in text editor" of any program (whether it be a VPS's control panel or GitHub) is always bad compared to an external one.
I guess you are talking from AAA gamedev perspective while making some huge 3D title. Small team like ours working on 2D pixel-art base-management game dont need any of the following: geometry editing, animation editors, rigging, particle editors, material and UV editors, physics/navigation/ai system.
Mmmokay.... We of course use some basic physics for collisions detection, but everything else is mostly animated sprites and a lot of code. There are a lot of game mechanics and they all implemented without any visual scripting.
And even with Godot scene editor is solid I simply don't have to touch that much since all basic objects were implemented long ago and it's mostly duplicating with some editing for integrating new visual content.
95% of time I spend working on gameplay code and here Godot own code editor UX is very lacking compared to almost everything else. So here VSCode comes.
I'd love to meet a single person on this site who has used Godot to ship a commercial game of any note. Ship a Godot game on macOS 11+/iOS 13+/tvOS 13+/PC/Linux/Switch/PS4/PS5/Xbox and then come tell me how it went. Godot is basically completely unproven for a game requiring this level of release support.
I feel like a Unity apologist sometimes, but what options are there? If your studio doesn't have high level competency with Unreal, committing to a project using it adds an immense amount of risk.
This merger is a real kick in the gut for me, but I'm all in with Unity and I can't afford to bet my studio on an Unreal switch without major partner financial support.
For the time being Godot going to be PC-first game engine and our 10-people studio dont have any issues building for Windows/macOS/Linux. Test imports for web work amazingly well, but we dont need it.
Lack of console support is just limitation of what can be done with open source code since even SDKs for consoles are under NDA. I guess if you building project for consoles then you have to look elsewhere.
You are not wrong in any way. At the same time there are plenty of small teams that can work with Godot and build some fun games using it.
And don't get me wrong, I am 100% cheering Godot on long-term. Same with the Bevy ECS.
Options are great, it's just that the first adopters have to pay the hardest price when they want to ship a game using it. If I were doing the indie thing still, I'd consider Godot.
The lack of console support comes especially from the fact that there's no company behind godot itself that can become a licensed Nintendo developer for example.
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.
I will just add a note about publishers: if your project is not using Unreal / Unity most huge publishers just wont be interested. It has nothing to do with Godot console support or anything else about Godot itself.
Basically all big publishers have their own pipeline and in-house teams for porting / QA / certification and it's all built around Unity or Unreal. So it's all about market share.
So yeah choosing Godot will certainly limit your options in terms of what publishers might fund your project.
I think all the reservations about Godot are valid, but let me offer my perspective. In 1996-1997 I remember meeting with Epic to evaluate their engine in develop for a game a AAA game at Activision. I remember in the late aughts (like 09?) being asked to evaluate Unity for a VC that was considering investments and wondering how much commercial developers would actually use it.
These engines are all risky until they aren't. And Godot certainly seems at the tipping point of adoption. Also, all game engines have strengths and weaknesses so that you would want to use Unity or Unreal in many particular cases for a long time. But Godot also has some strengths, not the least of which is that it is open source.
The key thing I would watch is the transition to 4.0 and Vulkan. That seems like a point at which they can either pick up momentum or lose it. The SDK problem for consoles can easily be solved by contractors / middleware if there is enough good games to make it worth the time to bother.
I like the engine but I don't think it is super competitive in 3d. For example, to use it on Quest you have to use GLES2, which is missing a number of features. Quest 2 is a mobile GPU, so you aren't going to be state of the art but I have seen more games that seem to squeeze more performance out using Unreal on that platform. Hopefully the switch to Vulkan will help them get better 3d performance on mobile gpus.
There are a ton of changes in the works from Godot 3. to 4. One of the biggest problems with Unity, in my experience is compatibility as the engine moves forward in versions. You always see projects that are stuck on older versions of Unity because the team doesn't have the time to make the changes so it works with the new version. In general I haven't seen that as a big issue for Godot. Code for old versions seems to run on new versions. But I have never seen a jump as big as the one to 4.0. The question I am wondering is will they be able to make that many changes to the engine and have it be reasonable to transition projects.
They can't be universally true can it? I know Hades is built on a basically in-house engine, and I think it released on all platforms simultaneously... then again that studio might not even qualify as "indie" especially now... are custom engines like that really that rare nowadays?
Supergiant games doesn't have a publisher, they publish it themselves so they can do whatever they want. I don't really consider them indie, to me "indie" is when the people developing it are also the people funding development, meaning people make choices without worrying about what others opinions.
As for self made engines, if you make it yourself then that is a risk. If you make it in unity or unreal then the publisher knows they can easily find people to help you ship it if there are problems, but for a self made engine it could be unsalvageable.
I guess it's depend on your goals and what kind of game you are buidling:
* Funding. Making games is hard and while some of them can be finished using limited resources and free time. Having even small salary is better than living off kebabs and ramen (depend on location). Also artist dont usually work for free.
* Expertise in limiting your creativity. If you actually want to finish and release something then having deadlines and feature cuts is actually a good thing. Yeah most of these 1000 cards on "Ideas" list wont be implemented, but you'll get something done.
* Marketing. Making a good game is not enough nowadays to get any return on time and money invested. Bare minimum to launch on Steam is to collect 10,000 real wishlists before release since otherwise your game wont be features. Wishlists alone is a difficult task that require deep know how in traffic arbitrage since otherwise you'll spend 5x more money. Also making good marketing
* PR. Even in a team of 10 project management and coordination take a lot of effort. Dealing with press, youtubers, streamers and possible future community is a hard work that might require more capacity than you have.
Yes you can be self-funded and everything like marketing and PR can be done in-house, but it's cheaper for publisher since they usually have dedicated people working on each area full-time. It's doable to make it all yourself, but every unique role will distract you from actually making fun game.
Also publisher that invested money into your project will also be motivated to at least get that money back.
> The lack of console support comes especially from the fact that there's no company behind godot itself that can become a licensed Nintendo developer for example.
The lack of commercial entity isn't the problem. The problem is that adding any sort of platform support to an open source engine is completely incompatible with the license terms of the console SDKs.
> 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.
Why would this be the case? You can contract with a company that has experience porting Godot games to Switch to do the technical work. But you would have your own distribution agreement with Nintendo and you would certify and publish the game yourself.
> The problem is that adding any sort of platform support to an open source engine is completely incompatible with the license terms of the console SDKs.
There is a port of SDL2 to Nintendo Switch that is accessible to anyone that has a distribution agreement signed with Nintendo. There's no reason Godot couldn't have the same kind of support there.
I’ve never done any game dev but have been programming in various domains for a long time. If I wanted to spend a few weekends making a “hello world” game in Godot, where do you recommend I start?
As a starting point, I’d like to make a single-player open world procedurally generated isomorphic map that I can explore with a hovering camera. Is this easy to do?
Thanks. Dwarven Skykeep is my first real commercial project too. So I'm not going to give you any obvious learning tips as anyone can find some good tutorials on youtube. Advice about trying out gamedev that I could actually give are:
* If you can start with some paper prototype or just create some digital visual gameplay screen mockup. Its easier to work toward something you can see.
* Start small and dont bother with code architecture or quality. If 3D seems to hard start with just 2D. Your first goal is to get MVP as quickly as possible. Prototyping on boxes is the best.
* Once you get literally anything running more ideas will flood your mind. So write them all down instead of concentrating on just a single task.
* If you stuck with one idea just jump to another one within the same project. This way you'll find what works.
* Dont hesitate to look for references or play some demo versions off Steam and look for ideas. It much easier to see good and bad sides in someone else game and it help to make your one fun.
As about technical side: isomorphic map does sound like algorithm problem and not game-engine problem. At least on 2D side that I primarily work with Godot have all you need to procedurally generate scenes and reuse them afterwards.
For what it's worth, Godot is actually used quite a bit for gambling machine games. I've got a few friends who work for companies in that space doing the art.
> You can't even [common action] without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line.
To be fair, in my experience this is par for the course in Unity too
Caveat, this is a meta post. I'm not a gamedev (not professionally at least), and don't have experience in either.
This reminds me of something I rant about often, linux naysayers on HN. Because of them, I tried buying a macbook in 2015 and had some of my most frustrating experiences in my life, culminating in a talk for a national conference I had to redo on a friends windows laptop in half an hour because it failed to display on the projector. Turns out the HN crowd who kept saying "mac is unix like linux but better since it's not a bazaar open source mess" aren't always right after all.
People have some bad experiences with X product where X product is often open source and being open source explains the bad experiences. However, when Y product also offers similar bad experiences (and even worse ones) but they paper over it in their minds because "it just happens" although it's probably just because they're used to it. Repeat for photoshop and gimp (my SO is an animator and adobe products crashing is a common experience, as is redoing work in case a save was forgotten), linux and mac, etc.
Anyway, I'm not a gamedev, I just see a similar pattern and it's hard not to notice.
As a Linux user on my daily drivers and a Mac user on my work-issued machine, I agree with this sentiment completely. Linux has weird issues a good amount of the time if you're trying to do unusual stuff, but so do Windows and Mac, and on those platforms you're less equipped to pop the hood and fix the underlying issue.
I have to agree with this. I moved off Windows into Linux as a daily driver mainly due to issues with docker support (pre WSL2, but even that had filesystem issues the last time I tried to used it). I recently accepted a new position that provided a Mac M1 and it's just a generally frustrating experience comparatively. Specifically, anything that involving keyboard directed window management is either non-existent or flaky at best, and a ton of functionality that it just inconsistent with the rest of the OS / applications (why is a separate fullscreen the default functionality, and why can you no longer Alt-Tab + Cmd + Tilde to a window that's been made fullscreen if you have a second non-fullscreen window open?).
Maybe my flow just isn't compatible with the OS (it feels very visual + mouse oriented), but between a previous ~2 year stint with another Mac-only job and these ~3 months, about the only thing I have to say that's positive about the OS is the spaces feature.
And like you mentioned, even when I had an ambiguous error on Linux, there was usually enough information to find a similar enough problem online to at least narrow down what I should investigate.
Yeah, Mac's UI of spaces/desktops is so busted that it usually takes me a couple tries to get the window I want. I've also watched another user lose track of every window that goes fullscreen.
>I had to redo on a friends windows laptop in half an hour because it failed to display on the projector
What situation would possibly require you to redo a presentation because it can't display on a projector? PowerPoint is cross-platform and Keynote can export to PowerPoint. This seems like hyperbole.
I second this opinion. As a (non-hobbyist) game developer, I started my current game with Godot, but after running into many issues including performance which was the final dealbreaker, I decided to port the whole game to Unity.
Finally I could focus on developing the game rather than running into engine related issues and limitations and having access to all the time saving assets in the Asset Store was (literally) game changing. Having the Asset Store is a whole new world. And as a dev with funds, paying for assets to save weeks of time was a no brainer.
Back to Godot, yes deleting stuff in Godot is pretty scary cause there is (or at least was) no way to know what effects/errors it could cause.
GUI system (at least last time I used it) was very unfortunately not well designed making it extremely hard to get consistent positionings. I feel it's so bad that just using HTML+CSS would be better cause then it would be possible to confidently put things and keep them where you want to.
And yes, overall as someone who has also used the C++ side, it does feel like some guy's homebrew engine. I felt things weren't as solidly designed as they could be. And this is talking about foundational stuff.
The C++ source code is really not modern C++ (or you could call it anti-modern C++).
I would not advise anyone to develop a game on it if your livelihood depended on your game's success.
Of course people can and will prove me wrong by still powering through and creating a successful game with it, but your time is better spent using a more mature engine like Unity or Unreal.
Even if you want to get your hands dirty and help fix bugs or add features to the engine, there is no guarantee that your PR will be merged.
Game development is probably the most riskiest type of software development already business-wise. No need to up your risk.
Of course if you are a hobby indie dev and do it just for the enjoyment of building things, then no problem.
As for Godot's future ... well it's been many, many years, but if I understand correctly they're mainly still working on 3D rendering features. There are tons of other areas that are still the same with the same limitations as they were years (5 years+) ago. I think with not so solid foundation and the pace of development, it will take many many years if ever to catch up to Unity.
I do like the way Godot engine does some things and I do hope for it's success as competition is always good. I just don't have much faith in it from what I've seen. I do hope I will be proven wrong though.
> 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.
they'd ultimately choose them because of support more than jank, to be honest. They care less about the ability to fix a bug 3 years down the line than the ability to phone up engine experts they don't have to directly hire to fix it for them.
I'm assuming Godot doesn't have such support past enthusiast forums.
Yep, I bought enterprise support for my studio for exactly this reason.
Great example: Apple updates Xcode to 14, which includes some undocumented change to Clang that ends up completely breaking Burst static initialization. Unity's fault? Nope. But they fixed it quickly. When Godot breaks, glfh, that's on you.
Is this something that happened or an example of something the could happen? I mainly target Apple’s platforms and while moves like this don’t leave me feeling confident about Unity, the acrimony and legal battles between Apple and Epic (and Epic’s level of support for development on Max, especially ARM Mac)leaves me feeling even less confident about switching to Unreal.
I think Epic’s doing a pretty reasonable job of distinguishing between Apple, and people that develop in its engine on Apple machines. The 5.0.2 release, for example, had loads of MacOS-specific bug fixes. There are compromises versus developing on Windows, of course - you lose hardware Lumen, for example. No native AS support either yet, but it runs okay through Rosetta depending on what you’re doing.
I'm surprised you would say that Godot has more bugs than Unity. Unity is an endless fountain of bugs that keeps on giving when you least expect it.
Godot does lack some features. But that depends entirely on the kind of game you're aiming for. The 2D market like RimWorld could easily move to Godot.
> The 2D market like RimWorld could easily move to Godot.
I really all for Godot and our team have positive experience with it, but I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts. Might be Godot 4.x will get improved profiler, but for now it's really lacking.
So unless you move everything into C++ I dont think you'll manage good performance in Dwarf-Fortress-like simulation game. Though might be I overeastimate how much simulation / physics game like RimWorld require.
Personally, as a professional programmer who's interested in developing a Dwarf-Fortress-like sim game as a side project, I've been keeping an eye on Bevy as an open-source game engine that would likely have good performance for a sim game with lots of moving parts. Being a Rust-based ECS game engine lends itself to a lot of potential for heavy parallelization, which you'd need to maximize that sort of number crunching performance on a modern CPU
You can implement the heavy stuff in C++/Rust, compile it to a dll and import it into whatever engine you want. The hardest part about making a game like dwarf fortress is to implement a good UI, making it run fast is much easier and shouldn't be a priority when selecting engine. Game engine performance is mostly about rendering and not your custom simulation code.
I mean, there's rimworld for an example of "dwarf fortress with better UI but slower simulation". Commercially it's worked out for them, but I do find myself wishing for the scale of DF when playing rimworld. The new game UI does warn you away from even the larger map sizes they do have implemented though.
Rimworld implemented their simulation using unity objects, if they wanted to increase scale they could rewrite it to run the simulations in custom code and thus run just as fast as dwarf fortress. Or faster if you parallelize it well. Then they could just look at the world state and render that every frame, which is super cheap since its just a bunch of 2d objects and a bit of text.
> I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts... C++
I don't see why that would be. Godot has bindings for all sorts of languages including C#. Why would it be any harder to write C# code with Godot bindings than C# code with Unity bindings?
Problem is not to write GDScript or C# code in Godot, but profiling and performance optimizations: toolset of the engine is really lacking in this area so it's really hard to find out what are major bottlenecks are and what is eating most of frame time.
Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. If you have a lot of objects and non-obvious performance drops it's really hard to find them.
In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.
> Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. ... In case you use C++ you will be able to use mature profilers
Why couldn't you use your regular mature C# profiler like you do anywhere else? It's officially supported. Both the mono profiler and JetBrains work.
> In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.
You can do exactly that right now. Use the C++ profiler to find hotspots in Godot and the C# profiler to find hotspots in your code.
I can easily answer both of your questions. Because I obviously want to know how much time exactly game code takes together: both engine and "scripting". Using weird combinations of two different profilers is not a good day to work on code. Both Unreal and Unity have proper usable profilers and Godot doesnt.
Also unfortunately our project is usingGDScript and there is no profiler for it.
Another option that is still young (young as an Open Source project, but has a lot of historic development behind it) is O3DE (https://www.o3de.org/) I think this has a lot of potential if it gets enough attention and development.
I don't have much hope for it, I know several people that worked for amazon lumberyard (it's old name), that have quit because that organization is collapsing in on itself, losing engineers way faster than they can hire, and the engine is still buried under a mountain of tech debt inherited from Cryengine (that real Cryengine has resolved a long time ago)
One quit because the new render was so performance intensive, an rtx 2080 super was min spec for the lightest of scenes to achieve 60fps.
Another because he became the last engineer on his team after all the others quit and moved elsewhere at Amazon.
Even hoping open source saves it is unlikely, as it's only in name. The CI and infrastructure to meaningfully develop it open source does not exist.
As a final nail, the install process takes over two hours, which is just not competitive.
> dropping the scene graph/ECS way of doing things
A scene graph and an ECS are basically polar opposites, arbitrarily heterogeneous object trees to facilitate genaral manipulation vs. rigorously organizing data to facilitate good performance. Please explain what you mean.
engines like Unity and Godot encourage you to organize your conceptual model of your game in their scene/node and component systems. if this is the only way you learn to make games, you will only ever think about things in these high-level, abstracted terms, instead of thinking about what the computer is really doing, thinking about what you want the computer to do, and thinking about how simple you could make things if you didn't force yourself to use such systems inherent to these engines.
Do you mwean, why use a good, "abstracted" game engine if you can make a bad, "simple" one yourself? Or why make portable games "instead of thinking about what the computer is really doing"? Do you think advanced games could be made if the designer doesn't "think about things in these high-level, abstracted terms"?
I suggest an exercise to understand the value of abstraction: a remake of a Commodore 64 game using JavaScript (Canvas to simply draw pixels, nothing fancy).
> Do you mwean, why use a good, "abstracted" game engine if you can make a bad, "simple" one yourself?
you should definitely make something good instead of something bad. I don't understand what you mean by this.
> Or why make portable games "instead of thinking about what the computer is really doing"?
I'm assuming by "portable games" you mean the code is easily able to be ported to other platforms. code portability and "thinking about what the computer is really doing" are not orthogonal concepts.
> Do you think advanced games could be made if the designer doesn't "think about things in these high-level, abstracted terms"?
there is nothing wrong with thinking about game design in high-level, abstracted terms. what is misguided is thinking code should be written this way.
> I suggest an exercise to understand the value of abstraction: a remake of a Commodore 64 game using JavaScript (Canvas to simply draw pixels, nothing fancy).
I'm having trouble understanding why you've made this suggestion for me? what does it have to do with anything?
I was the engine architect for a couple of team game projects I worked on in college a few years back. at the time, the Unity ECS/scene hierarchy system was The New Hotness and everyone was evangelizing it, professors were encouraging us to explore using it (without giving any implementation or theory advice—our first project had to be written in C89, the second, C++).
it was a gigantic waste of time and resources. we could have made our games functionally identical in a fraction of the time if we just did things the easy, obvious way, and then we could have used all that extra time to make those games that much better.
I'm having trouble understanding the question—there's plenty of open-source games that do not use ECS or a Unity-style scene graph. this mode of thinking being the default is relatively recent in the history of video game development. if you've never tried something like that before, PICO-8 might be a good starting point. this blog post might also prove useful: https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...
I've only slightly dabbled in game engines, and have only been exposed to ECS and scene graphs, so I was asking for other methods, since they don't seem to be nearly as popular. Searching gives me results, but I can't qualify them, so maybe aren't "interesting" to actual game devs. I added "practical" because this is HN, where sometimes theoretical tangents take hold. :)
Honestly I think most sensible ways of organizing renderable entities end up approximating either ECS or scene graphs. The difference is that you’re doing the management yourself instead of relying on engine’s functionality, so you get way less features but way more performance due to lack of unnecessary overhead.
There are kinds of games where simply having a input handling function, logic tick function and draw function executed in a big loop is pretty much all you need, and I assume that's what GP is talking about. I like to write games this way on game jams and it serves me well.
OTOH, there are also kinds of games that I simply wouldn't dare to write this way without figuring a solid abstraction out first, and things like ECS can often fit pretty well for that.
I have used Unity since 2007, Unity 2. This is by far the biggest blunder in their history. Did John Riccitiello get a visit late at night and capitulate? What happened? As a long time user, pusher and investor now, this concerns me deeply.
In the second link above, a Bing ad is presented to download Chrome while describing a domain of "www.google.com" but when clicked takes the user to googleonline2018.com ... maybe my expectations are out of date, but how is that possible? The otherwise excellent article doesn't explain.
What do you mean by "describing"? If you mean the thingy in the bottom of your screen when you hover over a link, this is trivial to fake and Google itself is the largest user of this "feature". In a Google search, right click a link and copy it, then paste it somewhere. It will be a long ugly google.com tracking URL, even though what your browser showed you in the hover display was the link to the actual website.
I tested it in Firefox and Chrome. While they both display a spoofed URL in the status bar when hovered, they differ if you right-click the link. In Chrome, nothing changes. In Firefox the status bar string changes to the actual, not spoofed URL.
At least in Firefox, one can check easily what the actual URL is before clicking without having to copy-paste elsewhere.
If it's callstack-based the event handler could easily just run the redirect in setTimeout. Making it time-based might work, but would break a lot of common use-cases. Maybe they could block only cross-origin redirects?
There still is the issue of Mozilla being the only one without a direct incentive to prevent this fix from rolling out. With their whopping 3 percent market share, I doubt they'd be willing to break a web feature we've had for decades.
The way the faking works is that the site catches your click event and redirects you to somewhere else. Therefore, the only fix is to prevent such redirects. Preventing JS redirects would break many things. AJAX form submission with a redirect at the end, for example, is very common.
Preventing them in onclick handlers of a[href] elements would break fewer, but then you have the issue of correlating the redirect with the click. If you simply ban window.href= in the handler, sites could simply use setTimeout or set a flag and have a repeating background task trigger the redirect when the flag is set. Alternatively, you could do something like prevent all redirects X seconds after a link is clicked. Unfortunately, that would only discourage sites that are trying to be fast (like Google). Scam sites are usually slow and bloated anyways.
The trick works by cancelling the link click event and redirecting somewhere else in JS. The only way to prevent that would be to not allow any redirects in JS, including buttons.
Sorry i misstated, it was the article at the second link from post i responded to. first image of that post, under where it says 'Get Chrome - Download Chrome Today' there is a green text that shows www.google.com. I thought that was enforced by the search engine and not able to be manipulated.
At the risk of insinuating too much, there is a concerning incentive for Bing to provide corrupt links to Chrome.
That definitely seems like a major flaw with Bing's search ads. They should be either deriving that green domain name, or verifying it matches the link, or at least verifying that you own that domain.
I can't find a current Bing search ad whose green domain name doesn't match the domain of the destination of the link. Hopefully they've fixed this by now.
Interesting. I had not known that. I tested it in Firefox and Chrome. While they both display a spoofed URL in the status bar when hovered, they differ if you right-click the link. In Chrome, nothing changes. In Firefox the status bar string changes to the actual, not spoofed URL.
At least in Firefox, one can check easily what the actual URL is before clicking without having to copy-paste elsewhere.
It seems to rewrite the link when it gets a mousedown event. Once I right-click, or if I left-click and then drag (to avoid an actual page navigation), the new hovered URL is the google.com/<tracking> version.
Also this only seems to apply to search ads/promoted results. Organic search results don't get rewritten, and copying and pasting a link address gives me the expected destination URL.
GOG.com sells games that do not have DRM and are generally not evil.
But the unity games on the platform - they all phone home and send back detailed telemetry on what you do in-game. (I also know paradox games are a mess too)
Thankfully the GOG terms allow you to install and run the games offline without requiring these shenanigans to play your game.
Slightly off topic: in [2] the first screenshot showing "download chrome" query in Bing - do I understand right that the green "google.com" text is not the actual domain of the ad link?
I couldn't reproduce this, Bing no longer shows me ads annotated that way. But that seems like a strange feature to let the ad owner present custom domain name...
You can usually pick what domain you want to show up there when you buy an ad. It's common so you can use obnoxious chains of tracking links redirecting into each other and not show up as emjcd.com
Sure (I mean that is shady but whatever) but at least it would seem logical to verify the redirect chain ends up on that domain or better yet (since the redirects could change later) only allow the domain if ownership has been verified though DNS or similar.
I simply don't see why I should be able to buy ad that shows "google.com".
But if the ability to override the domain is truly that important, then there needs to be manual vetting of the ad buyer and the target domain. I'm sure you could automate it with signed TXT records, but I think there should still be a human in the chain to at least double-check everything.
I'd say that's almost all mobile ad networks, as it's not the network themselves but the ads.
This is good for both companies as Irnsrc gets deeper down the stack in terms of data and targeting and unity gets more spend flowing into their systems increasing their efficiency.
Too bad the IDFA issue is slowly killing all forms of performance advertising. Unity should be looking to buy studios akin to Unreal IMO.
[1] https://www.benedelman.org/news-021815/
[2] https://blog.infostruction.com/2018/10/26/adware-empire-iron...