Vapourware Codexian Game Development Thread

[Lance Treiber]

Took a marketplace product that I happened to be familiar with, because I helped a client with it. It's an MMO kit, but within two hours I made it into a single player RPG Kit. It lacks some functionality, but mostly it's all there.

Some difficulties encountered so far:

- Only Characters possessed by a PlayerController can be moved through Add Input Vector in UE5. Meaning that non-player characters can only move on the NavMesh, which is ridiculous. Had to rewrite a bit of the standard engine classes.
Now I "fake possess" any number of party characters.

- Drawing the hex-like cursor above all surfaces, but behind the character, was a bit of a challenge.

- A lot of design to consider. Porting Fallout 1 into 3D is not obvious. Settled on allowing verticality. Notice hexes exist above each other. I expect a lot of pain in the ass to hide geometry between the camera and the character in the future:

I've been at it with this project for a few days now, the progress is great. Tomorrow custom A* navigation to run on hexes.

 

[Nathaniel3W]

Lance Treiber does UE5 no longer have decals? Could you not turn a hex-shaped decal on and off when you select a character?

 

[Lance Treiber]

Lance Treiber does UE5 no longer have decals? Could you not turn a hex-shaped decal on and off when you select a character?

No, a decal would've been easy. It's just an artistic decision, I feel strongly against the cursor distorting itself on the ground. It's a cursor, it shouldn't do that.

 

[what am i doing]

Implemented a basic calendar system. Simulation uses a count in days, but can also render a year-month-day date. This uses a symmetrical quarters calendar, each quarter consisting of two 30-day months and a 31-day month; and the year has one intercalary period that lasts one day (two on leap years). It can also be rendered as a proleptic Gregorian date, but the stock campaign's world uses the symmetric one. Adjusted product demand tracking to play nice with this system.

Improved editor tile brush; can now be given a variable target size to cover large areas faster. Still need to add a visual size representation for it overlaid on the world, and tweak some tile recolour stuff to be less burdensome on my laptop's weak GPU.

 

[Lance Treiber]

Never worked with pathfinding before. Implemented A*.

Okay:

Same cost, but ugly:

Ugh.
In certain situations, ugly paths come up sometimes. Not a lot, but it happens.

String pulling algo would work on a navmesh, but in hexes I don't see how. Unless we recalculate a lot, lot, lot.
Checkboard neighbor order hack also doesn't seem doable, because hexes aren't like square grid where going up or right is same move cost when you're going North-East. In Hexes, there's always one hex better than another for heuristics.

Leaving it like this for the moment. Now got to make the character actually run on the hexes.

This website is amazing, by the way https://www.redblobgames.com/pathfinding/a-star/introduction.html

 

[Nathaniel3W]

Lance Treiber when evaluating each hex, you should calculate the actual straight-line distance from that hex to the destination and use that to determine the preferred hex. I think a hex 2 spaces away by zig-zag should be slight closer than a hex 2 spaces away in a straight line.

 

[Lance Treiber]

Lance Treiber when evaluating each hex, you should calculate the actual straight-line distance from that hex to the destination and use that to determine the preferred hex. I think a hex 2 spaces away by zig-zag should be slight closer than a hex 2 spaces away in a straight line.

Yes, checking for distance between Next hex and Goal hex is the "heuristic" part of A*.
What I didn't show on the screen when the ugly path happens is that the Goal is hidden behind the wall:

So naturally the path is being drawn towards that coordinate in this particular case, due to the heuristic.

It's this particular case that's annoying. In most other cases, the zig-zagging occurs, which I like.

The hex layout:

 

[The_Sloth_Sleeps]

Lance Treiber when evaluating each hex, you should calculate the actual straight-line distance from that hex to the destination and use that to determine the preferred hex. I think a hex 2 spaces away by zig-zag should be slight closer than a hex 2 spaces away in a straight line.

Yes, checking for distance between Next hex and Goal hex is the "heuristic" part of A*.
What I didn't show on the screen when the ugly path happens is that the Goal is hidden behind the wall:

So naturally the path is being drawn towards that coordinate in this particular case, due to the heuristic.

It's this particular case that's annoying. In most other cases, the zig-zagging occurs, which I like.

The hex layout:

Sorry if I am teaching you to suck eggs but....in the cost function couldnt you simply override to use euclidean distance, so the for the evaluation of diagonal nodes its using the physical distance (which of course is greater), not equal grid distance.

 

[Lance Treiber]

in the cost function couldnt you simply override to use euclidean distance

Already using euclidean. Because of that, it prefers the path that it prefers, since those points (the ones on the arrow-like shape) are closer to the goal hex in the world.

 

[The_Sloth_Sleeps]

in the cost function couldnt you simply override to use euclidean distance

Already using euclidean. Because of that, it prefers the path that it prefers, since those points (the ones on the arrow-like shape) are closer to the goal hex in the world.

Maybe something is messed up when you generate the nav mesh, or somewhere. Because as a proof, you can do a print out of the cumulative distances, positions of all the centre points of the actual closest path and then the distances, positions of centre points of that calculated path, and you could demonstrate they are not equal.

 

