Supply yards

For the purposes of this exercise, let's agree that a large part of Castle Story has to do with building things. If we do this, it brings up two points inherent in any construction site - material transportation and construction cranes. I believe Castle Story can use both, but let's go over them one at a time.

Any real construction site needs a material stockpile in close proximity to it, but right now, this is impossible to do. There's no way to move materials out of stockpiles unless you're building with them, which means your workers spend most of their time walking back and forth between your material yard and your building site, which may not necessarily be close by to each other. I suggest implementing some kind of system to move materials to a construction site in bulk, or at least specifically, allowing the relocation of materials from one stockpile to another.

But because this has to be an automated process, we can't do it stockpile by stockpile. To remedy this, I suggest implementing the concept of a "supply yard." This entails highlighting an area of the world and marking the whole thing as a "supply yard." This gives you a unified system to track the amount of resources in the entire yard as a single counter, as well as issue move orders globally. Say I've built four rows of 12 stockpiles for a total of 48. 40 of those hold stone, 8 of them hold wood, and they're all full. If I define the whole area as a supply yard, then click on the supply yard, it would tell me I have 160 stone blocks and 32 logs. I can then click "Transfer" and order that 100 stone blocks be transported to another supply yard closer to my newer construction site that I've just now set up.

Alternately, I can "request" materials. Say I'm going to be constructing a large building and I need 180 stone blocks for it. I don't have a single supply yard with enough stones for that. I COULD just ask for transportation from all the other ones and do the mental math, or I can click on the supply yard I need filled up and click "Request," then select 180 blocks. These would then be delivered to that particular supply yard from anywhere the Bricktrons can find, provided it can actually hold 180 blocks. If the whole of the "kingdom" doesn't have that much in its supply yards, or there are multiple yards requesting the same limited supplies, the one with the highest "priority" gets them first, which would be a tag assigned to the yard itself.

OK, so what will I need to create a building? How do I know I need 180 stones and not, say, just 50? Should I count them by hand? Well, not necessarily. The developers have talked about turning entire buildings into set-pitece blueprints. I'd say use this, and have the game give us the numbers for the whole building. Say I make two-storey 8x8 tower with a turreted roof in blueprint, then I enclose the whole thing in a box and say "You are Building 1." The game should then be able to keep track of the materials needed to make the blueprint a reality, and I would thus know what's needed to make it, meaning I'd know what the nearby supply yard should request.

In fact, I'd go as far as to say that a building site like this should be able to be connected to a supply yard directly, telling the builders to only ever take materials for the building from THAT yard. This could then let the building track how much resources it needs vs. how much there are in the "linked" supply yard. It would, then, let us know if it has insufficient materials and better tell us just how much it will still need.

This brings me to my final point - haulers. Suppose we allow Bricktrons to just move things from supply yard to supply yard. There'd have to be someone doing this, right? Well, that brings us to a new job type - the Hauler Bricktron. Whenever a supply yard issues a "move" or "request" order, it creates the hook for a job that Bricktrons can be assigned to. These Brictrons will do NOTHING else but move supplies. Either they'll specifically move them from one supply yard to another as requested, or they'll scour supply yards and look for the resources another is requesting. And to avoid confusing, when a supply yard issues a "move" order, then count all supplies tagged to be moved as existing in the destination yard so you don't end up with a yard being emptied of supplies it was supposed to move.

Actually, let's talk about overfill. One of the biggest problems in mining is filling up your supply yard and forcing your diggers to travel to another one AAALL the way across the map. Instead, I'd suggest setting up supply yards with "overfill" settings, such that if it fills up to, say, 80%, it would issue an "overfill" order and have Bricktrons move materials out of that yard and into another, prioritising yards actually requesting the materials being moved out. I'd say "overfill" should be a single, global job that exists at all times. Bricktrons assigned to it will be notified of overfill warnings in any designated supply yard without them having to be assigned to that yard in particular, though I don't see why yard-specific jobs can't be assigned in addition to this if you're worried about a specific one.

---

A game like Castle Story has potential for great enjoyment, but also great frustration if we end up having to fiddle with low-level Bricktron management. To my eyes, the more automation the game has in the process of resource management - i.e. the less I have to worry about individual stone blocks and stockpile squares - the better the game will flow. The whole point here is to let the player focus on building structures and training soldiers, rather than command-moving Bricktrons around the map. And it's not like the game does everything on its own - the player still has to set up the hooks for the automation, but it should allow us to think on a larger scale.

