Dungeon Fishing : Mobile Fishing Game
Members: 1
Duration: Ongoing
Date: 2021 - Present
Note: As of now, the game is still under development. More will be posted as more features get added.
Brief
Dungeon Fishing is a fishing game set in a dungeon developed for mobile. As an avid adventurer, you wish to explore the perilous depths of the dungeon just like any keen adventurer would. Do you seek fortune? Do you seek status? No. You seek something greater. Your calling as a fisherman demands you to travel floor by floor and seek all the fish you can.
​
Systems
Fishing Line (Verlet Integration)
I wanted the game to have some charm by adding small noticeable details. One of these details was the fishing line. Since you’re always going to be looking at the fishing rod, I thought restricting the fishing line would dull the fishing experience. So, I thought why not add some physics in the game to spice it up?
The first problem to figure out was how. How am I going to make a fishing line behave like a rope? After spending a bit of time researching online, I came across the term, Verlet integration. The mathematical method is used to determine the trajectory of a projectile that is influenced by an external force. This would be perfect for some rope physics. With the help of a video, I was able to get a physics-based rope working.
Since this was going to be used for a fishing line, I created a class and named it, FishingRope. Inside the class, I have defined a struct called, RopeSegment, which holds a vector3 pos and vector3 oldPos. These will be used to update the rope’s movement.
Next, I have defined an array of RopeSegment and called it, ropeSegments. These are the series of points we’ll keep track of in order to replicate a rope-like behaviour. In the Start function, I have assigned a new RopeSegment into the array going downwards.
As a result, it would look something like this:
Great, we have a line, except we can’t see it. Let’s add a function so it does draw a line.
Every update, I call the DrawRope function. What I’m basically doing in this function is updating the lineRender’s positions according to the positions of each RopeSegment. To explain further, I have defined a vector3 array called ropePositions. Then, I’m iterating through each RopeSegment in ropeSegments[] and assigning each of its position in ropePositions. Once I have done all of that, I then tell the lineRenderer to set its positions.
​
​
Looking much better now, the next step is to implement a rope-like behaviour. To do this, I have a function called, Simulate().
This part of the function calculates the segment’s velocity based on its current position and old position. I also want gravity to influence the segments’ movement, so I’ve added forceGravity to its position.
​
The second part of the function involves the constraint aspect of the rope. I call the function, ApplyConstraint(), which restrict pairs of RopeSegments to maintain the behaviour of the rope. I call this function at least 50 times within FixedUpdate(). The more often the function is called, the more accurate the result becomes. Therefore, I stuck with 50 to ensure my results were accurate enough.
I use the changeAmount to correct both of the segments’ positions.
With all of the calculations done, we have a working rope. In addition, I’ve attached the first segment at the end of the fishing rod, and the last segment at the bait. As a result, we have a complete fishing rod ready to go.
To further improve the fishing line, I plan to add a collider on the rope. As of now, the fishing line phases through the ground, which subsequently breaks the immersion. Therefore, that step has been placed on the to-do list.
Throwing Bait
The next system I would like to discuss is the throwing mechanic for the bait. It’s a fairly small feature, but I would like to break it down in hopes to further improve it.
The player throws the bait by swiping on the screen. So, when the player swipes their screen, I calculate the swipe distance and direction, and call SwipeDetection(). In this function, I dot product Vector2.up and the direction, and compare this against the directionThreshold.
To explain this line further, here is an example:
Let’s say the directionThreshold is 0.2. If I swipe up in an angle, and that angle was along where 0.8 was. Then, I can proceed through the function, since 0.8 is greater than 0.2. If I swiped at a steeper angle like 0.1, then it wouldn’t consider it and return false. To summarise, directionThreshold can be thought of as a tolerance factor on the player’s swipe direction.
Further into the function, I call another function that calculates the distance the bait should travel. Before I show off some code, I would like to show a drawing to encapsulate the idea.
Here, I’m trying to determine the throwForce, while also ensuring it travels along the z axis. maxForwardDistance is the maximum distance the bait can travel. This is set in the inspector for debugging purposes. The totalPercentage is calculated by two factors from the player’s swipe, the swipe distance and the swipe time. I want the distance travelled by the bait to be determined by those two factors.
-
Maximum distance travelled = maximum swipe distance and minimum swipe time
-
Medium distance travelled = minimum swipe distance and minimum swipe time or maximum swipe distance and maximum swipe time
-
Minimum distance travelled = minimum swipe distance and maximum swipe time
The total percentage between the two is determined by:
Where swipeDistancePercent is the percentage of the maximum swipe distance and swipeTimePercent is the percentage of the minimum swipe time.
That’s the basis of calculating the throwForce. I do plan to come back and improve this section, since the solution doesn’t seem elegant to me.
With the distance calculated, the next function I called is ThrowBait(). This function adds a force to the bait according to the calculates throwForce and the direction:
I was skeptical of using AddForce for this particular part, since I have always found rigidbodies to be unpredictable. I originally used a Vector3.Slerp function and made the bait travel in an arc every throw. However, while testing this, one striking factor I found was it generally wasn’t satisfying to throw. The entire throw was restrictive and felt it was under consistent control. As a result, I went with the AddForce method. It’s true rigidbodies are hard to predict, but they are very pleasing to see in action. The result itself will be amusing, which is what I wanted for my game. I want a bit of wackiness in there.