9 ms·

"And the reason why the game has its own culling implementation instead of using Unity’s built in solution because Colossal Order had to implement quite a lot o

"And the reason why the game has its own culling implementation instead of using Unity’s built in solution because Colossal Order had to implement quite a lot of the graphics side themselves because Unity’s integration between DOTS and HDRP is still very much a work in progress and arguably unsuitable for most actual games." This sadly tracks with my own experiences with Unity's tooling, where DOTS did ship but its implementation rots on the vine like every other tool they acquired. The company is woefully mismanaged, its been mismanaged, and given the very public pricing incident from a few weeks back, they aren't focusing on improvements to the engine, but on any way to scrap money from its users. Bevy's ECS implementation is really good, and I want to see it succeed here, in addition to Godex.

wilg 3y ago
DOTS is homegrown isn’t it?
- thrillgore 3y ago
  Right, it is. I intended to talk about Bolt and ProBuilder, tools they bought, added to the engine, and then left to rot. Although to build DOTS they did poach a lot of ECS and Data-Oriented folks like Mike Acton, who left earlier this year.
Sakos 3y ago
I don't understand how Unity burns through up to a billion in revenue every single year, yet their engine still feels so half-baked and unpolished. Where's all that money going?
- djbusby 3y ago
  Lots of cash can be burned in meetings and by managers of managers. I'm sure my case is not unique here but, meetings that cost $100k are common at $BigCo. And there dozens of those per day.
  - paulddraper 3y ago
    You have 5-hour long meetings with 40 people each costing $500/hr?
    - EwanG 3y ago
      Let me introduce you to the world of PI planning where two days of every quarter are spent with approximately 100 people (developers, program managers, etc) for each line of business to plan out the next quarter of work - even if 90% of it is continuing the work from the last quarter...
      - azemetre 3y ago
        Two days sounds lucky. I've been in SAFE plans where it took an entire week to plan things, it was unreal. Like you I met people I've never seen or heard of from the company all giving their input on software I'm creating. I'd never see them again until the next SAFE planning, only this time it felt like 1 SWE out of maybe 15 (yes there were only 3 teams of 5 devs, put 100+ in these SAFE meetings) contributed anything meaningful. Company wasted so much money, then the org shut down for spending $500 per customer per year in maintenance (this was a health insurance company) whereas the main company would only spend $70 per customer per year. You'd think leadership of the org would get fired for this but they were rewarded with other positions within the company to do the same thing. Unreal. Why do shareholder's put up with this? I guess the healthcare monopoly is the only reason to.
        tter3 3y ago
        Half a day is spent on collecting and analyzing the confidence vote. The results of the confidence vote have no impact on the plan except as a baseline for the next PI.
        KingMob 3y ago
        Ugh, I still shudder at our weeklong SAFe planning. At least I got a couple free trips to Europe for the meetings.
- intelVISA 3y ago
  Agile shaman took the wheel
  - psunavy03 3y ago
    Agile done properly is literally the opposite of this. Big Important Exec spouting Agile terms they don't understand and cluelessly forcing top-down crap on the teams, more likely. Normalize your story points, prole! Daddy needs metrics!
    - torginus 3y ago
      Personally, I've never seen 'Agile' done well. Every project where we made good progress was engineer driven. We talked to customers about what they wanted so see and we created tasks and implemented them. Every project managed by a dedicated servant-leader Six Sigma Kanban certified Scrum ninja-coach project has been a bureaucratic shitshow, with constant cargo culting to agile priniciples and forced ceremonies.
      - _w1tm 3y ago
        > Personally, I've never seen 'Agile' done well. Every project where we made good progress was engineer driven. We talked to customers about what they wanted so see and we created tasks and implemented them. > Every project managed by a dedicated servant-leader Six Sigma Kanban certified Scrum ninja-coach project has been a bureaucratic shitshow, with constant cargo culting to agile priniciples and forced ceremonies. The engineer-led project sounds more agile than the latter Agile insanity.
    - red-iron-pine 3y ago
      > Agile done properly No True Scotsmen would do programming this way!
      - psunavy03 3y ago
        Ah, yes, the classic internet tactic of making up so-called "fallacies" to avoid engaging with the other person's actual arguments.
- animal531 3y ago
  Their worst problem (compared to Epic) is that they don't finish projects. They'll want a new feature, for example new scriptable graphics pipelines which will allow them to modify the core rendering a lot easier. Ok that's fine, but then instead of implementing one they try to implement two, while at the same time completely ignoring the existing pipeline which everyone is currently using. The time to get the new pipelines working properly and onboard everyone is counted in years in this case. Those features they actually "finished", but there are so many experimental packages that just sit there forever, or work in a half-baked manner.
  - DonHopkins 3y ago
    They hired the TextMesh Pro dude Zoltran, what must have been six or so years ago, with the promise that he'd integrate TextMeshPro into the "new" UI system, which I was looking forward to. I was just recently reading Unity's web page about what's new in the UI system, which announced that TextMesh Pro is finally built in! That took a while. https://unity.com/features/ui-toolkit https://unity.com/features/ui-toolkit I really love TextMesh Pro and Zoltran's mesmerizing tutorials, I learned a lot about Unity reading his code, and he was totally into what he was doing and hyper productive when he was a highly regarded indie developer, but I got the impression (just guessing, no inside knowledge) that he was wasn't 1/100th as productive working inside Unity as he was on his own, or maybe they put him on something else than he originally went there to do. It's been my experience that user interface toolkits are often turf war shit shows. I hope he's doing ok there! https://www.youtube.com/@Zolran/videos https://www.youtube.com/@Zolran/videos i.e. the classic 9-year-old Unite 14 demo: https://www.youtube.com/watch?v=q3ROZmdu65o https://www.youtube.com/watch?v=q3ROZmdu65o
    - animal531 3y ago
      Oof, yeah the new UI Toolkit is another example of something that's dragging along. Even in their official docs they still recommend that you use the older system.
