143 replies to this topic

[ambershee]

Well, I'm back. Should be back in business for code-monkeying as of tomorrow.

No code uploaded to SVN yet - has there been any merging, or am I going to do it?

Need a playable base as soon as possible

[xiongmao]

I'll be able to upload some codes tonight based on the sources you uploaded. But there is no custom map to launch the game as I didn't want to lose time in UIScene creation
Let's talk about this on Msn this evening.

[ambershee]

Custom map can be easily done. I'll knock it together quickly tonight then - it only takes a few minutes.

I'll try and get online tonight, but my home connection is still largely lacking. If all else fails, dump into the forums. I can normally reply fairly quickly

[R0n1n]

Im back too. I had to help out at my dads business tha last days so i couldnt find much time.

I can build you a Testmap quickly if you still need it.

Edited by R0n1n, 16 April 2008 - 05:25 PM.

[ambershee]

Don't worry about a test map, just keep on the road of assets. The kismet sequence that the map requires is literally two boxes, so it can be copied over in seconds. It's the user interface scene that takes time

[xiongmao]

I've uploaded the project into SVN: Folder 5WeekProject at the root. There are only UScript classes.
here is a listing of what has been done:
- Remove start message (press fire to start)
- Create StartVolume : which display a message as soon as the pawn has leaved the volume ( Playerstart(s) must be in this volume)
- Create ConsumeVolume : a simply volume that cause one damage per sec (configurable in unrealeditor)
- Create FinishVolume : volume which ends the match (for now it only writes "stop timer" in the console) end match will be handle soon.
- Create FiveWeekHUD: Simple HUD which display localMessage, Weapon and health (based on UTHud)
- Create Some classes StartMessage, BonusTimeMessage used to handle messages displayed on screen
- Create BonusTime an item based on health pickup item with amountTime, respawnTime and pickupmessage configurable in ued

- Add my sample camera, this class is not used for now and is just added for example.

Someone (luke?) can make a little UIScene for FrontEnd class?

Looks like we 're near to release something for first tests

Edited by xiongmao, 16 April 2008 - 11:45 PM.

[ambershee]

Way ahead of you. The menu classes I also uploaded contains a simple button bar based menu, I've knocked up a scene for it already, but I don't have it to hand; it lives on another machine. I'll have it all merged, uploaded and playable by the end of tommorow

Edit: Nearly got a wall-walking implementation working. The pawn correctly aligns to surfaces and such, but isn't accepting input.

Edited by ambershee, 17 April 2008 - 06:29 PM.

[MikePurvis]

I'm working on the camera. I'll post something this afternoon.

[MikePurvis]

I just tweaked the values in the extended camera. I think it's allright for a test camera. The main probem with it is that the camera should orbit the players location instead of rotating in the cameras location as it is now.

I will try substituting the PLayers Location later. If that is in fact what is occurring.

function UpdateViewTarget(out TViewTarget OutVT, float DeltaTime)
{

	  local vector		Loc;
	local rotator		Rot;
	local bool			bDoNotApplyModifiers;

	// Default FOV on viewtarget
	OutVT.POV.FOV = DefaultFOV;

   Loc = ViewTarget.Target.Location;
   Loc.Z = ViewTarget.Target.Location.Z + 42;
   Loc.X = ViewTarget.Target.Location.X - 30;

   Rot = ViewTarget.Target.Rotation;
   Rot.pitch = 0;

   ViewTarget.POV.Location = Loc;
   ViewTarget.POV.Rotation = Rot;

}

[ambershee]

As an update, I'm nearly done with wall-walking. The only current standing issue is in third person (it works perfectly in first person) - and this is finding a way to rotate the third person mesh in respect to the floor normals that I'm using. At the moment, it always points downwards.

[xiongmao]

@Mike: where do you use "bDoNotApplyModifiers" This boolean is used in the upper class to tell if CameraModifier has to be applied. This shoud be useful to place Blur Effect and other screen effects

@Luke: wonder to know how you do this

