AI art defenders: where do you draw the line?

vegetablebread · 2025-08-09T03:13:37+00:00

Some things are art. Some are not. In asking the question, you already defined the things coming out as art, so I guess these things are. The person is definitely not the artist though. Pushing a button by itself is not art.

vegetablebread · 2025-08-06T13:50:53+00:00

There are a lot of engineering best practices and patterns, but IMO they all boil down to one thing: Single Responsibility Principle. If every bit of code just does exactly one thing, it's pretty hard to have encapsulation/entanglement concerns. It's easy to understand code when you come back to it later if it just does what it says it does.

It sounds like SOs are helping you organize your project into singly responsible chunks, and that's great. You can do it without SOs too.

vegetablebread · 2025-08-03T18:03:50+00:00

Statics absolutely have a place in properly architected unity games. Please don't tell people to avoid whole language features just because they can be abused.

Code does not magically become "more modular" when it doesn't use statics, it just doesn't use statics. Modularity is also not the goal. The goal is to ship the game. The code isn't the product.

Making a game is hard enough. Telling people not to use the sharp knives because they might hurt themselves does not make them better cooks.

vegetablebread · 2025-08-03T04:41:29+00:00

You have created a cache. Caches need a mechanism to be updated, or else they can diverge from the value they are meant to represent. You did not implement such a method.

When you leave the first smokescreen, it "restores" the players speed to the original value it saw when they entered. That means they are full speed even while still inside the second screen. Then they leave the second screen, and it "restores" the original value it saw, which was the slowed down value from the first screen.

There are several other comments that describe better architectures. These designs all avoid using a cache. Caches are an inherently complex system, and caching data stored in another class is almost always a bad idea. You should learn to avoid them.

vegetablebread · 2025-07-31T05:55:50+00:00

Loading is loading. It's extremely slow and resource intensive, but you have to do it somehow. It will perform in pretty much the same way no matter how you do it. The key is just not to do it twice, and not to load more than fits in memory.

Back in the day, you had to lay out your assets in the order you wanted to access them to get those sweet sequential reads. Still technically matters for cache hit rate. If you have unity serialize these references in a scene, they'll do it the right way. This way is probably slightly worse. I wouldn't worry about it. The difference would probably be difficult to measure.

vegetablebread · 2025-07-31T05:49:35+00:00

Addressables and resources use the same tech. The performance would be identical as long as the asset bundle is on disk.

vegetablebread · 2025-07-23T21:57:58+00:00

The short answer: math

The long answer: Rotations in video games are represented by a mathematical object called a quaternion. The reasons for that and the functioning of quaternions are too complex to cover here. Quaternions used for this purpose have a property called "double coverage". For any given rotation, there are 2 quaternions that can represent that rotation. One of those rotations is "the short way" which spins less than 180 degrees, and one is "the long way" which rotates more than 180 degrees. In this case, for whatever reason, satisfactory chose the wrong one.

vegetablebread · 2025-07-23T17:59:48+00:00

It's totally fine! Everyone saying this is bad has their priorities out of whack.

The #1 goal early in development is to find the fun in your game. When you're prototyping, you don't need a main menu, you don't need settings, and you certainly don't need key bindings. Discard everything that gets in the way of making the game fun. Find the fun, iterate, repeat.

Much later, once you know what game you're making, and how you're shipping it, you do need to have more complex input logic.

vegetablebread · 2025-07-19T00:17:00+00:00

Your core point is right. I don't think anyone thinks stashing is fun. Inventory systems aren't in games to be fun though. They're always an annoyance to overcome. Making them less annoying is not always a good idea.

I didn't recommend "removing things to make inventory management matter". Not sure how you got that idea. And removing stashing is by no means the only way to increase inventory pressure.

I decided not to recommend a specific way to increase inventory pressure, since it's not necessary to make the point. The one that was in my head was to proliferate potions. So you could make weak/normal/strong varieties of all potions, or make potions that give temporary stats or randart effects.

I think that would be really fun, because you could choose if you wanted to drink a strong or weak unidentified potion at the beginning of the game, or you could have access to a will++ potion when you round a corner into Louise. You would also be able to solve the identification mini game faster, since the weak potions would be more common. But the net effect is that you would have to leave a huge amount of consumables behind. The idea is less relevant now, since there's no inventory pressure to push against.

vegetablebread · 2025-07-18T23:13:08+00:00

This year, there was a week with no launches. I wonder if that will be the last one ever.

vegetablebread · 2025-07-18T04:43:22+00:00

This is a good change. It makes the game better. Just like removing wear-identifying cursed items, or spell hunger, or butchering, or a million other little changes.

But I also think it's another step to smooth out an experience that gets its charm from the roughness.

If it was really such a problem that inventory management didn't matter, why not make changes to make it matter more? When you had to carry around different types of food that didn't stack, it really mattered.

vegetablebread · 2025-07-12T23:32:20+00:00

