next »

[archgame]

Preparing Character Controller and Camera Controller Scope in preparation for hiring a programmer. recent edits are in red.

PROVIDED MATERIAL:
Unity Project:
   Test Scene:
      Sphere Mesh
      Objects:
         Items, Buildings, Obstacles.
      Character (rigged with Mecanim set up):
         Animations:
            Idle 1, Idle 2, Idle 3, Walk, Run, Jump Enter, Jump Up, Jump Peak, Jump Land, Fall, Climb Enter, Climb Up, Climb Down, Climb Dismount, Swim Enter, Swim Move, Swim Exit, Sit Enter, Sit Idle, Sit Exit, Push Enter, Push, Push Exit,, Crawling Enter, Crawling Move, Crawling Exit, Pick-Up, Talk, Eat, Pull
 
CONTROLLER SCOPE
 
Introduction:
The character controller will be used on multiple playable characters and will therefore need to have variables exposed publicly for easy adjustment in the unity editor as well as booleans for each function to determine if the player has the ability to do them. A controller input script will be provided, from which all input should be derived; This script will format the input variables appropriately so no calibration is needed within the character controller script. Additionally a mecanim tree will be established with animations input (although this is subject to change with programmer input). It should be assumed that whenever “up” is used in the function descriptions, it is referring to a direction vector related to the character's base and center of the sphere. A character is defined as grounded when the character collider is interacting with a groundable surface, which is split into two categories, the first for the sphere (bottom-most ground) and the second for all other platforms. For further clarifications on the desired move functions the programmer may reference Wind Waker for all functions except the Jump function which they should reference Super Mario 64 for the initial Jump and Super Smash Brothers for multiple Jumps. Inverse Kinematics will be used for the feet, legs, and torso. The character’s forward whisker is a raycast defined as the character’s forward direction of a length defined by the Interact Distance Variable. Using the Super Character Controller, the character controller will need to perform with the following functions:
 
Idle: Character enters the idle state when they are grounded, it is the default state. After a certain amount of time as defined by the Wait Variable, the character will cycle through idle animations.
 
Walking: A joystick push of any value less than a full push (i.e. 1.0) will move the player forwards at a rate determined by the walk variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.
 
Running: A full joystick push (i.e. 1.0) will move the player forwards at a rate determined by the Run Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.
 
Jumping: When the Jump Button is pressed, the character should move in the up direction by an amount determined by the Jump Variable. While Jumping, the players forward direction will still be derived from the Follow state, allowing for change in forward direction and deceleration, but not acceleration in the forward direction. There will also be included a Number Of Jumps Variable which will determine how many sequential Jump functions a character may perform without returning to a grounded state. If the Jump Button is pressed while Jumping and the maximum number of Jumps as defined by the Number Of Jumps Variable has not been reached the character should move in the up direction by an amount determined by the Jump Variable. When the character reaches the height as determined by the Jump Variable, the character should switch to a Falling state.
 
Falling: When a character is not grounded (as determined by the characters distance to a surface with the appropriate grounded classification), the character should enter the Falling function, unless in the Jumping or Climbing function. While in a Falling state, the character should be moving opposite of the up direction with the addition of any forward movement at a rate determined by a global Gravity Force Variable. When the character collides with a surface containing grounded information, a landing animation should play and the character returns to a grounded state. If the character has any forward movement, the character should immediately transition to either a Walk or Run state depending upon the Joystick variable, and if there is no forward movement, the character should transition to an idle state.
 
Climbing: When the character is within a globally defined range to a surface deemed climbable by tag and the Climb Button is pressed, the character will enter into the Climbing state. The Climbing state is entered into with a Mounting Animation. While in the Climbing state and the Joystick is pressed in an up direction the character should move in the up direction parallel to the mounted surface (not the center of the sphere). If the Joystick is pressed down the character should move in the opposite direction of the up direction parallel to the mounted surface. If the joystick is pressed to the left or to the right, the character should move to the left or right of the mounted surface. The character will exit the Climbing state when the become grounded, reach the top of the mounted surface, reach either side of the mounted surface, or reach the bottom of the mounted surface. All dismounts except for the top surface dismount will play the standard Dismount animation when entered into. The top surface dismount will play the Climb over animation and the character shall be moved in a negative perpendicular direction of the mounted surface into a grounded state.
 
