Everest Expedition - Sprint 1 Review
Everest Expedition - First Sprint
I am currently working as the programmer on a game for CAGD 370 called Everest Expedition. The main idea of the game is that you use your mouse, which controls your trusty pickaxe, to scale the side of Mount Everest while using WASD to traverse through the world. Now that we have finished the first sprint of our prototyping process, I have realized how much I underestimated the difficulty of getting the Unity physics system to do what you want it to. The first thing that I did for the project was set up the GitHub, which wasn’t too difficult or anything and took me roughly 20-30 minutes to set up and get running. After this, I set up a unity project and attached it to GitHub and with this, our group was able to start working on the digital prototype.
A large portion of my time was spent trying to learn how to use joints and make colliders work, and in the end, scrapping all the time I had spent since it was not working as I had intended. The joint system was acting funky from the beginning, and even after I learned which joints did what and how to use each one, they did not react well when trying to be controlled by the mouse, and often ended up breaking or working differently than intended. Therefore, once I realized that this was not the way to go about it, I did more research on how to make an object follow the mouse on the X and Y axis, and opted to use an empty game object attached to the player to spin the pickaxe. After a few failed attempts at getting the code working, I finally got this idea to function properly, and the arm worked well as far as rotating around the player.
Working joint based on an empty game object
(child of the player with the pickaxe as a child)
When it came to the collision system, the pickaxe did not work quite as well. The rest of my time during this sprint was spent trying to get the collision system to work, and carry the player along with the pickaxe when it was swung. I tried nearly everything that I know at this time and nothing was working, which got frustrating very quickly. I tried doing research on this but it was such a niche topic for making an object move by swinging, that I could hardly find anything useful in terms of getting it to work. Because of this, I was unable to complete the card for launching the player with a force opposite of the pickaxe’s direction, and will be moving this card over into the next sprint.
![]() |
Lots of failed code attempts after the joint system was ruled out. |
Which brings us to my plan for the next sprint. I am going to spend a good portion of the time learning about collision systems and how to get our character’s pickaxe and body to react how we want it to when swinging around and climbing. I have already done part of my research by asking my professor about the basics of the unity collision system and how I could get this idea to work, but I am planning on going into office hours for a more programming-based professor, because I feel that Google searches may not be the best way for me to figure this out, and would rather have this very specific situation explained to me by someone who knows more about collisions and how to script them. After doing this, I plan on using my new knowledge to hopefully practice collisions and get a grasp on them before plugging them into our game, since they need to be near perfect so the game controls will feel precise.
Overall, I think I learned a lot from this sprint and have a lot more to learn from here on out. One of my cards was definitely a lot more difficult than I had imagined it to be, and from here on out I will be having the producer split the cards up into more reasonable lengths of time. I have a lot to learn about Unity and am hoping I can at least learn what I need before the end of our next sprint.
Comments
Post a Comment