Hey Everyone! Stephanie again. As Tom mentioned in last week’s livestream, we’re working together on food! In today’s test environment, young Sean Connery brave Willad Northpoint is harvesting berries off of bushes so he can eat them later.
(He still doesn’t get hungry yet, but one day! One day…)*
Since some of you displayed an interest in the more technical aspects of content creation, I thought I’d take some time this week to show off some behind-the-scenes screenshots.
A berry bush is an entity. Entities are objects with a physical manifestation in the game–people, trees, furniture, etc. An entity is modeled in Qubicle, exported to a qb file, and contains a .json file that describes its attributes and functionality.
JSON is a popular format for organizing data. JSON files are really just text files that have a certain syntax. They can be opened in any text editor, including Notepad. Team Radiant uses Sublime because it’s fast, pretty, and offers a lot of powerful keyboard shortcuts useful for coding. Here’s berrybush.json open in Sublime:
Note that the format of the JSON, and the attributes exposed inside of it, are not final! They may yet change. A lot. So if you’re planning on making or altering mods inside Stonehearth, take this post as an invitation to think about how your functionality is organized but not as a recipe book as to exactly how to use the code.
That said… on to the code! JSON is a key-value-pair rich language. The first line in this file has a key of “type” and a value of “entity”, which means that this file is going to describe an entity (as opposed to a command, or an animation, etc). When the file is consumed by our code, our code will thus know how to interpret the rest of it.
The second key, “components”, indicates that the entity is going to need a bunch of code-logic blobs in order to interact with the world. Every component listed here, (stonehearth:commands, model_variaants, render_info, destination, etc) is implemented as a reusable C++ or LUA class. Components are added to and removed from entities like lego blocks to incrementally define their function. The key/value pairs inside each component specify how this component should work inside this particular entity.
Going from top to bottom, the stonehearth:commands component means that the berry bush will have 2 user-interactable commands on it, chop_tree and harvest_berries. These commands, implemented in the files specified, define what icon to show when the bush is selected, and what blob of code to run when the button is clicked.
The model_variants component specifies the model(s) that will be used to display the entity in the world. Right now there’s just one.
The render_info component specifies that the model should appear in the world at 0.15 scale, which is slightly larger than usual. (The default scale is .1)
The destination component describes the default distance from the center of the model that entities interacting with the model should stand when interacting with it.
The unit_info component specifies what will be displayed on the screen when the entity is selected.
The Stonehearth:resource_node component means that some kinds of interactions (in this case, chop) will produce resources when the bush is destroyed. This bush can withstand 1 axe-chop, and will as a result, produce 1 piece of wood. Changing these values is super fast, which makes balancing the game on play easier.
Stonehearth:harvestable indicates that this bush can be harvested for resources. The resources are renewable and will return every hour. (This is purposefully short for testing; it will definitely change as we tune the system.) Harvesting the bush produces a new entity: a stonehearth_berry_basket. Harvesting will happen using the harvest_command. Though this is also specified under the commands component, reiterating it here means that the harvest LUA code will be able to know exactly which command to use when when executing.
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?
When we get closer to release, hopefully we’ll be able to give you some documentation describing the reusable components available to you, and how to use them.
* <existential philosophy> I actually feel a little guilty about this hunger thing. Wolves, by comparison, feel relatively benign. Though they’re far more immediately lethal than hunger, they’re an outside threat that our little people can team up to (eventually) defeat. Hunger, on the other hand, is an insidious, inside threat; the very first impulse in the game that transforms our setters from self-sufficient free-spirits into meat creatures that must compete with each other in order to survive. I find myself thinking about snakes in Eden, or at the very least, paragraph 2 of this old PA rant from 2008.
Which is not to say that hunger is making our game, as a game, worse. Quite the contrary! I loved Populous II, especially the parts where you traumatically inconvenience the people of your world. 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.</existential philosophy>