clnq

As the article says, it’s likely that the devs who previously would test their apps prior to release had higher quality apps just because they were experienced and skilled devs, not because of an arbitrary number of people testing the app for an arbitrary length of time.

If Google would want to get rid of shovelware on the Play Store, they know what to do - (edit: better) automated + human reviews, like Apple. That would be what would nip shovelware in the bud.

But they’re just trying to outsource the cost of that. It feels like one of those Google initiatives that was started by someone who cared, then got watered down to the point of counter-productivity by MBA logic.

No one is saying it, but a part of the reason is that a long power distance makes it difficult for a junior to object or negotiate a request. It’s usually a plain “yes, I’ll do it”, no matter the consequences.

Kaliningrad oblast is an exclave of Russia by the way. Enclaves are states like the Vatican - entirely surrounded by one state.

It’s a fine comparison in the context of what computer science means to programmers.

Prior to the 00s, software engineering was a lot more technical, low-level, and skilled work.

Today, a bootcamp will tech anyone to copy and paste things together from SO into a product.

To the average programmer, programming is much less science and much more art these days. Much less any kind of science (including rocket science) and much more something you slap together.

I worked in companies where an internet outage made all programming grind to a halt without Stack Overflow. You really can’t hope to go to the moon with that kind of mindset.

I’m not saying that we don’t have brilliant programmers who still write very rigorous low level code. But I am saying that they’re not really in demand all that much these days.

This also makes computer science courses focus on things like JavaScript in programming only. I would know as I work with low level systems, but only through my own tenacity, perseverance, and continuous learning. In my CS BSc I didn’t learn almost anything about low level work on modern day hardware that I use. It really was all Java and JavaScript, Web design, really basic computing and math. Af the end of my studies, I could explain a pumping lemma is and how to use a few JS frameworks, but not how large an L1 cache is on various machines.

So yeah… UX/UI vs rocket science — the scales in computer science have tipped a lot.

I also miss consumer computing in the 80s and early 90s. Everything in a computer was so accessible, programming was all close to the metal.

Won’t they have to investigate once a complaint like this is filed? It seems like the activist is trying to get more attention to this to hurry the investigation?

A lot of value in code reviews comes from knowledge sharing and collaborating on code. It is close to a pair programming exercise that many people in the team can partake in asynchronously.

I’m sorry for not answering many of your questions, but I do think it’s not worth it, at least in a professional context.

For personal use, it might be different.

A thing called the Competency Framework can help.

> In recent years, it seems like the whole world has become more ornery. Maybe that has something to do with the pandemic, or with political disagreements. Whatever the reason, people have become faster to attack, and slower to recognize each other’s shared humanity. One aspect of this has been a constant barrage of attacks on communication services

I’ve been feeling this very acutely as well, but most people I spoke to say nothing has changed. Good to know it’s not just me, although it’s unfortunate things are changing this way.

No, friend, poly counts are rarely a raging fire these days. Not 10k poly counts. That was in the 90s.

That’s a very good resource, nice find! I think we can agree CO is between AA and AAA. I think it leans much more on the AAA side from my industry experience, but arguments could be made that it’s not all the way there and that therefore it’s AA. But this is a bit semantic. They make AAA money and have AAA standards and marketing. And that’s a bit unusual for 40 people, of which 10 are probably admin and 30 are dev.

They have a large publisher (Paradox Interactive) who prescribes their schedules. They also made bet bookings from Cities: Skylines that put them quite evidently in AAA. Finally, they release the games for all major platforms. All together, this describes a AAA game developer.

In contrast, an AA developer would work with publishers like Annapurna Interactive, Devolver Digital or Team 17, while a III game would have a much smaller scope - like The Witness, The Stanley Parable, or Hellblade: Senua’s Sacrifice. It is clear that Colossal Order doesn’t work with a small publisher or make games of indie scope.

If you were just sealioning, don’t do that please.

The design was iterated, but the game assets are redone almost completely, and the systems appear largely reworked, too. This is evident when you play the game.

The scope of work done for this game was exceptionally large for a company with 40 employees, assuming it was done within the usual AAA timeframe.

So you know the saying “premature optimization is the root of all evil?” Producers love that statement because it removes half of the complaints around work being rushed.

Optimization is not done throughout the process and later there’s not enough time. Assets are made with bad topology and it would take time to redo them. Or it would take time to write a tool that retopologizes them automatically.