Rather than thinking about which Bricktron goes where and how far each log is, I get to think about what I want to build, how much it will cost and how long it'll take to transport the materials here, as well as to build it. That's important, because the bigger the player can think, the bigger the game will feel. To me, that's what'll make or break it, eventually.

Indeed, zoning is a very good way of allowing a player to create complicated tasks easily. You should be able to create all kinds of zones, from supply zones to pathfinding zones, but that is for another post.

I would also like to have the ability to set prioritize stockpiles so that bricktrons will fill up stockpiles in a specific order and allowing bricktrons to walk over empty stockpiles. You could then build continuous stockpile areas(Once the stuck bricktrons bug is fixed) and not worry about the bricktrons "building" walls of materials that block or extend the route to stockpile tiles further back. You also need to be able to select a group of stockpiles to set their acceptance options, as well as all the stockpiles within a certain zone.

Actually, I think we can be cheeky and NOT fix the AI issue of Bricktrons dumping resources all over the place. Instead, if we go with supply yard zoning, we can simply task Bricktrons to sort supply yards, moving materials from half-filled stockpiles to other half-filled ones and thus condensing the materials. They can even do this with gravel in boxes before they've filled into blocks. I like automation, but I enjoy seeing the game display it, and having essentially a warehouse worked making sure everything is stacked right would be a great boon. Also, even if Bricktrons were to always put stuff in half-filled stacks over empty ones and only take from half-empty ones, you'll still end up with odd-stacked ones unless you have a person responsible for rearranging them.

Actually, if we go with the supply yard zoning concept and we make barrels stored on supply stacks, we can automate the warehouse worker to not just rearrange materials, but also go to the crystal and empty the barrels, then bring them back to the yard without me having to order him every step of the way. It's easier than putting barrels right next to the crystal, after all.

I keep bringing up the Settlers in other threads, and there's a reason for that - that game handled material transportation better than most by having many steps of delegation. Rather than have a worker do everything, material would be moved from point to point, with a chain of workers handing material to each other. That way, resource gatherers could spend all their time gathering and leave their produce at their own doorsteps, haulers would take it to the warehouse, then haulers would take it to the build site where it's needed, then workers could stick to their own building site and spend all their time working, instead of worrying about materials.

Delegation of responsibilities is key, in my eyes.

I was referring to the bricktrons getting stuck in stockpiles if you build them close together, not the AI.

So, what I meant was that if I have a 6x6 grid of stockpiles and make that a supply zone I can also prioritize the stockpiles so that bricktrons will fill the high priority ones first. I can then, for instance, prioritize the 6x row furthest back above all others, so that the bricktrons will fill that first, and when full they will start filling the one in front of that one, and so on.

If the AI was left to its own devices it would just fill the front row first and would then have to run around all of those supplies to fill up stockpiles behind the wall of supplies.

Actually, the more I think about it, the more I think we need a "smarter" solution than to try and rely on how smart the Bricktrons are. To this effect, I'd like you to follow me on a quick hypothetical situation for a moment.

Suppose resource stacks don't just come in single 2x2 plates, but instead just start 2x2 and can be extended. You know how you build tunnels? You click a side, that side extends one step. You click another side, that side extends one step. Suppose we did the same with a basic resource stack? If you want to have a 6x6 grid of stockpiles, you wouldn't have to build 9 separate stockpiles, you could just build one and extend it twice in both directions.

Then, once you have this large stockpile, any Bricktron can deposit items to it from the stockpile's edge regardless of where there is free space on the stockpile, and any Bricktron can pull any brick from the stockpile's edge regardless of where that brick is on the actual stockpile. Essentially, this would act like one huge stockpile that can just hold lots of stuff. This large stockpile would be able to stock stone on top of wood on top of stone with no need to be only one or the other. If a Bricktron needs to pull a log that's supporting stones above, the entire stack would shift one brick down automatically as though someone went in and rearranged it.

Here's something else clever - if you make the stockpile big enough, it starts being able to hold more than two levels of stuff. Say we institute the following rule: Any stickpile larger than 3x3 stacks (6x6 blocks) and with a land area of at least 12 stacks (48 blocks) becomes able to store materials up to four levels high, up double from the two levels it starts off with. Make it even bigger, say at least 4x4 stacks and at least 24 stacks in area and it goes up to 6 blocks of stuff.