Swimming: When the player enters a surface deemed swimmable and the difference between the ground surface and swim surface is larger than three/fourths the character’s height as determined by the Height Variable the character shall enter the Swimming state. The swimming state is entered into with a Swim Enter animation. While in the Swimming state a joystick push will move the player forwards at a rate determined by the Swim Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame and its position on the swimmable surface, the animation will be adjusted to make it look as if the character is below the surface.
 
Floating: When the player enters the Falling state and the Jump Button is held down the player will enter the Floating state. While in the Floating state a joystick push will move the player forwards at a rate determined by the Swim Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame and its up position as determined by the distance from the player to the sphere when the Floating state was entered into.
 
Driving: While in the Driving state a joystick push will move the player forwards at a rate determined by the Drive Variable at an acceleration determined by the Acceleration Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame. While in the Driving state, joystick presses outside a defined range will have no effect on the characters movement (i.e. the character will not be able to immediately rotate in 180 degrees, but will be forced to turn at a rate similar to a wheeled vehicle).
 
Pushing/Pulling: When the character’s forward whisker collides with an object that is pushable and the Push Button is pressed the character will enter the Pushing state. While in the Pushing state the character will reorient so that the characters forward direction is perpendicular to the nearest surface of the object. While in the Pushing state if the Joystick is pressed up the character and object move in a forward direction as defined by the perpendicular orientation direction. While in the Pushing state if the Joystick is pressed down the character and object move in a backward direction as defined by the negative perpendicular orientation direction. While in the Pushing state if the Push Button is pressed, the character exits the Pushing state.
 
Sitting: After a determined amount of time the character will enter into the Sitting state. The Sitting state is entered into by the Sitting Enter animation, which transitions into the Sitting animation, which is a random series of three animations. When any Button or Joystick is pressed by the player, the character exits the Sitting state with the Sitting Exit animation. The Sitting state is also determined by the proximity of a sit-able surface or ground, which will determine which animations and where the character is located.
 
Interact: While in the Idle state and the Interact Button is pressed the character enters into the Interact State. While in the Interact state the character plays an animation determined by camera targeted object or forward whisker collided object. For example if the targeted object is an NPC, the character will play a Talking animation. For example if the nearest object is a collectable, the character will enter into a Pick-Up animation. If the Interact animation has an exit time, this will determine at what time the character will exit the Interact state. If there is no exit time for the Interact Animation, pressing the Interact Button again will exit the Interact state.
 
CAMERA SCOPE:
 
Introduction:
A camera input script will be provided, from which all input should be derived; This script will format the input variables appropriately so no calibration is needed within the character controller script. It should be assumed that whenever “up” is used in the function descriptions, it is referring to a direction vector related to the camera’s position and center of the sphere. Additionally, the camera will maintain an oblique frustum to frame the character. Next, the camera will maintain a list of proximate objects of a distance defined by the Proximity Variable. Lastly, The camera will have collision detection to prevent the camera from going through certain objects, indicated by a list of tags (“ground”, “building”, etc). The camera controller will need to perform with the following functions:
 
Following: The default camera state is the Following State. While in the Following State the camera will follow the character at a distance in the reverse direction of the character’s forward direction at a length defined by the Camera Distance Variable. The Camera will maintain a lock on the character as defined by the characters Target Position and Height Variable. The character’s Target position will be located with a vector as defined by the character’s forward position with an amplitude defined by the character’s moving speed. The camera Target position will use whiskers (multiple raycasts) to determine proximate obstacles. When the Joystick input vector is within a threshold indication right or left character movement as defined from the screen position, the Camera position will not change while the lock rotation will continue to update (See Legend of Zelda: Majora’s Mask for example).
 
Horizontal Rotation: When the Camera Joystick is pressed in either horizontal direction the camera will rotate around the target in that direction at a rate defined by the Rotation Variable. After a set amount of time as defined by the Wait Variable, the camera will smoothly rotate back to character’s forward direction.
 
Look-Up: When the character is not in a Moving State and the Camera Joystick is pressed up the Camera will smoothly move towards the grounded surface and pivot up. Additionally the camera angle will decrease to give a wider cinematic view. If the character enters a moving state or the Camera Joystick is pressed down, the Camera will smoothly return to a Following State.
 
Above: When the Camera Joystick is pressed up the Camera will smoothly move away from the grounded surface and pivot down. Additionally the camera angle will decrease to give a wider cinematic view.
 
