143 replies to this topic

[ambershee]

Hi guys,

Welcome to the thread used for discussing the 5 week project. I anticipate, seeing as there are only four of us, this should do the trick quite nicely.

Feel free to chat off-topic or join other threads.

Documentation may be found here:
http://sheelabs.game...le=5weekproject

Please add content as necessary. You will need to register first.

[xiongmao]

Guess you need to change menu like Here

What kind of stats michael refers to ?

A proper HUD should be implemented to show the important statistics.

[MikePurvis]

Hi:

I'm just checking in here. I checked out the shelled level for the jump n run and it's a really clean kismet setup.

How do you guys want to divide up the tasks?

Mike

[ambershee]

I'd assume for the time being, we'd only be talking about time remaining, and health - since those are the only statistics in the game; but this could later be expanded. Also, if we implement my idea that health = time, then that's all we need to display at all.

As for task division, we can't do it class based, as almost everything we write will either be in the game mode or player classes - so we'll have to take a 'technology' or 'feature' based approach.

If I set up a custom game mode, extending UTGame, with a basic pawn and controller based on UTPawn / UTPlayerController, then I can make the minor stat adjustments to player speed, acceleration and jump height.

That means one person can work on a timer system (can we get word from Michael - I still think using the existing health would be the perfect system, seeing as it already exists, and can be easily employed - and even kills the player when it hits 0.

And someone else can start implementing a decent behind view camera.

Then when a feature is done, you can post the code for it in the forums, so that I can merge it with the existing game mode / player

[xiongmao]

I agree so we need to define precisely the main tasks ( about 7-8: 1 per person which represents mandatory tasks then some extra optional features ) .
Wiki is good to show project aim and features but not for team work, michael should come here, he is the one who can tell which tasks have to be done first.

[ambershee]

Organisation has largely fallen into my lap - we should be just fine using forums and wiki - so long as we maintain regular contact.

The most important features are quite clear - the game is a speed run game;

• We need to create a custom game mode and player class, derived from suitable parents (aforementioned UTClasses respectively)
• We need to create a timer system, that counts down from one point in a level, until it reaches another (volumes are ideal). This system should possibly count the total time counted down, as well as modified time (losing time or gaining time from pickups / damage etc)
• It must have a 3rd person view.

Those are clearly our compulsory objectives. The game mode will not exist nor work properly without them.

Very important tasks would include:

• Displaying vital statistics, e.g the timer
• Win / Loss screens dependent on, and showing relevant info relating to outcome.
• A special pickup that adds time.

Less important tasks include:

• A variety of new environmental factors, such as new volumes or interactive actors.
• A system of power-ups.
• Multi-wall jump.
• Fancy visual effects, e.g speed dependent motion blur.

And of course, the potential additional fun stuff, as listed on the wiki.

Agreed?

[xiongmao]

Yep sir
interested by the timer system and HUD, guess I have to add your msn address to debate
See Ya Tonight

Edited by xiongmao, 03 April 2008 - 02:48 PM.

[R0n1n]

Greetings my coding monkeys !!

(sorry i wanted to say that for ages )



Replies to your Posts:

Guess you need to change menu like Here

If you can do it.. great! Please tell me early so i can work on the Hud-Graphics and create the necessary textures.

What kind of stats michael refers to ?

I was referring to the Countdown (how much time is left), the time (how long the player is already running) and the Healthpoints.

can we get word from Michael - I still think using the existing health would be the perfect system

I thought about this too. In the end i decided against it because it would mean using impact hammer or falling from high places means a loss in time. Besides i dont want to hear that "AARGH" and see the effect when beeing damaged every second. If we use Healthpoints we should ignore damage from impacthammer and falling. We should also remove those Sound- and Visualeffects when being damaged.

And someone else can start implementing a decent behind view camera.

I found a Mutator that does the behindview thing. The *.uc files are also in there. Might be interesting for you guys to see how it's done. It's 28.3kb, so i'll just e-mail it to the Coder working on the behindview.

Organisation has largely fallen into my lap

Yeah. I think it's best to let coders organize their workflow.
However i'd like you to give me feedback what you're working on and discuss gamedesign related stuff with me. Please don't implement things if you're not sure im okay with it.
I don't wanna be a controlfreak but i will get my grades for the gamedesin. For that reason i wanna make sure i agree with the design.
But feel free to bring your ideas to the table please!

We need to create a timer system, that counts down from one point in a level, until it reaches another (volumes are ideal).

Not sure if this is a problem: I noticed that overlapping volumes can cause problems. I definately want to use some physic volumes in the leves. So we should only use volumes as triggers if they dont interfere with physicsVolumes. If they do we should use triggers.

[ambershee]

I can answer / counter most of these

Guess you need to change menu like Here

If you can do it.. great! Please tell me early so i can work on the Hud-Graphics and create the necessary textures.

Hud != menu, but we should be able to create a main menu, and Hud with any graphics you give us.

can we get word from Michael - I still think using the existing health would be the perfect system

I thought about this too. In the end i decided against it because it would mean using impact hammer or falling from high places means a loss in time. Besides i dont want to hear that "AARGH" and see the effect when beeing damaged every second. If we use Healthpoints we should ignore damage from impacthammer and falling. We should also remove those Sound- and Visualeffects when being damaged.

It's a custom game mode. The player doesn't have to have the impact hammer at all (we define his starting weapons with a simple single line of code) - but in the interest of hammer jumping, it'll take me literally two seconds to make an impact hammer that doesn't do any damage (four lines of code). I can also prevent falling damage (or increase the falling distance) with a little work - although falling from high places could be a game mechanic. So we can still easily use the health variable - unless you have any other objections.

And someone else can start implementing a decent behind view camera.

I found a Mutator that does the behindview thing. The *.uc files are also in there. Might be interesting for you guys to see how it's done. It's 28.3kb, so i'll just e-mail it to the Coder working on the behindview.

Is it ActionCam, per chance?

We need to create a timer system, that counts down from one point in a level, until it reaches another (volumes are ideal).

Not sure if this is a problem: I noticed that overlapping volumes can cause problems. I definately want to use some physic volumes in the leves. So we should only use volumes as triggers if they dont interfere with physicsVolumes. If they do we should use triggers.

Volumes do not conflict if they are different types. They also can be assigned a priority, so that if they do overlap, one will take precedence over the other.

[R0n1n]

Hud != menu, but we should be able to create a main menu, and Hud with any graphics you give us.

Okay got it. It's not on top of the To-Do List but definetly something we should add once the basics are done.

It's a custom game mode. The player doesn't have to have the impact hammer at all (we define his starting weapons with a simple single line of code) - but in the interest of hammer jumping, it'll take me literally two seconds to make an impact hammer that doesn't do any damage (four lines of code). I can also prevent falling damage (or increase the falling distance) with a little work - although falling from high places could be a game mechanic. So we can still easily use the health variable - unless you have any other objections.

I feel stupid not knowing that kind of stuff. There is reason why i need some help with the coding part
If you can do it that easy then go ahead. Remove the Enforcer but keep the impacthammer. Please remove the splashdamage hurting the Player when jumping with the impacthammer. And i would remove the fallingdamage. I dont think damage reducing time makes the game more interesting.

Is it ActionCam, per chance?

Nah, it's called "MK3rdPersonMutator_v1.21"
Downloadlink: http://files.filefro...;/fileinfo.html

Some Comments about the other potential Features (taken from the Wiki):
I had some of those ideas but didn't dare bringing them up because i didn't want to scare you guys I guess i overestimated the time it takes to implement that stuff.

- I love the "two edged" swords idea. I will think of some other Pickups besides the TimePickup.
- "player should accelerate slowly to a very high maximum speed". Like that one too. What do you think about accelerating in steps instead of a steady acceleration? Imagine your basespeed is 1. If you can run 10 seconds without stopping your speed increases by1 up to a max of 5 or something.
- walking on walls? I love it. But this would need mind. 5 new animations (i dont have the time to do them) that need to look as good as the other animations and a new way to control the playermodel. I don't think we can realize this in five weeks.
- Motionblur? Need. How about increasing the strength of the Motionblur the faster the player is running (or when he picks up a speedboost)?

Edited by R0n1n, 03 April 2008 - 06:16 PM.

[R0n1n]

I started working on the visuals for the level today. Watching good old Tron and looking at some other footage.
If you need meshes, textures or anything else tell me. As long as you remain silent i'll stick to the level.

[ambershee]

I feel stupid not knowing that kind of stuff. There is reason why i need some help with the coding part
If you can do it that easy then go ahead. Remove the Enforcer but keep the impacthammer. Please remove the splashdamage hurting the Player when jumping with the impacthammer. And i would remove the fallingdamage. I dont think damage reducing time makes the game more interesting.

Will the player need to take any damage at all? The reason I'm asking is to see if we can jump ahead in the code, and from my own personal designerbrain perspective.

I spoke to xiongmao earlier, and we agreed that the health code already gives us several things - namely a whole number statistic that is a) drawn to the HUD already, b) is already tied to several modifier functions, c) can be modified with a 'damage volume' and d) already has health pickups. It saves writing a timer, letting us move on to other features. Although xiongmao is still quite happy to implement a fresh timer based system if desired.