Why I suggest this is it gives us an economy of scale. One of the biggest problems is how fast stockpile groups fill up and how little gain you get for expanding them. Basically, it's a linear gain - one more stockpile holds 4 more items. With this, you can actually start to double and triple the storage space your building and REALLY save on ground footprint in the long run, but to do so you'd end up needing a LOOOT of flat ground to build on. 24 stacks is 96 blocks of land space, all in one giant rectangle that's at least 8 wide in every direction. That's a lot of ground space to devote to just stockpiling supplies, sure, but you'd need three times the stacks to hold it with just smaller ones. Again - an economy of scale, plus it's a good way to build "up" instead of sprawling "out," which is important with the smaller land area of the floating islands and the craptons of rock produced in gaining more flat ground.

---

I envision a larger castle having a single MASSIVE stockpile three or even four times as high as a normal one, housed in a giant warehouse or yard, from which resources are transported to smaller stockpiles nearer to construction sites, and TO which resources are transported from smaller stockpiles near mining and logging sites. Again, this goes with my idea of delegating transportation to a separate type of Bricktron that isn't involved in producing or using the resources.

I should probably point out that the dev's have specifically stated that you will not be able to store an entire building as a prefab. You may only be able to store that tower on a level by level basis, basically having a tower level with stairs and a door, stairs and no doors, and then a top level. I am guessing that the limits placed on a prefab will be based on block count, so you may only be able to save 50 or so blocks in a single prefab.

There is no "we" relying on how smart the Bricktrons are, I have specifically said that I wish to manually input behavioral instructions within certain zones precisely because I don't want to be restricted by the limitations of AI programming.

As for the rest of your post, I think you're just complicating one part of the process and diluting another.

First off, if you want several levels of storage you should build that(Although I could see being able to double the current stockpile height to allow for 8 units per stockpile), this is a part of the challenge, a part of the construction side of the game, coming up with effective designs for things like storage. Implementing in-built solutions simply makes the game more shallow. Additionally, you are creating a single "solution" for a specific "problem" instead of utilizing broader game mechanics such as zones and physical size.

As for dilution, allowing supplies to "magically" jump around in the storage area without actual Bricktron interaction is not a good thing. People will find ways to abuse it, it will narrow the logistical and economic side of the game, and it's simply a "solution" to an inconvenience, not a real design issue. Not having to consider the proportions of your supply area, not having to consider the logistical issues involved in your rate of resource extraction, creating tasks that require no manpower(Automatic shifting of storage inventory), potentially accessing the same supplies from multiple points on the map, etc.

The implications of your latest suggestion I fear would only serve to limit the potential of the game. Your initial suggestion, involving zones that the player can define, is far superior.

I do not like the idea of zoning, however i would have nothing against grouping stockpiles into a large logical stockpile or supply yard. I also support bills started suggestion of stockpiles not being discrete. Just make it so you can walk over unused stockpiles then have them defined with click and drag. ( i would limit it to 3x3 version of the current stockpile) I do not want to have to leave bricktrons to just act as warehouse workers, however having a carting activity would be fine. (mine stockpiles to castle stockpiles)
Just a note, the only problem with higher stacking of resources is the current box filling and creation of resources.

I think that some of what is being suggested here is getting a bit too complex for the needs of castle story though.

If you want any kind of complex behavior you will have to define areas in which you can further define the complex behavior. For instance, if you have a two wide staircase that sees a lot of traffic then it would be nice to zone that staircase and only allow traffic in one direction on each side of the staircase. If you want bricktrons to navigate a complex structure in an effective manner then it will be helpful to zone it and provide a set of rules for their behavior. If you don't want to use zoning then don't use it, but being against something simply because you find it hard to understand is not a very helpful thing.

Do you have any way to talk which is not set on insulting?

I would, as i said, avoid zoning. I could zone a stairway and force up traffic on one side, and down traffic on the other. However this will halve the number of people using the stairs at one time if you have people moving in a single direction mostly. I would instead implement a standard movement principle within the bricktrons path finding to make them default to certain behaviours. This way you could have them always default to using the left hand route if there is adjacent staircases.

In summary, i would prefer the instil the intelligence in the bricktrons rather then having to define every single stair i build as to which way you can move on it.

The tiniest of things can often have a huge impact. But the main thing is that there is no need for the "solution". If a bricktron wants something from a stockpile he should go pick it up, there is nothing in this process which would require him to be able to access it from any other place than the actual physical location of the item being picked up. You have this design concept where bricktrons and resources physically interact throughout the game, but then suddenly there is a departure from this design for no apparent reason.

I can't yet see all the possible ramifications of such a feature, but it's these things that people always think are just harmless, small, inconsequential things, and then people find ways of abusing them, undermining vast portions of the game. For that reason you simply shouldn't add things that aren't necessary.

