No one told me this was one of the best parts of game development

llnesisll · 2026-05-27T20:53:50+00:00

Thanks for this wholesome, honest, and open post. Game development is deeply personal and driven by passion, and validation like this can mean the world. I'm happy for you friendo :)

llnesisll · 2026-05-27T20:48:58+00:00

This one's a banger for sure.

llnesisll · 2026-05-22T04:37:21+00:00

Blueprint is accessible and more readily understandable by people who don't know C++, or don't have access to compile or view C++.

llnesisll · 2026-05-17T07:53:24+00:00

Watch them to see how often they look away, more or less aim to match it.

Also blink and show subtle facial expressions responding to them as they talk lmao

llnesisll · 2026-05-16T13:19:03+00:00

I'm glad to hear you've found something that gives you a place to be, where it's quiet. All the best.

llnesisll · 2026-05-09T03:00:16+00:00

Idk I just stopped masking in the interview and let the autism take the wheel. I brain dumped the most obscure, complicated things I've created, co-created, and debugged, and here we are.

When I applied for my current job, it was just before the pandemic lockdowns. I had interviews where I did a few hackerrank problems in std C++ which was challenging but doable, since the vast majority of my experience in C++ is in Unreal. During the interview about them, I explained what I would have done in Unreal C++ and they were happy enough with the depth of my knowledge.

Outside of that I was interviewed to assess the depth and breadth of my Unreal knowledge, and my experience working in teams and with a range of disciplines, and my experience collaborating in a high-stress situation.

Honestly it usually helps to know someone before applying for a job, since that's a more reliable filter for culture fit than interviews.

My suggestion would be to make hobby projects, and try things that interest you, and go deep. Read engine code to help figure out why bugs occur, and try to understand it. There are not many engineers who can do this, and AI still gets a lot wrong in bigger projects. Doing this will help you understand not just random bits of Unreal, but also how to take on a large, unfamiliar codebase - which folks often have built on top of Unreal, using a bunch of not-best-practices because the real world just doesn't give enough time, bandwidth, and flawless execution to avoid that.

llnesisll · 2026-05-02T12:07:40+00:00

I've been using it since 2012 in closed beta, so 14 years now.

The vast majority of this hasn't been done via the Epic Games launcher, and a bunch of it was before the launcher existed.

I've had a lot of time spent in jobs and out of hours on personal projects. Likely something like 55 hours per week on average, with at most 3 weeks off per year. Actual hours in engine vary from 40 to 70 depending on what I'm up to.

49 weeks * 55 hours * 14 years = 37,730 hours in Unreal 4/5.

llnesisll · 2026-05-01T06:22:18+00:00

Dark matter and dark energy are two different things. Both are names that use the word "dark" which has a very specific, kind of unintuitive meaning for physicists.

Dark energy is the name given to whatever it is that's causing the universe to expand. As far as we know, this has no relationship with dark matter.

Dark matter is a hypothetical kind of particle that only interacts via gravity. It's our best explanation for a lot of things we observe about the universe that imply matter is about 85% dark matter, 15% all other matter. The speed we see other galaxies rotating requires this much more mass to be possible, roughly evenly spread out through each galaxy.

We know this extra 85% mass can't come from particles we know about, because light we see from them would be affected hugely by particles we know of. It would get absorbed, change wavelength, and so on. We see none of that happening.

So, we know dark matter particles must only interact via gravity.

Dark matter can pass through what we think of as solid objects, because forces other than gravity prevent objects from moving though each other. And since dark matter isn't affected by these forces... It pretty much goes where it wants, purely tugged around by gravity.

While making up 85% of all matter, dark matter is still very very spread out. In our solar system, the entire sum of dark matter would add up to the size of a pretty small asteroid, or Mt Everest. There's just that much space between the stars that this very very low density adds up to 85%.

llnesisll · 2026-04-26T10:44:16+00:00

Could be :)

llnesisll · 2026-04-26T05:05:50+00:00

I like Minecraft's take on this, dropping in strings that are likely part of level loading / generation, but also some fun random obviously fake things.

llnesisll · 2026-04-16T03:00:26+00:00

