My task for today is to scope out the remaining work for the prototype, and then work on it today and tomorrow. I am hoping I have done enough work to have the prototype done by tomorrow evening.
I am scoping out the remaining issues in the milestone I linked above. I’ve been struggling with focus this week. The best way I’ve found to stay on task is to first look ahead and list out what needs to be done. I keep it specific enough to be a singular feature without actually writing out the logic to do it myself.
Let’s start with this.
Time to bust out the calculator!
Sidenote, I found a new plugin for VSCode which is working nicely.
2021-06-20 Update: I imagined this would have been finished by now, but something strange happened last year.
There’s been one item on issue #10 that has been holding the whole card back.
Of course, we did take a left turn yesterday. And the unique mechanic that came out that investigation was worthy of the time spent. It’s time to get back to the real work.
Issue #10 is critical to getting the game working correctly. I know this because I’ve taken the time to assess what are the most critical features to getting the prototype done. You can use any kind of kanban board to track your work. I’m using Glo Boards by GitKraken because I like their stuff. Trello and Miro are also cool.
My first stop is Skylinerw’s guides. I need to learn a bit about rolls and weight. Alright. It’s not so bad. Each time is multiplied by its weight. I want to use Minecraft’s rarity values to create some mental correlations, so we’ll drop Ender Pearls 2.5% of the time.
We have to start somewhere. I’m not sure where, but we must go forward.
Let’s always drop one piece of food. That’s one entry. I looked around the creative menu yesterday and settled on cooked salmon.
I’ll add the rest of our items now.
Figuring out weight is not my strong suit. I’ll take a look into Minecraft’s vanilla datapack for this. The zombie files should provide an answer.
Ah, quick bit. I should have added new pools instead of entries in one pool. Duh.
I’ll make one pool with cooked salmon, another pool with a torch, cooked salmon, and a 25% chance to drop one scaffolding. I’m foreseeing this being a bit of an over-abundance. I think it’s probably better to start high and see how it feels before we begin reducing.
Studying the zombie file for another few minutes has afforded me some better options. Let’s get rid of our first entry and go with only two pools. One is our common items, set to use the function “set_count”.
We’ll use this in conjunction with roll to do some fun stuff. Experiment time!
This…actually turned out well. I looted 25 zombies and got this spread of items. I’m a fair bit surprised it turned out so well. Instead of wondering how much better it could be from the get go, let’s leave that to when we’re playtesting a lot.
This is feels like a worthy spread of loot given the effort put in. I would expect the player not to run out of food, and probably even have excess.
We cannot forget to deal with Silverfish.
They are a special case, as they will always drop 1 to 3 torches.
And it works! It took about 30 silverfish to get a stack of torches. I’m thinking this may be another lever I can use to refine some gameplay loops! We’ll see how it goes.
The final bit of work I’d like to do, before I go to sleep, is to refactor the predicates light block tables from yesterday. I got a bit of advice that I could bring this repeated stuff into one table by using reference at the table type. Let’s try that.
Tonight, I learned about Predicates. They don’t exist in the vanilla datapack.
But why would they be?
If we instead look at the Minecraft Wiki’s page on data packs, we see that Predicates are a whole folder in its own. It takes exactly the kind of conditions I designed in the last post and makes them available globally through this usage:
Damned sweet. I’m in love with predicates.
Off to dreamland. I’ll update the rest of the ores tomorrow.
I started designing and producing a datapack game for Minecraft back on March 6, 2020. I started by live-tweeting the design and development process. I ran a few work threads, and had a good deal of fun.
Throughout all of that, I began to get a bit dissatisfied with how Twitter organizes larger threads. Getting the content nicely organized sucked.
It’s been about a month, and I’ve decided to switch over to a blog format for a couple of reasons:
Through investigating this, I have found out a bit more about the Bonus Rolls feature and location condition feature. I’m beginning to think there may be a VERY interesting idea of lighting up an area being a requirement before players can mine.
When designing Minecraft maps as a hobby, I think it is very important to remember to have fun as you go. Here is my current scoped work to get to a prototype. I’m fairly confident I can get there.
Let’s test to see if light level actually applies the proper loot table.
This whole theory is based on whether or not the loot tables respect the light levels in the game. We’ll test this on coal.
I’ll toss this into the custom loot_tables folder I’ve setup. I have a coal_ore.json just setup for just this kind of thing.
2:30 PM CEST
I don’t know, got distracted for awhile there watching YouTube, scrolling Reddit, and playing a bit of Animal Crossing. Let’s test our theory.
Nothing worked. Next step is to goto the Official Minecraft Wiki and take a look at the loot_table properties to see if something is wrong.
OK, things seem to be lining up. The wording makes sense. Off to the /r/MinecraftCommands Discord for some peer review.
Oh, I suppose that makes sense. Let’s try to add this complexity. My next idea is to add a few Alternative Conditions. We’ll check all six sides of the block for the light level of that block.
My first attempt with setting this up was a bit of a mess. I went into Minecraft’s default coal_ore.json for some checking on formatting. I perhaps don’t know how to use the generator appropriately.
Ah, yeah. That was the problem with my first pass. Let’s bring everything up to the parent level.
3:24 PM CEST
Success! This block now only drops when it’s been lit.
Next up is applying bonus drops based on the Lucky status effect. I don’t quite have a plan for how to use it, but we’re here now and might as well take a look at applying it. Let’s give an additional one roll for each level of luck.
3:42 PM CEST
OK, I can’t figure out how these bonus rolls work on loot tables.
I figured it would be something fairly close to increasing the Bonus Rolls number. I’m thinking maybe it has something to do more with multiple entries needing to be rolled for.
Alright, got my answer some time ago and took a break for some nachos.
Essentially, bonus tables do not apply to mining. Since this is an extra investigation we can’t really afford to spend more time on, we’ll move on to something else.
However, I was advised that a way to do this would be to use the entity scores condition. I could probably use that to listen to the Luck level. The only real thing holding me back is figuring out the ranges. I’ll hold back on adding the bonus feature until we get a prototype out.
Silverfish are hiding!
I want silverfish to spawn when ores are dug-up in the dark. Let’s make that happen by dropping a spawn egg and then using a function to swap it out. I would have preferred to drop an entity directly, but we’ll stick with this for now. It’s highly likely this won’t even make it to the final map.
But it’s fun.
It took a bit of wrangling, but I’ve got the silverfish spawning properly now. I always get tripped up on the NBT.