5 Week Project
#41
Posted 16 April 2008 - 11:45 AM
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
#42
Posted 16 April 2008 - 12:33 PM
Let's talk about this on Msn this evening.
#43
Posted 16 April 2008 - 12:38 PM
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
#44
Posted 16 April 2008 - 04:55 PM
I can build you a Testmap quickly if you still need it.
Edited by R0n1n, 16 April 2008 - 05:25 PM.
#45
Posted 16 April 2008 - 07:06 PM
#46
Posted 16 April 2008 - 11:44 PM
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.
#47
Posted 17 April 2008 - 08:53 AM
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.
#48
Posted 17 April 2008 - 07:10 PM
#49
Posted 17 April 2008 - 08:29 PM
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; }
#50
Posted 17 April 2008 - 09:01 PM
#51
Posted 18 April 2008 - 08:17 AM
@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?
#52
Posted 18 April 2008 - 08:30 AM
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?
#53
Posted 18 April 2008 - 09:08 AM
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
#54
Posted 18 April 2008 - 09:16 AM
The whole game uses only one level, split up by teleporters
#55
Posted 18 April 2008 - 11:06 AM
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.
#56
Posted 18 April 2008 - 11:09 AM
Edit: You could edit out the 'exit' button for the presentation copy.
Edited by ambershee, 18 April 2008 - 11:10 AM.
#57
Posted 18 April 2008 - 11:56 AM
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
#58
Posted 18 April 2008 - 12:15 PM
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.
#59
Posted 18 April 2008 - 12:27 PM
- 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.
#60
Posted 18 April 2008 - 12:36 PM
- 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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users