u/Zvyaginsky

We're a small horror studio and over the past year students showing up asking for internships went from occasional to constant. Game design, Unity, Unreal, 2D and 3D art. Most come out of university programmes that teach the tools and never make anyone ship anything. The usual answer is to hand them a slice of a real project. We tried something else. Teams of three, one designer, one artist, one programmer. Two months each, one finished game.

The split is the part worth stealing. One month to build, one month to polish. I expected the fights to happen in the first month. All of them happened in the second, because by week five the thing runs, and every instinct they have says it's done and it's time to start something new. Learning that a working game and a finished game are different objects is most of what they actually took away.

Four games came out of it. A minesweeper reworking where you play a vet, a cozy game about small animals catching bugs, a Reigns-style card game about a mute doctor, and a top down pixel art shooter about a girl going after the corporation that killed her father. All four are in 12 languages now and heading for release, and we're taking them to Tokyo Game Show.

Question for anyone who's localised short games. Was it worth it? These run under an hour each and I still don't know whether 12 languages on something that small pays for itself or just looks thorough.

Follow up to this: https://www.reddit.com/r/UnrealEngine5/s/STrAnfrb5Z

I'd gone from a fake second camera to Planar Reflection, and Planar was crashing whenever the camera crossed between it and a Lumen volume. Someone in that thread pointed me at hit lighting for reflections instead of fixing Planar. I said at the time it probably wasn't viable for our target hardware. Then I tried it anyway.

Turning hardware ray tracing on is what exposed the actual problem. Our config had r.GenerateMeshDistanceFields=False and r.RayTracing=False sitting in it. Software Lumen traces against distance fields. No distance fields and no hardware RT means nothing to trace, so it had quietly collapsed to screen traces. The config came over from UE4 and still had r.TessellationAdaptivePixelsPerTriangle and r.LightPropagationVolume in it, neither of which exists in UE5. Nothing errors. It just looks worse than it should and you assume that's what Lumen looks like.

First run after enabling everything gave us a GPU crash. D3D device removed, which everyone reads as running out of memory. The log said DXGI_ERROR_DEVICE_HUNG with 6022 MB used against a 7131 MB budget, so it was a driver timeout, not memory. Hit lighting on mode 2 plus reflections at full resolution plus every sublevel of the house loaded at once, on a laptop 5060. Mode down to 1, reflection downsample factor to 2, sublevels unloaded, and it held.

We kept mesh distance fields switched on so software Lumen still has something to trace on cards without RT.

Virtual Shadow Maps threw Non-Nanite Marking Job Queue overflow the moment we enabled them, because VSM is built around Nanite and our content isn't Nanite yet. Same reason one bathroom costs 1952 draw calls.

One thing still broken. Since enabling the skin cache our MetaHuman grooms render as red and black blocks. The config had r.SkinCache.CompileShaders=False, so the binding never had a skin cache to attach to. Does the groom binding asset need rebuilding after that flag changes, or is there something else that has to be redone?

Every projectile was Spawn Actor on fire, Destroy Actor on hit or lifespan end. Fine in testing, fine with a slow-firing weapon. Then a playtester picked up a fast-firing one and frame time spiked every time they held the trigger. Wasn't physics, wasn't rendering. It was garbage collection. Spawn and destroy actors fast enough, and the engine's constantly allocating and cleaning up. Something has to pay for that. It paid mid-fight.

Fix was a projectile pool. Pre-spawn a batch, keep them disabled until needed. Fire re-enables and repositions one instead of spawning fresh. Hit deactivates it instead of destroying it. Same result on screen. None of the churn underneath. Wish I'd profiled before assuming it was projectile count. It was never the count. It was the spawn and destroy rate.

Anyone else trace something like this back to churn instead of what's actually on screen?

We ditched the traditional HUD entirely for our horror game - health, objectives, all of it lives on an in-world fitness bracelet and phone instead of overlay elements. Felt like a slam dunk on paper. Then we playtested the first real chase sequence. Player needs to know their state in under a second. "Glance at your wrist" is a fine ask in an empty hallway. It's a terrible one when something's behind you. Ended up splitting information by urgency instead of by device. Time-critical stuff went ambient - audio cues, screen behavior, environment - nothing you have to go looking for. The bracelet stayed for everything you'd actually choose to check: objectives, inventory. Immersion held, panic stopped depending on the player finding a UI element mid-chase.

Anyone else running into this with diegetic UI - how far do you push "no HUD at all" before it fights the gameplay instead of serving it?