"Cozy Game" Dev Log: Prototyping gather mechanics
I'm finally getting into the actual mechanics of the game! I always like to take the approach of building from the "bottom" up - which means, in this case, the first order of business is building all the "go out and gather raw materials" mechanics. These are usually the simplest, but ironically, as a result, they take the most thought to put together. (Unless you want one of your core mechanics to just be "go out and click on a bunch of things until you run out of inventory space", in which case it doesn't take any thought at all.)
For me, though, I have a small, but unbreakable, set of design rules I put down for gathering mechanics back when I first wrote up my initial design docs. The mechanics I make can thus be absolutely anything... as long as they follow every single one of these rules:
- It must behave like a webpage, not a webapp.
- It must be distinct from all other gathering mechanics.
- Do not trust the client.
Let's get into what each of those means!
Webpage vs. Webapp
First, I want to define what a web-app is.
A web-app is essentially an entire program that runs in your browser. All of the bits and pieces that Do Things ™️ are loaded up into your browser and run on your computer. Things get sent to the server pretty much just as "save points" for the app, or if the app has a mechanism that actively sends stuff remotely (like posting a message to social media).
A web-page, on the other hand, is a largely static thing. Your browser is sent the data to show, and it shows the data. If you want to do a different thing, you click to a different page. If you reload a page, it will show you basically the same thing it did before.
Now, to be fair, this is a dramatic oversimplification of both concepts. You can have dynamic web-pages that aren't full-on web apps - that is, in fact, exactly what I'm doing. But the key differences could be boiled down to something like this:
- The contents of a web-page is defined by the server, while the contents of a web-app is defined by the client. (This one will be especially relevant later)
- A web-page is single-function, while a web-app is multi-function.
Distinct Mechanics
You might think this would be the hardest one... and you'd be right. The basic approach for making different mechanics like gathering or crafting distinctly different from each other is, essentially, to build a mini-game for each one. You - okay, I - want each mechanic to potentially be fun to play in its own right, while also being different enough from the other mechanics as to provide a "buffet" of gameplay that will allow lots of people who enjoy lots of different types of gameplay to all feel like they can engage with and enjoy the game equally well.
Here's the catch. Each "mini-game" has to follow the first rule. It must be a webpage, not an app. The whole minigame has to be played using basic webpage interactions: clicking links/buttons. The whole minigame has to be single-function. And, that single function can't be the same function as any other minigame.
This already narrows things down quite a lot! Chances are you have to wrack your brain just to think of even one thing that would apply. But we've still got one more rule...
Don't trust the client
This is a pretty fundamental concept of online game design, but it is even more important when your online game is done via a web browser.
If you're making a more "normal" game, you have basically your game as a custom client. It probably connects to your server using a custom protocol, with custom data packets, a custom authentication system, etc. The bulk of the logic is going to happen in the client, so your server's job is to persist the game state and to validate the updates received from the client.
Is this kind of a system hackable? Of course. That's why every single MMO in existence has hackers and botters. But it takes a decent amount of technical knowledge to pull off.
Now, let's take a look at a webpage. A website. A web-app. Let's say you're playing a match-3 minigame that's built to run in your browser, as web-apps do, and it maintains a high score leaderboard.
The data transferred between the client and the server is totally normal HTTP traffic. The minigame runs using totally normal JavaScript. There are literally thousands of resources for learning JavaScript and how to send POST etc. requests. If the game is calculating your results client-side and then sending them to the server, it is super f---ing trivial to just tell the server "hey yeah so here's my score" with whatever number you want.
This means that in any sort of a website game where cheating actually matters, the only way to avoid it is to do all of the result and mechanics calculations on the server itself.
Luckily, this intersects perfectly with the first bullet point!
If everything is determined on the server, then that means the server knows at any given moment what information should be on the page. And thus, if you reload the page, it will be at exactly the same point in your minigame.
If everything is calculated on the server, then that means the client only needs to send the specific actions themselves, not the results. In other words, your game interactions can be boiled down to "click something and it does something".
All Together Now!
I'll be honest, that all gives me some pretty tight restrictions to work within. Fortunately for me, my biggest problem is decision freeze/analysis paralysis - in other words, I work best within tight restrictions!
So! My current definitely-decided gathering mechanics are foraging and mining. I also want to do something like... woodscraft, or forestry, something for sourcing lumber since that's a fundamental material type, but I haven't figured out a way to make the obtainable materials more interesting than just "here's a new type of wood, just like the old type of wood but different, see it has a different name and it's a different color" quite yet. I've got some loose ideas but nothing's come together.
...Right! So I have foraging and mining. I spend a while thinking about various games I've enjoyed, how they do foraging or mining types of mechanics, and whether or not they could adapt to my requirements.
For foraging, I got an idea from a kid's "spot the differences" picture game, combined with having been playing Potion Craft more recently. When you spend an Action on foraging, it rolls your "loot" and then generates a picture using area-specific environment images and inserting clickable images for the things you "found". It'll tell you once you've found everything, or you can click "Collect" early as long as you've found at least one thing. I figure your underlying Foraging skill will affect the pool of possible forageables that can be selected in the initial roll. And if you write yourself a script to automatically find and "click" all the images for you... well, sounds boring but it won't break the game balance.
For mining, on the other hand, I was inspired by the long-abandoned mining mechanic in FF14. No, not FF14:ARR, the original FF14. The FF14 that met with such horrendous player feedback that they yanked it and remade the whole game from scratch. Kuzco's poison.
I can't find the wiki that has a run-down of how it worked, but it was an overcomplicated combination of the bouncy line mechanic (it was a circle that expanded and contracted), hot/cold style feedback on each "hit", and to top it off you had a limited number of strikes before the node was no longer usable.
I loved the heck out of it. But you can't deny that it kind of sucked.
Of course, this being my favorite mining mechanic ever, it made an obvious starting point. So I had to sit down and ask myself, why did I love it and why did it suck? Turns out those were easy questions to answer. I loved the timing aspect and the hot/cold mechanic. And it sucked because you only got three tries.
A timing mechanic is completely antithetical to the whole page-state design requirement, so that left me with a hot-cold mechanic.
ET VOILA. The completed prototype for mining!
The up/down buttons don't actually do anything yet as I prototyped it out using a single axis for the values, but it's working great! It mostly just needs a bit of polish and a pile of content, now.
For integrating skill levels, I'm thinking that your mining skill affects not only the available pool of resources, but also how "close" you start off. E.g. having a high mining level and rolling a low-level material will start you out pretty much right next to the strike point. Which would be really easy to implement, because it means that you basically just have a starting distance check and cut off all potential materials that would start out further away than the defined max distance.
Next up is prototyping foraging... which is going to be a little tougher, since I'll need to actually make some dev assets for it instead of just slapping some raw DIVs into my templates. Can't work out the implementation for layering clickable images into non-clickable images if you don't have any images.