The other reason is from a personal perspective - whilst we can force the player to monitor two variables (time and health), we could potentially simplify and cut it down to one thing - this is called 'dramatic focus'; it places more emphasis on what is really important to us, which is how quick we can navigate. I can remove falling damage, that's not a problem. I'm for allowing the environment to strip the player of time, quite happily - it means the much faster players can deliberately ignore risks, if they believe they can push that little extra for overall time, whilst still not being defeated by the counter? Risk and Reward

It's your call - because we'll need to write it sooner rather than later, and xiongmao is itching to get away on something.

- "player should accelerate slowly to a very high maximum speed". Like that one too. What do you think about accelerating in steps instead of a steady acceleration? Imagine your basespeed is 1. If you can run 10 seconds without stopping your speed increases by1 up to a max of 5 or something.

From a code perspective, constant acceleration is better, namely because it already exists and wouldn't require any alteration of the existing movement code, other than making the acceleration slower, so that maximum speed isn't achieved in a literal split second like in UT3 - more like over four or five seconds.

- walking on walls? I love it. But this would need mind. 5 new animations (i dont have the time to do them) that need to look as good as the other animations and a new way to control the playermodel. I don't think we can realize this in five weeks.

5 new animations?? For what? Also, I don't believe any additional controls would be necessary?

