Something tells me the coders amongst you will be more than happy with this week 
http://stonehearth.net/2013/11/12/behind-the-scenes-with-bush-4/
6 Likes
I like the more technical character of this weeks updateā¦ please more 
.
P.S. So it is āofficialā now, our models will be scalable via the related JSON-Entity-files.
2 Likes
Really psyched about this update, probably more than even the land generation one (thou that one was awesome too, this is just more meta-awesome).
But if I needed any more proof that the experience you get out of an exercise depends on the part of yourself that you put in, let me state for the record that creating a God game pretty much completely obliterates the experience of playing one.
Very true. I think the same might be true for mods (on a smaller scale). So the more people making mods, then there are more people enjoying other peoples mods, and all is much better with the universe.
1 Like
Well, thatās what weāre doing now but even without consulting him, I can already hear Tony yelling āNo! Nothingās official yet!!!ā
9 Likes
Nice to get a look a some of the code would definitely love to see more like this, though I am probably in the minority for having a preference for seeing code rather than more models.
1 Like
oh sweet baby geezuz, a n3rd rage blog entry from @sdee? Christmas done come early! 
edit: this is just so ā¦ awesome! 
Different components can be added/removed from this file as we add/remove functionality from the berry bush. Writing Stonehearth is very much an exercise in defining and implementing the reusable components that describe the many interactions in the game. For example, if we decide that only one person can harvest a bush at a time, we might add a lease component, which implements the concept of exclusive use. If we decided that the bush was flammable, we might add a materials component that specifies that the bush is made of wood and leaves. We would then need to write a new āflammableā action that triggers on wooden items when they are exposed to fire.
So, when thinking about your mods, think about the entities you want to add and the pieces of functionality that belong to each item you want to add to the game. Can they be broken down into generic, re-usable components? What data is required for each?
2 Likes
agree, good desktop tuesday 
1 Like
I can appreciate the extra effort required to produce the more technical entries, but they really are quite fascinating, and help paint a better picture of what it takes to develop SHā¦
The added benefit is that portions of these entries can likely be used in any planned guides or tutorialsā¦ 
1 Like
Itās wonderful to see how things are working below the surface! Thank you for posting information like this.
I must say that Iām impressed by how modular everything seems to be! Iāve worked on mods for other games that werenāt very well designed for it and the experience was pretty awful. Iām really looking forward to tinkering with SH!
1 Like
So where do these buttons show up? When you right click on the berry bush?
thatād be my guessā¦ all contextual action itemsā¦
Right now, single clicking on any item in the world brings up its unit frame in the lower left corner of the screen. The commands available on the item are in there. You can then click them with the mouse, or hit a hotkey to activate them.
ā¦ just thought about translations. If text is āhard codedā in the single entities, we will have to touch every single file to translate the complete game, no?
Right now yes, but we have a plan to fix that! I wrote it down in a notebook two months ago; I hope I can find it again. 
The gist is that eventually, the translations will go into a separate file, and the server will do the substitutions as it sends them along to the UI. We did think about putting all the strings in the UI, where separation is already built in, but we wanted to make sure that modders who are just adding simple entities didnāt have to touch multiple files (the UI text file and the entity .json file) in order to add something simple.
4 Likes
Great and very good point. If there is a way to include some intelligence in Stonehearth to extract the stringsā¦ hope that will make it into the game! ā¦ and let us know if we can help searching for the notebook .
3 Likes
I know this is the First Release, and not to throw a bug in the rug, but isnāt that a bit too much micro management for StoneHearth? The technique of going to every berry bush and saying āharvest meā seems wrong. Like more work than I want to do when playing. Iād much rather go to a community task list and add āPick Berriesā, and individual workers would choose when that task was appropriate (perhaps based on community hunger levels).
Of course, in the wood cutting paradigm we have see so far, you select the tree and say āchop meā. Workers choose when to chop or build based on proximity, supply count and other factors. Might that suggest then, that berries are āqueuedā like trees. You can say āharvest meā but no one will until they āneedā to.
Ah, but thereās the rub, is it not? I have to queue them. In the paradigm I am proposing If I created a build task that used wood and there was no wood to be had, the worker would just go chop the nearest tree.
Yup, just saw the problem with that too. We just planted those trees in the town square and some ābrave Willad Northpointā comes and cuts down my carefully planted trees. So to prevent harvesting trees/stones/berries or any resource from random locations we have to designate those resources we want removed.
Interesting design decision.
this could be remedied by having a designation you can apply to a range of trees/bushes (mark an area), all to be harvested when necessaryā¦ that way you dont have to click individual bushes, but you also dont have to worry about the wrong bushes being harvestedā¦
mind you, i dont mind the step of individually clicking bushesā¦ it satisfies the OCD hunger painsā¦
Good points, all!
Thatās exactly what Tom said.
So we have a line item for this on the board, but we havenāt hashed out all the details on exactly how to do it yet. Until then, weāll bias each harvest towards multiple servings.
Glad you guys have such good insticts as to what the game should be. 
For the record though, I also do like clicking on the bushes. GLOMPH, SCARF. CHOMP.
2 Likes
well, as they sayā¦ super awesomely awesome great minds think alikeā¦ 
edit: and thats not to say that both options cant coexistā¦ having multiple ways to perform a task is usually a good ideaā¦ so, some folks can multi-select, while others can single-selectā¦
and still others, if possible, can prioritize items that are within a multi-select rangeā¦ for those situations when you have selected a group of bushes, trees, etc., and still want to have a particular entity worked on firstā¦
ex. the player has selected the three bushes below to be harvested, but then proceeds to āforceā a particular bush in the sequenceā¦
1 Like
@sdee How about adding discovered food sources to a list (BING - You have discovered Berries! Go out and collect them to offer your settlers something yummy or to paint your clothes in a berry-blue tone.) On that list you could select and de-select which source you want to be gathered and allocate workers to a task ācollect foodā. You still would have the option to click on bushes (and others) simply to de-activate single units of an entity as they might be located in an area which you do not like to be entered (too dangerous, too far away, ā¦). So it would be less micro-management but you could still do more strategic decisions and optimize the process (Which food source should have priority? Where should it be gathered?).
1 Like