I’ve been playing too much xcom and I felt like my c++ skills were waning so I thought it would be a fun quick project to quickly spin up a turn based squad commander system.

The camera

First thing that is distinctive about xcom is that it’s an isometric game, therefore the camera is fixed above the level and travels along various levels of the map. To achieve this effect I made a quick camera pawn that does two things: Ray traces to a fixed height above the ground and constantly aligns itself to a specific pre-set orientation.

Instead of going crazy with pre-mades I just threw a camera component onto a pawn class with a few pre-set parameters.

Header code:

  //CLASS BLUEPRINT EXPOSED PROPERTIES
	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "2D Camera Settings")
		float BaseHeightOffGround;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "2D Camera Settings")
		float CameraAlignmentRate;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "2D Camera Settings")
		float HeightCorrectionRate;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "2D Camera Settings")
		FRotator BaseCameraRotation;
	//END CLASS EXPOSED PROPERTIES

	//START COMPONENTS
	UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "PrimaryCamera", meta = (AllowPrivateAccess = "true"))
		UCameraComponent* PlayerCamera;

	UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Collision", meta = (AllowPrivateAccess = "true"))
    	UCapsuleComponent* CameraCollider;

The tick function I have two lerps: 1.) for the current camera orientation and 2.) for the result of a down racytrace + a fixed offset.

//Ensure we're rotated properly to the desired world rotator that the user specified
    FRotator currentRot = GetActorRotation();
    FQuat newRotation =  FQuat::Slerp(currentRot.Quaternion(), BaseCameraRotation.Quaternion(), CameraAlignmentRate*DeltaTime);
    SetActorRotation(newRotation);
    // Get the world object
    UWorld* World = GetWorld(); 
    // Check if the world exists
    if (World)
    {
        FVector Start = GetActorLocation();
        FVector End = Start + FVector::DownVector * BaseHeightOffGround*10.0f;
        FHitResult Hit;
        FCollisionQueryParams QueryParams;
        QueryParams.AddIgnoredActor(this); 
        bool bHit = World->LineTraceSingleByChannel(
            Hit,                
            Start,             
            End,              
            ECC_Visibility,     
            QueryParams         
        );
        if (bHit)
        {
            FVector newWorldPos = FMath::Lerp(Start, Hit.Location + FVector(0,0,BaseHeightOffGround), HeightCorrectionRate*DeltaTime); 
            DrawDebugLine(
                GetWorld(),
                Start,
                Hit.Location,
                FColor(255, 0, 0),
                false, -1, 0,
                12.333
            );
            SetActorLocation(newWorldPos);
        }
    }

THE RESULTS!

Note: the red line is just for my debugging purposes. Also the camera will not be visible in game.

The DSP engineer in me is balking at the casual use of a delta time and a linear interpolation. But, we’re on a PC running at low data rates (60hz!?!? pfffffff I could get this running at 24khz) and variable frame sizes so while I keep thinking “I could optimize this to be less MIPS” I think I’ll just press on…

Commanding/ Game structure

In xcom the turns are play out that you select a squad member, choose their action, move to the next squad member, choose their action, until you have no more squad members, then your turn is over.

Now there’s a few ways I could implement the squad mechanics. Specifically the way that each squad member gets controlled and how the player controller interacts with them. I could have the user’s controller re-posses each pawn upon selecting them (which might save memory but increase the work upon possession). However, I would still need to perform path finding to move the character to a specific location. Instead I think the way I want to play it is to have every squad member owned by an AI controller that receives broadcasts from the player controlled camera pawn. Below is my rough diagram (I think there’s a gamemode state in there that I need to throw in but generally I think this is fine)

In addition to handling the general flow of the game I think the other side is that this sets the game up for multiplayer from the start.

The command/game state messages I think I’ll probably make delegates in the game mode that the controllers can subscribe to. Then the deaths of squad members and selections I think I’ll push to to the controllers? My thought here is:

I’ll probably jump back on this tomorrow and start coding up the events and perform in a test or two.

(Writing as I’m doing this fyi) I wanted to re-write the leaning in the game. Right now the movement is all very snap, which has some skewing to it but i wanted a more gradual lean in.

