6/22/2014 – Snip snip


Alright. It’s time to get serious about cutting features. *Puts on game face*

Last night I went through the skill tree and cut absolutely everything that I didn’t have immediate plans for. Meaning that any time a skill either hadn’t already been fully implemented and tested, hadn’t already been worked into a quest or didn’t serve the core gameplay in a concrete way it got cut. Some of them may make their way back in during the beta, especially if it turns out there’s a hole in the balance, but even so, it hurts to see some of them go.

Snip snip. Gotta get this beta out the door.

I also merged several skills that were related and turned them into bonuses for existing skills whenever possible. All told we cut everything down from 86 skills to 57. Nothing major was lost – all the survival skills and magic skills are mostly in place – but a lot of the ‘fringe’ skills that are just fun-sounding had to be dumped. Horseback riding was one. I loved the idea (and again, I may still implement it during or after the beta) but with all the other travel options there was no reason to include it.

I’m also cutting back on the level of customization between different regions. I’d planned to have more different in architecture in residences between northern and southern regions. It’s going to be limited to texture variation now. Thankfully the terrain is varied enough to help make up for it. (And we’ve already seen how big a difference textures alone can make between two separate regions.) I’m not too broken up about this one.

No creatures have to be cut, praise the gaming gods. And we already have our cast of characters so we won’t see a loss in NPC variety.

One that really hurts is the Obex temples. I already have a pretty decent suite of Obex assets (you’ve seen them in early gameplay trailers and screenshots) but getting them properly finished would take way too long. So I’ll be modifying a set of generic assets for the temples. I hate resorting to more generic assets – I’ve already had to use them to patch the holes in my above-ground structure templates – but at least I can retexture them with my Obex textures and sort of make them my own. Blarg. Oh well, whatever – the end result will be the same from the player’s perspective, and that’s all that matters. In fact the end result will be better from the player’s perspective. Gotta hang on to that.

This one stinks too – I’m eliminating destructible structures. Not entirely, because several structures have to be destroyed during the main quest, but I’m eliminating the ability for any random structure to be destroyed. This is something that may return in an algorithmic form, because currently it relies on me creating a destroyed variation of each structure. If I can find time to write a system that intelligently removes and blackens / scorches the appropriate parts of a structure template – and I don’t see why that’s not possible, though it would be difficult – then it’ll be back on the menu. But given how fringe this feature already was, I have a feeling it’s gone for good. (I’ll keep the destructibility system fully in place for modders, of course.)

Okay, and the number one feature I’m bummed about cutting is: paths modifying foliage. The plan has always been for stuff like grass and ferns and other foliage – anything that isn’t a tree, basically – to get pruned away when you lay down a new path. I’ve got it partly working, but this is purely aesthetic so I can’t justify finishing it. Paths will work the same with or without it. So I’m cutting it. (Stay strong, Lars.) This is one I will be adding to the game post-release if I have to. It may not affect gameplay but goddamn it, it’s just too cool not to include somehow.

On the additive side of things: I’ve finalized how archaeology will work. (You saw a tidbit in the University video, but only of the end result.) I’ll save the play-by-play for next month’s Kickstarter update but I predict you’re going to like it. It’s not crazy complicated and it relies mostly on existing mechanics (crafting, bartering, examining) but it’s a multi-step process with four independent skills involved.

Read more here: 6/22/2014 – Snip snip

5/31/2014 – To Upgrade or Not To Upgrade


Unity’s new GUI system has been threatening to drop for so long that I’d all but written it off as vaporware. But lo and behold, it’s coming out in the next update, and it looks glorious.

This system would address a lot of the problems I’ve had with my NGUI-based system. But despite all those problems, I’m 90% sure it wouldn’t be worth it to upgrade at this point. Weird, isn’t it? I’ve been running into this a lot lately – I use a lot of middle ware, and in most cases I’m at least 2-3 versions behind because I don’t want to break any systems this late in the game. The last thing I upgraded was the character controller and it was *barely* worth it – I lost a week to re-implementing all my custom code.