Targeting: When the Camera Target button is pressed the camera’s look at transform will lock onto a proximate targetable object as defined from a list of proximate targetable objects. If the Camera Target button is pressed again, the locked object will change to the next locked object in the list. While the Camera Target button is held down, the Camera will continue to update in the Targeting State. If the Camera Target button is released the camera will move smoothly back into the Default state. If there are no proximate targetable objects in the List, the Camera should smoothly move to a position in the negative forward direction of the character’s forward direction and lock onto the character.
 
Narrow: When the Target Position whiskers detect the character is between two vertical surfaces, The Narrow state will be entered. While in the Narrow state the Camera position will be set at a distance defined by the Narrow Distance from the character in a direction perpendicular to the two vertical surfaces with the camera’s lock position defined by the same vector. Additionally, the camera angle will become larger to create a cinematic sense of compression.
 
Rooftop: When the character is on a rooftop as defined by the tag of the grounded surface, the Camera position will move in a negative forward direction as defined by the Rooftop Variable. Additionally, the camera angle will decrease in size to give a cinematic sense of the sublime.
 
Jumping: When the Jump button is pressed, the camera will enter into the Jump state. During the Jump state the camera should perform the same as the Following State, except the camera’s up position will not change, unless the character leaves a defined screen frame, at which point the camera will return to the Default state.
 
Crawling: When the Crawling Button is pressed the Camera’s forward direction will orient towards the character’s forward direction and the camera’s up position will move towards the ground to be equal to the characters colliders center. Additionally the camera will pivot up and the camera angle will increase to provide a cinematic sense of compression.
 
Swimming: When in the Swimming State the Camera will perform the same as the follow state except the Camera’s up position will be derived from the swimmable surface, not the ground.
 
Waiting: After a set amount of time as defined by the Wait Time Variable with no controller input the Camera will begin to pull out and rotate around the character. After a second set amount of time as defined by the Wait Time Variable, the Camera will jump cut at timed intervals as defined by the Cut Time Variable to certain macro and micro scenes in proximity to the player. These scenes will be predefined with Cameras set up (as a means to give the player direction, similar to the sword light in Shadow of the Colossus).
 
Collision Detected: When the camera collides with an object, the camera should move towards the player to avoid going behind or through the collided object.

Original Text Below:

We are currently looking at redeveloping our game’s character controller for the fifth time. At this point, our other side projects are becoming fruitful enough that we have extra capital and it seems that it might be wiser to hire a programmer to do our character controller instead of us continuing to bang our heads. Before posting on hiring boards however, we wanted to get some answers so we don’t approach the boards completely naive.
 
Scope of work: a variable character controller in Unity3d 5.6 with C# that will be able to walk, run, jump (double), climb, push, swim (surface only), and crawl. The tricky part is that our game is on the interior of a sphere, so the controller needs to work with a variable vertical axis (see the devlog to get a better understanding). We will provide a character with all the animations set up, the sphere, and test obstacles in a unity project with the folder structure established. Our latest controller used the Open Source Super Character Controller.
 
Here are a few questions we have, (mostly relating to the contract):
 
What range of fee can we expect to pay?
Is it typical to do hourly or fixed fee?
How does the payment schedule typically work?
What sort of timeline should we expect for a character controller?
Are there typical playtest milestones for this type of contract work that we should request?
Should we specify engineering standards?
What else should we be specifying in the contract?

[Schrompf]

We are currently looking at redeveloping our game’s character controller for the fifth time. At this point, our other side projects are becoming fruitful enough that we have extra capital and it seems that it might be wiser to hire a programmer to do our character controller instead of us continuing to bang our heads. Before posting on hiring boards however, we wanted to get some answers so we don’t approach the boards completely naive.
 
Scope of work: a variable character controller in Unity3d 5.6 with C# that will be able to walk, run, jump (double), climb, push, swim (surface only), and crawl. The tricky part is that our game is on the interior of a sphere, so the controller needs to work with a variable vertical axis (see the devlog to get a better understanding). We will provide a character with all the animations set up, the sphere, and test obstacles in a unity project with the folder structure established. Our latest controller used the Open Source Super Character Controller.

If I would have to do this job, I'd inquire as how to climbing is supposed to work. AssassinsCreed-style climbing took ~5 people and several years, while a simple "climb a designer-specified ledge with a precanned anim" is maybe an hour of work.
Also: how is the area between "dry feet" and "swimming" supposed to work?

