Revive this topic? Yes, Discourse. You can’t tell me what to do.
Of things to come
I’ll wrap this up as soon as I get bored of the current Minecraft session or so. In other news, I didn’t know you could edit videos with Blender. It’s a pleasant surprise, although the GUI is still, at its core, Blender.
So let’s talk a bit about the last part. You might have noticed, it has sheep. You might also have noticed that it had fancy lights. You may also have noticed that the last clip had a weird kind of view on it.
What I was working on, but am kinda ditching now, was a real-time importer of Stonehearth sessions into Unity3D and from there on, into the magical world of VR. There’s a video of mine which is basically the longer version of the preview clip:
and before somebody asks, yes, I did script the cursor to move around randomly to “imitate” a real one. Yes, that did take me a few hours to get a semi-realistic thing going. The cursor actually has a velocity, an acceleration and some form of simple AI… including hover and click sounds, which are not present in the title screen.
and then there’s @Froggy’s version, which uses the 2D camera to represent the stuff. It was still displayed within OpenVR, or a Vive to be precise:
Both these videos look way less interesting as a video than they did live in 3D, let me assure you.
Being the perfectionist that I am sometimes, I wasn’t really satisfied with just whipping up a green plane, place some trees and then do the video there. I’ve wanted the real stuff. So I kinda patched the world generator so it gave me a neat little table of cubes that I could use, and wrote a script that was able to export the model paths and positions and then re-import them back in Unity.
Thanks to Albert, I was able to get the exporting done all the time, not just when you’ve started a new game. So the current state would be this:
So basically, I would have something that would allow me/you/whoever to save their current SH game into a file, then boot that file up in VR. Models are all loaded directly from the .qbs (the .smods need to be extracted for this to work), the terrain is created properly and even water is there… more or less. Because I’m really horrible at this whole graphics stuff, the lighting is really bad, the base materials that I’m using to clone everything and the water is horrible because I can’t do shaders.
So I thought maybe if I can get terrain, water, most entities and buildings working, it would be something that could be released. Although I don’t know how many own a VR device, seeing your own (or others) creations in VR could be really neato. However, the building part is kinda the dead end of this project…
As you can see, everything related to buildings is horribly off and I have no idea why. Literally, I have absolutely no idea. The offset seems to change per rotation per entity per direction. As in, a door facing north or south needs to be pulled forward, then pushed to the left, while the same door facing east or west needs to be pushed back, then pushed to the right for the same amount. It doesn’t make sense and i have no idea why this is the case. There’s no model origin on any entity, nor its parents; the offset in Unity for the lantern is 0.425/0/~0.4 (or maybe +/- 0.075), but doors are -2/0/-1. Plus, everything is duplicated (once the real entity, once a ghost entity that apparently exists, but is invisible… somehow).
It’s not enough that Unity and SH use completely different systems (light handed vs. right handed), and Qubicle of course supports both formats so I can’t even be sure which one to pick… and in the end, I think I’ll just add this to my pile of dead projects. It was nice while it lasted, but I’m really done with those fixtures.
So in case you feel really fancy, the export script, which utilises dark witchcraft and shouldn’t be used for anything but exporting stuff:
So, if someone actually manages to tell me how to properly transform Stonehearth coordinates into Unity3D coordinates, I might get this going again. Unitl then, I’m going to wonder why most things are placed pretty okay, but some are horribly offset.
It’s the season for Frostfeast! This is the second time that we celebrate Frostfeast and like last year, I would like to share some pictures of the progress along the way. You can find last year’s report here:
This review contains spoilers to the campaign and content of Frostfeast 2016. If you don’t want to get spoiled, don’t read this until you’ve finished the campaign!
You will be told when the campaign is over - we’re breaking the fourth wall for that. Finishing Frostfeast can be done in as few as 23 quests, or as many as infinite. So technically, if you’re really into it… you can finish Frostfeast within two in-game weeks! I recommend taking it at a pace though.
You have been warned. Ready? Let’s start.
The Good, the Ugly, and the UI
You will have noticed that Frostfeast comes with an entirely re-colored UI. That’s not the only change, and that’s not how it started… I was wondering if it were possible to make the in-game menu at the bottom a bit more festive. Sadly, debugging UI things in Stonehearth in Alpha 19 is quite broken and unusable… so I’ve had to dump the HTML from SH into a normal .html, adjust some paths, then open it with Chrome and Firefox. That allowed me to play around with it in real-time, which sped up development a lot compared to changing files and then refreshing the game GUI (which takes a few seconds every time).
So let’s take a look at the evolution of the GUI. This is the normal SH one:
The first draft was really just “Add some snow to the top of a button, then add a glazing effect to the button itself”. I’ve done this using CSS voodoo, so we didn’t need to re-do all the button graphics and technically speaking, we could apply this effect to everything. We thought about adding it to dialogs and windows too at some point (the snow, at least), but decided against it. After I’ve done the CSS bits, @Froggy made some prettier graphics… although we had lots of iterations here.
In the end, the effects were polished and we’ve even replaced some of the graphics with more winter-y ones. A challenge was the town overview (the tower), because Rayya’s children is also overriding this one… and we couldn’t really, without some effort, have a different one for Rayya’s children. So in the end, I think @Froggy somehow ended up with “Let’s do an Igloo” and I’ve said “Alright, but we need one of those poles, too”. I think the end result is really nice:
After we’ve had the start menu, @Froggy kinda went crazy and replaced the whole GUI. I’ve helped here and there with some CSS, but he did all the work on that one. I was skeptical of the blue font at first, but meanwhile I think it fits pretty well.
The New Cleric
Last year, we’ve used the fancy dialogs for conversations, but had still the old parchment scroll for the quest itself. So basically, although we had these:
The normal SH dialog bulletin, as seen in Frostfeast '15
We still used these (ignore the i18n errors for a second):
The old encounter format, based on the returning trader, as seen in FF '15.
So at some point, we weren’t happy with how that looked. It looked horribly outdated, it wasn’t easy to read and it didn’t fit the rest of the encounter flow. I wasn’t happy the way the dispatch (the encounter that creates the quest-encounters) worked either, so a full rewrite was done. Let’s talk about the UI first; an own bulletin dialog had to be done… and for that, we had to mess around with SH’s files again, because as of Alpha 19, there was no appropriate point for own bulletins to be added. There were some events, but they were either too soon (“frostfeast” < “stonehearth”, because f comes before s) or too late (stonehearthReady, stonehearthGameReady). After modifying the base_bulletin_dialog.js, we’ve ended up with the first draft:
First draft of the new GUI. Old text, the first two strings I could find as button names, and a misleading "OR"
It was basically the old text with new graphics and some visualisation. However, the visualisation wasn’t correct, it’s not really an “or”, it’s more of an “and optionally”. Because if you fail the first bit, the second won’t be accessible. So after lots of HTML fun (again, outside of Stonehearth), I’ve ended up with these.
The only nuisance they have is that they’re quite large, they’re taller and wider than your normal dialog. But that’s barely noticeable anymore because I’ve tried to make it a bit taller and a bit wider, and utilise the space more useful. As comparison, with the same width and text, they were a tad too tall:
Dialog would not fit under the 11-foot-8 bridge. *ding*
But that was way too much space and way too much information, so we’ve tried to condense it down and I think we’ve succeeded.
Let’s talk about the technical background for a bit. Last year, the CoP’s campaign was a bit boring. After the introduction, you were offered the same encounter again and again and again. The requests and the rewards might have differed, but all in all, it was just more of the same. In order to provide more depth to it, I’ve had to rewrite the dispatch encounter. The dispatch encounter is responsible for giving you a daily quest. He shall give you one quest per day, and one quest per day is what he shall give you. He shall not give you two, nor zero, unless he will proceed to give you then one later that day.
cleric_dispatch_encounter is “just” 182 lines of lua that is responsible for a more in-depth quest system than Stonehearth’s normal encounter system allows. We can define a list of possible encounters in JSON and attach all kinds of requirements to it, like
Maximum and minimum allowed/required successful finished quests
Maximum and minimum allowed/required successful failed quests
Maximum and minimum allowed/required total done quests
Maximum and minimum allowed/required success/failure ratio
Maximum and minimum allowed/required reputation
Maximum and minimum allowed/required day passed
(Group) of encounters that may only be done once
Using this method, we were able to give you a somewhat smooth transition into the whole business. There’s a tutorial consisting of 6 quests, which are all rather easy. After those, you get some easy quests, then it’s a mix between easy and normal quests and at some point, you only get normal quests.
The quest encounter itself has also been rewritten; so the GUI and the code behind it is completely new. The new cleric encounter has 819 lines of lua - twice the size of the returning trader. It allows for a lot to give a smooth experience.
However, not everything is smooth - unlike some of Stonehearth’s normal campaigns, the cleric quests are time-important. If you ignore them for too long, they will simply disappear (and count as failed). It’s not possible to just not accept a quest requiring a mason offering until you have a mason, for example. After a few hours, the courier (and the offer) will be gone, only to return the next day.
To allow one quest per day (down from one per two days), the quest has also been changed. Instead of waiting 24 hours, the courier appears early in the afternoon and returns late in the morning. So if you’re quick to accept the quest, you have more time to prepare, and if you’re quick to turn it in, you can get another quest from him when he comes back in the afternoon. Otherwise, you’ll have to wait until the next day.
Both dispatch and the cleric encounter are way over-engineered and would allow for much more than what we have utilised.
The central piece of Frostfeast 2016, and this hearthling, is the monument.
Iconics are hard. File paths too. At this point, the monument doubles as swimming ring.
Frostfeast '15 did not really have a story; Frostfeast '16 does. There’s a background lore that is not explicitly stated, but hints can be gathered here and there from the dialogs. The monument is another way; it represents, abstractly, the story of Frostfeast.
The monument itself is just a “space”, a canvas if you wish. There are five components to it: Four pillars, and a tree.
The pillars that are received during the tutorial and placed by your hearthlings at the monument.
The tree was, I’ve gathered, super difficult and annoying to make. I assume it was about as annoying as me trying to write the AI that places the pillars. I’ve spent so many hours trying to figure out why it doesn’t work, only to find out that I’ve missed a comma somewhere in a JSON and nobody ought to tell me that this was an error… instead, it silently loaded the file somehow, but not in the way that it should have been. Yay, fun.
So while I was waiting for the tree, I’ve used the good ol’ Frostfeast tree from last year (that is still available as decoration, but pales i comparison) to play around with. It looked like this:
Doesn't look too bad, could probably have passed, but not good enough for me.
We wanted the tree, and the monument, to be epic. We also had this idea of introducing a reputation system: If you did stuff for the CoP, you gained reputation. If you were slacking, or failed quests, or just generally did not-nice stuff, your reputation would sink. Succeeding quests raises your reputation, and doing so with the stretchgoal even further.
But how do we display reputation? Just a number? A bar? A vague text that changes now and then? Nah, we’re using the tree. Because, you see, the tree is magical. It can feel the festiveness. Why, you ask? Because.
There were, once again, so many revisions because I’m hard to please. Like, really. If we’re doing some pretty thing, we’re not going for something “good”, we’re going all the way or not at all. Let me share some revisions:
I wish I could have adjusted the braziers too, to have their color and strength be affected as well. But because there’s no way to do that in Alpha 19, it had to be scratched. It’s one of many ideas that we sadly had to sacrifice, and it’s bugging me a lot. The reputation affects one aspect of the game though:
Scientists recently found out that donating presents can affect the way you feel cold.
The transition between these stages is, by the way, completely fluent. Each branch is affected individually.
The transition from "completely healthy" to "pretty dead", sometimes with more than one step in-between because 16 FPS gifs.
As your reputation falls, your tree is slowly dying, but as your reputation rises again, so does your tree’s health - like a phoenix rising from the ashes. Just with less fire involved, because dry trees are quite a fire hazard. We’re all responsible here.
Of course, just a tree would be boring, too. So we had to have baubles. Once again, while waiting for assets, I’ve… improvised.
If you’re really quiet, you can hear them baaaawing. It’s almost like they’re real sheep, attached to a tree, which the engine doesn’t like and therefore throws errors every second.
Apparently, putting miniature sheep in a tree isn’t a good idea. Who could have predicated that? What about some berry bushes?
In the end, I was revoked the privilege to make baubles, @Froggy made the proper ones and we’ve ended up with the tree we have now. As a quick comparison, here’s the “old” tree and the one we use in the monument, fully decorated:
We’re happy with the end result and we believe that the monument is quite a sight, worthy of being the center of a village.
In the Church of Plenty, I am some higher up representing an ancient Order, Achernar.
Not everyone with green hair is immediately untrustworthy and inherently evil. He seems like a nice guy.
I’ve always wanted Frostfeast to be a true representation of the winter holidays, and not just a generic, cheery “oh it’s christmas and everything is nice” mod. That’s why the day is shorter and the night is longer, it’s why there’s a cold mechanic, and it’s the reason crops take more time to grow (with the exception of oak saplings, for balancing reasons). Unlike for example Candledark, Frostfeast never had any enemies you have to fight, and this isn’t different in FF '16. You are still up against the environment, but this year, the environment is not as static anymore, it’s a bit dynamic. Once again, not as dynamic as I would have wished it could be, because we had so many limitations, but it’s at least a tiny bit.
So back to the campaign. After the tutorial is completed, Achernar appears and sets up a camp next to your base.
Look how cute! They're cheering their monument up!
It’s staffed with Achernar and five of his subordinates. Once Achernar has settled down, he might show up in some quests. Oddly enough, he will always try to get the presents destined for the Church of Plenty… But he pays good, really good. Not only does he give you more offerings, but his offerings are (on average) filled with more valuable things.
He and his friends are some force you would not want to mess around with. And here’s why:
This video contains quite a few things we had to work around with. For starters, at the very beginning, the effect didn’t look as good; it was quite choppy. It wasn’t a clean trail, but rather it it was “punctual”:
Visual representation of a frostfireball that ran out of ink mana.
Tweaking around with the cubemitter fixed that. Then I had no animation, or weapon… So I’ve used the archer one, which looked a bit ridiculous:
How silly, that’s not a bow!
I’ve tried to mask this fact by giving them a bigger weapon, but it did not quite work.
Slightly bigger dagger. The fact that they are using the archer animations is now not as obvious.
The other issue was the trail itself. If the projectile was removed, e.g. because it hit or its target died, the projectile was immediately removed, and so was the trail. That’s bad. In the video, you can see that some bolts are slowly fading away halfway-through… and that was quite tricky to achieve! I had to write my own component that “decouples” the effect from the main entity before said entity is destroyed. It then kills the effect, letting the trail gracefully die, before the effect entity itself is destroyed.
As you can see in the video, they’re not just good at ranged combat, but are also excellent melee fighters. I’ve had to provide quite a few combat actions myself in order to achieve that.
The model itself also underwent several changes. In order to quickly evaluate possible colors, I’ve adapted the SHVR project in Unity I’ve made before. I’ve added a function to load a model and then quickly re-color it, based on the grey scales. This wasn’t perfect, but allowed us to quickly see what the model would look like in a different color. It also gave us a rough mapping (old color -> new color) that @Froggy could use to re-color the model.
One of the early drafts. I wanted to aim for "slightly generic evil purple".
After some frustration with @Froggy, I’ve tried pink. But apparently, that wasn’t good either.
At some point, the color of the monument was also taken into consideration. Originally, it was black-ish obsidian. Here, another not-serious-attempt at coloring.
At some point, I’ve just sat together with @Froggy, streamed how I’ve changed the colors in Unity, and he said “stop”. I wasn’t very fond of the white-winter-camouflage-y tone at the very beginning, but by now, I think the color fits really well. It’s not just the cultists themselves, but also the monument and the pillars, along with the glow effects, it really fits together. It was definitely a very good choice on @Froggy’s part, so well done.
Last but not least, a few out-of-context screenshots of things that didn’t go as planned during development.
The last bit isn’t a scaling issue, but it was a FPS killer originally. Just a single one was enough to make camera movements almost impossible, although 94% of the model was empty. In the end, I’ve written a hackish component at two in the morning that allowed us to separate entities and improve the performance a lot. There is still much that could be done, but I think it’s good enough…
While adding new features to Frostfeast '16, we’ve also discovered a lot of things that were broken last year… but we didn’t notice, for some reason. So look forward to the following additional changes:
All items and recipes have been re-balanced. I’ve written a tool that gives me a list of all items, their worth, and their ingredients worth and balanced the Frostfeast items accordingly.
Presents will no longer give you a fixed amount of items. Where you previously got up to 20 pumpkin pies, you’ll now only get up to 20. It’s random between one and a fixed value per item.
Chimneys are now just one entity. At least, to the unpracticed eye…
Chimneys can be moved around without weirdly becoming more and more.
Heat sources should work fine now. Really. Promise. Maybe.
Firepits are now on 24/7 and require fuel (except the goblin firepit, which runs on ██████████).
If hearthlings stay too cold, they might get the sniffles.
Items and offerings for the professions that were added since last year.
Many smaller bug fixes and general quality improvements.
Oddly enough, at some points, when going through the code, I almost feel like last year’s Frostfeast couldn’t have worked at all. There’s so many bits that could never have worked… but probably, nobody noticed.
From here on forward…
So this has been Frostfeast, and with that, I’ll enter modding hibernation once again (just like last year). This means I’ll get out of touch with the game and its systems real quick. So while some things would be nice, like for example an updated Zulser, they are put on hold for the time being. If I fancy modding Stonehearth again some day, those might get a revive.
With all my “spare” time I have now, I’'ll focus on work, my studies, and maybe trying to find something else to do…
There's a chicken hidden somewhere in this picture. Can you find it?
I might drop in here from time to time to post a picture, gif or video about its progress, especially if something has gone hilariously wrong. I won’t disappear from the Discourse after all, just hibernate a bit.
As I’ve written in the last update for the VR bits, because of Stonehearth’s way of dealing with animations/coordinate systems, trying to achieve something like that in Unity is sheer impossible. Consider it dead, unlikely to be revived.
Uh, not to interrupt so much, but if you want to import SH animations into Unity, you can reverse the process in Blender by loading up the animations to the model in blender and then exporting as a different format or just save as is since Unity can read .Blend files
Not to like, force you to do it or anything just letting you know
The problem is to do it in an automated and somewhat comfortable way, without having a too big pipeline. If you go over Blender, you’ll either need to ship Blender with your application or require users to have it installed/give you the blender directory path so you can use it. Then you need to write a script that imports the animation and exports it in something useful, then call Blender with that script, passing in the animation path (that you’ll likely have to extract into a temp directory somewhere unless you want to teach Blender how to read the .smods/zips too).
Unity’s support for Blender is also kinda wacky. Last time I’ve checked, there was no real support for .blend files - the Unity editor just transparently used Blender itself to export it to .fbx, which was then imported. However, this is all done in the Editor, so during design-time - not at runtime, where you would usually do it. Because Unity is just calling Blender, it also requires you to have Blender installed, even if you don’t want to do anything but importing the .blend you’ve found somewhere.
That means to get it working this nicely, you would need to have somebody install Unity and Blender - both not exactly lightweight applications, that shouldn’t be required to just run a game.
Plus, the issue was more about positioning the single bones than anything else. You can see it in the door - I didn’t even try to do an animation, I just wanted to know how to place the door/its components with an idle state/idle animation, but no matter what I’ve tried with pushing the values around and rotating the coordinates around, it was always off.