One upgrade I’m dreading / looking forward to is Unity 5.0, which might squeak by before FRONTIERS is released. That will have an all new lighting engine, that would fix FRONTIERS’ flat-looking interiors. The exteriors in FRONTIERS look fine without global illumination but the dynamically built structures can’t use light maps. That leaves me with a handful of dynamic shadows, resulting in a very flat look. In theory real-time global illumination would fix that with little extra work. But of course I won’t *just* be getting an upgraded lighting engine – every other damn feature in the engine will be upgraded alongside it, breaking god knows how many things…

Read more here: 5/31/2014 – To Upgrade or Not To Upgrade

5/23/2014 – Randomization


Hey all – apologies for not showing any signs of life. Development is more fast-paced than ever and it’s so, so easy to let days (even weeks!) slip by without realizing it. Thanks to Gazz for poking me and asking for an update.

So what have I been working on? Well now that the issue of memory errors and structure loading is in my rear view mirror I’ve turned my attention back to the problem of filling out the gameworld with stuff to find. It’s all well and good to have hundreds of plants and books and objects to discover, but I can’t just dump them into a pile on the player’s front lawn. They have to be distributed in a way that makes some kind of sense. But of course like every problem I’ve encountered this turns out to be trickier to solve than I had anticipated.

(Colors are arbitrary, I just like the way they look.)


It all starts with object flags. Remember that post about spawning random characters? It’s the same basic approach with objects.

Every object in the game has the following flags, which are stored in the WIFlags class.

  • Base Rarity – Common, Uncommon, Rare, Exclusive
  • Wealth – Poor, Middle Class, Wealthy, Aristocracy
  • Alignment – Erasthai, Zenonia, Strata, Bislan, SleepingGod
  • Occupation – Guild, Aristocracy, Priest, Soldier, etc.
  • Region – Benneton, etc.
  • Subject – Business, Personal, Utilitarian, Skill, Scripture, SubjectAgriculture, SubjectArchaeology, SubjectBiology, etc.
  • Faction – Settler, Warlock

All but Base Rarity are implemented using the FlagSet class (also mentioned in the characters post) so these are just integer bitmasks with names attached to make them more human-readable.

Each object also has some basic properties that are used to determine if an object will fit in a container when spawning, or if it’s made of an appropriate material.

  • Weight – Weightless, Light, Medium, Heavy, Unliftable
  • Size – Tiny, Small, Medium, Large, Huge
  • MaterialType – Dirt , Stone, Wood, Metal , Flesh, Glass, Liquid , Fabric, Fire, Ice, Bone, Plant
  • CurrencyType – A_Bronze, B_Silver, C_Gold, D_Luminite, E_Warlock
  • BaseCurrencyValue – (0 – x)

Some objects extend the WIFlags class. Books use the WIBookFlags class, which adds the following:

  • SkillSubject – Crafting, Guild, Magic, etc.

So the first step is to go through every object in the game – that’s 785 objects not including individual plant species, books or prepared food variations – and set their flags. This takes a long, long time.


Once all the flags are set the next step is to categorize these objects. This is done using WICategories, which is just a list of objects & spawn probabilities paired with a name. Eg, the ‘KitchenUtensils‘ category might list ‘Frying Pan, Fork, Knife, Plate, Cup, Goblet’ etc. This may seem unnecessary given that objects already have flags, but context can tie together objects in strange ways that flags can’t really describe (at least not without tons more flags). Put another way: Categories describe where you find objects while flags describe what’s true about an object regardless of where it’s found. (Clear as mud? Good.)

They’re also useful for lumping together specific kinds of objects. Instead of creating a ‘Table‘ flag – which would only be used for a dozen or so objects at most – I just throw every table variety into a single category called ‘Tables.’ Of course tables can show up in other categories too, like ‘LargeFurniture‘ or ‘DiningRoomFurniture.’ Categories can be as granular as you please. Some contain hundreds of objects, others contain only three or four.

