903 views

# Hello Villagers!

There’s no way to actually prove this, but I’m pretty sure more people have played fishing mini-games than have actually gone fishing.

You can fish in Zelda, in Nier, in Red Dead Redemption 2, in Pokemon, in Deadly Premonition, in Torchlight, in Yakuza. You can hardly walk into a Gamestop without tripping over a pile of rods and tackle boxes.

And of course fishing is especially prominent in life sim games like Animal Crossing, Harvest Moon, and Stardew Valley. Village Monsters is no different – fishing was one of the first hobbies I added to the game.

There’s a lot to draw inspiration from, and if it seems the tone of this post is overly negative it isn’t because I don’t like fishing mini-games… it’s because of how intimidating they are! With so many different standards and expectations there are almost too many options, and this left me feeling paralyzed when designing the system for my game.

The good news is I’ve finally settled on a system, and I’m super excited to talk about it.

But first let’s talk about how bad of a designer I am.

# Failed Prototypes

I prototype every feature – often before I even analyze or document it – and fishing was no different. In a lot of ways prototypes are ‘meant’ to fail (seeing what doesn’t work is more valuable sometimes than seeing what does), but my fishing prototypes took the word ‘failure’ to a whole new level.

My very first prototype was similar to what you find in Breath of Fire. You’d be presented with a side view of the body of water you’re fishing in and your goal was to guide your hook to a fish and reel it back to shore.

1st Prototype, 2017

It was… fine. It was certainly unique compared to my contemporaries, but the more I played with it the more I realized this wasn’t necessarily a good thing. It was equal parts clunky and boring, and I scrapped it shortly before the Kickstarter.

The prototypes that followed were all over the place. I experimented with “fish HP” and “rod HP”, I put in timed button challenges, I tried out things like line strength and fish stamina and generated all sorts of random numbers.

Another fishing prototype

I wanted to capture the full cycle of fishing – the relaxation of waiting, the excitement of hooking, the struggle of reeling in a big one – but nothing I tried was working. You might even say I was floundering… heh… heh… ugh.

Then one day inspiration struck. Perhaps it was Poseidon himself that whispered in my ear, or perhaps it was that 4th Monster energy I just drank. Whatever the case was, the outline of fishing should look like revealed itself before me anchored by three words…

# Dash, Mash & Clash

Fishing in Village Monsters can be broken up into three distinct phases which I lovingly call Dash, Mash, and Clash.

After casting your line in a body of water the music dims and you can let your mind wander as the outside world fades into the periphery – that is, until a fish bites. That’s the Dash, referring to how you must quickly hook the fish before it gets away.

After hooking the fish it’s time to Mash, which is exactly what it sounds like. Your job is to reel in the fish as fast as possible. There’s no subtlety required, so mash that reel button as hard as you can. A little fishing meter tracks your progress.

Of course, most fish won’t be too pleased about the hook in their mouth and they’ll often try to fight back. This leads to our next stage, Clash, which finds you being challenged with a series of button prompts as the fish attempts to get away.

If you miss a prompt then you’ll start losing the progress you made reeling the fish in. Miss too many and the slippery fish will make their escape..

However! If you manage to get a “Perfect” during this stage then the fish’s defenses are shattered which makes it much easier to reel in. This gives the clash stage a high risk / high reward component and acts as a test of skill compared to the previous test of stamina.

These two stages cycle back and forth until the fish is caught or gets away. How often they cycle and for how long depends on the fish. Easier or smaller fish need less reeling in while legendary fish require several clashes before they submit.

And there you have it! Fishing is finalized in forthcoming folly, Fillage Fonsters.

# What’s Next?

Finalizing any gameplay mechanic is sorta like writing the 1st draft of a story – it’s a great feeling of accomplishment, but there’s lot of editing and polish to do.

Now that I have all these levers and nobs to play with it’s time to give each fish a “personality” – heavy fish that are hard to reel in, fish with extremely quick ‘hook windows’, and so on.

There’s also an entire range of possibilities for upgrades: lures that attract fish faster or rods that make reeling in easier. Then I can start looping back into other parts of the game, like a potion that slows down the clash stage, or a mushroom that attracts rare fish when used as bait.

You’ll be able to play with the new fishing system yourself once the latest Village Monsters demo hits later this month.

There are no comments to display.

## Create an account

Register a new account

• ### Similar Content

• Hi all!
We are looking for people to help make a simple TPS shooter game - the goal of the project is to create a hobby team that would eventually be able to learn, tackle bigger projects and make some cool games.
We have a GDD that still needs some work and we are clarifying it as we speak:

Currently we are looking for:
Concept Artists
2D Texture Artists
3D Modellers
C# Programmers
Level Designers
Sound/FX

• Project Name: Rift One
Role Required**: (Language - C#)
- Dedicated Unity Programmers
Previous Projects: N/A
Team Size: 6
Project Length: n/a
Compensation: Rev-share until we get funding.
Responsibilities:
- Must know Unity.
- Must Know How Gitlab & Sourcetree work
- Friendly and chilled
Project Description: An Sci-Fi FPS based in a alien world, where you, mark maxin are forced to enter a portal that transports you to another world.
**Contact**: please Email us at data7games@gmail.com

• For this Screenshot Saturday we're showing the different tabs in the Cargo Bay where you can find all Minerals, Gems, Gases, Artefacts and Fossils you have in your inventory.

• Mystery Me

Play now! For Free. This game is made by one person with only 1 year of self taught experience. Normally the game needed 2+ years of work to finish!! However I spent 8 months on the game and made something to see your thoughts on my try for something different in terms of how you progress in game and evolve based on your feedback.I don't get any money for that and it would be a pleasure that at the end of the day the game takes a lot of feedback so I will know where to improve and happily continue doing what I love.
Itchio:https://geo-games.itch.io/mystery-me
Discord Server : https://discord.gg/yQ6Duwg
Website : https://www.geogames.gr/
Release Trailer:

• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?