What I’m saying is by the time it’s “time” to optimize, there’s not enough time to optimize. It happens very commonly. But the alternative is taking development slower to do things right. And you simply don’t get investment for schedules like that in most companies. Not to mention that it’s goddamn hard to do when the execs lay off people, ask them to RTO, and induce serious attrition otherwise. Sometimes the team just can’t settle into a good process as people leave it too much. So you’re between a rock and a hard place — on the one hand: attrition and low morals, on the other hand: a tight schedule. This doesn’t apply to Colossal Order from my knowledge, but it does apply to many AAAs.

There is a problem at the root of this - extremely over-ambitious production schedules as norm. Most other things are symptoms. Most of what I described is a symptom.

> I place equal blame on them for delivering a subpar product, whether it's under their control or not.

What else is there to say...

> If they don't like the environment of a particular studio, they can always choose to work elsewhere.

They like it. The industry just has issues beyond their control which are in the process of being solved, gradually. No one will drop their dream job to satisfy your entitlement right now, sorry to say. You are free to not buy the game.

Because it is one of the 1,000,000 things to pay attention to in game development. Someone or some software probably just made a mistake in setting up its LOD. Or some dynamic LODding code didn't properly cull the LOD0 mesh. Or that code couldn't be finished in time. Or it was something else.

It's completely normal in AAA games to have a few imperfect and in-optimal things. Budgets are always limiting, and development times short. Plus, it's a hit-driven industry where payoff is not guaranteed. There are some things you can do (which are usually management-related and not dev-related) to make the game a success, but estimated bookings are rarely on-point. So trade-offs have to be made to de-risk - corners cut where possible, the most expensive part - development - de-prioritized. These are much bigger trade-offs than a single mesh being unoptimized. A single mesh is nothing.

It's a fun fact that this mesh is LOD0, and so is the teeth mesh. But that alone doesn't tank the performance of the game and is probably unlikely to be addressed in lieu of actual performance fixes. The fixation on these meshes in the thread is kind of excessive.

A lot of these comments are quite galvanized so I don't want to add to that - just giving more context.

> I don't buy that excuse.

This means you are, sadly, very uninformed. There is a lot of rolling with the punches in the games industry, and many engineers want to optimize things more, and work OT to do so (as there is an extreme shortage of time to do this in AAA space on company time).

Colossal Order has about 40 employees, even though they are AAA. Here - proven otherwise.

Great - not participating is and was always an option. But this does not mean it's not an ARG.

Hmm, it doesn't necessarily need to follow other game design rules. Sometimes the point is just to figure out the mystery.

All I'm saying is that capitalism does not prescribe greed. Take away capitalism and you have the same problems with greed. Take away greed and capitalism doesn't sound so bad anymore.

This is an ARG, not a real thing. There's merch and some "documents" to explore[0]. Sovereign barges in international waters, alpine underground labs - quite meaty.

The author of this article got whooshed. For anyone still thinking it's a scam or something, read the first words of their X profile bio[1]:

> An Alternate Reality Corporation

[0] https://delcomplex.com/archival-media/

[1] https://twitter.com/DelComplex

I ran a tech startup for several years and I can say you have a simplistic view of this. My company didn't want to be a unicorn, it didn't want VC money, and it didn't want the whole pie. It was funded out of pocket until it became profitable. It was under capitalism, and yet we had no investors other than the founders to be greedy for. We just built a product that was important for us, and we were content with earning enough for this to be worthwhile.

Capitalism is not synonymous with greed. We just idolize greedy people. We call them things like "successful", "self-made", "inspiring", or "capitalist" to absolve them of their greed. In the Soviet Union, people would call greedy people "successful", "self-made", "inspiring", and "communist".

It's really just the greed.

Assuming there is some ebb and flow in demand, they should keep employees around with nothing to do, yes.

Moreover, there is natural attrition. They can stop hiring, promote internally, and so on, until they’ve reached their desired head count.

The point is that both of these are doable when the company is wildly profitable. And they should be done for the negative secondary effects of layoffs (ruining lives, morale loss, people following their laid off friends out of the company, etc).

It seems like these days companies don’t even freeze hiring and grow competencies in house in times like these that much. They just assume (often wrongly) that they’ll quickly hire everyone they need once the demand picks up. But it takes years of training before an employee is fully integrated and has all the institutional knowledge to perform at their peak, and it takes many months to fill difficult positions.

Some people who have been around tech for a good number of decades have seen this fashionable layoff footgun used more than once.

Presumably 20+ years of experience somewhere far away from C++.

> Auto-fire is trivial to detect

Tell me you've never worked on an anti-cheat without saying you've never worked on an anti-cheat.....