As you can imagine, adding items to categories takes at least as long as setting flags. And I’m constantly creating new categories as I build out the world.


Between categories and flags we have a pretty thorough description of what an item is and where it ought to be found. This information is used by containers. Containers are objects like chests, bookshelves, barrels, tabletops – anything that can contain other items. This doesn’t mean the items have to be hidden from view – in the case of bookshelves and tabletops the stuff that’s ‘in’ the container is in plain view.

If I want a container to spawn objects I attach the FillStackContainer script to it. This script has a couple of different settings. One lets me specify exactly which items will go in the container – useful for quest items and the like. Another lets me specify a category of items, plus a range of total items. A third lets me specify a category, range AND flags for filtering which items can appear. Two barrels can both use the ‘FoodStuff‘ category to fill themselves, but a barrel using the ‘MiddleClass‘ wealth flag may fill itself with tomatoes and parsnips while a barrel using the ‘Poor‘ wealth flag may fill itself with potatoes.

For containers whose objects are hidden from view this script will fill the container the first time the player opens it. Otherwise it will fill the container the moment it becomes visible.

This script will also re-fill containers after a specified interval. By default this setting looks to whether the structure housing the container has an owner (and whether the owner is NOT the player). If it has an owner it will periodically refill the container – the logic being that if somebody lives in the structure their dining room table will eventually be filled with plates and food again even if you’ve raided the place. There are cases where I’d want a container to re-fill regardless (eg a beehive filling with honey) so I can override this if I like.

When I’m editing a structure in Unity I simply place containers where I want them to appear in the game – wine barrels in the kitchen, chests of gold in the attic, etc. The flags specified in the FillStackContainer script are added to the flags specified in the structure. If no flags are specified then the structure flags will be used exclusively.

And as I discussed in the character spawning posts, structure flags are mixed and matched with city flags, chunk flags, and so on. The result is that a middle-class barrel filled in Riverbog might be full of mushrooms while a middle-class barrel filled in Apple Valley might be filled with Apples, even though the FillStackContainer script uses the same settings in both cases.

Structure Templates

Things get a little weird when I’m using the same structure template for two different structures. A structure template is like a blueprint for the structure – it tells the game where to put walls, ceilings, characters and items. It also tells what materials to use for each part of the structure. What it doesn’t specify is flags – that’s the job of the structure using the template.

There are over a hundred structure templates, but there are many more times that number of actual structures in the game. So in many cases I’m using the same structure template for multiple buildings. Some variation would be nice in those cases. We’ve already got some when filling containers, but what about the containers themselves? What if I use the same structure template in a poor neighborhood and a rich neighborhood? If the blueprint just calls for four walls, a roof and a floor, the furnishings and materials can mean the difference between a nasty-looking shack in a bad neighborhood and cute little lakeside cabin in a nice neighborhood. But if the furnishings are the same in both cases that’s going to look a little strange.

The solution is world item placeholders. These are similar to containers, but instead of containing objects they just spawn a single object. If I know a structure template will be used once I can drop in a specific bed or chair and arrange it just so. But if I suspect it will be used multiple times I’ll drop in a placeholder and tell it to spawn something from the ‘Chairs‘ or ‘Tables‘ category. When the structure is built the structure builder looks at these placeholders, then pulls an object from the category based on the placeholder/structure/city/regional flags. So in a nice neighborhood that bedroom will have silk sheets and the chest a the foot of the bed will be gold plated, and in a bad neighborhood the bed will have burlap and the chest will have spikes.

But this is only a partial solution. When I don’t use placeholders I have a great deal of control over the FillStackContainer script. I can tell a barrel spawned in the kitchen to spawn kitchen-related goods. But if I spawn that barrel at runtime, even if it matches the flagset of the spawner, it will fill itself with items from the default ‘CommonItems’ category. Sure it inherits some information from the structure’s flags, and that helps, but we’ve lost the fine-tuning. I’m working on ways to fix this.


If we were in single-player land I’d make spawning purely random. (Or near enough, anyway – results would be weighted by rarity.) But since this is a multiplayer game spawning has to be reproducible, meaning that the same container spawning on two separate computers has to spawn the same items in the same order. Otherwise the server would have to be solely responsible for spawning objects / distributing that information to every other player – laborious, slow and prone to error.

So instead of using System.Random with the current time as salt to pull a random index from a WICategory, or something along those lines, I pre-generate a lookup table in each WICategory:

Objects in category: [A],[B],[C],[D],[E]
Lookup table: [4],[0],[0],[2],[4],[0],[3],[4],[0],[1],[1],[1]

Each entry is an index for the objects array. The number of times that index shows up in the table is determined by its rarity. The lookup table is generated in order, then shuffled using a function that accepts a System.Random. To ensure the shuffling is always the same, I use the hashcode of the category name as salt.

You might think that’s enough – each time I ask for an object from that category it just sends the next index in the lookup table – but because we can’t guarantee that the same containers will ask for objects in the same order we need to go a little further. (Plus, a repeating linear sequence of random numbers eventually starts feeling stale. I was surprised at how quickly I noticed repeating patterns on bookshelves and the like.)

To make sure request order isn’t an issue – and to avoid noticeable patterns – I generate a third table. This time each entry is an index for the lookup table, and it includes each index [x] times. (So far x is 3; that seems to work.)

Random index table: [5],[11],[10],[0],[5], etc.

Then when containers request an item from the category, they’re required to pass a hashcode and an index along with it. This is used to determine where to start looking in the random index table:

Code: Select all
public bool GetWorldItem (WIFlags flags, int hashCode, int index, out WorldItem worlditem)

int randomIndex = (Mathf.Abs (hashCode) + index) % RandomIndexTable.Length;
int itemIndex = RandomIndexTable [randomIndex];


In 99% of cases categories are used in a loop, so there’s usually a unique index handy. If we’re just pulling one item 0 obviously works fine. As for the hashcode, the full path of the WorldItem making the call is guaranteed to be unique, so I typically use the hashcode for that string. But it doesn’t really matter what I send to the function as long as a) it’s relatively unique and b) it’s always consistent.

Add this all together and you get a stream of items that looks totally random, but ends up being exactly the same each time you do it.

To-Do List:

World Seeds – It would be nice if a single number (derived from the character’s name, say) could influence every other element of randomization a la Minecraft. I haven’t quite figured out where to put that yet.

Flag-based materials – Earlier I talked about swapping out materials in a structure template based on flags. This works for items but not for the components that make up the actual structure – floors, walls, etc. I can already swap materials manually so tying it to flags shouldn’t be difficult.

Restore the ability to fine-tune – Using placeholders in structure templates is useful as hell but I need a way to control the containers that are spawned at runtime. This is currently my top priority.

Read more here: 5/23/2014 – Randomization

5/8/2014 – Deadlines


There’s been a lot of chatter about release dates, not just in the forums but everywhere. (I got 3 chats in the past hour alone!) I figure some sort of official-ish response is in order. I’ve said a lot of this elsewhere but this is me putting it all in one place for easy reference.

Will the game be delivered end of Q2 2014?

Maybe. I have no idea. Here’s why:

Back up a year or so. After Kickstarter I thought I was going to be a badass when it came to project deadlines. You’ll find I don’t brag often, but I’ll brag my mismatched socks off when it comes to work ethic and self discipline. My level of devotion to a project is unusual even among fellow workaholics. I simply do not stop. I’ve never missed a deadline professionally, not even on the really crazy jobs.

So with all that under my belt I figured I’d waltz onto the indie scene and show folks how it was done. Okay maybe not quite that dramatic, but I was pretty sure I’d beat par. Lots of people (especially other devs) warned me that deadlines would slip, and that it might be wise to avoid announcements, but whatever – there’s always someone saying I can’t do such-and-such and they’re usually wrong. So I ignored advice on this particular point.

Well, they were right. Don’t ask me how because I still don’t know – it could just be lack of experience in this industry, or maybe it’s something intrinsic to the industry itself, or maybe it’s just karma for murdering all those poor innocent deadlines in the past – but I haven’t made a single major development deadline on this project since the Kickstarter ended. Doesn’t matter whether it was internal or publicly announced. Sometimes I’ve been a week late, other times several months. Anything farther out than a day and I might as well be using a magic 8 ball. You can imagine how much this gets under my skin. Then again, maybe you can’t.

So the only true answer to the Q2 2014 question is: No idea. It doesn’t seem impossible, and I’m going to be as pragmatic and disciplined and brutally realistic as always, but if it happens it’ll be less well-planned inevitability than glorious surprise. I’ve (sort of) come to terms with the fact I’m not directly in control of when this game will be finished. It’s a little like white water rafting. There’s no question that I’ll reach the end, but when that happens is up to the river – my level of control is limited to avoiding rocks and not tipping over.

When is the beta coming? When are more screenshots coming? What about more gameplay footage? When will [x] be finished? When will you send out [z]?

Again, no idea. On the next full moon. On Friday. Christmas. Thanksgiving. Pick a day, any day. All these things will happen – that much I’m certain of at this point – but beyond that? We’re all bouncing in the same roulette wheel and I won’t insult you by pretending to know where we’ll land.

Just to be clear, this isn’t my way of telling you to stop asking. Keep asking, I don’t mind, really. The fact that I don’t HAVE an answer may get under my type A skin, but the fact that you all WANT an answer? That does exactly the opposite. I love knowing that people give a damn. Just be prepared to hear ‘I have no idea’ each time you ask, because that’ll be my go-to response from now until whenever it’s done.

All that said, I’m going to keep the end of Q2 2014 deadline in place on Steam and in the videos because as far as I know it’s not bullshit and it may actually happen. If I get to a point where that no longer feels true I’ll ditch it in favor of ‘when it’s done.’

Read more here: 5/8/2014 – Deadlines

4/24/2014 – E̶a̶r̶l̶y̶ ̶A̶c̶c̶e̶s̶s̶ ̶(̶?̶) Preorders!


Just posted a KS update about preorders vs. early access. Thanks for the feedback earlier – I feel much better about this option.

If you know anyone who wants to support us you can send them to the main site, or you can embed our Humble widget:

Code: Select all

I’ll make an announcement post for visibility and I’ll be posting to Greenlight as well. Really curious to see how this goes… *crosses fingers*

Read more here: 4/24/2014 – E̶a̶r̶l̶y̶ ̶A̶c̶c̶e̶s̶s̶ ̶(̶?̶) Preorders!



I only have a moment but there have been some good developments and I want to share them.

First off – I’m going to go with preorders (via Humble) instead of Early Access for the time being. I was going to wait for the setup process to be completed before announcing this. But it’s taking longer than expected so I figured I’d end the suspense. Lots more on that in an upcoming post.

Secondly, the texture situation I bemoaned in the latest KS update is now firmly under control. Not totally solved – but under control.

Lastly, the game is really coming together. It’s not just a sluggish tech demo like the pre-alpha, or a walking simulator like the alpha, or a lose collection of unrelated apps (as I’ve taken to calling later builds), but a real honest-to-goodness game. Very exciting. The beta inches ever closer.

Read more here: 4/23/2014

4/17/2014 – Early Access (?)


$157k might sound like a lot, but in reality FRONTIERS has a teensy tiny budget for what I’m attempting to accomplish with it, especially when you consider how much of it is lost to fees and to the tax man. When I crunch the numbers it still looks like we’ll cross the finish line before the tank’s empty, but we’ll definitely be running on fumes, and I don’t like close finishes. What if I get sick? What if translations take longer than expected? I want more money in the bank in case things don’t go as planned.

By now you all know I’m strongly against running another Kickstarter campaign to raise more money. The idea just seems gross to me – you’ve already supported the game, so running another campaign feels like using the sunk cost of your first pledge as ransom for more. (Isn’t there a name for that kind of scam?)

But now that we’ve been greenlit, there’s another option: early access. The problem is that early access is gross in its own way.

While I see nothing wrong with the idea in principle, I’m not convinced that the system isn’t hurting the games industry as a whole in practice. And while the idea of early access for FRONTIERS doesn’t give me the same gross feeling as running another Kickstarter, charging random Steam people for the game in its current state still feels shady. Assuming I did it, the next question is how? How would I offer FRONTIERS on early access and keep it fair, not only to newcomers but to KS backers? Is it even possible? That’s not an easy question to answer.

The first ethical hurdle is price. I’m selling the game for $15. So naturally I’d offer early access for $15 or less, right? Say $5, since it’s unfinished? Nope. That might please the average Steam customer, but it would also undercut the backers who pledged for beta support. They paid $25, so if I’m going to be remotely fair that’s what I’d have to charge for early access. Of course this is an unfortunate case where fairness has disadvantages. $25 will seem high to anyone unfamiliar with the reasoning behind the pricing AND the drop in price on final release may leave them feeling burned. Plenty will write it off as a money grab.

That leads to the second hurdle: motivation. Let’s not kid ourselves – it would be a money grab, more or less. In my case the only reason to go on early access is for money. I could feed everyone a line about opening it up for valuable playtesting and feedback, which is what early access was created for, but the backers who pledged for beta access will already provide that. That’s not to say I wouldn’t find Steam feedback valuable – hell, maybe would be transformative. But the bottom line is that if you had asked me six months ago whether I’d consider it, I would have said ‘no thanks.’ (It would be convenient to forget that, but I won’t.) That being the case, should I really be taking advantage of the system? I’m not sure.

Third hurdle: when does it end? Something I do not like about early access is the way a game can remain in that section forever. Developers can get away with charging near-full-price for an ongoing beta for years, and when they’re called out on the bugs and missing features they fall back on ‘hey we’re early access, what do you expect?’ I’m referring to a non-existent worst-case-scenario composite developer of course – the realities are a lot more complex. But the problem of developers hanging out on early access while never delivering a final product is a real one.

Okay, set the ethical stuff aside. What about the fact that I’d no longer be dealing almost exclusively with backers? Steam is huge. HUGE. I’ve always known this, but Greenlight showed me just how bloody huge it is. I’m not sure I’m ready to dilute the FRONTIERS support base yet. Everyone following the project is so positive and helpful, and I suspect that’s because they sought FRONTIERS out and not the other way around. What happens when FRONTIERS starts popping up on the Steam front page? That kind of attention is inevitable – and when the game is done, it will be most welcome! But now? I’m not so sure. (That could just be my inner critic screaming that they’ll hate it, though I’m less worried about first impressions than I used to be. The game has come a long way since the last alpha and while it still has its problems, it’s shaping up into something enjoyable.)

So yeah, not an easy question to answer.

Here’s what would need to happen at a minimum.

  • Ask Steam to keep FRONTIERS off the main page regardless of popularity or interest. (I don’t think early access games should be on the main page anyway.) Save that exposure for the final release and spare casual players as much temptation as possible.
  • Do research and get feedback. Find out how early access has burned players, then try to avoid those pitfalls.
  • Create a document outlining what features exist now vs. what features are planned, then put it front-and-center on the early access page. Many early access games already go beyond the required ‘it’s not finished’ statement, but many still don’t go nearly far enough. People need to know exactly what they’re getting into.
  • Impose a highly visible, well-publicized time limit on how long FRONTIERS will remain available on early access. Something like 3-6 months.
  • Don’t let the money get to me. I only need a trickle to finish the game, not a flood.

I just read over this entry and despite all the hand-wringing it sounds like I’ve pretty much made a decision – but I’m going to hold off on making it official until I do my research and hear back from you guys. Maybe someone will talk me out of it.