Here are a few questions we have, (mostly relating to the contract):
 
What range of fee can we expect to pay?

I usually take 60€/h, but that's embedded work. In game-related jobs you usually get way less, like ~40€/h. Which is the lowest mark at which I take the job, lower simply doesn't cover all the expenses and risks anymore.

If you aim for India or similar, you'd probably get away with ~5€/h.

Is it typical to do hourly or fixed fee?

For a well-defined job, a fixed fee is more common. The contractor will use the above calculation internally, though, based on an estimate of how long it will take. And to be honest: I've never met a client before who was actually able to define the task well enough. Hourly billing is more fair, at least in my personal view, because it accounts for all those "Oh no, that's NOT what I wanted" moments.

How does the payment schedule typically work?

Contract, possible upfront payment, work, possible milestone and corresponding payment, final approval, final payment, possible maintenance at a hopefully well-defined amount.

What sort of timeline should we expect for a character controller?

Depends on the movement, but I'd say: maybe 10 to 20h to get it all work cleanly, given a working physics engine. Which I assume is the Unity built-in physics, so you should be fine there.

Are there typical playtest milestones for this type of contract work that we should request?

Difficult to say, but from the top of my head:
1) Basic movement and stopping/gliding at collisions, push probably comes automatically along with that.
2) Crouch, Jump, Double-Jump
3) Climb? See issues above.
4) Swim.

Should we specify engineering standards?

Feel free, but only if you're prepared to PAY for all the overhead you cause by this. Seriously, this is Unity. It's hacky by design.

What else should we be specifying in the contract?

Don't overdo it. The only thing you can do with a contract is to sue the gal/guy afterwards. If you're not prepared to sue, the contract is only a state of intentions. So treat it like this: a paper describing the intentions you and your partner have in common. If you can't trust the contractor, you're lost anyways. So don't bother writing an elaborated contract, use the time to talk to that girl or guy and make sure you both have a firm grip on what needs to be done.

[archgame]

@Schrompf Thanks for all the advice, really helped answer some questions we had. Our idea for the contract was more to make sure the payment was worked out and to give as detailed of our intentions as possible (hate the idea of legal-action, more to make sure we have all the information we need). We put together a new scope below, which was helpful in itself for defining how we wanted the character controller to work in the game. Maybe we are still missing some specifications, are there any obvious questions we haven’t answered?
 
Introduction:
The character controller will be used on multiple playable characters and will therefore need to have variables exposed publicly for easy adjustment in the unity editor as well as booleans for each function to determine if the player has the ability to do them. A controller input script will be provided, from which all input should be derived. Additionally a Mecanim tree will be established with animations input (although this is subject to change with programmer input). It should be assumed that whenever “up” is used in the function descriptions, it is referring to a direction vector related to the character's base and center of the sphere. For further clarifications on the desired move functions the programmer may reference Wind Waker for all functions except the Jump function which they should reference Super Mario 64 for the initial Jump and Super Smash Brothers for multiple Jumps. Using the Super Character Controller, the character controller will need to perform with the following functions:
 
1. Idle:
Character is grounded and after a certain amount of time will begin to cycle through three idle states.
 
2. Walking:
A joystick push of any value less than a full push (i.e. 1.0) will move the player forwards at a rate determined by the walk variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.
 
3. Running:
A full joystick push (i.e. 1.0) will move the player forwards at a rate determined by the Run Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.
 
4. Jumping:
When the Jump Button is pressed, the character should move in the up direction by an amount determined by the Jump Variable. While Jumping, the players forward direction should be locked and any forward movement should be added to the Jump direction. There will also be included a Number Of Jumps Variable which will determine how many sequential Jump functions a character may perform without returning to a grounded state. If the Jump Button is pressed while Jumping and the maximum number of Jumps as defined by the Number Of Jumps Variable has not been reached the character should move in the up direction by an amount determined by the Jump Variable. When the character reaches the height as determined by the Jump Variable, the character should switch to a Falling state.
 
5. Falling:
When a character is not grounded (as determined by the characters distance to a surface with the appropriate grounded classification), the character should enter the Falling function, unless in the Jumping or Climbing function. While in a Falling state, the character should be moving opposite of the up direction with the addition of any forward movement at a rate determined by a global Gravity Force Variable. When the character collides with a surface containing grounded information, a landing animation should play and the character returns to a grounded state. If the character has any forward movement, the character should immediately transition to either a Walk or Run state depending upon the Joystick variable, and if there is no forward movement, the character should transition to an idle state.
 
