The premise is pretty simple: 4X game, hex grid, max 8 players. I have a map manager actor which basically acts as the database for my map (I suspect this approach will be replicated when it gets to setting up player empires etc).
The hex grid is sorted. Each hex tile starts off “undiscovered” (which = flat black). if you’ve visited the grid, or scanned it prior, it’s obviously “discovered” (light grey), and if you’re currently scanning it (ie in close range), it’s “scanned” (white). There are further interactions with each hex (such as mouse overs for example). but they aren’t really important here.
So… how do I show this one single hex differently to each player? I’ve mucked around with layers, which seem cumbersome. ChatGPT has suggested line traces depending on player controller, which sounds really expensive; and Dynamic Material Instances which I couldn’t figure out how to make work for my purpose…
It’s proximity triggered? Can just use a basic collider attached to player character. If direction is important you can get overlapped tiles and check dot product with forward vector to identify which side it is.
Dynamic material instance should work. Perhaps a thread to detail what specific issue you are having with it. But tons of tutorials out there so probably just double check and you should be able to figure it out.
Can also look into material parameter collections as another means to update material at runtime. I tihnk it is both simpler and more flexible compared to dynamic instance.
Just to clarify @BIGTIMEMASTER, I need the material (or colour if it is a Dynamic Material solution) to look different per player controller at the same time.
So player 1 might see it black. Player 2 grey. Player 3 white. 4, 5 & 6 black. 7 & 8 white…
Does that make sense?
Turn based game, so while technically, it is proximity based, there are a lot of these references going on at once. My map size is 150 x 75. It’s a lot of hexes
I might misunderstand, but… a player controller only possess a single character at a time. So a collider on the possessed character still works I’d think.
A lot is unclear though. I thought this is just a single character per faction? But maybe you mean that all units belonging to a faction have this effect going on?
No matter really, the important thing is that you shouldn’t assume there is a performance problem before actually testing, regardless of what anybody says. I mean, modern shooting games must have thousands of line traces happening at any given moment, and they have to run extremely fast.
Think Civ VI for example. In space. Each empire will have numerous ships to control at any one time. I’m thinking a hard-coded pawn (with traits for AI understanding) per empire, which will need to be controlled by a player controller because… that’s the way the engine works. maybe. at least, that’s how i understand it…
This is very true. I’m not actually worried about performance yet. I haven’t gotten that far to worry about it. I’m still setting up my map, but trying to do so in a “future-proof” kind of way. Trying to avoid having to come back and rewrite these elements a million times if I can help it. Having to do that is what generally kills these kinds of projects…
i’m not familiar enough with the genre to be of very much help most likely, but if it is true that, at any one time, this perimeter check / highlight action is only happening on a handful of units, I think it would be perfectly reasonable to just do it with a collider that is attached to character.
That would be the simplest way to get started anyhow. A more flexible way to do it would be have an actor component add a collider and manage it. That way if you wanted to forego this system for something else in the future, all you have to do is remove the component.
Dynamic material instance sounds about right. Those are not replicated so they will look different per-player depending on what code executes for each player.
You can also have a non-replicated “state” variable within the tile actor, so each player has its own local state. Replication is opt-in so you get to choose what replicates and what doesn’t. If you replicate nothing you can have the game look totally different on different machines.
Yep, I think replication is the solution (or rather, utilising non-replicated options). Setting things up so material changes don’t replicate sounds like the easiest setup.
Sooooo… marking this as solved as I now have a pretty clear idea on how I’ll set things up. Muchos gracias.
I still don’t think DMI is a realistic alternative tbh.
Each empire will have numerous ships to control at any one time. I’m thinking a hard-coded pawn (with traits for AI understanding) per empire, which will need to be controlled by a player controller because… that’s the way the engine works. maybe. at least, that’s how i understand it…