Companies have a "core product" they sell that most of the time it costs a lot to develop, in R&D, physical materials, whatever.
Ultimately, to be competitive, they tend to sell that product at minimum/no profit margin, then obtain most of the revenue from "augmented products"..
A very simple example is, you buy a water heater that costs $10 (core product), then they sell you an extended warranty for $2 (augmented product). The company makes its actual income from the later..
With software it's the same, in the case of something like Unity or Unreal, the engine is the actual core product. It costs a fortune to develop, so the companies rely on augmented product to turn profit (ads, online services, etc)..
Now what happens if the market changes and the augmented product revenue diminishes? (As example, general income from advertising is down due to restrictions by Apple, more competition in the online service space, etc)..
This means that, as augmented products turn no profit, the company is forced to turn back to the core product for profit, either reducing R&D cost (firing people), or changing the business model (charging royalties). This means, even a profitable company can fuck up majorly..
But with FOSS, the equation changes. There is the notion of open ecosystems. The core product is developed by a community of individuals and/or companies. They all benefit the same from it..
Here's my GDC talk about it:
Because the core product cost is near none, companies in this ecosystem can benefit from simply investing in augmented product and having much higher profits. This is why so many FOSS companies have been so successful recently on the enterprise side...
My wish is that this model finally comes to the game industry, so we can all benefit from this open ecosystem. Godot is meant the stepping stone into this and Its important that industry realizes how dangerous is to rely on proprietary solutions that develop technology at loss.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The best piece of advise I can give to those moving from Unity to Godot is: You have to imagine Godot "Scene Tree" as "A tree of components without entities". This has two quirks:
- Its much cleaner to understand scenes at a glance
- Composition is far more flexible.
Thread🧵
You don't need multiple scripts per node for behaviors, add more child nodes with scripts.
Also, prefabs or scene composition as a concept do not exist. You can simply instantiate or inherit any scene anywhere else. You can also make the instance editable and do local changes..
And, ultimately, understand the concept that there are no "global settings" per scenes. Scenes are just nodes.
Things that in Unity belong to a scene, such as lightmaps, navigation, environment, etc. In Godot is still just nodes, allowing to mix and match anything as you want..
While on the topic of switching software. I started doing 3D modelling far before most artists today. In 1994, I learned 3D Studio 2.0 and even back then I used this to make videogames. I was very comfortable with 3D Studio, but in the late 90s I moved to Linux..🧵
Of course, while working on Linux was a blast for me as a programmer, doing 3D on it was super hard. There were some FOSS projects at the time but nothing came close to 3D Studio. Until Blender came out..
For a year or two I was extremely annoyed that Blender was so weird and strange. I though many times "why did they not just copy 3DS interface which is far more intuitive than this mess?" But I eventually gave up and learned it and loved it..
I made this graphic to explain how I see in my mind the difference between proprietary and FOSS innovation.
FOSS is everywhere and relies on the collective intelligence, while proprietary can focus investment better and advance faster in specific areas.. but.. 🧵
While it seems proprietary innovation has an edge, FOSS can also catch up very fast, so proprietary software innovations often have a limited window to profit until FOSS alternatives appear and displace them. Unless they keep innovating and reinventing themselves, of course..
The idea that large companies have lots of money and hence FOSS can't catch up is a common myth in my view. FOSS often has better quality and quantity of human resources, simply by brute force elimination and hence it tends to produce better software.
Letting aside that a lot of developers felt (rightfully) offended with this meme, I think few people realize why this change happened or what is behind this. In my opinion the following are the reasons why the industry came to be like this: 🧵
1. The main event that changed everything was the rise of digital marketplaces. Before them, if you wanted to publish (or even get investment for) a game, you had to go through a complex process of lobbying for publishers with retail access. That strong gatekeeping is gone now..
2. This, combined with tools that made it easier to develop games, such as Flash and then Unity, allowed much smaller teams to create amazing games for a much lower cost and eventually saturate that market..
This is probably a good example of how Godot is just designed different to most other game engines. In most existing engines, if you want to start taking advantage of multiple cores to optimize your game logic, you have basically two choices: 🧵
The first one is to use Jobs. Jobs is basically using threads yourself but sugar-coated with things like dependencies. It is still a very low level solution, requires large rewrite, and does not solve most of the thread-related problems such as race conditions, IPC..
The second one is to use ECS. This solves more problems for you, but its still considerably more complex to use and adapt your game logic to and, if your game requires dozens or hundreds of complex entities (not [tens of]thousands), the DO nature is not really an advantage..
With @godotengine my feeling is that it succeeds by being written backwards to most of the literature you can find on game engine topics. Due to this, it is of little interest to most seasoned engine programmers, it attracts a different kind of developers instead..🧵
If you read on how to make a game engine, you will actually find very precise material:
- ECS
- Data Oriented
- GPU driven rendering
- Render Graphs
- Complex memory management
- etc.
But this is not how development is done in Godot..
Godot development prioritizes that a feature exists first with the least cost of implementation, and that this feature is optimal enough so at least it can be used in most cases. The goal is to understand how this feature must work and how users expect to utilize it comfortably..