Read more here: 4/17/2014 – Early Access (?)

3/17/2014 – Beginning of the End


The endgame has begun – the focus has shifted from ‘let’s experiment with gameplay and environments‘ to ‘we need to lock this shit down yesterday.’ Possibilities are whittled down to actualities every day now. More and more content is getting cut to fit everything into the schedule. (Don’t worry, it’s still nothing you’ll miss – though that buffer is nearly gone.)

My immediate goals are to finish the beta, get the game on Steam / GOG / Humble Bundle (I will definitely be using Steam to distribute the beta, so a Steam Greenlight campaign will be launching shortly), then use the beta feedback to tweak the game until it’s ready for the general public. And this all has to happen in three months, four tops.

This is the stage where things get really, really difficult. It’s been challenging up until this point, of course, but the margin for error was forgiving and I took advantage of that. Over the next few months I will have to expertly balance PR, development, business and personal life / health leading up to the game’s release and a major slip-up in any one of those categories could sink the project. This is it. The plates start spinning now.

I’m a big believer in acknowledging the possibility of failure. Failure hides in the corners of every large project waiting to slip a poisoned blade between the ribs of an overconfident project leader. This project has to look especially enticing – first-time developer, ambitious design, low budget, epic scale. But acknowledging the possibility of defeat doesn’t mean accepting defeat as inevitable, any more than looking both ways before crossing the road means accepting death by semi as inevitable. I get paranoid when I don’t see failure sneaking up on me, because that means that I’m either kidding myself (or, even worse, that I haven’t challenged myself.)

Expect fewer devlogs from now on. When I do post they’ll be dense and important.

Read more here: 3/17/2014 – Beginning of the End



I thought you might be interested in a count of raw submissions for each kit type:

  • Early Book Kit: 21 (leveled off)
  • Final Book Kit: 56 (still seeing new submissions)
  • Master Chef Recipe Kit: 117 (leveled off)
  • Plant Creator Kit: 185 (leveled off)
  • NPC Creator Kit: 21 (still seeing new submissions)
  • Coat of Arms Kit: 14 (leveled off)
  • Engineer Structure Kit: 7 (still seeing new submissions)

The Plant Creator kit for Botanists is by far the most popular, but the book kit is catching up really quickly. There was a small trickle of submissions for the first two days and then it jumped to 20-25 submissions a day with no sign of slowing down. I’ve only checked a small handful to make sure the kit was working properly (it is) so I can’t speak to how good they are yet, but I’m optimistic.

I’m actually a little stunned by how popular the plant kit was. I was prepared for ~300+ submissions but I was expecting more like 50-70. The good news is there’s far less redundancy than you’d expect. I’ve only got 11 plants marked down for potential merging so far. (If multiple plants have the same visual/edible/medicinal etc. properties but have different names then I want to turn them all into the same plant, just with a variety of local names. I’ll be contacting and securing permission from each backer to do this so don’t worry about your plant disappearing without notice.)

Exactly how all these plants will fit into gameplay remains to be seen, but back when I offered the kit I knew that it would be very different than the standard ‘memorize the appearance and properties of 5 kinds of plants’ that you see in a lot of survival games. I’m excited by the idea of a game world that actually has some biodiversity. If you’re dumped into some random forest there will be hundreds of species of plants that could either fill your belly or kill you (or make you hallucinate!), and there’s no way to tell which it will be just by eyeballing them. In the real world you’d have to rely on a field manual – in FRONTIERS it’s going to be the Examine skill. Anyway, really looking forward to getting them all imported.

There’s also surprisingly little redundancy in the recipes. Everyone wisely assumed that the basics would be handled by someone else so nearly every submission is unique. Of course redundancy in recipes isn’t nearly as problematic as it is with plants, so provided the ingredients and arrangement of ingredients don’t conflict I don’t mind including a few subtle variations.

Read more here: 3/5/2014