6. Climbing:
When the character is within a globally defined range to a surface deemed climbable by tag and the Climb Button is pressed, the character will enter into the Climbing state. The Climbing state is entered into with a Mounting Animation. While in the Climbing state and the Joystick is pressed in an up direction the character should move in the up direction parallel to the mounted surface (not the center of the sphere). If the Joystick is pressed down the character should move in the opposite direction of the up direction parallel to the mounted surface. If the joystick is pressed to the left or to the right, the character should move to the left or right of the mounted surface. The character will exit the Climbing state when the become grounded, reach the top of the mounted surface, reach either side of the mounted surface, or reach the bottom of the mounted surface. All dismounts except for the top surface dismount will play the standard Dismount animation when entered into. The top surface dismount will play the Climb over animation and the character shall be moved in a negative perpendicular direction of the mounted surface into a grounded state.
 
7. Swimming:
When the player enters a surface deemed swimmable and the difference between the ground surface and swim surface is larger than three/fourths the character’s height as determined by the Height Variable the character shall enter the Swimming state. The swimming state is entered into with a Swim Enter animation. While in the Swimming state a joystick push will move the player forwards at a rate determined by the Swim Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame and its position on the swimmable surface, the animation will be adjusted to make it look as if the character is below the surface.
 
8. Floating:
When the player enters the Falling state and the Jump Button is held down the player will enter the Floating state. While in the Floating state a joystick push will move the player forwards at a rate determined by the Swim Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame and its up position as determined by the distance from the player to the sphere when the Floating state was entered into.
 
9. Driving:
While in the Driving state a joystick push will move the player forwards at a rate determined by the Drive Variable at an acceleration determined by the Acceleration Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame. While in the Driving state, joystick presses outside a defined range will have no effect on the characters movement (i.e. the character will not be able to immediately rotate in 180 degrees, but will be forced to turn at a rate similar to a wheeled vehicle).
 
10. Pushing/Pulling:
When the character is in a defined proximity to an object that is pushable and the Push Button is pressed the character will enter the Pushing state. While in the Pushing state the character will reorient so that the characters forward direction is perpendicular to the nearest surface of the object. While in the Pushing state if the Joystick is pressed up the character and object move in a forward direction as defined by the perpendicular orientation direction. While in the Pushing state if the Joystick is pressed down the character and object move in a backward direction as defined by the negative perpendicular orientation direction. While in the Pushing state if the Push Button is pressed, the character exits the Pushing state.
 
11. Sitting:
After a determined amount of time the character will enter into the Sitting state. The Sitting state is entered into by the Sitting Enter animation, which transitions into the Sitting animation, which is a random series of three animations. When any Button or Joystick is pressed by the player, the character exits the Sitting state with the Sitting Exit animation. The Sitting state is also determined by the proximity of a sit-able surface or ground, which will determine which animations and where the character is located.
 
12. Interact:
While in the Idle state and the Interact Button is pressed the character enters into the Interact State. While in the Interact state the character plays an animation determined by the nearest interactable object. For example if the nearest object is an NPC, the character will play a Talking animation. For example if the nearest object is a collectable, the character will enter into a Pick-Up animation. If the Interact animation has an exit time, this will determine at what time the character will exit the Interact state. If there is no exit time for the Interact Animation, pressing the Interact Button again will exit the Interact state.

[Schrompf]

Iiek. I talked me into this, did I?

It's a good thing you wrote this. My thoughts:

a) Where's all that "animation" stuff coming from suddenly? I thought this was about a Character Controller, which is about the movement of a capsule solely.

If you intend to keep animations in the contract, adjust your time and cost expectations accordingly.

b) Running only when stick is at 100% elongation won't work. Each and every controller has slight deviations, even when perfectly calibrated right before starting your game. Use a threshold, like 90%, or even better: make it configurable.

c) ... sorry, haven't read it all. Maybe someone else chimes in.

[Reyn]

2. Walking:
A joystick push of any value less than a full push (i.e. 1.0) will move the player forwards at a rate determined by the walk variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.

If I'm getting this right, this is how Dark Souls does it right?

4. Jumping:
When the Jump Button is pressed, the character should move in the up direction by an amount determined by the Jump Variable. While Jumping, the players forward direction should be locked and any forward movement should be added to the Jump direction.