[Lance Treiber]

Because as a proof, you can do a print out of the cumulative distances

Ah, you want to use cumulative distances as a way of reconstructing the path, instead of move cost.
But what the do with the move cost then?
Some hexes are marked as costlier than others, e.g. cost 1 or cost 2 (moving over hard terrain).
And the path is constructed as a reversed series of move costs.
Your post gave me an idea. I could start storing multiple reverse paths and if two hexes with the same move cost present themselves, I could prefer hexes that are euclidian-closer to the Start position. I'll give it a try tomorrow. But I get a feeling this will be much more costly.

 

[std::namespace]

Never worked with pathfinding before. Implemented A*.

Okay:

Same cost, but ugly:

Ugh.
In certain situations, ugly paths come up sometimes. Not a lot, but it happens.

String pulling algo would work on a navmesh, but in hexes I don't see how. Unless we recalculate a lot, lot, lot.
Checkboard neighbor order hack also doesn't seem doable, because hexes aren't like square grid where going up or right is same move cost when you're going North-East. In Hexes, there's always one hex better than another for heuristics.

Leaving it like this for the moment. Now got to make the character actually run on the hexes.

This website is amazing, by the way https://www.redblobgames.com/pathfinding/a-star/introduction.html

when you are calculating the cost of moving to the adjacent tile, you do that either clockwise or counterclockwise starting from the same coordinate in relation to the agent, right? (if you are saving the full path)
when you are reconstruction the full path through the least cost and cant decide between tiles because both have the same cost, you can too chose clockwise first, remember that, and next tile do counterclockwise
that would make him zigzag in case of uneven cost

maybe an heuristic like if your coordinate x,y you are calculating the cost from is "left" of the target, take the left tile for the same cost
if its "right", go right
"left, right" in a comparison to target x,y
but this is just another coord comparison in the hot path

the first option is betta...

 

[NoMoneyNoFameNoDame]

A*?

Interesting. I shall discuss Redacted* since no one bothered to examine the technical side of my game.

I hate navmeshes because sometimes that shit doesn't work, and I hate A* even more because it is an obvious choice.

So instead I relied on a small amount of collision, physics, and raycasting. This won't work for games where you move fast e.g. in
flight simulator or driving game. Also there's no AI jumping or climbing. Also trees are for the most part walk-throughable.
There's no point to make every tree an obstacle, it would bloat cache and make even the most rigorous AI get stuck for no reason.
Thankfully Unity3D's tree system is so piss poor that it actually feels natural to pass through the awkward prefab-challenged annorexic turds.

Getting To It.

Here's how it works. Every object is somewhere, and if one is close to you, then you can consider if a raycast touches it.
List of objects near you shouldn't change often since this is not a high-speed vehicle game. You could think of the raycast
as a second level of precision rather than the first.

So the guaranteed situation is game has cached all pathing-related game objects in memory in a quadtree, then has another cache of objects which are the nearby ones.
And this latter cache is what updates once in a while. The former only needs to update if something is created or destroyed.

Now I did something more than this simple approach. I took on the problem of movement. Because you want obstacle avoidance
to be smart. No one wants to see all npcs play a game of pong.

So I must try to estimate when an NPC should stop moving. This means there's a distance you want NPC to be away from any object before an NPC should stop.
But to estimate the right distance you make other estimations based on object size.

This works pretty well for most objects despite their geometry but you have to play around.
This works shittily for giant structures because the origin of the structure can be so deep or weirdly in it,
by the time you approach the origin you're inside the damn building.

So the secret is one of two methods:
1) you create a bunch of small but invisible objects that form a railing around your large structures,
then your character will detect these and by being distance from the railing points will avoid getting to close
to the larger structure enclosed.

2) if you're too lazy to do #1, you create an oversized bounding box that you modify yourself,
and then have NPC turn around upon contact with the bounding box.

Obviously the point of navmeshes is you don't have to worry about all that shit.
However I found the exercise interesting and it helped form the basis of how AI worked in my game.

Now a couple other issues need to be addressed. I don't even give the NPCs gravity/physics.
Howeverr for the player I added my own gravity and player controller, but this is fine because the pathing in the game
does not apply to the player. This is because the player unlike NPCS usually doesn't hug walls with their faces.

ON the AI side of things a couple issues still emergent:
1) How does an AI chase you around a building if, one of you is on interior and the other exterior, what if there is no clear path?
Answer: They don't. However if I had to solve this problem I would give them warping technology.
However you would need to define clear exit and entry points, plus corners of the exterior to go to.
Companions in the game use warping technology, and enemies chase you across maps using warping technology.

2) How does an AI go down a ramp or chase you across a gap to reach you?
Randomness. If Randomness isn't enough to catchup to you, they just don't reach you.
There's no memory either which is probably for the best because chances are player or battlefield
changes by the time you would exhaustively check all positions. Double-backing possibility also
suggests leaving this random as opposed to memorized is better.