- Motionblur? Need. How about increasing the strength of the Motionblur the faster the player is running (or when he picks up a speedboost)?

That would be the idea - motion blur increases proportionately with speed. I know it's easy to do with the camera, and I think I can get it per-object as well.

[xiongmao]

all right , here is an one hour test on timer stuff

The Test Gametype

class EA_FiveWeekProject_GT extends UTDeathMatch;

var config int nbSeconds;

var EA_FiveWeekProject_Timer WPTimer;

function PostBeginPlay()
{
  super.PostBeginPlay();

  WPTimer =spawn(class'FiveWeekProject.EA_FiveWeekProject_Timer');
  WPTimer.totalTime = nbSeconds;
  WPTimer.fiveWeekGT = self;
}

function startFiveWeekGame(float remainingTime)
{
 LogInternal("start");
}


function endFiveWeekGame(float remainingTime)
{
 LogInternal("stop");
}

defaultproperties
{
  DefaultInventory.Empty
  nbSeconds=60
}

The startVolume

class EA_FiveWeekProject_StartVolume extends Volume
	  placeable;


event Touch( Actor Other, PrimitiveComponent OtherComp, vector HitLocation, vector HitNormal )
{
  if(Pawn(Other) != None && EA_FiveWeekProject_GT(WorldInfo.Game) != None && !EA_FiveWeekProject_GT(WorldInfo.Game).WPTimer.isStarted)
  {
	 EA_FiveWeekProject_GT(WorldInfo.Game).WPTimer.startTimer();
  }

}

