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.
Hi. As I said last week, Tony has been pounding away at a re-vamped construction system. A part of this is the ability to show planned-but-not-constructed buildings in a blue, wire-frame mode. Here’s a shot showing the new renderer in action. As your guys complete the wall, the brings go from wire-frame-blue to solid voxels.
This week we continue our march toward the preview release in December. As usual, our time is divided between slow but steady progress on gameplay and on the boring-but-essential features that we need to actually ship a game: clear modding APIs, installers, and performance tuning.
One such under-the-covers enhancement was to change the way we treat professions like the Worker and Carpenter. There’s a lot that goes into a character’s profession: how they appear on the screen, what kinds of things they’re allowed to do in the game, how they react to their environment, etc. A Worker or Carpenter might run from an invading orc, but a Footman or Archer would engage to defend the town.
Our original system allowed modders to manipulate all these aspects independently. It was flexible, but difficult to use. We’ve re-factored things around the notion of “equipment.” Like in RPGs, all characters have a set of equipment that they wear. In Stonehearth, you will be able to associate AI scripts with a piece of equipment. So the scripts for chopping trees, hauling, and other workman-like tasks are associated with the “Worker’s outfit” equipment piece. The AIs for crafting are associated with the “Carpenter’s outfit.” When a citizen takes off one outfit and puts on another, the AIs are swapped out as well.
Of course, that begs the question: what does a person look like with no outfit on?
Two Live streams this week!
I’ll be streaming both today and this Thursday, at 4:00 U.S. Pacific time on both days. I’ll be taking a first nibble at the eating/drinking systems in the game, mostly modelling and animating. As always, you can tune in at http://twitch.tv/radiantentertainment
Work continues on the crafting system, world generation, and renderer. This post will focus on the progress we’ve made on crafters. The very basics of the system are pretty much done. We can write a recipe for an object, specify the ingredients, and instruct the crafter to go build it. Now we’re moving towards actually doing something with those crafted objects.
This screenshot is a nice summation of crafting so far. We’ve got:
The Carpenter, in his Carpenter outfit
His low-level, work bench. For now nothing more than a glorified stump, but it will be upgradeable!
The “out box” stockpile, where the Carpenter will drop off the goods he crafts
The crafting window where you can select objects to craft
And lo’ a whole pile of crafted objects on the right!
As you can see, the chairs, beds, tables, etc. in the pile are all minified. That’s how your crafted items will look when they’re not actively in use. The next step is to build the system that takes the minified object and expand it out to it’s full form when you place it in the game. So at your command, a worker will run over to one of those mini-objects, say the bed, haul it to your desired placement location, and drop it in it’s fully expanded form.
It’s been a lot of work getting the core crafting engine in place, but we’re definitely closer to the end of the work than the beginning. The good news is the whole system is data driven, so adding new crafters and craftable items is very straightforward. In other words, adding the 2nd, 3rd, and 4th crafter will be WAY WAY less work than adding this first one. And of course all of these APIs will be available to you as a modder, so you can make your own crazy crafter.
This week I’m continuing my work on the sleep system. A first cut of this puppy is more or less done. As you can see from this debug screenshot, we have beds! And people have learned how to sleep in them! Here’s how the system works in its first iteration.
As time goes by throughout the day, your citizens grow more and more sleepy. When their sleepiness hits a threshhold, they figure it’s time to go to sleep and start looking around for an unused bed. If they find one, they will claim it as their own, run to it, and fall to sleep. So citizens know whose bed is whose, and won’t hijack someone else’s bed. This means that each little guy can potentially have his own home if you build your town that way.
Ownership of a bed will eventually expire. So if something…unfortunate…happens to one of your citizens, someone else will eventually claim their bed. Also, if a citizen can’t find a bed for a while, either because there are none available or because he can’t get to any of the beds, he will eventually give up and just collapse on the ground, exhausted. Sleeping on the ground will be much less effective than sleeping in beds, so you’ll have plenty of incentive to make enough beds to go around.
With this basic implementation in place, we’re going to call sleeping “done” for now and move on to other aspects of the game. We’ll see how it works in practice and add richness where necessary. One obvious enhancement is the ability to explicitly assign a bed to a particular citizen, and we will almost certainly add that soon. And obviously we’ll need to implement our facial animation system soon, so everyone doesn’t sleep with their eyes open!
Busy days continue for Team Radiant. We’re making progress simultaneously on securing office space, growing the team, and working on the game. I will be pleased when the first two items are taken care of so we can spend 100% of our time on the last.
Today for Desktop Tuesdays we’re revisiting the Carpenter. Most of you have already seen this guy and his workshop here, so what’s the big deal? Well, Stephanie has been cranking away at the core crafting engine, and we’ve hit a breakthrough for how we want crafters and their workshops to behave universally in the game. The good news is that workshops like you see here are back and will play a major role! We threw them out a while ago because we couldn’t work them into our original crafting plans, but now they’re back.
The even better news is that it’s my job is to overhaul the workshop model, and I’ll be doing it on stream this Thursday at 4:00 California time, which is -7 GMT! You can tune in at http://twitch.tv/radiantentertainment. It will be nice to do another live stream, and I’m looking forward to explaining the workshop-related changes and answering your general questions.
Ack! I missed our regular Tuesday developer update, but I have a good reason! We’ve put the finishing touches on our Kickstarter video and submitted it for approval. Hopefully the Kickstarter guys can get back to us in time for our scheduled launch on the 29th.
Ok, so back to business. If you’ve been following along, you know that all your little citizens have an RPG-like class. That goes for the military units like Swordsman and Archer, but it’s also true for your crafters. And so (drumroll), here is a shot of the Weaver class and a lot of her craftables.
The weaver spins raw materials (cotton, flax, wool, etc) into consumable goods like cord for bows, and cloth for clothes and bedding. Where do those sheep, plants, and tools (the spinning wheel and loom) come from? Other crafters of course! We’re shooting for a real economic model between the the crafter classes, with all kinds of interesting dependencies between the production of raw materials and their refinement into consumable goods.
That’s it for now. Happy Tuesday…belatedly. And because it’s pre-Kickstarter week, here’s a new desktop wallpaper!
Greetings. I’m back from GDC and ready to get back to the grindstone. GDC was a great learning experience, both for the technical and business tracks and the other great indie devs that I got a chance to meet. So, hopefully a little wiser, he’s the long promised combat update! Here’s a video of the raw engine in action:
I’m afraid we went a little overboard on combat. We both have strong fighting game backgrounds, so we didn’t want units just pound away at each other until one fell over. So here are the broad strokes of what we’ve done.
Every unit has a unique set of combat abilities. The goblins have two abilities the “swing with your mace” ability and the “block with your shield” ability. The footmen have four abilities, the three different sword swipes and a parry ability. (these are just placeholder abilities we’re using for now to test the engine.) Every ability has the following properties:
Execution phase: The amount of time it takes from the start of the move to the point at which the ability activates. For a sword swing, the execution time is the time it takes to wind up and swing the sword. For simple combat abilities, this will always be less than a second, but for a spell it may be a few seconds while the spell is being cast.
Active phase: The period after the execution time when the attack is active. For a melee strike you can think of this as instantaneous, but a channeled spell might have a long active phase.
Recovery phase: A period of time after the move when the unit is unable to perform any other action. For a sword swing, the recovery time is the time it takes the footman to reset his sword to the ready stance. Again, for simple combat abilities, this is less than a second, but it matters.
Cooldown: The amount of time before the ability can be executed again. For instance, maybe a powerful spell can only be cast once every 60 seconds.
How Combat Works
If you know fighting games, then you probably know how this is going to play out. During combat, units are completely vulnerable during their execution time and recovery time. Look closely and you can see guys getting hit while they’re winding up to do an attack — they are being hit out of their execution phase.
This means speed matters! A series of fast attacks can overwhelm an enemy by interrupting a greater percentage of his attacks. So you’ll have to factor in your units’ attack speed before sending them into combat.
So there’s a look at the raw combat engine. There’s still lots to do and bugs to fix, but this is a pretty significant milestone in getting a base implementation of the game’s major systems: harvesting, building, crafting, and combat.