johnnyanmac 3y ago
>Bevy's ECS implementation is really good, and I want to see it succeed here, in addition to Godex. Godex is ultimately putting lipstick on a pig. it can improve performance a bit, but ECS isn't some magical optimazation to slap on as a plug-in. cache coherency in the gameplay layer can't fix engine level bottlenecks.
torginus 3y ago
Tbh, there are many ways to skin a cat, using ECS is not necessary to ship a performant game, not is it necessarily the modern thing to do. It's one of the many architectural patterns you can build a game on top of, and has many advantages as well as detractors. For example, Godot isn't really build around ECS, but the idea of servers which are mostly autonomous game subsystems that can process their area of expertise (rendering, physics etc.) mostly independently, and are loosely coupled to the general game logic. ECS architectures originate in the PS2/PS3 era, when CPUs were awful. Tiny caches, horrible branch mispredict penalties, slow memory, fragmented memory spaces and lack of a random access storage forced developers to build their games around predictable memory access patterns, that in general resulted in streaming architectures, where data necessary for the game data to be streamed in tiny chunks to be processed. While generally this is good practice even nowadays, with the advent of superfast CPUs with amazing speculative execution, great branch predictors, and tens of megabytes of cache, this is no longer strictly necessary, especially considering that most modern games haven't really increased that much in terms of stuff going on on the screen compared to say, a decade or two ago. It's still uncommon for the player to fight more than a dozen dudes in an action game. And in games with thousands of things on screen at the same time, often specialist logic and handling is necessary.
- nvm0n2 3y ago
  Sure, but surely a city simulation is the perfect textbook use case for a cache-friendly architecture like ECS?
  - torginus 3y ago
    Well, ECS only makes some operations cache friendly/parallelizable - namely linear iteration through the array of entities, where not all fields of each entity are used. I'd imagine a city simulation involves a lot of graph lookup and traversal, spatial lookups and is generally a hairy and messy affair, not sure how easy it is to adapt that to ECS. Then again, SimCity and Transport Tycoon simulated complex cities on, by today's standards, very frugal hardware, so city simulation might not even be such a CPU hog.

wilg 3y ago

DOTS is homegrown isn’t it?

thrillgore 3y ago
Right, it is. I intended to talk about Bolt and ProBuilder, tools they bought, added to the engine, and then left to rot. Although to build DOTS they did poach a lot of ECS and Data-Oriented folks like Mike Acton, who left earlier this year.

Sakos 3y ago

I don't understand how Unity burns through up to a billion in revenue every single year, yet their engine still feels so half-baked and unpolished. Where's all that money going?

djbusby 3y ago
Lots of cash can be burned in meetings and by managers of managers. I'm sure my case is not unique here but, meetings that cost $100k are common at $BigCo. And there dozens of those per day.
- paulddraper 3y ago
  You have 5-hour long meetings with 40 people each costing $500/hr?
  - EwanG 3y ago
    Let me introduce you to the world of PI planning where two days of every quarter are spent with approximately 100 people (developers, program managers, etc) for each line of business to plan out the next quarter of work - even if 90% of it is continuing the work from the last quarter...
    - azemetre 3y ago
      Two days sounds lucky. I've been in SAFE plans where it took an entire week to plan things, it was unreal. Like you I met people I've never seen or heard of from the company all giving their input on software I'm creating. I'd never see them again until the next SAFE planning, only this time it felt like 1 SWE out of maybe 15 (yes there were only 3 teams of 5 devs, put 100+ in these SAFE meetings) contributed anything meaningful. Company wasted so much money, then the org shut down for spending $500 per customer per year in maintenance (this was a health insurance company) whereas the main company would only spend $70 per customer per year. You'd think leadership of the org would get fired for this but they were rewarded with other positions within the company to do the same thing. Unreal. Why do shareholder's put up with this? I guess the healthcare monopoly is the only reason to.
      - tter3 3y ago
        Half a day is spent on collecting and analyzing the confidence vote. The results of the confidence vote have no impact on the plan except as a baseline for the next PI.
      - KingMob 3y ago
        Ugh, I still shudder at our weeklong SAFe planning. At least I got a couple free trips to Europe for the meetings.