Why do you even say this if you really don't know it?

In short - you don't want false positives with anti-cheat, you can tolerate some false negatives. Input timings and sequences are impossible to use for this, as button mashers (it's a pseudo-sport) can press buttons at up to 20 times a second - far faster than auto-fire would. Regularity of presses just takes care of the most obvious auto-fire, but once again - there isn't a clear human-robot threshold. And most auto-fire will be far on the human side.

So you normally use a composite or layered approach. If there are enough signals of cheating on layer 1, you do more thorough checks on layer 2, 3, etc. The higher layers can be other players watching replays, ML, behavior-matching, and so on. Layer 1 can be "too lucky" checks, speed checks, ESP (extra-sensory perception/clairvoyance), altered memory, data packet manipulation, suspicious IPs, honey trap code paths/memory locations/impossible game states, skill inconsistencies, stupid values written into obfuscated memory, etc. All of those, by the way, have significant false positives on a large scale. But higher layers are almost always heuristics-based (human or machine), and with high false positives. So all together - not good, not easy.

KM setup is easier to detect as there are certain expectations such a set-up must meet for the user, which are a different set of expectations from a controller. But it's still harder than one might think. Analog triggers can be simulated, noise can be introduced in smooth mouse movement, button presses that aren't feasible on a controller can be disabled on the keyboard, etc. Once again - the issue is with false positives. You don't want to ban a person because they play the game more "cheatey" naturally than the hardware that fakes it.

Tamper-proof hardware with an auth mechanism is a really elegant solution for near 0% false positives. You can't mod a controller if you can't open it.

And I suspect that players wouldn't mind buying such hardware if it put them in authenticated/cheat-free lobbies.

What Microsoft might doing here is a slightly different topic. All I am saying is that anti-cheat is really not what you're saying it is.

I mean… 1900. Noticed it too late for an edit.

The purchasing power equivalent of $1,200 in 1990 is about $40,000 today.

I think management was seeing such collateral damage as just rounding errors. But it did not work out this way.

Engineers above the senior level were far more likely to leave than juniors. This was because finding remote, well-paying work even today is still a lot easier for a senior, principal, fellow engineers, than it is for those less experienced. I would say principals and seniors were most likely to leave. They left the company I was talking about 2:1 compared to others.

Fellows/distinguished level engineers didn’t leave much either. But probably because the RTO mandate was negotiable for them, as many other things. Moreover, it might be difficult to move laterally to a different company and remain at that level, with that pay.

It was mostly that the middle fell out.

I guess companies always think they’ll get the undesirables and replaceables out with layoffs, but through a lot of secondary effects (morale, distrust, lack of stability, leaving friends, and so on) they often get rid of the people that are most in demand and hardest to replace.

It might not be 2:1 in every case, but I do believe that the ones in demand are most likely to leave in “soft” layoffs like forced RTO or whatever Musk was doing at X, where the employees themselves choose whether to to or stay and submit. If you just decimate the company evenly, the outcome could be less destructive.

A lot of people are talking about the numbers. But top senior engineers are hard to find. The ones who were let go also took institutional knowledge with them. This is why they are in demand, they are “proven” and they can operate much better in that role than their replacements.

I was not let go, but I left a company along with a wave of others (mostly those senior enough to be certain that they’ll find great work) when the company U-turned on their remote work promises. The team I was on was responsible for a major feature of the product, and only had two very senior software engineers, who both left in protest when it was ultimatum-style demanded that they’d move into commutable distance. It’s almost like we were let go. Like many people, we had moved away from an expensive city during the pandemic and were not looking to come back.

The company has replaced us with more than 15 contractors of junior to mid skills. Despite this, they are now periodically emailing us to come back, and work remote. It started as “come back, we will let you be remote”, and has evolved to much more appealing offers over time.

The difference between us and many more contractors is not that we’re John Carmacks and the contractors are graduates. It’s part seniority, but much larger part - a ton of knowledge about the systems the company had and the types of systems in the industry used for the feature we were responsible for.

Good luck replacing institutional knowledge with cheap labor. Every company thinks they’re special and they’ll have a great time with this footgun. And good luck to them! But I don’t know anyone who has found good employment now and wants to return to that.

Some layoffs could be more “amicable”, so I can imagine people wanting to return. But it will be hard for those in the industry who legitimately got much better jobs, which a lot of seniors that dedicated long tenures to the footgun company did. On the other hand, juniors might be easier to swap out than long-time seniors, though there are still costs to training them. It’s a lot of extra work before one employee is fully replaced by another.