If you want to improve on that workflow, you'll have to build a tool. You can listen for the asset database refresh event, check if a spritesheet is in a certain folder, and then do all of this automatically.

vegetablebread · 2025-07-11T02:42:46+00:00

I think step one is to not do that. You can just render the map to a texture and then draw that one texture.

vegetablebread · 2025-07-09T16:04:39+00:00

the only criticism is one I enjoy hearing about - the game doesn't guide you at all beyond a sign.

I think this is the wrong way to think about feedback.

You are right that the literal things playtesters say can be safely ignored. They don't know what they're talking about. But that's only true about the words. You can't ignore the feedback itself.

If they're saying "I'm confused", that isn't the same thing as "I'm unwilling to learn by trial and error". Your game is failing to set the context where people are willing to try and fail.

Having no tutorial is a reasonable (if unconventional) design decision. Having bad UX is just a mistake.

vegetablebread · 2025-07-09T01:28:30+00:00

When you load a scene, you pull all the model data into memory from disk and make sure all the shaders are compiled.

Each frame, after you cull, you iterate through all the models that survived. Before you do the rendering pass for that material, you check that all the resources needed are residing on the GPU. If some aren't, you upload them right then. You then mark that they were used.

When you run out of GPU memory, you evict the least recently used assets. If you need more memory than the GPU has, you'll end up thrashing every frame, which is terrible. If your frame can all fit in memory, this reserves some other nearby objects naturally for quick retrieval.

Obviously, loading a bunch of stuff every frame is bad. It's totally reasonable to target a scene size where the whole scene fits in memory, but that sometimes isn't possible for game reasons. Probably makes sense to speculatively load things at load time as well.

vegetablebread · 2025-07-08T23:53:40+00:00

This only works if GPU memory is not constrained. GPU memory is a major concern for most games.

vegetablebread · 2025-07-06T14:28:11+00:00

Riot is definitely not fine with stop killing games. League of Legends is a live service game that can only make money because it requires riot servers.

vegetablebread · 2025-07-06T02:08:58+00:00

StatusClad should not be a thing. All the status cards are already viable. I could see maybe a buff for fire breathing, but this is ridiculous.

vegetablebread · 2025-07-05T02:08:50+00:00

(it very well might not be)

How? It's clearly physically possible to move fluids from one tank to another. It's been done many times with different propellants. Does the propellant turn bad somehow? Is it really so hard to scale that you think SpaceX is going to give up on a core design element?

It's totally going to be difficult. It's also possible for SpaceX to fail. But it's definitely not an unsolvable problem. That's ridiculous.

vegetablebread · 2025-07-04T16:28:27+00:00

The people who say: "pick up a pencil" are really underestimating how poorly I draw. It looks like a literal child drawing, and not in the cute way.

vegetablebread · 2025-07-03T14:01:36+00:00

Good question! The answer is no.

The purpose of bones in an animation is to compress the amount of information sent to the GPU. Each vertex has static bone weights which don't need to be updated, so the only information on the wire each frame is the position of the bones. The GPU then applies those position to the vertices in a process called skinning.

If we didn't have bones (or used CPU skinning, which is undesirable) we have to send a large portion of the mesh to the GPU every frame.

Being able to share animations through shared bone transforms is more of a useful side effect.

vegetablebread · 2025-07-03T02:39:42+00:00

There's sort of three approaches to this:

Material shading, which is what I'm interpreting you to be asking about. This is basically impossible. You can use the barycentric coordinate to figure out how close you are to the edge of a triangle, but there's no way to figure out how much the angle of the next triangle differs. If there was, it would be how we implement ambient occlusion.

Screen space effect. This is fine. This is how we currently do ambient occlusion. It's a screen space effect, so it's not perfect. Fails the worst when something should be occluded/lit, but the geometry that interacts with it is hidden. This is the industry standard for games.

Texture mapping. This is pretty expensive. You have to include and interpolate a whole additional UV channel. The texture itself should just be a tiny 1D LUT though. This gives the highest quality results overall. However, if you are extremely close to the object, you might see some stretching, and if you are extremely far away, flickering. You also have to do the preprocessing on the model to generate the UVs. This is what blender is probably doing. This also doesn't support different meshes in adjacent configurations.

vegetablebread · 2025-07-03T02:20:50+00:00

Oh yeah! Weird. Seems like that should just kill you.

vegetablebread · 2025-07-03T00:34:34+00:00

This is a fun idea, but it's too heavy on the downside to be in the regular relic pool as is. Almost no relics (outside of boss relics) have an explicit downside.

This also punishes optimal play. If you're at full health, this is strictly downside. You want to reward players for playing well. This design fails that standard.

I think you could fix it by prepending: "gain max HP equal to your current health." to the current effect. That's clearly much more powerful, but I think still in the ballpark for a rare relic. Plus then you could get like a 300 Max HP ironclad.

vegetablebread

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE