[Dev Blog] Behind the scenes with Bush #4


#1

Something tells me the coders amongst you will be more than happy with this week :smile:
http://stonehearth.net/2013/11/12/behind-the-scenes-with-bush-4/


#2

I like the more technical character of this weeks update… please more :wink:.

P.S. So it is “official” now, our models will be scalable via the related JSON-Entity-files.


#3

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.


#4

Well, that’s what we’re doing now but even without consulting him, I can already hear Tony yelling “No! Nothing’s official yet!!!”


#5

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. :smile:


#6

oh sweet baby geezuz, a n3rd rage blog entry from @sdee? Christmas done come early! :smile:

edit: this is just so … awesome! :+1:

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?


#7

agree, good desktop tuesday :thumbsup:


#8

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:


#9

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!


#10

So where do these buttons show up? When you right click on the berry bush?


#11

that’d be my guess… all contextual action items…


#12

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.


#13

… 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?


#14

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. :wink: 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.


#15

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 :wink:.


#16

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.


#17

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… :smile:


#18

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. :slight_smile:

For the record though, I also do like clicking on the bushes. :wink: GLOMPH, SCARF. CHOMP.


#19

well, as they say… super awesomely awesome great minds think alike… :rocket:

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…


#20

@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?).