The stopVolume

class EA_FiveWeekProject_StopVolume extends Volume
	  placeable;

event Touch( Actor Other, PrimitiveComponent OtherComp, vector HitLocation, vector HitNormal )
{
  if(Pawn(Other) != None && EA_FiveWeekProject_GT(WorldInfo.Game) != None && EA_FiveWeekProject_GT(WorldInfo.Game).WPTimer.isStarted)
  {
	 EA_FiveWeekProject_GT(WorldInfo.Game).WPTimer.stopTimer();
  }

}

The Timer

class EA_FiveWeekProject_Timer extends Actor;

var int totalTime;
var float remainingTime;

var float rate;
var bool isStarted;

var EA_FiveWeekProject_GT  fiveWeekGT;

function startTimer()
{
  remainingTime = totalTime;
  isStarted=true;
  setTimer(rate,true, 'checkTime');
  fiveWeekGT.startFiveWeekGame(remainingTime);
}

function stopTimer()
{
  isStarted=false;
  setTimer(0, false, 'checkTime');
  fiveWeekGT.endFiveWeekGame(remainingTime);
}

function increaseTimer(int amountSeconds)
{
   remainingTime += amountSeconds;
}

function decreaseTimer(int amountSeconds)
{
   remainingTime -= amountSeconds;
}


//Loop function
function checkTime()
{
  remainingTime -= rate;
  if(remainingTime <= 0)
	  stopTimer();

  LogInternal("remainingTime: "$remainingTime);
}

defaultproperties
{
  rate=0.1
  isStarted=false
}

Timer Features:
- start (from touch startVolume)
- stop (from touch stopVolume)
- increaseTime
- decreaseTime

The timer is a field of the UTGame, like this he is accessible everywhere.

Comments ?

[R0n1n]

Okay i thought about the Timer/Healthpoint issue. I just dont like using Healthpoints as healthpoints (damage) AND time. It's like shooting myself in the foot and i grow older. Here is what would like to do:

Storybackground:
Today science is working on expressing human intelligence digitally. They also talk about the theoretical possibility of saving a humans brainpatterns (and therefore his soul) in digital form. That would allow humans to live in digital networks without the burden of a body.
Imagine a future where this techonolgy is real. The player represents such a digital human soul (go watch Ghost in the Shell). His most important goal is of course to enrich and improve himself with new data, information and functions. So he runs through the vast networks to hunt such information. But he needs energy to stay "alive". Once he leaves his server and travels the networks he is cut off his energysource and constantly using up his energy. He will have to be quick, refill his energy and try to retrieve some important data before he disapears. Luckly he can restore his own backup if stuff goes wrong.

Implementation:
We only use the Healthpoints. But we call them "Energy". This means we have to change the icon in the HUD and maybe some Messages that talk about "Health". Player constantly looses energy, can regain some through pickups and will loose energy from falling damage. I want to playtest the fallingdamage. Dunno, it could suck but it could also enrich the gameplay. Not sure jet. So we need it for now. We remove the damage of the impacthammer. That way it all makes sense and it goes well with the leveldesign i have in mind and the UT3 playermodels (come on, they look sci-fi).

--------------------------------------

Another idea i had while thinking about his: We now got the explanation WHY the player runs through these levels. He tries to find new information that enriches and completes his digital soul. How cool would it be if he actually becomes stronger for every level he can complete? We could reward him with increased speed, jumps, starting energy or even special moves (like holding down a key in midair to make him fall slower and therefore allow him to jump further). We would have to save his progress somewhere so he doesn't have to do it all again everytime he plays.

How do you like that? It is a bit radical because its not part of the gamedesigndocument and something new. But i really like this idea and it fits well with the backgroundstory. Tell me what you think please

--------------------------------------