Im assuming you're talking about committing to a jump, like the Castlevania jump where you cant change your direction once you're in the air?
Getting multiple jumps is fairly straightforward but getting exact Mario-like jumps is not.
 

6. Climbing:

Youre talking about Shadow of the Colossus or Breadth of the Wild climbing right? Not ledge climbing like Overgrowth. This one I dont know, it could be straightforward to implement even if "up" is different from surface to surface, but it will get problematic if there is uneven surfaces because animations wont fit and you'll have to use inverse kinematics for that (this is what SotC and BotW use). Also I've read the climb over animation is a bitch to implement, you can see even BotW just makes you jump over the ledges.

12. Interact:
While in the Idle state and the Interact Button is pressed the character enters into the Interact State. While in the Interact state the character plays an animation determined by the nearest interactable object. For example if the nearest object is an NPC, the character will play a Talking animation. For example if the nearest object is a collectable, the character will enter into a Pick-Up animation. If the Interact animation has an exit time, this will determine at what time the character will exit the Interact state. If there is no exit time for the Interact Animation, pressing the Interact Button again will exit the Interact state.[/i]

Interact might be extra complicated if interact zones can overlap each other (also pushing objects should use the same intractable logic), Dark Souls solves this by letting you toggle selection with Y, which entails having a list of interactable objects in range and looping trough them.
Other than that, stuff like the pick up animation might also be complicated; how to guide the character hands to said collectible? this is why most games just have you walk trough collectibles to collect them.

Driving and Swimming are also relatively easy to nail down once walking is implemented, but getting all of them to "feel" right takes time and iteration.

a) Where's all that "animation" stuff coming from suddenly? I thought this was about a Character Controller, which is about the movement of a capsule solely.

First post says all animations will be provided.

b) Running only when stick is at 100% elongation won't work. Each and every controller has slight deviations, even when perfectly calibrated right before starting your game. Use a threshold, like 90%, or even better: make it configurable.

True, most of this is kind of a solved problem for games, but Unity has its own quirks. Making settings like the deadzone and the running threshold configurable is always the best choice. I play a lot of For Honor and now that they introduced guard deadzone settings in the last patch it makes a huge difference.

To summarize: I'm interested in this, I'm just a Systems Engineering student in his last year, but I been working with Unity for a couple years, mostly just as a hobby, and mostly in 2D, and I have this summer relatively free. I know my way around vectors and I even have a little prototype in 2D that is the inverse of your inverted sphere problem; an archer vs archer game where you walk and jump around planets each one with their own gravity and effect area, and I can tell you that making Unity's built-in physics work friendly with that is a pain in the butt, yet absolutely doable.

[archgame]

With the text of the scope increasing in length I decided instead of posting it in every post I would just post it at the top, with changes high-lighted in red, hopefully it makes for cleaner reading.

The biggest thing we added (in part because writing out the character scope proved helpful) is the camera scope, which we figured we might as well get a quote for while we are looking for character controller programmers.

@Schrompf; Thanks for taking a look, I tried to make it more clear that animations are already provided and the model is rigged, ideally the person is only programming, maybe adding tags or layers to the scene, but ideally only working with script. I also clarified that the input script will take care of all the controller calibration, so it may be assumed that the numbers coming from the script are good to go!

@Reyn Thanks for being so thorough. I know exact Mario like jumps are difficult and this is more of a technical question, but how have people successfully mimicked these types of things in the past? I'm thinking of fan re-makes. Also as for the climbing, it will only be planar surfaces, nothing tricky and yes the hope over does seem difficult, a BotW solution will probably work. As for the interaction, you were right and I amended the Interact to use the Camera's targeting system to get a list of proximate objects (also it's negation should indicate there won't be any inverse kinematics for the pick-up animation and similar ones.

The Scope text seems to be coming along, we'll probably be posting it to job boards at the end of the month, we were going to hit up Unity Forums, the LA Unity Group (we are based in LA and it could be beneficial if the programmer is in SoCal as well), as well as Tig Forums obviously, but are there any other suggestions of where we should post the job?

Lastly, the input has been great so if there is anything further, we'd love to hear it (especially concerning the camera since this is a first draft). Also I know I initially opened this thread under the business section (seeing as the whole point is hiring a programmer), should I double post in the technical forums too?