intelVISA 3y ago
Agile shaman took the wheel
- psunavy03 3y ago
  Agile done properly is literally the opposite of this. Big Important Exec spouting Agile terms they don't understand and cluelessly forcing top-down crap on the teams, more likely. Normalize your story points, prole! Daddy needs metrics!
  - torginus 3y ago
    Personally, I've never seen 'Agile' done well. Every project where we made good progress was engineer driven. We talked to customers about what they wanted so see and we created tasks and implemented them. Every project managed by a dedicated servant-leader Six Sigma Kanban certified Scrum ninja-coach project has been a bureaucratic shitshow, with constant cargo culting to agile priniciples and forced ceremonies.
    - _w1tm 3y ago
      > Personally, I've never seen 'Agile' done well. Every project where we made good progress was engineer driven. We talked to customers about what they wanted so see and we created tasks and implemented them. > Every project managed by a dedicated servant-leader Six Sigma Kanban certified Scrum ninja-coach project has been a bureaucratic shitshow, with constant cargo culting to agile priniciples and forced ceremonies. The engineer-led project sounds more agile than the latter Agile insanity.
  - red-iron-pine 3y ago
    > Agile done properly No True Scotsmen would do programming this way!
    - psunavy03 3y ago
      Ah, yes, the classic internet tactic of making up so-called "fallacies" to avoid engaging with the other person's actual arguments.
animal531 3y ago
Their worst problem (compared to Epic) is that they don't finish projects. They'll want a new feature, for example new scriptable graphics pipelines which will allow them to modify the core rendering a lot easier. Ok that's fine, but then instead of implementing one they try to implement two, while at the same time completely ignoring the existing pipeline which everyone is currently using. The time to get the new pipelines working properly and onboard everyone is counted in years in this case. Those features they actually "finished", but there are so many experimental packages that just sit there forever, or work in a half-baked manner.
- DonHopkins 3y ago
  They hired the TextMesh Pro dude Zoltran, what must have been six or so years ago, with the promise that he'd integrate TextMeshPro into the "new" UI system, which I was looking forward to. I was just recently reading Unity's web page about what's new in the UI system, which announced that TextMesh Pro is finally built in! That took a while. https://unity.com/features/ui-toolkit https://unity.com/features/ui-toolkit I really love TextMesh Pro and Zoltran's mesmerizing tutorials, I learned a lot about Unity reading his code, and he was totally into what he was doing and hyper productive when he was a highly regarded indie developer, but I got the impression (just guessing, no inside knowledge) that he was wasn't 1/100th as productive working inside Unity as he was on his own, or maybe they put him on something else than he originally went there to do. It's been my experience that user interface toolkits are often turf war shit shows. I hope he's doing ok there! https://www.youtube.com/@Zolran/videos https://www.youtube.com/@Zolran/videos i.e. the classic 9-year-old Unite 14 demo: https://www.youtube.com/watch?v=q3ROZmdu65o https://www.youtube.com/watch?v=q3ROZmdu65o
  - animal531 3y ago
    Oof, yeah the new UI Toolkit is another example of something that's dragging along. Even in their official docs they still recommend that you use the older system.

johnnyanmac 3y ago

>Bevy's ECS implementation is really good, and I want to see it succeed here, in addition to Godex. Godex is ultimately putting lipstick on a pig. it can improve performance a bit, but ECS isn't some magical optimazation to slap on as a plug-in. cache coherency in the gameplay layer can't fix engine level bottlenecks.

torginus 3y ago

Tbh, there are many ways to skin a cat, using ECS is not necessary to ship a performant game, not is it necessarily the modern thing to do. It's one of the many architectural patterns you can build a game on top of, and has many advantages as well as detractors. For example, Godot isn't really build around ECS, but the idea of servers which are mostly autonomous game subsystems that can process their area of expertise (rendering, physics etc.) mostly independently, and are loosely coupled to the general game logic. ECS architectures originate in the PS2/PS3 era, when CPUs were awful. Tiny caches, horrible branch mispredict penalties, slow memory, fragmented memory spaces and lack of a random access storage forced developers to build their games around predictable memory access patterns, that in general resulted in streaming architectures, where data necessary for the game data to be streamed in tiny chunks to be processed. While generally this is good practice even nowadays, with the advent of superfast CPUs with amazing speculative execution, great branch predictors, and tens of megabytes of cache, this is no longer strictly necessary, especially considering that most modern games haven't really increased that much in terms of stuff going on on the screen compared to say, a decade or two ago. It's still uncommon for the player to fight more than a dozen dudes in an action game. And in games with thousands of things on screen at the same time, often specialist logic and handling is necessary.

nvm0n2 3y ago
Sure, but surely a city simulation is the perfect textbook use case for a cache-friendly architecture like ECS?
- torginus 3y ago
  Well, ECS only makes some operations cache friendly/parallelizable - namely linear iteration through the array of entities, where not all fields of each entity are used. I'd imagine a city simulation involves a lot of graph lookup and traversal, spatial lookups and is generally a hairy and messy affair, not sure how easy it is to adapt that to ECS. Then again, SimCity and Transport Tycoon simulated complex cities on, by today's standards, very frugal hardware, so city simulation might not even be such a CPU hog.