About the speed and acceleration:
I prefer the idea of an increase in steps. But both ways it's cool so implement it with constant acceleration if thats easier to do. But one thing is important to me. We mustnt increase from 0 to maxSpeed at the same rate. The player should be able to start running if he wants to and not wait for his character to slowly gain speed. This is necessary to jump around between movers for example. At first we need quick acceleration to his mediumSpeed and from there accelerate slower until his maxSpeed. He should feel two states. Standing still and running. Nothing in between. But the running should accelerate until he has to stand still again.

Red is bad, green is good ^^ meeeeh.. i hope you get my point. I have such a hard time expressing myself in english. The dictionary is my best friend these days

5 new animations?? For what?

People running along walls move completly different than on the floor. So you need new animations for the running and for the transfer between floor and wall in 4 possible ways (just what popped into my mind) if it should look cool. And something like running along walls could be cool enough to build a whole mod aroung it. BUT you have to do it right. And therefore i am convinced you need great animations and a controlsystem that makes running not only in XY but also in ZY and ZX comfortable.
Just seems to be a lot of work to do it right.

Edited by R0n1n, 03 April 2008 - 11:37 PM.

[THE_SPELUNKERmw]

Can I be the comic relief?


I suggest cinematic camera views if possible since you are doing a custom level!
Make the camera shift position constantly to give the player the best combination of seeing what they need to and cinematic beauty!


I LOVE how metal gear solid does this as well as other games. Basically, you have no control over the camera, but it moves where you need it to and makes things look more like an action movie if you want them too!

Edited by THE_SPELUNKERmw, 04 April 2008 - 03:58 AM.

[ambershee]

You want to write code for that ?

The timer class is alright, but I would recommend using a system more similar to damage volumes - when in volume, decrease timer at predictable rate. This rate can therefore change for given volumes, or even add time or other sillyness if we ever really wanted to. Code flexibility is good to have

We only use the Healthpoints. But we call them "Energy". This means we have to change the icon in the HUD and maybe some Messages that talk about "Health". Player constantly looses energy, can regain some through pickups and will loose energy from falling damage. I want to playtest the fallingdamage. Dunno, it could suck but it could also enrich the gameplay. Not sure jet. So we need it for now. We remove the damage of the impacthammer.

Falling damage was removed last night, but I'll plonk it back in for you before I upload some code tonight for testing. The Impact Hammer has had it's damage removed, but we can modify the push amount and distance from which it can auto fire with ease.

How cool would it be if he actually becomes stronger for every level he can complete? We could reward him with increased speed, jumps, starting energy or even special moves (like holding down a key in midair to make him fall slower and therefore allow him to jump further). We would have to save his progress somewhere so he doesn't have to do it all again everytime he plays.

Let's ignore this for now - because this is a lot of work. I had thought about this myself, but it seems more prudent to just give the player the equipment he will require or can use at the beginning of a level, and then take it away again when it is finished.

I prefer the idea of an increase in steps. But both ways it's cool so implement it with constant acceleration if thats easier to do. But one thing is important to me. We mustnt increase from 0 to maxSpeed at the same rate. The player should be able to start running if he wants to and not wait for his character to slowly gain speed. This is necessary to jump around between movers for example. At first we need quick acceleration to his mediumSpeed and from there accelerate slower until his maxSpeed. He should feel two states. Standing still and running. Nothing in between. But the running should accelerate until he has to stand still again.

I'll look into it, but I think it'll remain constant; it wouldn't however take a significant amount of time to hit maximum speed, and you should design levels only when you are aware of the outcome of player movement metrics - he should be able to easy jump around movers, but he'll just be able to pick up speed outside of it.

5 new animations?? For what?

People running along walls move completly different than on the floor. So you need new animations for the running and for the transfer between floor and wall in 4 possible ways (just what popped into my mind) if it should look cool. And something like running along walls could be cool enough to build a whole mod aroung it. BUT you have to do it right. And therefore i am convinced you need great animations and a controlsystem that makes running not only in XY but also in ZY and ZX comfortable.

