Correcting RTSCameraController

Project: Armament
Role: Game Programmer
Completed: 119.03 Cpl Wallace Donegan Game Programmer
Start Date: 4/19/2018 20:15
End Date: 4/26/2018 17:06

The script RTSCameraController needs to be corrected.  The functions that allow the camera to pan with the mouse have been commented out and arent functional.   Also the script references axis's that do not exist on the project at this time.  "PanSpeedBoost" and "Zoom" are referenced but arent to be found.  

We need to make corrections to this script in order to get it functioning as intended.  While you are making corrections there are functions you need to implement as well. 

  • a,s,d,w to move the camera
  • mouse to edge the screen to move the camera
  • the scroll wheel to zoom in and out
  • q and e to rotate the camera
Correcting RTSCameraController

No Public Asset Available

Complete Task
3.00 HR.
The task is finished and uploaded. FULLY functional on my machine at the time of upload. Created an entirely new scene and agenda folder for this as none of the work I have done previously works at all. All the scenes and prefabs are completely broke. I recommend deleting anything of mine that is not in an agenda numbered folder. 


@Wallace Would you have time to try to look this agenda over and get it fixed for us?

@wallace  hey man looks great.  Keep up the great work!  Could you set the value range for the pan speed higher for me?  Its too slow right now when i imported it into my test scene using the large map.  Also i noticed that the camera would "climb" the mountain.  and we dont want the camera moving without the players imput.  What would be the best way to fix this?  @james?  @wallace?

Can we make these values a public property so that the designer can modify them as needed or are they set that way already?

@Jonathan Don't we want the camera to stay at the same elevation at all times so if it goes up a mountain or in a valley the camera unless zoomed in our out would say at the height?

Absolutely!  The problem is the mountain is higher than the max camera height.  so how about for now we just increase these range values allot so I can figure out the sweet spot?  What do you think? 

The max range values i should clarify.  

@All I have been at work and just barely got home to see any of these conversations.

The Main camera holds the RTSCamera script, on that component are Private Serialized Fields (not public properties, I will not use public unless absolutely necessary) these values can be modified in the editor. 

@Jono The camera climbs with the mountain because it is raycasting the terrain and maintaining a zoom height above ground. This is typical behavior in most RTS games I've played but if a change needs to be made the designers can figure that out and I will correct it. 

There should be no problems modifying any of the values, they are base values I set based on a typical scene's scale. I made the script as ... plain as simple ... as I could.  I would have commented more but I felt the names of the variables and their locations within there respected region tags were fairly clear and more comments would only have muddled the code.

EDIT: If the Range attributes in the Private Sertialzied Fields needs to be updated that is completely fine, those values are there to limit the sliders so they are manageable, ie. you move the mouse 1 px and the value changed by 1000. That would make it difficult to use. The range is set to mitigate that. If it needs to be adjusted for the project a few times that change should be seen as fine-tuning for the overall whereas adjusting the slider is for map specific tuning. Basically, when finished with the project these ranges should represent the minimum and maximum height required across the entire map set. (This info can later be used for other performance tunings when nearing the end.)

@wallace I figuired the reason the camera acted like that was because of raycasting.  I was curious and wanted to ask you and james weather or not we wanted this drastic change in elevation when scrolling up a mountain.  We could fix this in level design?  Or we could raise the max hieght of the camera?  One thing is for sure though the max speed of the pan needs to be increase at least x2 maybe x4  The reason i suggested jacking the max range up would be so i could find the sweet spot and we could adjust from there rather than adjusting and testing then having you adjust again and again?  Thoughts?

Also it was very easy to understand as well if that was your intention.  The readme gave me all the information i needed.  Could you put this information on top of the script in comments though?  I would hate to lose the info later on


Edit: As for the dramatic change in elevation, perhaps I can add a Lerp to smooth the effect, I didn't actually test it on a real piece of terrain as all the work I've have done previously is corrupt in the last build I retrieved form MCU. I started from scratch with a flat piece of terrain. 