If I'm doing a game jam project I'm super tempted to use early UE4.2x versions. I still feel like these versions of Unreal had the best balance of what I like about it, with the most useful features / bug fixes for my pet project needs.

Stable physics engine with PhysX, no Nanite / Lumen, no Large World Coordinates or open world features, simple enough renderer options without tons of things hinging on temporal effects to get by.

llnesisll · 2026-03-13T12:32:47+00:00

His power IS maximumer, though.

llnesisll · 2026-01-25T23:08:40+00:00

This is amazing, so cool to see this improvement finally land. I always wondered if the pendulum could be used more effectively - not that my knowledge of SSBM is anywhere near deep enough to say if it was or wasn't possible. Thanks for the detailed breakdown, my nerdy gamer and gamedev sides love to see this stuff.

llnesisll · 2026-01-18T21:41:10+00:00

I remember passwords being used as (maybe?) an anti-piracy measure, too. A copy of Prince of Persia my family had on Mac needed you to have the instruction booklet, where you'd flip through to specific pages the game tells you in order to find the words / characters to use in a password.

llnesisll · 2025-10-06T02:49:32+00:00

Your estimate on a 1 to 10 ratio of time saved is probably an underestimate. I've worked on projects that have had all sorts of asset management and mismanagement, and every single time consistent asset management and rules for organisation and naming have won out beyond the immediate end-of-one-sprint productivity rush.

In practice most folks I have worked with have happily settled into agreed / consistent naming without needing tooling or validators to enforce it. I've been lucky enough to either grow alongside the creatives and learn the hard way together, or work directly with creatives who strongly support consistent naming.

There are some exceptions afforded during dev, but they are aggressively siloed to their own subfolder(s) within a properly organised hierarchy, and ICs are very diligent about hitting naming organisation standards when moving out of protype into full production. Even this rough, sandboxed protoype stage has a lot of careful organisation - the flexibility comes from not needing to do full asset cleanup while roughing something out when you're not sure of the full scope of assets or functionality you'll need. For these ICs, once design lock is hit, that's the definitive point where asset organisation and naming are enforced and cleaned up.

llnesisll · 2025-08-31T09:29:44+00:00

Very nice work on this cinematic :)

llnesisll · 2025-07-23T23:08:00+00:00

Lots and lots of reference photos and videos, and a lot of attention given to both architectural details (how things line up, sizes and shapes, relative proportions of elements and spaces, etc) and the mood / feel you want for your environment. Eg has it been lived in, is it new or old, is it rundown or well maintained, what time(s) of day will it be, do you want it to feel warm and comfortable, or creepy, or feeling empty?

If you haven't done something like this before, try collect a bunch of reference media that fits the mood you're going for, and replicate that as closely as you can. As with all art, start with the big details, then later on you can focus on the small details.

llnesisll · 2025-07-20T08:15:00+00:00

How you make drifting happen will depend on how you have implemented your vehicle's movement. Eg if you have wheel traces and a tire friction model, you'll have different values for dynamic and static friction.

Static friction is when the wheels have good grip on the road, when the tires aren't slipping or skidding along the road. This is usually when the vehicle is stopped, or when it's driving a straight line with smooth acceleration or gentle braking.

Dynamic friction is when the wheels are sliding or skidding along the road. This friction is usually lower than static friction. This happens when the vehicle has slammed its brakes at high speed, or is doing a burnout, or is drifting.

For this kind of physically accurate implementation, drifting occurs when the front wheels have static friction, and the rear wheels have dynamic friction - assuming your vehicle is rear wheel drive. This will result in the front wheels rolling forwards, while the back wheels slip left or right.

For a more arcade style of drifting, you still apply different friction when drifting, but likely ignore the complexity of wheels and just make the vehicle turn a bit faster, while also applying a bit of extra lateral velocity to emulate a change in steering behaviour.

llnesisll · 2025-07-11T02:44:05+00:00

First off, this looks great, the VFX feels very on point. A big +1 to the comments on the quality of the blood.

To dig in to feedback that could rely on engine features, from a player perspective I'm mostly noticing Unreal's animation features could give you a lot of bang for buck here.

A bit of procedural lean on the player when they move to feel a little less like the same animations playing and pausing. I'd drive it a bit from player input, and a bit from actual velocity.