Don't forget, this is a 5 week implementation of a game prototype, not the next triple-A block buster title. As it happens, like I said, I did this in UT2004. If the player has significant speed and approaches an object which may be wall-walked, then he will begin to traverse it. Think back to my example of Sonic the Hedgehog again; in both the 2d and 3d games, he can't suddenly switch from running along the floor to a vertical wall, there are transitions (curved surfaces) in between. His animations also do not change - nor do they need to, he just keeps running whilst possible.

The control system wouldn't change, because the transition is smooth. The camera would rotate with the player to facilitate this.

Anyway, I can't guarantee I'll even have an implementation, but it's something to bear in mind. I've been working on it for UT3, and if I get it working, I get it working. It was intended for use in our racing game.

Edited by ambershee, 04 April 2008 - 10:06 AM.

[R0n1n]

I like the idea of Volumes. It's a good thing to be flexible in the designprocess.

Let's ignore this for now - because this is a lot of work.

Im okay with that. Let's implement the basics before we do anything else.

and you should design levels only when you are aware of the outcome of player movement metrics

Im not insane enough to try building levels without knowing the metrics
But i don't think we can do it with a constant acceleration. It will either take forever to start running (which sucks for a jump n run type game) or the player will get insane speed if i can run straight for a couple of seconds. And that again is a problem in leveldesign if i can't allow him to run straight for a while.

Don't forget, this is a 5 week implementation of a game prototype, not the next triple-A block buster title.

I know. That's why im not sure about it. IF you do wall running it is a big change in gameplay. It has to look good and you have to build all levels geared towards this feature. And i think for the 5 weeks it is too much. Dont get me wrong: I like the idea. I just think we would need more time to do it right. For me too.. i need time to run around and play to get a feeling for the movement and build levels tailored towards it. I dont see this happening in 5 weeks time. I'd add this to the "Would-be-cool-to-do-after-we-get-the-basics-done-feature-request-list".

Another thing:
Do you need a Package with dummymeshes to work on the pickups?
What do you think about the Backgroundstory? Do you like it? Would be happy to get some feedback about it.
Can you define all stuff like jumpingheight- length, speedvalues ... and so forth in to an external file or in one place inside the code or something? I guess we will have to tweak all of those variables for balancing. It would be good if you could do it all in one place.

Edited by R0n1n, 04 April 2008 - 10:39 AM.

[ambershee]

Another thing:
Do you need a Package with dummymeshes to work on the pickups?

We can use existing meshes as placeholders until final art assets are available without many difficulties.

What do you think about the Backgroundstory? Do you like it? Would be happy to get some feedback about it.

It'll do for the time being - as a basis, it's solid enough to work from, so with a bit of tightening it'll work well later on. Although is a plot necessary ?

Can you define all stuff like jumpingheight- length, speedvalues ... and so forth in to an external file or in one place inside the code or something? I guess we will have to tweak all of those variables for balancing. It would be good if you could do it all in one place.

Have you ever looked at UT3 code? Every class has a set of 'default properties'. These are all the important variables used in a class, and are found at the end of the text file.

Jump-Z, player speed and player acceleration are amongst these

[xiongmao]

I'll check DamageVolume this weekend. The background story is a good start.

[Edit] I found the field PainTimer in PhysicsVolume which is the timer that cause pain every second in LavaVolume for example but I think we can't use it as each volume has its own timer. In our case, we want a timer which is shared between all volumes. However we could use the VolumeTimer of each volume to affect the main Timer located in the UTGame class.

What do you think ?

Edited by xiongmao, 04 April 2008 - 05:09 PM.

[MikePurvis]

Hi:

Looks like a lot went on the last couple days. I've been in class most of that time. I was in a discussion earlier this week about changing the rate of accelleration in a game. I think that acceleration should be constant.

It looks like the camera is up for grabs so I'll work on that. I have a version of the ActionCam as reference. Is there anythingwrong with writing functions that can be integrated into the Pawn and Player Controller classes AmberShee?

I like the additional story ideas as well that explain why the character is running. However, I think it is not neccesarry and it could stand on gameplay alone. I had fun in the level shell.