It's easy to say that you want to "instill intelligence in the bricktrons" if you don't have much knowledge of AI programming. There isn't a single AI in the world capable of performing complex tasks in a functional manner, or one capable of innovation. It's why game AIs cheat, and why they are still easily beaten. You simply can't rely on the AI for complex behavior.

Nobody's saying that the AI should be downgraded instead of a zoning system. What adding a zoning system will do is allow complex behavior in the game when the AI eventually fails to accomplish tasks in an acceptable manner.

If stair traffic was generally going in one direction then you wouldn't zone the stairs, would you? You're simply creating problems where none exists.

And when the default behavior falls short? What then? AI is, as stated, woefully inadequate at accomodating complex behavior. You are simply opposed to zoning for irrational reasons, your objections show that much.

This is off topic and will be my last movement based response.

And i never implied anyone was suggesting the AI should be downgraded. Do AI's have issues when attempting complex tasks, yes, but that does not mean that bricktron path finding cannot be optimised to the point of not needing movement zones. Also, you are overlooking the fact that a zoning system relies on the path finding algorithm to function and increases its complexity.

Your missing my point, movement is a complex and dynamic aspect of the game. A double staircase during building can have all units going one direction in a group(flood), or a constant trickle of units going one direction, or a mixture of units going up and down at either rate. You can force a zone onto each stairway meaning that there will always be a way up and down. However if you end up with a flood of units going in one direction you can never take advantage of the full width of your stairs.
Also, you suddenly get attacked. Do you then manually go through and switch stair modes to free flow while defending? If you don't you may try to retreat up your stairs but your big bulk of soldiers gets bottlenecked at the bottom trying to go up a single stair while your enemy just goes up the second flight and stabs you. What if your dedicated stair gets blocked somehow and you dont notice? Your bricktrons then take a long slow way or get completely stuck. Zones are not a perfect solution to movement control either.
Also, unless you fully define your castle with movement zones you will have the same problem with units clumping and getting confused at either end of your stairway/hallway/corridor or whatever.

AI's are not good at complex behaviour, however i would argue that neither are human builders. If you send 20 builders into the same location they will all get in each others way and only a few of them will be able to progress at a time. As such, if you have too many bricktrons using a single route and getting congested, maybe you are doing something wrong with your castle design. Instead, use two or more building groups and distribute your workers around more evenly.

As a final note, movement in restricted circumstances such as stairways is far from complex for an AI. Moving large volumes through a moderate sized passageways is much harder as it can no longer be control by simple rules of movement.

As far as I'm concerned, "zoning" needs to happen because the player needs some way of macro control over his recources. I need to know I have, say, 50 stone blocks and the building I just blueprinted needs 80 BEFORE I run out of stones. People keep saying Castle Story is an RTS, but in an RTS, you have a readout of your resources and a cost for each building. Even if we break this down into Castle Story's "single block" building process, I need to know if I can afford to lay the blocks I'm laying. You can't expect the player to simply count stone blocks in his yards by eye, that's simply not good gameplay.

Additionally, Castle Story needs better resource organisation and delegation of labour. If you rely on Bricktrons to simply walk over and get the resources they need from wherever those may lie, you will end up with a very bad situation where your workers travel the map for a single stone block, wasting copious amounts of time. You will also realise, and very quickly, that you DO NOT WANT many people building the same building, because they jam each other up on walls and build out of order. At most, you want two or three people building a structure. But if your resources are too far away, you want 10 or 12 people working on it so they carry the resources to the site faster. Isn't it just logical to then split the jobs and have 10-12 people carry resources to a stockpile set up for exactly how many you'll need, then go off to log or mine or something, and leave just two or three people to use the resources and erect the actual building? That's division of labour.

As for large stockpiles, yes, my intention was to trade storage capacity for land area. As I said, larger stockpiles may hold several levels, but they take A LOT of flat ground to create. Seriously, a 4x6 stockpile takes up 8x12 blocks on the ground for nothing but storage. That's a lot, especially in a game with combat where you'll need to wall that in to protect from monsters. You can always build in multiples of smaller stickpiles and not waste space. And yes, I'd say limit them in length and width. This really isn't mandatory - I have no problem building warehouses on multiple floors for this time, sure, but that still takes zoning in order for me to treat an entire supply yard area as a single entity and be able to track what's in it across multiple small pads.