Updated the RTSCamera script.

1. Added a dedicated Instructions region within the script for details on how to use it.

2. Broke out some logic form the main update function to better segment the different parts and functionality.

3. Added the ability to drag with the middle mouse button to rotate the camera. Additional settings for the speed of that interaction can be adjusted in the editor.

@Jono Do you want me to merge again?

yep ready to go :)

Ok its ready too go.  I also added Robert's latest code changes as well.

@wallace could you turn private properties into public properties for me?  So that way i can edit the values in unity.  We want to avoid having anyone but the programmers alter the code.  The middle mouse button features feels really nice also good job

No I cannot. I make those private variables [Serialize Fields] which means they can be edited in the editor. If they are not marked s serialized they are for internal calculations and should not be altered. What specific variable are you referring to, if it is one I forgot to serialize I will serialize it but I won't make them public. Public properties leave a bad smell in code.

Can you make it so i can alter the max range values for pan speed?  Max hight.etc I would like to be able to change those values in the unity editor

Oh I see, NO, you cannot change the max and min values in the editor and you shouldn't' be able to for good reason. IF the max and min need to be changed they need to be changed in hard in the code, the sliders are all that should be editable in the editor. If this is a problem I will remove the sliders and you can manually punch in the numbers by hand. The idea of having a slider is so you can't set some ridiculous number that is so far out of range that it breaks things. that is why you just go into the script and loosely change the maximum value for the variable your concerned with. If you don't want to change them yourself I will update the values but I will need some updated numbers on what you want the maximums to be.

EDIT: I just updated the script, increases all the maximums to what I really feel are extreme values, Hopefully, this is sufficient.

Oh i see your concern wallace thank you for explaining it to me.  Yeah we want the only person to change the code being the person who made the code.  so to prevent the back in forth could you make it so i could just punch in the values?  We will optimize it later im sure but for now I dont want any restrictions in the editor.  So please however you see fit if you could give me that control that would be awesome :D  thanks wallace

Ok, well I just increase all the values, if they are still not enough I will remove the restrictions until we have figured out what a maximum sized map is going to be so we can restrict these values to an operatable range.

On a side, no whatever map you are working with is simply huge and highly recommend it be a candidate for the largest of the maps.

Also, to note, When using Unity's physics system if things are scaled dramatically out of normal proportions it has a noticeable performance hit on the engine. A Human is roughly 2 meters tall, that is 2 unity units. An effort should be made to keep things close to actual scale in relation to one another to avoid issues with the physics. (Sorry its a side rant I know but it is important. I was under the impression that an object's scale doesn't matter in regards to physics but I was proven to be wrong in that assumption and want to avoid seeing Armament fall into that same trap.)

thank you @wallace.  I think it would be best if you removed all restriction entirely until we have everything set in stone.  Also in regards to your concern i believe everything is right now and planed to have real world proportions 

Ok, will do. And sorry for the rant, I know there is an entire conversation that can be had involving game objects, world scale, and all the things involved in that. It is of course more of a guideline than a hard rule, but good to have in the back of the mind. 

I will remove the ranges for now so you can play with it freely, but please keep in mind some of the values take very little change to have drastic game-breaking effects.

I'll update this thread when i have it uploaded

@wallace thanks man appreciate it

Ok, It's uploading now and should be done momentarily. I am stepping back from this now as this task is completed as per the agenda. Any limitations I placed on values that control the script have been removed so it can be played with and adjusted freely. Any further updates are stylistic and should be discussed amongst the designers before bringing this agenda back for polish. 

As to my process of creating the default settings, please view this screencap. 

The cubes use the same texture in order to visualize the size of scale. The smallest cube is 1 meter, the next above it is 2 meters, and the third is 4 meters. The middle cube most accurately represents the size of a human height and values were tuned to feel comfortable at that scale based on that.