Grapple Gliders - Sprint 1

    For the first sprint, I tasked myself with starting up the super basics of the digital prototype: ground movement, jumping, and gliding. At kickoff, I wasn’t really sure what the level design would look like, so I decided to take care of the early programming. I did not do the grappling mechanic in this sprint because I wasn’t sure how the lead wanted it, so it was decided that he would do it in the next sprint. I also added the extra task of making the grapple target trigger, since it’s less work for the lead to program when trying to do the grappling mechanic.

Luckily, since 280 went over the new Unity Input System and an easy way to do movement, I was able to get that task finished pretty quickly. Although, at first, I didn’t realize that the player character wasn’t technically always moving “forward” since the camera angle didn’t change. Thankfully, that was a simple change.

Jumping was also easy as well since that was also covered in 280. For now, I left it so that the character can jump infinitely so I was able to test colliding with other things in the scene.

Doing the gliding mechanic turned out to be a lot harder than I expected it to be. At first I thought it was pretty simple, but nothing I did seemed to get my player character to do any kind of gliding motion. It would just fall like normal. I googled “gliding mechanic in unity” a ton of times and most of them were pretty complicated things that I didn’t understand or it used something that I couldn’t use. Funny thing is that I spent an entire afternoon trying to figure it out, but the thing that actually gave me something resembling a gliding move was a simple transform.Translate function. Of course, that’s probably not going to be used later, but it works for the preliminary basic movement.

I used a coroutine to do the gliding action, but I had a problem where it wouldn’t stop unless I used StopAllCoroutines();. I’m not sure why that happens.

While I was doing the gliding, one thing I realized was that we really should’ve considered working on the camera in this sprint because it really hindered my progress in programming the glider mechanic. I was talking to a friend (who knows coding much better than I do) about how to do this and she mentioned that I’d probably need to add in an input for tilting the character or at least changing the way that the character is pointing. So for now, getting the camera to rotate is my task at the moment. 

Other than how difficult doing the gliding mechanic was, I had a problem with the player character in that if I didn’t freeze its rotation, it’d just fall backwards for some reason. I’m still not sure why this happens, and I know we’ll need to figure out how to make it not do that if we want to utilize a more advanced gliding mechanic. While I was trying to program a simple camera rotation (click left/right arrow keys to rotate that direction respectively), I kept running into the problem of it just not happening at all. The debug log showed me that it always kept staying in the “performed” state and wouldn’t move to “canceled” unless I clicked out of the game window. Even though I asked my friend for help, I still wasn’t able to figure it out.

Overall, I think for this first sprint, I was able to do my tasks and not stress out over finishing it, which is honestly a bit of a first for me. That makes me kind of proud. I mainly just hope that I can keep it up for the rest of the semester.

Comments

Post a Comment

Popular posts from this blog

Aftershock Simulator - Sprint 16

Image
  On sprint 16 in Aftershock Simulator, I assigned the team 87 points and 51 points were finished. We’re beginning to pick up now that we have a plan on what to do. In this sprint, our team started on the tutorial levels and the objectives system. And of course, there was some extra work to do for the UI in the game as well.   As a producer, I still find it difficult to gauge the difficulty of a task, especially when it comes to programming. I still end up needing to change the point values of some cards because they end up more difficult than expected. For example, I had figured that creating the basis for the objectives system wouldn’t have been too difficult, but not necessarily. A few of the objectives require you to click certain UI elements on the screen, and the things that would “listen” to those UI elements are all each in their own separate scripts, so now there’s the added work of finding them and knowing where to put the code. I always end up asking people if t...
Read more

2D MegaMan Level 2 Feedback (10/27/21)

     Making a late-game type level is incredibly difficult. I had my idea of making the player climb up, but I wasn’t really able to implement that. I couldn’t really think of a layout for a room that wasn’t having the player zigzag up the room. Although, according to my playtesters, what was in the level was pretty good. At least I was able to avoid the “no clear way to the exit” problem I had with my tutorial level. It was a simple “gather the keys to unlock the exit” type level, and unlike my tutorial level, there was actually a point to it.      Players generally praised the way I set up my keys, as you need two keys to unlock the exit, but there are 3 in total. You can get the first key through an easy or hard route, and then you have to get the second key by passing through some enemies. When getting the second key, I put in a weapon deleter that takes out the Nado so you have to jump through a bunch of enemies to get to the top of the room. There’s a...
Read more

Chicken Scramble - Sprint 1

Image
  To start off, this first sprint was kind of disorderly. Since we’re using a completely new project management tool with no prior experience, it took some time to get used to (and still getting used to it). I suppose for my other teammates it wasn’t a big deal but it was an added pound of stress to my shoulders as the producer. To add to that, there was some confusion between me and the designer as to what the whole game idea and aesthetic was. My original idea for the game was a multiplayer maze in which the goal was for two players to compete to get to the other side of the maze. We could have ways for the players to mess around with each other, like using door switches to open and close doors. To clear up the confusion on what we were building, we set up a meeting to talk about it. To prepare, I made a design map of what I thought it should look like. (In the picture, the blue dots are door switches, yellow dots are checkpoints, and the red dot is where the enemy spawns. Bl...
Read more