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.
It's the end of the road for Unity. ( at least what most of us think Unity still is, but it's not )
The technology was always more or less "fine". Unreal Engine didn't "kill" Unity and it will not in the future.
For the better part of a decade, Unity tried to become not-sure-what but way more than "just a game engine", and that's the problem, I don't know exactly what and neither do they.
To be clear, Unity is not "dead" and will not be dead for a while, but the writing is on the wall with this "merger".
I'm not sure how is Boeing and who is McDonnell Douglas but I already wrote the off my mind.
> Unity tried to become not-sure-what but way more than "just a game engine", and that's the problem
IIRC most of their revenue comes from Unity Ads, so they'd be dead if it wasn't for this weird pivot. From the business POV, not being "just a game engine" probably saved them.
Unity is arguably the most popular game engine and has a large market place for plugins/extensions. It is almost unbelievable that there isn't a viable strategy to expand and refine the core product. My intuition here is that the product was taken over by people who wanted fast, huge financial growth, so they invested in what they saw as an opportunity to do just that, while weakening the core product and their image.
I think the key problem is that most game developers are broke and most games are unsuccessful if they even ship.
The "picks and shovels" business model where you build tools for customers who use them in their own enterprises can be very successful. But it does require those customers to be successful in their enterprises. (Or you can rely on customers to be willing to pay out of pocket at a loss because it's a hobby, as with music instruments.)
Without some kind of other monetization, Unity is essentially selling picks and shovels to miners on a mountain with almost no gold in it.
To be clear, I don't think this justifies what Unity is doing. But they are clearly trying to be a $$$$ business in a $ market, and are willing to sell their souls to get the extra $$$.
What? The video games is nearly a $200 billion dollar industry[0] and Unity is one if the most popular engines, if not the most. How is that a “mountain with no gold”?
However most users of Unity don’t make very much money if any at all. So unless they switch to a revenue share based model (instead of fixed license pricing) $200 billion is not that meaningful.
There's lots of money, but it doesn't go to developers. The big profits go to publishers. If you're selling tools to developers, you'd better hope they're able to pass the cost along to the publisher. If they can't, they're not going to be able to pay anything significant for your tools.
> From the business POV, not being "just a game engine" probably saved them.
I agree, but if they were a "game engine and everything around games" instead of spreading focus and recourses all over what they have been trying to do, my guess is they would be in a very good position now.
>> IIRC most of their revenue comes from Unity Ads
This was and is a really interesting business for them and I still think it is a great way for them to grow.
Unity is so entrenched in the game business that if they were seriously worried about profitability they could just raise their prices and curtail investment and they would have a solid business. Like many unicorns they have been favoring growth. But at their core they have a solid product that people who make a lot of money depend on. Yes, 99% of game developer make zero or less, but its a huge industry and some very profitable developers / publishers use Unity extensively.
Unity's been killing itself with it's own fragmentation. Instead of upgrading existing systems, they've been replacing entire systems but never reaching a point of being able to deprecate/remove an old system.
So now there's 3 render pipelines, 3 UI systems, 3 physics systems, 2 input systems, and so on.
This makes it harder for new developers to get started, and it breaks a lot of the content on the Asset Store.
Just the HDRP/URP split alone is such a mess, with URP feeling like the second-class system and missing important features (while being the one designed to work on a wider range of hardware). But HDRP is the render pipeline used for shiny tech demos...
Yep, that's it. The engine used to be developer friendly, now it's downright hostile due to fragmentation. Half of it is deprecated, the other half is experimental and feels second class. They keep piling stuff up, and information is scattered. A modern project will have three of four different ways of adding libraries or third-party stuff. And the worst part: I might be totally wrong, because they might have completely changed everything since the last time I touched it.
Which is a bummer, given that since the XNA story, Microsoft has decided to outsource to Unity the whole "how to do 3D in .NET" story.
Given that the DirectX team is quite anti anything but C++, as shown by all attempts that eventually were killed (Managed Direct X, XNA), Unity's death would mean most shops would just move into C++.
While C++20 is quite nice, it would be a pity if such scenario would take place.
> If you don’t know ironSource, they bring a proven record of helping creators focus on what creators do best – bringing great apps and user experiences to life – while enabling business expansion in the app economy. ironSource’s suite of tools and solutions provides the majority of the world’s top games and many of the leading non-gaming apps with the monetization, marketing, analytics, and discovery capabilities they need to build and run scalable app-based businesses.
I'm sorry. I must be dense. I still don't understand what IronSource does. I thought, from the name, that it was like Perforce, but that is obviously not correct.
Is this the same supersonic as supersonicads? If it is, the only time I have ever seen them is basically convincing children like me at the time to download malware in exchange for $0.01 in free to play mobile game credits...
The ads they served were absolute bottom of the barrel awful, no legitimate brands, not even like clash of clans or anything - half their 'offers' were lockscreen ad APKs that installed themselves as unremovable device administrators that would kill play store and settings if you tried to open them.
If you played F2P games, mobile games, korean free MMOs probably starting from a few years ago, maybe half a decade ago, you will likely eventually remember SupersonicAds, Peanutlabs, Tapjoy (also purchased by ironsource), Matomy.
SupersonicAds would collect IMEI, ESN, etc as long as they could https://www.ftc.gov/system/files/documents/public_events/122... + wrote code bad enough and delivered their loaders over plaintext http to the point that google play was blocking apps including their sdk at one point
Different, but they also bought Supersonic Ads. I knew a handful of their employees, it was a good company until IronSource took over in 2015. Every single one tried to pinch their nose and stay on at IronSource but left within months
so IS owns both "supersonic studios" and "supersonic ads"? (though unsure if there is a difference anymore since the latter redirects to supersonic.com)
That being said .. many Mobile game ads are .. questionable.. but work for the publishers because you can trust humans to do shitty things. Check out https://www.reddit.com/r/shittymobilegameads/
Right, which makes the condescending tone of "if you don't know this company" even more egregious. They easily could've rephrased that to talk about ironsource's strengths without making a subconscious concession to the fact that 99% of their audience has never heard of this company they are MERGING with, not acquiring.
I mean, the phrasing might be needlessly contrived, but I fully understood what the company does (despite never having heard the name): Ad service and monetization. Granted, if you're not the type of game/app developer that Unity targets, you might not realize that this type of company even exists or how important they have become in recent years. But the quote perfectly describes what they do without going into unnecessary details.
I suspect that may be because you are familiar with the context.
I now know what they do, thanks to these comments, but that blurb I quoted is almost the Platonic Ideal for "Marketing Dross," and tells me exactly nothing, in many words.
At this point one my argue who Unity writes their blog posts for. But then again if you simply filter out the marketing speech, you'll end up with a pretty good, simplified description:
>If you don’t know ironSource, they bring a proven record of helping creators [...] bringing apps and user experiences to life. ironSource’s suite of tools and solutions provides [...] apps with the monetization, marketing, analytics, and discovery capabilities they need to build and run scalable app-based businesses.
Fair 'nuff, but I've spent most of my adult life, trying to explain fairly arcane technical stuff to non-technical people, so tend to use the vernacular.
I'd probably say something like "IronSource provides infrastructure to help game distributors make money off ads and measure the way their games are used."
Maybe also followed by "And they will make us FREAKIN' RICH!"
They run mobile game monetization, like micro transactions and ads. There is a reason they don't want to be open about that, everyone hates that and thinks it is toxic, but it generates a ton of money.
They have a sub-title in their article "Redefining the game engine – this is more than ads"
Then they go on to say "Advertising has long been and we believe will continue to be the economic engine for mobile games, driving players into their games and driving revenue at scale"
Then finally "It also reinforces our strong conviction in the long-term strength and growth of the in-game advertising business"
Seems like they are just doubling down on the ads in games mainstream...
presumably they mean adverts elsewhere for the game they are being driven to. Although of course if those other places are also mobile games, there is a certain bizarre oroboros to the whole idea... talk about zero-sum games, this is negative-sum
There was a GDC talk telling a a story where two bored indie game devs made an AI that churns out throwaway low-quality slot machine games as a joke, but actually earned much more money they they’ve expected (thousands of dollars per day). They jokingly told that the reason for high CPU numbers was their “anti-retention” model, where people get so bored by their game that they would literally click ads to escape into another game!
It does seem to be a circle: games carry adverts. The overwhelming majority of adverts is for more games. If you get the advertised game, you're now seeing ads in that game for more games...
Mobile games are a weird, impossibly self-sustaining beast. Developers (usually have to) dump money into advertising, even as their own games are advertising the competition.
Which as many people I’ve talked with about the mobile game industry tell me… is a cold calculated game of roulette, you burn money in adds trying to get enough attention to yourself that some whales spend enough on in game purchases to let the whole thing make some money… it’s a very “luck” driven market and they often are just experimenting with for side projects, which is one of the many less evil ways money flows into the mobile game advertising ecosystem.
The "luck driven" part is definitely true for Unity's whole niche. You can hear reports online of people "hustling", trying to hit jackpot, leaving jobs in order to spend a year doing random mobile in games to see what sticks.
The ads in smaller games push players away from those games, while pushing ever more players into the F2P megahits that are perpetually at the top of the store charts and still rake in millions per day (and therefore have great big advertising budgets).
There's little point trying to enter the mobile game market at this point.
I think the idea was to try and say "by hooking this into an ad platform, you'll get useful analytics like adoption rates, even if you're not serving ads," but the writer couldn't quite sell themselves to it.
I'm gonna guess there was a first draft of the doc that was basically "this is only about ads," but then someone who reviewed the doc said "this sounds terrible, explain how it's more than just ads," so they added a "this isn't just about ads" section and tried to come up with a list of bullet points, but they had very limited success because it wasn't true.
They actually doubled down when they started building their own Ads mediation platform after having an AdNetwork, but they struggled to grow. Their targeting tool "Pinpointer" failed and showed up on an earnings call.
> With ironSource, Unity will take the linear process of making games and RT3D content and experiences and make it an interconnected and interactive one - creating the opportunity to innovate and improve at every step of the cycle.
> What if that process was no longer "first create; then monetize?” What if creators had an engine for live games that by default enabled them to gain early indicators of success for their games through user acquisition of their prototype, and gave them a feedback loop to improve their games based on real player interactions as early in the process as possible?
Sounds like utter nonsense to me. Does anyone have an optimistic take on what this is trying to say in a good direction? I'm reading it as shipping more unfinished games, possibly with more ads
Sounds like Steam early access with metics and feedback. Maybe it’s referencing social media campaign to measure interest during the early prototype stage like star citizen has been doing.
Right? It disparages not putting profits first in the act of creation, but doesn't explain how its offering solves this problem. Instead it describes how to improve feedback loops. It leaves as an exercise to the reader how user acquisition leads to money. Filthy.
They want to turn their proprietary metaverse into a licensing cash cow using creator labor, thats the play. Each engine is doing their own version of the metaverse.
Been using Unity for almost 2 years. Had no wavering when Unreal demoed lumen, metahumans, etc, nor when Unity doubled down on mobile games (even though it's not my market). I've always liked how Unity doesn't respond to what other engines are doing and instead has just forged forward with what they've always worked toward; it's always been ol' reliable in terms of functionality and future.
However, I don't know how to interpret this in any other way than an exit plan for Unity. It's not an aquisition of ironSource, but a merger; this alone is a big change, but the release itself paints a clear picture of a complete reversal for unity: rather than being a capable dev tool for all platforms + non-games, it looks like they're now going to focus entirely on mobile and non-game applications? That's finally enough for me to consider a new engine (probably Unreal, maybe Godot).
I'm not inherently against whatever this hand-wavy solution to "first create; then monetize" is they're proposing, even though it'll 100% result in more low-effort, highly-monetized games that already plague the industry. I still have a lot of faith in Unity as a company and a paradigm pivot like this could result in something new if they play their cards right but... this being a merger puts a big question mark on what cards they'll have left to play when merging their deck with ironSource.
In short: there's a small chance this news will be very good long-term, but a high chance this news will turn out very bad for the future of Unity and unity devs that don't want to work with the kind of scammy monetization ironSource is known for.
I, for one, am happy for this merger / acquisition.
As a mobile games developer, I feel that Unity as a game engine has lost its way in the last few years, and the recent acquisitions reflect that. Instead of capitalizing on its merits and strengths - an easy-to-bootstrap multi-platform engine which is perfect for mobile development - Unity has opted to try and compete in the AAA/AAA-like market against Unreal. The recent announcments and the features actually being delivered from Unity support that strategic transition, and this leaves the engine in a state of constant conflict with itself.
Ask anyone who tried to integrate a 3rd party advertisment engine into their game and you'll understand why including a 'default' or an easy-to-bootstrap advertising and user-acquisition tool is a good move. This will hopefully streamline what is nowadays a less than ideal process. That is, if the merger will be capitalized upon instead of just serving the stock owners.
If it had been an acquisition, I wouldn’t have given it much thought. Maybe a pause, if I read some of the comments here about IronSource’s reputation.
A MERGER sends an entirely different message. Two messages. One, that unity is in dire straights, and two, that they’ve lost their sense of direction completely, given who they merged with.
It's confounding to me. AAA/AA has always been an unhelpful designation. Much of PC gaming's recent hallmarks have used Unity to great success, for example Hollow Knight. Developers used to proclaim their games were based on Unity almost akin to a badge of honor. That honor is diluted by Unity's pursuit of the indie mobile gaming space which is tarnished with microtransactions and ads.
Blockbuster titles may pull in more revenue. But they also can fail spectacularly. Is there a financial window for a tightly focused indie-game engine like Unity? I don't know. But it's hard not to see Unity's arc rhyming with the story of other VC-soaked growth-chasing operations.
Unity was never that great of an engine and tooling. I’ve only come across one extremely specific circumstance where it was technically the superior choice. Where it gained mindshare was its licensing deals before Unreal changed theirs. It grew with the mobile gaming boom and in order to keep growing they tried to grow to compete with the AAA/AA engines (most of which are either Unreal, in house and studio exclusive, or completely custom) and barely made it… I say barely because based on my experience and the conversations I’ve had, anyone who built a technically impressive game with Unity has probably built 80% of it themselves because the stuff that shipped with unity wasn’t up to the job. Unity survived because after a boom in developer mindshare courtesy of mobile games, lots of familiar developers were available to recruit for larger Unity projects where they got to spend their time reimplementing more and more of the entire game engine themselves on top of Unity because it didn’t really give anyone enough to build more than the simplest of games.
I’m not saying it’s broken or shit, it did deliver a working engine. Just that the entire marketing hype and ecosystem built on top of it was a technical house of cards held together by the suffering of the developers using it.
It’s the MongoDB of game engines, “worse is better” … because we spent most of the money on marketing, because marketing gets sales via our content marketplace before people can really discover how bad it is, and by then they’re fighting the sunk cost fallacy of the money they spent in the content store… just good old classic MBA “apathetic evil” … nothing special.
A big reason why I stopped buying/playing mobile games was due to the ads. I would be happy to just pay for a game and that'd be the end of it but its driven a lot of people away from mobile and towards PC gaming.
You may be celebrating this but you are just going to end up with less people watching your ads or downloading your game.
Unity dev here. I loathe mobile ad-driven games as well, but unfortunately Mobile dev is a numbers game. There is a gargantuan pool of regular joe-type people to whom ad-driven games are normality.
Power users like you or I rarely play these things.
It's all about optimizing the (user) funnel rather than the fun. If you don't you're at odds with google/apple, the platform operator, who usually promotes based on market performance.
So even if I were to make a fun mobile game where you have no advertisement or a t least a way to nuke the adverts, there's no customer base specifically looking for that, and if there was my game would be buried under a mountain of shit and i'd have to manually buy users ... so that 95% of them never buy the ad-free option...
Really the only option that prioritizes fun for mobile is bringing in an external audience.
Funny to think that the developers who haven't paid for the ability to remove the splash screen are also the ones likely to have optimized their games poorly
That's because very often mobile games are not developed with performances in mind or when they are, they'll use everything the device can give, often pushing it into throttling mode, because mobiles are not made to be run at sustain load for a long time.
Mobile is the most constrained platform to develop on if you want to actually have an optimized game, especially when supporting most Android devices.
Unity games run horribly on desktop.... how they think its legit a good mobile engine is beyond me
Like, Valheim runs like ass, all things considered. Battletech takes up like 50gb for a game without more than a couple of cutscenes and a camera that sits in the sky, and takes forever to load. Graveyard Keeper -- a PIXEL ART 2d game -- is for some reason made in Unity, and it takes way too long to load a couple of megabytes worth of textures
I don't recognize this company anymore. What a gibberish announcement. Their game engine is hardly discussed. Apparently the future is ads on mobile apps.
As a game developer with a released mobile game made with Unity I'll admit I had very mixed feelings about the news.
On one end it makes me wonder if Unity has it's priorities straight. On the other, I think there is definitely a lot of room for improvement with their own ad solution. Not too mention in order to fund any further improvements in the engine Unity needs to make money. Given that they produce no games of their own, it makes sense that they are expanding and improving their suite of services in order to bring in more revenue.
At least that's my hope. Unity has been in a rocky place for a while now (straddling the line between what it is and what it wants to be) and I think news like this combined with the layoffs can lead many to wonder if Unity is still committed to making a world class game engine that can grow with them for years to come.
> Unity has been in a rocky place for a while now (straddling the line between what it is and what it wants to be)
Yeah, they tried to compete with Unreal for some reason, and of course they lost. And when doing so they made the engine worse for small creators. For example it got a lot slower after they changed the asset database in the 2019.3 version, it feels horrible to use after that and just creating a new project now takes minutes.
It feels like they tried to compete with Unreal in the same way that Apple tries to enter gaming: very half-hearted attempts that they think are very serious. With Apple it’s “hey look we are a serious gaming platform. Look we have 3 new APIs just to support gaming and we paid a AA/AAA developer to port their game eventually” and with Unity it’s “Hey we can compete with Unreal. Look we even have new render pipelines with some of the features Unreal has and we bought Weta for some reason. Look we even put out a demo that barely works that we will never update showing just how graphically advanced Unity can be.” They both think these meager attempts are actually some great effort when it actually requires large investments of time and money to get where they say they want to go. E.g. Microsoft buying their way into the console market with the original Xbox. Basically just hemorrhaging money for an entire console generation so they could finally compete the next generation with the 360.
Apple’s gaming “strategy” — air quotes seem mandatory — continues to baffle me. It’s as if every year or two they put more pieces into place for a future that never comes.
(I’ll believe they’re serious about gaming when they release their own port of Vulkan.)
As a game dev and not a small creator I'd say Unity feels far more consistent and bug free, both editor and runtime. I can't say it's much faster but I wouldn't say it's slower.
I profiled this before and after the change using the same code files, the asset reload time is definitely much slower, and asset reloads also triggers a lot of times unnecessarily, often it reloads assets once when you select the editor window, and then it triggers another reload when you hit play, and then it triggers another reload when you end play, effectively reloading the code three times every time you change anything and test. This doesn't always happen, but it never happened before the change for the same code, maybe you can work around it but it isn't obvious what is causing it. The engine isn't slower, but the editor is much slower.
It might be that this improved some things for larger teams, but for the projects I've worked on it was a huge downgrade. Unity marketing said this change would speed things up for large projects, but for small projects with small assets and mostly code things got much much slower than before, which was my point that when they try to compete with unreal they are making the editor worse for smaller creators.
I'm not the only one experiencing problems, here is a thread:
What do you mean by a reload, exactly? If the asset isn't changed it won't be re-imported. If you're seeing erroneous reimports, then that is something you can track explicitly.
If you're talking about code compiles or script reloads, that's not really what the asset database deals with. (Although you can script imports so its not entirely unrelated).
That said, they did a lot of work to allow you to handle larger projects with (albeit manual) incremental compilations with asmdefs and the like.
I'm also pretty sure they also didn't add more code reload points, they just added load bars for when they did the code reloads. If you don't want the code to refresh automatically, you can just turn it off.
> If you're talking about code compiles or script reloads, that's not really what the asset database deals with.
Editor profiler says the asset database v2's AssetDatabase.Refresh calls a function named roughly ~"reload all assemblies". That happens every time you add an empty line to a default code file and at many other times. This didn't happen before, and that is where it spends most of its time.
> That said, they did a lot of work to allow you to handle larger projects with (albeit manual) incremental compilations with asmdefs and the like.
I haven't been able to work around this with asmdefs, if you use an assembly then changing any file in it trigger the above mentioned code reload.
> I'm also pretty sure they also didn't add more code reload points, they just added load bars for when they did the code reloads.
Editor is unresponsive for longer. I know they added more bars, but it is hard to mistake an edit/play cycle taking a second in 2019.1 and then taking 10 seconds in 2020.3 in the same project.
> If you don't want the code to refresh automatically, you can just turn it off.
I want things to reload automatically, disabling that is not a fix.
Given that Unity and ironSource stock prices have both dropped fairly substantially I wonder how that factors in to the deal going through at this time.
Does that make this a better deal for one vs the other?
It says ironSource share will trade for ~10% of a Unity share. Given that Unity is at around ~$33 a share and ironSource is ~$3 a share was the attempt to just combine forces for the benefit of both parties?
Sorry if this is coming off as a dumb question, trying to understand how this works to the benefit of disadvantage of them both.
To me this looks like typical ad industry consolidation. It's part of the eternal circle of advertising: when a new ad format shows up (radio, TV, web, mobile, etc) a zillion little companies pop up. Twenty years later there are just a handful of big players.
Unity made the choice to get into ads quite a few years ago when they acquired a company called Applifier. They ended up doing really well in mobile ads. IronSource, similarly, has done pretty well. But they're now competing with companies like Google, Facebook and Apple who have way more weight to throw around. At the least, if Unity had not done this acquisition, it leaves IronSource to be acquired or merged with someone else.
You could say, why is Unity in the ad business at all? But they're in way too deep to back out now. Ads are a huge chunk of their revenue. Trying to gobble up smaller competitors just makes sense in terms of trying to be one of the eventual survivors.
Well Unity is paying a 70% premium over what Iron Source was worth yesterday so it doesn’t sound like such a great decision financially. Also the absolute share price is not really that relevant since companies hardly ever have the same amount of shares.
"This tighter integration between Unity’s Create and Operate means a more powerful flywheel and data feedback loop that further supports creators’ success and understanding of what’s working between gameplay, design and their monetization efforts."
Aargh. Now what, built-in NFTs?
Ads in games have mostly been failures. You can sell items to your users, but ads in games are a bad fit. Either they interrupt gameplay, or they're ignored in-game product placement. This is also true for "metaverse" systems. It's not clear there's any role for "brands" in the metaverse. The systems which are profitable don't have them.
They're being more honest than you realize. In that quote they are basically saying they want this to make it easier for you to better target and milk the whales who play your stupid free-to-play mobile game. "Gameplay" here is being used the same as the gambling industry
Au contraire. Casual mobile games is the new television, and ads on television is a huge market. Or was a huge market; that spend will now eventually flow towards personal devices, a.k.a. mobile games.
I worked for too long on mobile games, ads mediation company are indeed the worst, IronSource included. It's a nightmare to work with their black box SDKs, and god knows what they do in that, in addition to tracking and showing ads (do you know some ads can take up more than 200MB ? That's sometimes more than the game I worked on...)
I hope this will incite more developers to look into open source game engine such as Godot and find better way to monetize games than ads.
I feel like there's room to innovate on monetizing gaming hobby projects without ads. And that Kickstarter and Early Access have polluted the well by asking for a one-time payment for an unknown final quality.
I'd be more inclined for something more of Patreon subscription model, with a game loop that had a very overt 'Hey if you enjoyed this latest update, consider becoming a supporter. If I get xxx supporters this month I'll keep making more cool stuff' with a clear connection to what would come. Regular monthly updates so long as monthly supporters exceeded a certain number.
I like this approach, I often thought of having it integrated into a game directly. Players could browse and select to sponsor from a few features I'd plan to integrate and thus allow them to have some say on what they'd like to see first as a community.
As of today, unity is worth 10-12bi, Ironsrc intended to go public at around 11bi last year, now they are being acquired at 4.4bi. Ironsrc main competitor, AppLovin is worth 12bi.
Ironsrc 2021 revenue was 553m, Unity revenue was 1.1bi. However, Ironsrc had a net income of 21m and Unity had a net loss of 531m. Both hold around 0.7bi and 1bi in cash respectively.
Does anyone there actually care about that… based on the history behind the company (well documented by other commentators on this story here) I can’t imagine management give a flying fuck about anything or anyone, except the money.
This whole press release was written for the executives of both companies, maybe the shareholders, but certainly not the employees, and definitely not the public.
Nit for @dang or OP - it's ironSource not IronSource
(This comment is not an endorsement of the merger which I'm personally not a fan of - we get an ad/installer company merging with the biggest non-AAA game engine company which creates all sort of problematic incentives)
> we get an ad/installer company merging with the biggest non-AAA game engine company which creates all sort of problematic incentives)
Whatever pushes people closer to Godot. Seriously though, the only thing I see that Unity has that Godot lacks is a rich asset / resource store, with lots and lots of options for whatever you want to build your game with. I would think the maintainers could produce such a store to facilitate funding the project and even provide their own offerings like code snippets for specific game types and then keep 100% of those proceeds (aside from payment vendor fees) towards the project.
It's either that or someone, somewhere with free time and energy builds their own and donates to Godot for every asset bought.
I really like Godot but I'm only a dev, I don't have time to design my own graphics, I just want to code different ideas to see how they go and go from there, I just want to download a few assets and get cracking, and right now that is far easier to do with Unity than it is with Godot it seems like. I think Godot adopting a Unity importer might help significantly.
I can think of a few others, though I did move from Unity to Godot and never looked back so clearly they're not deal breakers (for me):
- Doesn't handle 3D as well. Mostly optimisation stuff, though also things like procedural sky/sun is weaker I find with Godot than Unity. Though almost all of that are looking to change with Godot 4.
- As you mention asset store, but also just the size of the community. Can't really blame Godot for this though, their documentation is certainly very good which is about as much as they can do.
- GDScript is a great language, but I'm not a big fan of using engine-specific languages, rather than a generic one like C#. Of course it has its advantages, but it means you also miss out on whatever package manager comes with the language. Bindings remedy this, but they're not a simple out-the-box experience.
- Similar to above, GDScript and a lot of areas of the engine feel more strongly orientated towards fast and easy dev time rather than game performance. Its a personal choice so I can't complain much, and again bindings can help, but out the box GDScript of course isnt as fast as C# with ECS.
Thats about all I can think of, and as I say I use, and overall love, Godot so despite my complaints theres still more going for it than against it (for me)
> but it means you also miss out on whatever package manager comes with the language.
I didn't even consider that! Good call out!
> Similar to above, GDScript and a lot of areas of the engine feel more strongly orientated towards fast and easy dev time rather than game performance.
Correct me if I'm wrong or way off, but isn't GDNative (or whatever it might be called now) basically for those moments where you need a little more beef, but don't want to rebuild the entire engine, so you bring in Rust or D or any other language you know and love and bridge it in through GDNative?
Yeh so the bindings with GDNative do absolutely help performance, and I imagine Rust with Godot would be even faster than Unity with C# (You can also use GDNative to add ECS as well I believe), but out the box, and therefore likely the direction Godot is heading in, seems to favour workflow above performance.
That being said, it could be a "grass is greener" issue. There are plenty of engines that offer better performance but a worse workflow, Unity for one, that I'm not using and instead using Godot, and I guess bindings are as close as reasonably feasible to getting the best of both worlds, so I cant complain much.
Stride probably has a better chance at being Unity compatible being .NET and similar but it needs more polish to take on Unity. I only recently heard of it as it was used in Distant Worlds 2 but that game had an unfortunate launch and lots of bugs/compatibility issues.
As someone who uses (has used?) GoDot, would you say it may become to games what blender is to 3d modeling? It's such a huge slowdown to move from something you know (unity) into something new
Seems like Unity isn't too proud of that either. I wasn't able to figure out what ironSource do from the first few paragraphs due to them dancing around the truth.
I heard recently that most of Unity's money already comes from Unity Ads, so this is just the natural extension of that. It's sad, but that's our reality I guess.
Unity must be in more trouble than I thought. There's no way a game engine company that's doing well would merge with a company like this. They're reporting earnings in a month, so it must be pretty bad.
> In other words, there is no engine that is legally allowed to distribute console export templates without requiring the user to prove that they are a licensed console developer. Doing so would violate the console manufacturer's NDA.
Console ports of Godot are offered by third-party companies (which have ported Godot on their own).
Maybe it is semantics but it Sounds more like no console support. You pay a third party to port your game to consoles. Perhaps those third parties have built support into Godot, but as you said, it is not public, and not accessible to you other than as a paid service.
It’s about commercial contracts and NDAs and that sort of thing. You can’t share the console SDKs, so you can’t ship the features with the rest of the code due to contract reasons, so after your done, you share for a nominal fee (because contract/business reasons) the bindings between Godot and the console SDk, and then the studio who wants their game on console still has to get all the console SDk contract stuff done before they can actually build and test a console version.
I’ve looked into it with both Unreal, Unity, and a couple random engines that advertised their explicit support for various consoles… there is always some business contract stuff with the console owner company before you’ll ever be able to compile for the console, and then depending on the engine there is sometimes a deal you’ll have to cut with the company that built the console specific code/middleware/port/shim/adapter/etc … no game engine ships out of the box with a “build for XBox/Switch/PlayStation button” even in Unreal you’ll need the platform SDK installed and wired up which is documented from the Unreal side, but not provided, you have to get all the other half from the console vendor.
> no game engine ships out of the box with a “build for XBox/Switch/PlayStation button”
Nobody's putting the bar this high. I just want console support, I don't care much if I need to log in to Nintendo's website to download it. I'll need to go there to publish the game either way.
> in Unreal you’ll need the platform SDK installed and wired up which is documented from the Unreal side, but not provided, you have to get all the other half from the console vendor.
Sounds absolutely fantastic, can I get that for Godot?
Sure but the lack of transparent pricing is not appealing. As far as I can tell Unreal's Playstation/Xbox support is free on the engine side once you sign the console SDK stuff. Unity's comes with their Unity Pro subscription, which has a known price.
I was hoping unity would be the way for the indie studio to build AAA experiences (and indeed it seems to have already achieved that in some areas), but this kind of merger makes me skeptical about the long-term viability of that vision.
I do currently hold a long position in Unity, but this whole thing is starting to feel a bit yucky to me. Between Godot, UE, and the vast unknown of undeveloped engines, I think I need to re-evaluate my strategy.
My feelings exactly. Lately I feel like Unity is getting wrecked by Unreal. I consistently look at Unreal acquisitions and developments and think, wow they are adding immense value to game developers / designers there.
I have held off on migrating over, given that (from what I have read), I agree with Unity's long term vision (move to .net, package manager, rendering pipelines, UI toolkit, dots). The real question for me though is if they are going to pull it off, or get derailed along the way.
> I agree with Unity's long term vision (move to .net, package manager, rendering pipelines, UI toolkit, dots). The real question for me though is if they are going to pull it off, or get derailed along the way.
I've had more time to think about this. Unity effectively has a golden goose of an ecosystem right now and they're about to murder it with boardroom bullshit. How much energy was spent on this merger that could have been redirected to doubling-down on the tech stack? Multiplayer could really use some more attention, IMO.
It's definitely not too late for them to correct course, but I've seen this path so many times I do not reserve any hope. I took a loss on my entire Unity position this morning to get out from under any future bad decisions.
> I've had more time to think about this. Unity effectively has a golden goose of an ecosystem right now and they're about to murder it with boardroom bullshit. How much energy was spent on this merger that could have been redirected to doubling-down on the tech stack? Multiplayer could really use some more attention, IMO.
I see your point, but in a way I think this merger makes sense to prioritize. I would argue the majority of their user base is using the engine in its current form for mobile development. Unfortunately Unity doesn't have a golden goose like fortnight to draw revenue while they are internally improving the engine. It stands to reason if they can draw in more revenue from ads from their pre-existing user base they have more money to keep them afloat when times are tough while they continue engine improvements.
To be honest I don't like it. I would much rather they double down on fixing the engine and solidifying preexisting solutions. But I do think there might be a method to their madness.
You might be right though, it might just be boardroom bullshit haha. I'm still holding out hope. And in the meantime I'm going to diversify my engine knowledge.
The real issue IMO isn't that they aren't doubling down on the tech stack or paying attention to multiplayer. It's that are doing that but have gone full Google and kill these projects after they enter alpha or beta.
For multiplayer there was the original UNet, then the FPS Multiplayer Demo stack, then HLAPI/MLAPI, now we're getting "Netcode for GameObjects".
That also means their new tech stack rewrite for ECS won't get multiplayer support until they release "Netcode for ECS" at some later date.
There's stuff like buying Bolt and then depreciating it months later for Unity Visual Scripting.
It's like they have a ton of teams working on rewriting the engine but none of them communicate and often find out they've been rewriting the same feature as another team.
> For multiplayer there was the original UNet, then the FPS Multiplayer Demo stack, then HLAPI/MLAPI, now we're getting "Netcode for GameObjects".
This doesn't seem like the correct timeline of events. Anyway, if you want a clearer picture why they decided to throw the packages away, I recommend reading the source and/or trying to use them. For your reference: https://github.com/needle-mirror/com.unity.multiplayer-hlapi
> That also means their new tech stack rewrite for ECS won't get multiplayer support until they release "Netcode for ECS" at some later date.
> There's stuff like buying Bolt and then depreciating it months later for Unity Visual Scripting.
Bolt is Unity Visual Scripting. I really don't know what you find so offending here (maybe except Unity's inability to develop their own tools in-house).
> It's like they have a ton of teams working on rewriting the engine but none of them communicate and often find out they've been rewriting the same feature as another team.
I can't come up with a single example of this. Unity occasionally has a tendency to develop a "vnext" tool while still supporting a "legacy" tool, which seems great for backwards compatibility (and for long-running projects), but it just keeps confusing people endlessly. I don't like Unity, but hell, I don't envy them for constantly having to deal with this shit either.
> Anyway, if you want a clearer picture why they decided to throw the packages away, I recommend reading the source and/or trying to use them.
This isn't really a good excuse for why core features have been rewritten 4x without a production release and with no legacy version available for the latest engine.
You left out MLAPI from your link and the FPS Multiplayer Sample NetCode
I mean actually release it in a way that's stable for teams working on a game. Not "This package is available as a preview, so it is not ready for production use."
The current roadmap plan is for Netcode for ECS to reach production way after Netcode for GameObjects.
Bolt is not Unity Visual Scripting. It's extremely similar but that only makes it more confusing. Bolt is a separate asset which is still maintained, the last update was a month ago.
> develop a "vnext" tool while still supporting a "legacy" tool
Except their only production level multiplayer library, UNet is not supported anymore. There is no official way to make multiplayer Unity games right now that isn't a preview package or deprecated.
For 2D you still have some other options though. GameMaker, even with all its faults, still gives indie devs plenty of room to make good games. And there’s also the route of using more barebone frameworks like MonoGame or actually make your own little game engine in C++ or C#. (You’ll be surprised how many 2D indie games were created in this way!)
I can recommend godot. Got into it last weekend and compared to unity it runs like a dream. No freezing for seconds every time you make a change to a script
While a Godot fan, there are some serious rough edges all over the place.
Godot 4 finally solves the insane widget sizing/positioning hell, but is still itself super unstable (scenes corrupted between alpha releases) and buggy (scenes broken on clean import).
It's going to take at least another year for it to stabilize and be close to production.
Meanwhile, the 3.x branch is simply lacking features.
It's OK for 2D, though. If you can stomach the UI widget hell.
I really wish I weren't years into a major Unity project, because I'd love to make the leap. Every single time I see Unity in the news these days, I simply think "oh god, not again."
The only "AAA Experience" you can squeeze out of Unity is hardware requirements for your game. Use Unity and you have guaranteed worse performance than AAA titles for the next 10 years at least.
IronSource went public last year via SPAC at over $10B of market cap. The merger or rather aquisition? happens now at $4B. Definitely a big loss for many of the investors and most likely a lot of the employees who couldn’t get out fast enough.
I think the key problem is that attention is the only currency that many children have access to.
Many many many kids have mobile devices now, along with tons of free time and a strong desire to play games. What they don't often have is access to a credit card to purchase games or do in-app purchases. I think that a big part of why so many games lean on ads is because it's essentially the main currency that kids have access to: their own time.
Not exactly answering your question here, but I shipped a mobile game worldwide about a year ago with both ads and ability to unlock whole game via purchase to unlock.
My ads are as unintrusive as I could implement (watching an ad via button press to unlock a level). So far I have seen mostly iOS users are willing to purchase the game while Android users will heavily lean towards watching an ad to unlock a level. From what I have read (and seen so far) it looks as though the way I'm implementing ads is going to be highly unprofitable
Additionally integrating ads in general was a huge pain in the ass. I initially looked to Unity, then Admob, and finally mediation of the two. Funnily enough at one point I looked at mediation via ironsource along the way as I had heard their Unity integration was pretty good.
If your curious as to the exact monetization mechanisms you can check them via my game below.
I don't know if they _rely_ on it, but recent NBA 2K games apparently have interstitial ads, even though it's a full-price 60USD game with yearly releases already.
Absolutely disgusting, I already doubt the value of yearly releases, as you basically pay for an updated roster, but this is just overreach.
On mobile, the best model seems to be FTP with ads, then a small amount ($5) to permanently remove ads.
I don't develop games, but if I did, this would be a great addition, if I could 1-click this workflow to drive revenue.
This could also have quite the network effect on the ad network itself. You're now able to say 'All Unity apps ship with this network' yada yada.
The dark pattern will be "All games now ship with ads, and developers don't benefit from the ads" type stuff in order to drive premium subscriptions from developers. That or instead of the developer getting the 70% cut of the $5 'remove ads' purchase, they're instead going to get 40% and Unity gets the other 30%. I'm sure they'll figure out how to enforce monetization.
Unity is the most popular game engine on Steam and has majority share of the mobile game market.
The fact that they can't survive two years of a pandemic without losing hundreds of employees and accepting a merger is indicative of the relative illness of the entire game tool service industry. This is a decades-old company that didn't have enough war-chest to float a few bad years.
Given these market realities, one should not expect quality of life in the games industry to improve without unionization or government intervention.
This is just a guess but I think the main issue with unity is that the majority of the games released with it float under their 100,000 revenue target in order for them to get a piece of the pie.
I believe this is why they are rapidly expanding their backend services and ads network in order to try to eke out profit in other ways.
> I think the main issue with unity is that the majority of the games released with it float under their 100,000 revenue target
Those games don't cost them anything, though. You'd have to explain trouble in terms of games doing worse during the last few years than they were historically, which is the opposite of the truth.
I see your point and I think it's a good one, but could them being a public company and their stock price plummeting not also affect their bottom line?
I genuinely am curious here, as I'm not well versed in how a companies stock price can affect their internal financials and ability to run the company without laying people off .
> The fact that they can't survive two years of a pandemic without losing hundreds of employees and accepting a merger is indicative of the relative illness of the entire game tool service industry. This is a decades-old company that didn't have enough war-chest to float a few bad years.
Bad years? I thought the pandemic was unusually good for at-home entertainment.
Worked for a mobile game company in 2020 and 2021. Can confirm that 2020 was a very good year revenue wise, if not dying off a little bit towards the end of 2021
That makes no sense. 18 months ago was January 2021. For Unity to be down now compared to then is fully compatible with the idea that (1) 2020 and 2021 were high points for the industry, and (2) things have started to die off since the end of 2021. That's exactly what you'd expect.
But the fact that 2020 and 2021 were historic boom years means that the description of Unity as just lacking the war chest to weather a couple of bad years is nonsense. These were great years, not bad years.
Unreal Engine having a field day with this one. Honestly I'm super disappointed in Unity and I regret having purchased so many plugins on their store that I never even used.
Soon we will only have Unreal Engine dominating the scene as Unity essentially just signed their own demise.
They also have many hardware companies. It's almost an annual thing that some megacorp buys an Israeli hardware or semiconductor company.
We used to have a good hardware startup ecosystem in Denmark because former Giga employees had more money than they knew what to do with after Intel bought Giga in 2000. However it slowly burned out for some reason. Maybe the 2008 crisis had something to do with it.
Do you know particularly few Israeli companies compared to lets say South African or Polish companies? Wouldn't that just mean it's not a "startup nation" as if it was, you would have heard about those companies? Your reasoning here seems backwards.
Bad wording on my part but there's a lot of israeli companies i have never heard of on top of THAT MANY i have.
There's prominent israeli startups and unicorns you usually know about like Wix or some old ones like (ICQ/Mirabilis) and then there's a myriad of small ones you stumble upon because they are in your domain area like logz.io.
But then you hear about a company with like 1k employees and you are like...wth.
> Do you know particularly few Israeli companies compared to lets say South African or Polish companies?
"Startup nation" has been a well-known nickname for Israel for some time. On a per-capita basis, Israel excels at both the number of startups created and the amount of capital that they attract.
Instead of chasing the ecs waterfalls they should have been iterating on their product... Or actually shipped one of their next gen features within a reasonable timeline.
It'll be very interesting to see the impact on the games market 5 years from now on this, no competant business is going to use Unity for new projects after this.
[1] https://www.benedelman.org/news-021815/
[2] https://blog.infostruction.com/2018/10/26/adware-empire-iron...