I'm working on game workflow,
- start (need a menu)
- end
- state RoundEnded triggered when touching the volume FinishVolume
- display custom scoreboard (I will create a widget to display (the remaining energy and the elapsed time to finish the round)


What about story? When a match is finished: we go back to the menu which allow you to select another map or do we chain maps?

[ambershee]

I was actually just about to post my current implementation - I still can't work out how to rotate the player mesh (it always orientates 'downwards' into the Z-axis).

It's a big chunk of complex code. It's currently also missing double-jumping and dodge moving, and may have unforeseen issues with things like kickers. You'd want to set it up so that the player goes into the PlayerSpidering state when they enter a specific volume type, have enough speed, and are walking on an object with the correct physical material. To test it, you can just assign PlayerSpidering to the LandMovementState in the pawn default properties.

The implementation goes in PlayerController

state PlayerSpidering
{
ignores SeePlayer, HearNoise, Bump;

	event bool NotifyHitWall(vector HitNormal, actor HitActor)
	{
		Pawn.SetPhysics(PHYS_Spider);
		Pawn.SetBase(HitActor, HitNormal);
		return true;
	}

	// if spider mode, update rotation based on floor
	function UpdateRotation(float DeltaTime)
	{
		local rotator ViewRotation;
		local vector MyFloor, CrossDir, FwdDir, OldFwdDir, OldX, RealFloor;

		if ( (Pawn.Base == None) || (Pawn.Floor == vect(0,0,0)) )
		{
			MyFloor = vect(0,0,1);
		}
		else
		{
			MyFloor = Pawn.Floor;
		}

		if ( MyFloor != OldFloor )
		{
			// smoothly transition between floors
			RealFloor = MyFloor;
			MyFloor = Normal(6*DeltaTime * MyFloor + (1 - 6*DeltaTime) * OldFloor);
			
			if ( (RealFloor Dot MyFloor) > 0.999 )
			{
				MyFloor = RealFloor;
			}
			else
			{
				// translate view direction
				CrossDir = Normal(RealFloor Cross OldFloor);
				FwdDir = CrossDir Cross MyFloor;
				OldFwdDir = CrossDir Cross OldFloor;
				ViewX = MyFloor * (OldFloor Dot ViewX) + CrossDir * (CrossDir Dot ViewX) + FwdDir * (OldFwdDir Dot ViewX);
				ViewX = Normal(ViewX);
				ViewZ = MyFloor * (OldFloor Dot ViewZ) + CrossDir * (CrossDir Dot ViewZ) + FwdDir * (OldFwdDir Dot ViewZ);
				ViewZ = Normal(ViewZ);
				OldFloor = MyFloor;
				ViewY = Normal(MyFloor Cross ViewX);
			}
		}

		if ( (PlayerInput.aTurn != 0) || (PlayerInput.aLookUp != 0) )
		{
			// adjust Yaw based on aTurn
			if ( PlayerInput.aTurn != 0 )
			{
				ViewX = Normal(ViewX + 2 * ViewY * Sin(0.0005*DeltaTime*PlayerInput.aTurn));
			}

			// adjust Pitch based on aLookUp
			if ( PlayerInput.aLookUp != 0 )
			{
				OldX = ViewX;
				ViewX = Normal(ViewX + 2 * ViewZ * Sin(0.0005*DeltaTime*PlayerInput.aLookUp));
				ViewZ = Normal(ViewX Cross ViewY);

				// bound max pitch
				if ( (ViewZ Dot MyFloor) < 0.707   )
				{
					OldX = Normal(OldX - MyFloor * (MyFloor Dot OldX));
					if ( (ViewX Dot MyFloor) > 0)
					{
						ViewX = Normal(OldX + MyFloor);
					}
					else
					{
						ViewX = Normal(OldX - MyFloor);
					}

					ViewZ = Normal(ViewX Cross ViewY);
				}
			}

			// calculate new Y axis
			ViewY = Normal(MyFloor Cross ViewX);
		}

		ViewRotation =  OrthoRotation(ViewX,ViewY,ViewZ);
		SetRotation(ViewRotation);
		Pawn.FaceRotation(ViewRotation, deltaTime );
		
		Pawn.Mesh.SkeletalMesh.Rotation = Pawn.Rotation;
	}

	function bool NotifyLanded(vector HitNormal, Actor FloorActor)
	{
		Pawn.SetPhysics(PHYS_Spider);
		return bUpdating;
	}

	event NotifyPhysicsVolumeChange( PhysicsVolume NewVolume )
	{
		if ( NewVolume.bWaterVolume )
		{
			GotoState(Pawn.WaterMovementState);
		}
	}

	function ProcessMove(float DeltaTime, vector NewAccel, eDoubleClickDir DoubleClickMove, rotator DeltaRot)
	{
		if ( Pawn.Acceleration != NewAccel )
		{
			Pawn.Acceleration = NewAccel;
		}

		if ( bPressedJump )
		{
			Pawn.DoJump(bUpdating);
		}
	}

	function PlayerMove( float DeltaTime )
	{
		local vector NewAccel;
		local eDoubleClickDir DoubleClickMove;
		local rotator OldRotation, ViewRotation;
		local bool  bSaveJump;

		GroundPitch = 0;
		ViewRotation = Rotation;

		//Pawn.CheckBob(DeltaTime,vect(0,0,0));

		// Update rotation.
		SetRotation(ViewRotation);
		OldRotation = Rotation;
		UpdateRotation(DeltaTime);

		// Update acceleration.
		NewAccel = PlayerInput.aForward*Normal(ViewX - OldFloor * (OldFloor Dot ViewX)) + PlayerInput.aStrafe*ViewY;
		
		if ( VSize(NewAccel) < 1.0 )
		{
			NewAccel = vect(0,0,0);
		}

		if ( bPressedJump && Pawn.CannotJumpNow() )
		{
			bSaveJump = true;
			bPressedJump = false;
		}
		else
			bSaveJump = false;

		ProcessMove(DeltaTime, NewAccel, DoubleClickMove, OldRotation - Rotation);
		bPressedJump = bSaveJump;
	}

	event BeginState(Name PreviousStateName)
	{
		//if ( Pawn.Mesh == None )
		//	Pawn.SetMesh();
		OldFloor = vect(0,0,1);
		GetAxes(Rotation,ViewX,ViewY,ViewZ);
		DoubleClickDir = DCLICK_None;
		Pawn.ShouldCrouch(false);
		bPressedJump = false;
		
		if (Pawn.Physics != PHYS_Falling)
		{
			Pawn.SetPhysics(PHYS_Spider);
		}
		
		GroundPitch = 0;
		Pawn.bCrawler = true;
	}

	event EndState(Name NextStateName)
	{
		GroundPitch = 0;
		if ( Pawn != None )
		{
			Pawn.ShouldCrouch(false);
			Pawn.bCrawler = Pawn.Default.bCrawler;
		}
	}
}

I'm working on game workflow,
- start (need a menu)
- end
- state RoundEnded triggered when touching the volume FinishVolume
- display custom scoreboard (I will create a widget to display (the remaining energy and the elapsed time to finish the round)


What about story? When a match is finished: we go back to the menu which allow you to select another map or do we chain maps?

I'll have the menu for you today, I'd imagine.

From what I gather of the design, the 5 Week Project is set in a single map with one spawn point in a central 'neutral' room. The neutral room has teleporters that will teleport the user into a room containing one of the challenges. When the player dies, they are automatically re-spawned in the neutral room - UTGame does that for us. When the player wins, we should display their statistics on a 'victory' UIScene. This UIScene should give the player the options of either quitting back to windows, being returned to the neutral room, or being returned to the beginning of the challenge they have completed.

Perhaps when a player is killed, the 'defeated' UIScene should show, in the same fashion, showing their statistics, and giving them the same options, instead of relying on UTGame to respawn them?

[xiongmao]

The code is quite impressive hehe.
I don't know how this neutral room works (not even seen this in the code). I agree about menu with buttons, I'll make the Uscript classes and implements the button logic (and a dirty UIScene for test ).
I may take a look to your code to see if I can understand something

[ambershee]

That's because the rooms are not code - they are purely in the level design.

The whole game uses only one level, split up by teleporters

[R0n1n]

Perhaps when a player is killed, the 'defeated' UIScene should show, in the same fashion, showing their statistics, and giving them the same options, instead of relying on UTGame to respawn them?

They should respawn (because they will die quite often) and i dont want them to reload the map everytime. Another reason ist that it's going to be shown at an exibition. People walking by and playing it should not have to reload a level. They must be able to grab the keyboard and play a bit right away. But we can implement the Screen with his stats by pressing 'tab' if we can do it in time. Really a nice to have feature though.

[ambershee]

My intention was not to reload the map at any time ever - but instead just reset the player statistics, and 'teleport' them to a predefined location when they click a menu button

Edit: You could edit out the 'exit' button for the presentation copy.

Edited by ambershee, 18 April 2008 - 11:10 AM.

[R0n1n]

Just wanted to make sure

I was really surprised to read that you're nearly done with wall-walking. I though we agreed not to do it. Seems we had a missunderstanding there.
My problem is that i am desperately waiting for working movements so i can start with the leveldesign. Well, it seems you're passionate about the wall-walking and already spent time implementing it. So let's do it. But it's your responibility to make it look good and controlled smoothly.

I'll write a list of what i need:

High Priority
- Working walking and strafing. Increase speed
- Working jumps and doublejumps. Increase height and Distance
- Movement should work nicely with kickers, movers and physicsVolumes
- Document where i can chance the movement-attributes for balancing

Medium Priority
- Multiple Walldodges (thinking twice)
- Wall-walking

[ambershee]

I was implementing wall-walking for code-practice at work, rather than necessarily for the project. It's in there, but it doesn't have to be used.

Walking, Strafing, Jumps, Speed, Height, is all working. You could download the code drop from subversion and use it already. The variables controlling these are all in the default properties of the 5 week project classes.

I'll be updating the code drop today, but it'll contain UI based stuff, so you don't need to worry about that yet.

[xiongmao]

- Increase speed could be done throught a new state (PlayerRunning) in which groundSpeed and others properties could be increased. This state could be reached when the player stay in the state PlayerWalking during a configurable time (let's say 5s by default)
- About height don't know what is best between powerups or volume which affect player physics
- Document: all developpers should write a list of configurable fields of each class (Range value, optional, ...), this will be merged in a single document later.

[ambershee]

- Increase speed could be done throught a new state (PlayerRunning) in which groundSpeed and others properties could be increased. This state could be reached when the player stay in the state PlayerWalking during a configurable time (let's say 5s by default)
- About height don't know what is best between powerups or volume which affect player physics

I'm a little confused? I'm not sure we're talking along the same lines? The implementation wanted was to just increase the standard GroundSpeed - this has been done - jump height and distance is covered by JumpZ.

- Document: all developpers should write a list of configurable fields of each class (Range value, optional, ...), this will be merged in a single document later.

Documentation is a good idea. No need to merge into a single document - this is what we have the wiki for. IIRC, none of the fields are config variables, because we wouldn't normally want the end user tampering with them and making it easy for themselves. However, for the 5 week implementation, this probably isn't an issue and we can make the changes.

All such classes should have the same config file, I think.