(Normally I would use https://blueprintue.com, but wordpress is weird about iframes)

Now you can see here the process is, press button, move to desired input. My first thought was to throw in the delta seconds of the last frame, add a rotator and vector interpolation block and be done with it, however, Unreal’s input system is actually made for this. If you look at the top blueprint I have a few branch statements that was thresholding based upon the input value. Instead I’ll use that input value to skew between the lean position and the rest position.

My lean action by default is a 1-d float which is cumulative, which should mean that as I press the lean keys (Q+E) the value of the lean action (the Axis value line from the first plot) should increase as the buttons are held down.

Therefore, if I just use that value to skew between the lean position and rest position I should be good….

I was not good

What I described above is TOTALLY not how this works. Advanced input seems to not hold any kind of state from the previous frame unless you’re using defined curves. For example there is a “scale by delta time” modifier that works but it takes whatever the current input is and multiplies it by the frame time. This can be useful but my goal here was to avoid adding another accumulator within the player blueprint class. You can add an exponential curve but that’s just a modifier to the input values. I don’t think there will be a good way here other than adding a “currentInputValue” modifier and having it decay at a fixed rate…

This is one of those situations where I shot myself in the foot for using blueprints, however I think there’s enough syntax and other bugs that I saved myself from that I don’t care that much. For example In matlab (which I use a bunch at work) this problem can be solved via:

startPos = [-10 -20 -40];
endPos = [-10 20 40];
restPos = [-10 0 60];
inputAxis = linspace(-1.0,1.0,3);
[iAx iAy iAz] = meshgrid(inputAxis,inputAxis,inputAxis);
[xOut yOut zOut] = interp3([startPos;restPos;endPos],CURRENT_INPUT_VALUE,iAx,iAy,iAz);

I think unreal can do this with curves but my head moves towards code when we get to 2+ dimensions. But honestly this is me overthinking on coffee at this point, I’ll just throw it in with another accumulator and some alpha smoothing (https://en.wikipedia.org/wiki/Exponential_smoothing, which I believe is implemented in https://dev.epicgames.com/documentation/en-us/unreal-engine/BlueprintAPI/Math/Smoothing/WeightedMovingAverageFloat)

Attempt #1

First thing I is that I embraced curves:

Which was so simple I’m confused why I didn’t start with these. The only hitch I had is that it was annoying to find the “getVectorValueFromCurve” block. If you just blindly add a curve class or runtime curve class this isn’t exposed. Now the results:

This worked but now I’m hitting issues with state management. The rough way the Unreal input system works is:

if(currentState == buttonPressed && previousState == buttonReleased)
{
   Trigger(inputValue);
}
elseif(currentState == ButtonReleased && previousState == ButtonPressed)
{
   Ongoing(inputValue);
}
elseif(currentState == ButtonReleased && previousState == ButtonPressed)
{
    Complete(inputValue);
}else
{
    //DoNothing
}

Which essentially means that putting the logic attached to button presses is a fools errand. I need to move it out to the tick function, or I need to figure out how to modify the states above to keep firing the “completed” state.

Attempt #2

I tried messing with advanced input and hit the same state issue. I was hoping I could set the trigger to also be released but it never hits more than once.

No dice…gotta push the input value smoothing and the lean function to the delta. This will require another variable to handle the previous input value of the lean buttons. This might mess up the way I visualize the math but lets see what happens.

Attempt #3

This seems to be the best lean method. Essentially I needed to add one more var to handle the current value of the input and keep the same one that defined the previous variable. Below is the blueprints.

Pretty simple at the end of the day. Hard part about this stuff is never what you’re doing its always that transition from what you’re doing into the mental model that the unreal devs used.

Finally my management failure…

Which doesn’t really matter too much because I’m working solo, without a server to push content to. However its just bad practice to not protect yourself from silly confusing mistakes (which will increase as you get to the end of development).

Next goals

1.) Add a flashbang and grenade robot (look back in my notes I have a flashbang and m67 already modeled).

2.) Add a new weapon

3.) Add a humanoid character that rides the robots?

Spent a bunch (like 1-2ish hours) of time trying to get the chaos physics working with the tree and…

It kinda works but the issue comes into the in game interaction. The damage levels seem to be weirdly arbitrary and aren’t assigned to a root bone but the pieces themselves Also the definition of “damage” seems to be just a number that gets exceeded in a fixed amount of time. I could probably figure this out with another day or so of digging but I’m starting to get fixated on this rather than just straight up making the game. However, I’m going to go through my experience just to give an intro/document for myself in the future.

Making a destructible object

This part actually wasn’t that hard, essentially you just drag/drop a mesh in. Flip to the “fracture” mode and click new. Then you start using the slicing tools on the left hand side to cut apart the mesh, then you select sub-part of the mesh and cut again.

This creates a tree of destructible on the left hand side where each “level” is a root piece that has child pieces.

So the idea seems to be you break the root the rest will break off. However, that’s the part I’ve been stuck on, there’s damage settings that seem to not work the way I would expect. Either way I’m moving the goal to making more weapons and enemies.