I’m glad you touched on this subject. Handling double animation sets surely is an effort, but each of those sets (arms-only 1P and full-body 3P) individually is simpler than one set of full-body 1P anims. Anims made for 3P often don’t yeld cool results when used in full-body 1P, full-body 1P usually needs anims made specifically for this. And there is the optimization aspect too, with 2 separate sets, you can optimize the 1P for close view - high detail but only one instance per machine, and optimize 3P for less detail, but lots of instances per machine.
There are pros and cons with any approach, but I do find full-body 1P much cooler.
Yeah, a simple inventory like that is what I’m planning to start with. I’ll have to see what will be feasible to add or not as I go along, it’s very easy to underestimate amount of work before you start it.
I’m not perfectly happy with how the weapon customization happens only on the client side and only at the start, what forced me to code some anit-cheating logic when the gun is sent to the server. I’d like very much to make the customization happen on the server and get rid of the anti-cheat part. This should make it easier to allow gun customization during gameplay, using parts from the inventory. I have yet to take a second look at this in the future. It will probably be a great amount of work, that’s why I can’t promise dates at this point.
Thanks a lot for your comments above, I appreciate it!
As a suggestion, you could effectively have the guns represented by build strings that the system interprets. That way you only need to have the server send the build codes to the client, and all the client is doing is just assembling the weapon assets/data based on the build code. So in practice the client would build a weapon that would generate a build code which is sent to the server. The server then does any necessary anti-cheat logic (does the player have these items? Is the weapon the right level? etc), and then send either the build code confirmation or an error response to the client.
I think what you’re saying is similar to what I do, except I use arrays of structs instead of build strings. But the flow is very similar, if I understood it correctly. The problem in using this system during gameplay, as opposed to before the character spanws, is replication. I guess it’s easier to code a new system, in which the client customizes the gun directly on the server, instead of sending the gun to the server at the end of customization. This would also not need the anti-cheat check.
I concur, and wont even mention, the extra work for character customization. I’ve always used 3P for FP because the simplicity to manage and its how we’re designed in nature after all.
This is true, so one has to innovate ways to get cool 3P effect with full-body 1P. I do it with a little camera magic. For example, Reloading. If I’m to do it in real-life, I need to look down at my weapon to thru the process of swapping out magazines because of weapon weight and using hand/arms to do two different things. Its not very natural to hold a weapon in front up right and change a magazine.
I personally think we should be using High Detail on 3P nowadays and let the engine handle the LOD optimizing, You can get up close and personal to on characters opposite of yourself, which makes seeing those little details gratifying.
Good points… I’ll probably have a more solid opinion at the end of next update, when I’ll have completed all replication, animations, etc, for the full-body 1P character. But I tend to agree with you, except not so much regarding looking down for reloading. IRL, yes, you’re right. But, in-game, having the camera “fight” the player to force him to look in some direction can feel unnatural. For ultimate realism I guess you’d have to go into VR, as trying to compensate for some limitations with the mouse and keyboard could end up with an opposite effect in realism…
VR takes a whole new mindset with movement controls. Im not a big fan of teleporting in FPS, unless its on rails with Gallery shooter style mechanics. It could be just me, as Ive been using Gamepads, and M/K all my life. This is another area that could benefit from innovation.
In regards to reloading, I blend several cinematic camera movements for different events, Reloading is one of them. The players knows that when they invoke weapon reloading they will have to look downward at the weapon to do it and it doesn’t fill that unnatural, As a mechanic, It takes your eye off targets, leaving you vulnerable, which means you need to find cover to do it, if you don’t want to get shot.
I treat the camera as independently controlled system, using the Character head/neck for ‘home-base’ mounting. Thus, it can transition to cinematic Cameras and Rails then, return-to-base afterwards.
I found some decent 1p result by mounting camera to a spring arm thats mounted to the head/neck socket of 3p character. The spring arm allows you to insert lag, for a quick stabilizing hack. One can then dial up the lag or procedurally adjust to get Steadycam smoothness. You can deactivate for a rough jittery hand-held feel.
I like adding Tactics in subtle ways. The 3D Camera is one of the most powerful aspects of 3D, too bad most games under utilize it by locking the player in a specific perspective. I’m going away from that.
Character was updated to true first person view - now it has a single mesh (whole body) with a 1P camera attached to the head. Only one anim BP and only one set of anims. No more arms-only mesh and anims.
Many new original anim sequences and blendspaces for the Epic’s mannequin were added. These were made with true 1P view and 3P view simultaneously in mind, so they work for both.
Third person camera was added
The M4 rifle meshes were scaled up so they look better in the mannequin’s big hands!
Changes in the firing logic and anim simplified the code significantly, without reducing it’s looks and movements
Firing anims don’t need to be fed with custom play-rates anymore, they now work correctly with a play-rate of 1
Removed procedural fire anim for firing while aiming. Now firing uses the same anim sequence for both hip fire and aiming fire
Added reload while aiming, without the need for additional reload anims.
Gun sight position is now replicated, so you can see exactly which sight the other player is looking through
Gun and attachments now cast shadows
Added screen shake when firing
Added procedural aim sway (from a curve) when walking
The anim graph is more streamlined now, with the sight alignining code separated from the state machine