What about long-distance snipering an NPC? How do they react?
Now this always has bothered me. The solution was simply not to let the player do that from vertical advantages position,
and to always require ironsight aiming. Meaning you have to line your character up level to the opponent to have a chance your projectile hits.
If you hit an NPC from afar most will chase after you, but they obey the pathing rules. So yeah you could do hit and run tactics.

But.. but.. muh gunplay and muh realistic tactical challenges, muh seek and destroy!
The game level design was designed to be quite open. The truth is there's not many places you can truly hide from the AI.
And I would argue if the designer makes a decent effort to put NPCS and traps everywhere, the game difficulty is preserved.

I also consider the fact if you're hiding not that much of an issue because you still have Survival Stat issues to worry about,
and timed objectives of one sort or another. So yes you can hide, but that proves you're kind of a loser doesn't it?

Btw if this description how of things NPCs navigate interests you you should buy and play Redaxium 2.

 

[Lance Treiber]

I have complimented Fallout's visuals in another thread.

As I'm comparing real human proportions to Fallout's, some observations:

- longer legs
- shorter, stockier torso
- giant feet & fists
- bigger head

This is all minor detail when you don't think about it. But this is very good work shapes-wise. It allows us to see the character better, yet nobody even bats an eye at the disproportions.

 

[Lance Treiber]

Synced hex size, man size, man speed. The animation is not quite right (needs larger paces). Everything is too smooth. Feels weird and off.

 

[Gandalf]

Synced hex size, man size, man speed. The animation is not quite right (needs larger paces). Everything is too smooth. Feels weird and off.

Isn't the Fallout one based on sprites?

 

[Lance Treiber]

Isn't the Fallout one based on sprites?

Point being that it's inauthentic?

I think by rotating the character instantly, we're already in retro territory, because it's the imitation of sprites. The models are 3d, but you'll never see more than 6 sides of them.
Retro-styled FPSs also use this technique: only 6 directions + low framerate on animations (timestamped 22:47)


I'll also try going for a retro look with post-processing later, so the visuals will change. I'm only 2 weeks into prototyping here.

My goal is to recapture the familiar feels of F1's engine, as well as its game design philosophy and narrative themes. But I'm not looking to recreate the exact replica of F1. Some things will be new.

 

[Lance Treiber]

Realized I can steal hair from a MetaHuman. They've got over 30 haircuts in total.

Also got a free biker jacket from Sketchfab and adapted it to the character to test the workflow.

The detail is all lost on the jacket. No matter, this is but a placeholder. I just needed to recall how it's done, as I haven't touched 3d software in 5+ years.

When I start making my own clothes for raiders, it'll be less like biker jacket and more like this:

 

[ERYFKRAD]

Jacket's got one sleeve too many, bruv.

 

[beardalaxy]

Haven't been around here much because I've been working hard on my game. Long story short, all of the NPCs are done now and I smashed my goal of 5 months, instead finishing them in under 2. Taking a bit of a break until next year, then I'm going to put together a road map of how I want next year to go with some good deadlines. Plan is to have the game in beta before the end of 2024, I've got a good year ahead of me. Here are a couple screenshots, although the graphics aren't final as I'm still messing around with swapping out the stock tileset and don't have that ready yet.

Once I get the roadmap done I'll share it here. I'm super happy with my progress so far and the development is going really well!

 

[Renegen]

Synced hex size, man size, man speed. The animation is not quite right (needs larger paces). Everything is too smooth. Feels weird and off.

Lance, you seem to know your programming, I have a simple but important question I'd like to ask you.

How did you generate all of these hexes (or square tiles) on the screen? I mean, what are they? Just some graphical overlay? Still impressive.

When I think of making an RPG with tiles, I think of having like 1000 game objects each representing individual tiles, and that seems bad. But you just have pathfinding, and the tiles on the ground and it seems great. What method is that? And how powerful are these tiles to contain game data?

 

[RobotSquirrel]

When I think of making an RPG with tiles, I think of having like 1000 game objects each representing individual tiles, and that seems bad.

It is bad. Each of the "Tiles" are a uniform size meaning you can just use simple position values instead of individual objects. You'd only ever draw the objects for debug.
My suspicion on lance's implementation is he's using rays to find the height of each tile and to determine if the ray is inside a collider or not and if the tile is imperfect. Its pretty damn impressive though, I've not really seen a lot of people try to do that they usually stick to just using a tilemap for everything.

 

[The_Sloth_Sleeps]

Why would 1000 tiles be bad?

 

[Nathaniel3W]

So long as the tile isn't being ticked, I don't see why having it there would be any problem. If it's not even being drawn, then the only downside is file size and loading time. After that, having it sit there doesn't cost you anything.

 

[The_Sloth_Sleeps]

So long as the tile isn't being ticked, I don't see why having it there would be any problem. If it's not even being drawn, then the only downside is file size and loading time. After that, having it sit there doesn't cost you anything.

Even ticking 1000 tiles isnt so bad if they arent doing much.
If the update method of the tile has a IsDirty flag approach its not really going to notice any difference doing 1000 iterations over essentially a bool check.