Basically, a Bricktron construction project that actually works needs more centralised oversight. You shouldn't force the player to fiddle with the lowest levels of micromanagement like counting stone blocks by eye or giving individual Bricktrons individual short orders. You need the player to establish a chain of automation such that you let him think about what he wants to do, not the baby steps of the logistics of how to do it on the most fiddly possible level. That'd be like creating a third person action game and requiring the player to control every single joint in his character's body manually. And yes, there was a game like that... I couldn't get my character to take a step without toppling over like a log.

Players, in my opinion, should be worrying about locations, defences, resource levels and overall structure design, NOT individual stone blocks or individual Bricktrons or individual flights of stairs. Because really, once you find yourself spending more time mired in micromanagement, the game has already failed because you're basically not playing it, you're trying to make it work.

We're talking about zones, not movement. It is not off topic at all.

Yes, you did when you said "In summary, i would prefer the instil the intelligence in the bricktrons rather then having to define every single stair i build as to which way you can move on it."

Zones are not a replacement for AI, they are an addition. You obviously do not understand what I'm saying as you think I said that you will use zones to control all bricktron movement, when what I actually said was that you should be able to modify bricktron behavior in areas where the AI is not capable of behaving in the required manner.

They can't be optimized for that because that entails being able to innovate solutions to new situations, something AI can't do. You are basing your argument on an unrealistic concept of how AIs work.

First of all, adding anything to the game "increases complexity", that is irrelevant. Secondly, no it doesn't. Again you misconstrue my statements and base your argument on an unrealistic concept of AIs.

Something an AI cannot accomplish on an acceptable level, hence zones.

First off, if you create a zone on a staircase that sees traffic contrary to how you've zoned it then you're the only one to blame. Second, zones apply only to those groups and/or individual bricktrons you decide, not necessarily every bricktron on the map.

Yes. If you think this is a problem then you're the only one with a problem. Just as you'll have to manually move worker bricktrons away from any fighting you also occasionally have to make the additional click here and there.

You don't have to have your soldiers obey the zoning rules, and you can just turn it off for the occasion. This is just you trying to force a problem again.

And what if both of the stairs get blocked? What then? I guess we'd all have to fall over and die at that point. Again you create problems that do not exist. And nobody said zones are the perfect solution to movement control, I said it was an addition to the AI pathfinding for situations in which it fails.

And another "problem" created by you where none exists. Movement zones, along with all zones, apply only to those you want them to apply to. Miners don't get confused about the lumberjacks' logging zone, and nobody's going to be confused about these zones either.

The deal, though, is that this is exactly the reason why people, builders included, actually create behavioral rules in just the way I'm suggesting. We don't simply allow people to make up their own traffic rules, we have a shared set of rules that apply to everyone so that traffic can flow safely and effectively.

Yes, they can get themselves out of a jam in restricted locations, but they can't avoid the initial jam and if more agents are involved they will suddenly find it very hard to get out of it.

In the end it's as simple as this; if you just want to rely on the AIs pathfinding then you're free to do that. If you want a deeper, more complex game you use zones. Everyone's happy.

Actually, here's something else: "Waypoint stockpiles." Let me explain what those are:

A "waypoint stockpile" is nothing more than a single regular stockpile that doesn't normally hold any materials. Instead, it can be "linked" to another waypoint stockpile or to a regular stockpile. Doing so will create a "job" that a single Bricktron can be assigned to. Once you have a whole chain of those linking two large supply yards, you can issue "transport" orders to move materials between the yards, and they will be moved up the "chain" of waypoint stockpiles. What I mean by this is the worker tasked to the link between the source stockpile and the first link will start carrying materials to the first waypoint stockpile. As soon as there's material in that, the worked tasked with the link between that and the next one will move it forward, then the next worker in the chain will move it forward and so on until the material ends up at the end node. This would create a supply chain that employs only as many workers as there are links in the chain, meaning you can transport, say, 50 stone blocks and 50 wood logs all in a steady trickle, rather than sending all of your haulers (or worse, your workers) on epic journeys.

What this also means is you can have relatively minor stockpiles at resource-gathering sites set up as temporary ones, linked to a larger central stockpile. That way, as workers deposit materials, haulers will immediately pick them up and send them back the chain to your central stockpile area. This removes the need to have large stockpiles at resource-gathering sites, especially for logging, yet also removes the need to have workers travel away from stockpiles, and it also removes the segmentation of resource stacks when you don't need to hold resources near to where they were mined for speed. It also makes sense that, if monsters are attacking, you wouldn't want your resources scattered around on undefended patches. You'll want to wall them up and protect them, or at least have them inside your keep.