Maybe you have 5 relevant calendar events but it lists 3 and calls it a day. That is from my experience far bigger type of problem with AI. Hallucination by omission
Funny, but I hope it doesn't catch on. This genre of games is rather free from ads and the last thing we need is corporations shoving their marketing agenda into classics.
This is precisely how you advertise. But the beauty is that you can only do this a few times before the formula becomes worn out.
Others will have to come up with something else, entirely different, that is equally inventive.
Brilliant ad on the part of IKEA. It has all of the right ingredients, is totally unexpected, outlandishly absurd, and hits at a massive audience. Truly peerless.
When I searched for papers on using LLMs, I found that typically, you can have an LLM generate code and then ask it to find GitHub projects similar to that code. Then you can learn by looking at the pull requests and seeing how they structure things
In the old days, if I wanted to understand why memory offsets, padding techniques, or data layout structures were written a certain way, I had to stare at a senior programmer's code all day or wait for them to reply. But LLMs, while they do flatter me, explain things at a level I can actually understand. And LLMs don't get annoyed.
-Why do you cut API boundaries this way?
-Why do you change the order of struct fields?
-Why do you deliberately insert padding?
Most of it depends on the background and context. Sometimes you add it, sometimes you don't. To understand this tacit knowledge, you need access to senior developers. But their attitude often depends on how promising the student is and what background they come from. On top of that, you don't have to rely on the respondent's mood, authority, or availability.
Programming is fundamentally a field that requires seniors. In my case, I had no such seniors at all. I learned to code by buying codebases from failed companies and studying them. My first job didn't hire me as an employee—they hired me as the CEO of a subcontracting company (because that was structurally more advantageous for the contract). So I wasn't given the patience to learn programming fundamentals gradually. I had to pay penalties if I failed. Most of the projects I worked on were the kind where failure meant bankruptcy for me. Naturally, there was no one to teach me.
Most of my knowledge comes from reverse-engineering the code I purchased.
People say LLM code contains falsehoods, but commercially sold code has always had falsehoods too. Honestly, if we're just talking ratios, LLM code has fewer falsehoods.
In that sense, I still think it's a matter of context. If LLM code is false, was human code ever really true? LLMs do lie. They generate plenty of incorrect code. But humans do the same thing. If a problem comes up, you just look it up then and there. For me, LLMs and humans aren't all that different.
Good programmers are ashamed to push anything less than good (at least in their own opinion) to popular public repos. Some of those same pedantic programmers have no problem pushing crap in enterprise repos, and feel absolved because they are pushed to focus on deadlines, new features, and refactoring is very rarely planned for. I did and managed a lot of corporate software development in companies big and small, and did my fair bit of M&As and looked at codebases of successful companies. I dont ever recall feeling impressed. And I am regularly impressed by the aesthetic qualities of popular open source packages. I think commercial code is mostly shit, with the exception of regulated, serious industries (power, space, flight, etc.).
To elaborate a bit more: open source is about 'symbolic capital' — it's about building a reputation that says, 'I can write code at this level.'
Commercial closed source, on the other hand, is about 'I need to make money by writing this.'
Generally, open source projects tend to have less code written over time, especially when the contributors aren't depending on it for their livelihood. But with commercial closed source, it's not uncommon to have to write 60,000 lines of code per month.
On top of that, open source rarely has to deal with requirements changing dramatically mid-development. With closed source, requirements often shift from the original plan, and you end up compromising code quality just to meet those changing specs. As a result, if you're comparing purely in terms of logical completeness, open source tends to be better.
For example, singletons are rarely used in modern open source, but they're still pretty common in commercial code these days.
dry fasts aren't always what they appear. if you have significant glycogen stores in your body as you begin your fast you wont be dehydrated for the first day or two as water is freed. what usually happens is someone who starts glycogen endowed discovers that they aren't thirsty when they start fasting and tout it as dry fasting.
There are many studios with their own engines that rival or exceed UE5 - which seems overhyped, because at this point they caught up with graphics fidelity without terrible performance that dread a lot of UE5 titles.
Recent notable example is Crimson Desert, they spent years building their own engine for this game and IMO they raised the bar when it comes to creating a huge realistic world.
Others that come to my mind are Decima and RE Engine.
As a Korean freelancer, I’ve spoken with former developers from Pearl Abyss. They officially work 10 to 7, but the relentless crunch culture drives most people out.
While the company is extremely proud of its proprietary engine, I was told it causes severe internal politics. The studio is heavily biased toward the engineers who built the engine. Another huge downside is the lack of documentation—you can't just Google your bugs. (Granted, this was the situation two years ago).
The CEO is famously known in Korea for prioritizing developers while devaluing writers and planners. However, even within that developer-first environment, the proprietary engine has birthed a clear internal hierarchy among the programmers
The main point of using a 3rd-party engine like Unity or UE is not to buy technical excellence, but to get a 'good enough' asset pipeline, authoring tools and engine runtime cheaper than building and nurturing your own inhouse engine and tools team ... especially when the best programmers on those teams are then poached by Epic or Unity anyway ;)
I agree and that's why I'm happy not all studios not going this route. It usually means they game will be unique above average because one of the reasons would be needing the engine to work for something else than a "typical game template".
Crimson Desert's engine is heavily derived from Black Desert's engine (called BlackSpace Engine) so it wasn't really from the ground up, but your point still stands.
I've read somewhere they had several attempts until they could comfortably support the scale of the game, so maybe it was just rebuilding some major parts
This is one of the most sane takes on shipping code using AI where it's being actively reviewed and it respects your colleagues' time and attention. I like it.
There are not good workflows for doing this for a whole scene, especially where accuracy needs to be preserved. One shot models seem to be very good at providing 3D from a single angle, but multishot is very shoddy at this point, and without seeing behind things you have no clue about what is actually there.
Also, try meshy and look at how many polygons or triangles you get from any of the model objects. Hundreds of thousands, when you retopologize still goes to the high tens of thousands.
reply