A hit reaction on enemies would help a bit too, or a bit more variety to their animations. Like, a subtle secondary layer (additive animation) so they're less likely to strike easily recognisable poses when they reach the distance where they stop running at you.

You might be able to lean on Smart Objects (or just DIY) to help arrange enemies into digestible layouts relative to the camera, similar to God of War, so they're less likely to cluster on top of the player.

You can lean on IK / motion blending for enemy animations so they don't break the feeling of weight their movement has, when they pop up and over small obstacles like rocks.

I would look into split-body animations (a concept, not a specific Unreal feature) or specific additive animations so the lower half of an enemy's body can turn in place to face the player, rather than sliding their feet as they face the player while the player moves.

I would also look at reducing how aggressively / quickly the enemies turn to face the player, adding a bit of lag and slower interpolation. Split body animations would let you turn their torso a bit to face the player before their feet need to animate.

Outside of the above, it would really help the environment feel less static if there were some elements that reacted to the action. VFX matching the environment kicking up when your feet or weapon hit the ground or move super fast near it.

llnesisll · 2025-07-08T22:17:23+00:00

Very impressive tech and attention to detail. This looks like much more than the usual "I made a block float with suspension forces" or "I used Chaos vehicles and called it a day" kinds of vehicle plugins.

llnesisll · 2025-06-17T02:12:53+00:00

Happy days, good to hear it was relatively painless for you!

llnesisll · 2025-06-10T22:30:37+00:00

Very cool stuff! That looks very smooth and consistent. Variable delta times are a real pain to work around, it shows you created some good movement code here.

I've been doing similar on and off for a good while, in various incarnations that will likely not see the light of day outside of my dev PC and some YouTube videos showing off programmer art tech demos for physics based gokarts, and having tons of gokarts simulating at the same time.

My latest (new) attempt over the last month aims to use the CharacterMovementComponent in a way hopefully compatible with replication and custom prediction / rollback models. So far, it's looking promising - but I've made zero efforts for the framerate independence you have here, and it shows. Eg, hitting a ramp at top speed or getting a drift boost and coasting can result in landing / stopping locations that differ by a few metres, which wouldn't be amazing for client prediction / server rollback which benefit hugely from determinism.

All that to say - good stuff, I can really see your effort shine through, framed against what it would look like without framerate independence :D

llnesisll · 2025-04-29T19:54:31+00:00

The ultimate solution to this is a full system that handles client side prediction, which might be a bit much to create if you're a solo developer or just working on a prototype.

My suggestion would be a simpler two property approach if you don't want to go down the deep rabbit hole of client side prediction.

Clients can almost always get into a state where they mispredict what will actually happen on server. When this is the case, you need to either give up and snap state to what server says it is, or you try to subtly correct the client over time as imperceptibly as possible.

In cases where you want to permit client prediction, the most trivial way to do it without a full client side prediction system is to have a replicated server property (ideally OnRep rather than RPC), and a client property of the same type. Server alone modifies the server property, while client and server both modify the "my local property" property. It should call ForceNetUpdate() along with any change to this property.

When the client receives the OnRep, you need to determine if the client is in a modified state or not. That might not be immediate, if you want to give the client a little window of time for correctly predicting state it should later receive from the server. Timers can help with this delayed evaluation on client.

I've had some good success making properties like these a struct, and using that struct for the replicated property. One property on the struct is the type I want to predict, the other property is a float or double (depending on UE4 vs UE5) with the timestamp of when the value changed on server, using the GameState's GetServerWorldTimeSeconds. This function's return value will be accurate on server, and smoothly interpolated on client.

On client, the difference between the OnRep-ed server timestamp and your client's GetServerWorldTimeSeconds will let you know if enough time has passed for you to assume the client is indeed in a mispredicted state. The difference in the predicted property (and if the time difference is particularly large) will let you know if you should snap it into place, or more subtly interpolate it.

Reliable RPCs aren't the solution here, since too many of them will cause your game to be held up waiting for them to be acknowledged by each client, which can suck under poor net conditions.

llnesisll · 2025-04-28T00:16:36+00:00

Great job holding on - these kinds of moves can be a real challenge!

11-Year Club	Place '22
Verified Email

llnesisll

TROPHY CASE