Machinery

I'm going to start with a game comparison - does anyone remember Theme Hospital? Or, alternately, Evil Genius? Remember how those games went? In them, you'd define rooms that get separated by walls, and in these rooms, you can place "machines" that do something. For instance, you can define a room as a CAT scanner chamber, and in there you could but the actual CAT scanner, a control console for it, a little changing room for people to get undressed and so forth. Can we do something like that in Castle Story? You don't necessarily have to have the room definition specifically, even if we can go the Dungeon Keeper route of just marking a plot on the ground, but what about the actual machines?

Say we need a blacksmith - that'll take a forge, a grinding wheel and a water bucket, right? Say we want to have a more centralised location to spawn Bricktrons rather than the crystal way out in the wilderness. What if we could create some kind of device that would gather the blue crystals and spit out Bricktrons? We already have a catapult as a set-piece machine, why not more? Why not cranes or carts or a machine to produce energy of some sort?

And actually, why NOT define rooms via zoning? Why not define a 6x6 blacksmith and then wall that into a "house?" That way, you can create a "blacksmith job" and assign a Bricktron to it. Then every time you need weapons for your soldiers, you ask the Blacksmith job to make some, and the Bricktron goes and does it. I don't know how that'll work in the final game, of course, I'm just sayin'.

Generally speaking, I want the game's actual acting parts to be more than just stone blocks and wood beams. I'd like that to be just for support and superstructure, but for the actual forges, farm fields, beds or what have you to be actual specific world objects - things we actually put inside those buildings we create. After all, why ARE we constructing structures? Just to have soldiers stand on top of them? Why ARE we constructiong buildings with multiple floors if we have nothing to put in them?

There has been extensive discussion about this kind of thing in the past. The consensus boiled down to support for both "props" and "equipment".
Props being non interactive visual things such as decorations to make your buildings more unique and "you".
Equipment being all your things like forges, anvil, woodwork bench, etc.

I dont want to force you to have walls and a roof around the equipment, but i would define them into groups. This way you can have define all the equipment in a single area of your choice as a functional group to make certain things. I would also like to have environment effects such as rain stop usage if your silly and put them outside.

Yeah, yeah, definitely. Go with the Dungeon Keeper approach of just defining either a plot on the ground or a cubical space and let the player figure out how to "house" it. I'm just saying I want to have this functional machinery grouped up on "areas" so it's easier to control globally, rather than having to micromanage the use of every separate machine.

Yep, i agree completely with grouped items, i just want to stay away from defining areas on the ground. Let people have complete control over where things are and what they are near. There could be some things that have negative side effects on others, but i am not sure this is needed. This would mean you can optimise your set-up for what you make the most.

You still have complete control, kalric... You're the one defining the areas. Your objection is irrational.

I think the concern here is that defining a blacksmith on the ground might take up space the player may want to use for an armoury or a warehouse, and he'd rather have the items linked together without having to be in the same area. I do not disagree with this, interestingly enough. My main beef is that items are linked to function in unison as single items. That's why I'm so gung-ho about supply yards. Whether they're literally in the same defined square shouldn't be as important.

It's not as if the zones physically manifest themselves on the map, they are simply defined spaces so that the bricktrons know how, where, and what to interact with. The need for zones in relation to workspaces is so that dependent technologies can check for the required tools and equipment and to check that there is enough space to manufacture the mahcinery you want.

There are perfectly simple reasons why workspaces need to be defined, but that does not limit them in any way. Zones do not have to be a certain shape, do not need to be contiguous, do not exclude other zones or structures, they are simply checks for the game and defined areas for the bricktrons to relate to. They also allow for more complex instructions to be given in regards to build queues, supplies, worker management, etc.

It in no way detracts from your options, it simply provides more of them.

Zones is an overarching game mechanic, it is relevant in a lot of topics.

Yes, this exact same thing is being started again and its just annoying. And i have no intention of extending it beyond this post

No, Zones is not an overarching game mechanic, YOU want zones to be an overarching game mechanic. So far the only thing the developers have put in the game is groups. They have mining Groups, they have lumber Groups and they have building Groups. As such, i have been focusing on extending the Group mechanic that is already fundamental to the game.

Ok, i dont think you have ever actually understood what was being suggested. I do not want GLOBAL workplace zones. I do not want to have to define a workshop zone then fill it with equipment as this is a pointless step. There is always a footprint to each item you place in every game you ever play, defining its size and required working area. Hence you can always work out if there is enough space for the machinery amazingly. You could even call this working area an "Exclusion Zone" if you wanted.

There is no need for zones, yes it can be a useful mechanic, but it is not the be all and end all. There are multiple ways to do everything beyond a given pet idea.

Lumber zones and mining/tunneling zones are already in-game kalric...

What does this even mean? A zone is only global in the sense that an anvil placed on the ground is global.

If you want a equipment dependent tech tree then you want that.

That is even more restrictive. What you are proposing now is exactly what a pre-defined room would be, the exact thing you've been against the whole time. You seriously need to be consistent, and you need to read what I write properly. A zone would allow the game to check for dependent equipment, and it would allow you to define a workspace independently of the actual equipment. You could also assign specific stockpiles for the manufactured product.

Right now you are just contrarian because you've invested heavily in opposing zones, even to the extent of going against your own original argument of freedom for the player to decide.

If anyone else has thinks that what i am suggesting has a problem let me know.

He's contradicting himself from this thread.

He suggests that you should be able to group various kinds of equipment together(Which is actually just grouped preset workspace zones) with the express aim of giving the player freedom in placement so that he can define the areas himself. Then here, when a shortcoming of his idea is brought up, he adds his 'exclusion zones' that are preset workspaces, aka rooms. This is not consistent with his originally stated idea, nor is it consistent with his design aim, allowing the player maximum freedom.

It's not that what he's suggesting won't work, it's that it works poorly and restricts the player's options. kalric isn't opposed to zoning for any rational reasons, he has simply invested too much in opposing it. As you see in this thread he simply dodged defining what 'Global workspace zones' means, in other threads he has done the same with other 'arguments' he has put forth, and in others he has included zoning in his ideas and then claimed that he's not using zoning. Simply because his ego stands in the way, not a rational argument. He consistently states that I'm proposing zoning in stead of AI and groups because he has an adversarial view on the argument, as opposed to a rational view.

Organization of any kind relies on defining rules, spaces, tasks, objectives, and behaviors, and his grouping idea simply is not equipped to accomplish this. It is a part of accomplishing it, but it has extremely limited utility in complex systems. Zoning is an emergent game mechanic that allows for infinitely malleable, infinitely scalable, infinitely complex systems, allowing for deep and innovative gameplay. All the examples I have shown in various threads show its limitless potential, and that's just things I can think of without the actual game existing.

Let me just go through one of his posts here:

Anything placed on a ground is a defined area on the ground. Placing equipment on the ground is defining that area. The argument makes no sense.

How does defining an area conflict with that? You're the one defining the area, you can define it however you want, you can change it however you want. However, zoning allows for far more options, far more control for the player. Again, the argument is simply not sensible. This is a recurring theme in his posts on the subject.

No, he means this:

I know that he means that, it's just that it's a poor system for any sort of complex systems. It's simply an inferior system, which is why his argument is irrational.

No, that is not what I'm suggesting. First off, I'm not preferring anything; grouping has its uses, but it quickly becomes inadequate once any complexity is introduced. Zoning in relation to workspaces works in terms of defining areas wherein you provide a set of behavioral instructions. That is all a zone ever does. In terms of tools, equipment, and space it is a very good way of allowing the game to check for dependencies. For instance, if I have a catapult maker(or whatever, run with it) and I want him to build catapults I first require the game to check if I have the available equipment and resources. This can pretty much be accomplished by both groups and zones, but with additional complexity, such as a different group, making different things, using different stockpiles, but using some of the same equipment or maybe even some of the same stockpiles, the groups suddenly start being unwieldy. A zone, being immaterial, can stack infinitely on the same area, providing wildly different instructions to completely different groups or individual bricktrons. Now, a catapult takes up some space, and as such you need to check if you have the requisite space to build the catapult. Again, zoning a workspace will allow you to define that required space wherever you want it. Remember, zones don't have to be contiguous, they don't have to be a specific shape, and you can edit them afterwards.

Firstly, i read your article and I zones in of themselves are not an emergent game mechanic. If they are implemented with a high degree of complexity, they could become so, however i dont think that would add to the game for the effort of programming. it. Being able to to replicate an 8bit cpu with bricktrons like they did in minecraft seems a bit redundant to me.

No, i meant what bills said. Dont presume to know everything and state it as fact.

Two things, one, you are distinctly prefering and arguing for zones. Two, why are you assuming that there is going to be so much complexity that you will need to define so much to get things to work?

Also, is this completely off topic again now?

Bills, Tartantyco, this discussion is not going to die and i think we should take it out of un dedicated threads as the actual thread is being swapping with pure zone discussion. As such, please take all zone related discussion here.

http://castlestoryonline.com/threads/zoning-would-indepth-zoning-improve-gameplay.2376/

Then you didn't understand the subject properly.

There is no preference if they're not excluding each other. Stop making arguments of your own miscomprehensions.

Why are you opposing it? It's not a complicated thing to program, you don't have to use it if you don't want to, and it allows for great variety, increasing the replayability of the game. I assume you want a good game. The problem here is that you're not able to visualize the game, you don't see how limited your options will be without a dynamic and scalable system like this. I would compare it to CS construction and your average RTS construction; player designed structures as opposed to preset structures. "Ohh, designing your own structures, that sound complicated. Why not just have preset buildings, who would ever need to design their own?"

I don't think they should limit the game's potential just because some people don't see the use in something. I've pointed out a lot of issues already that don't just arise from some extremely complicated system, but are everyday issues players will run into and that will limit the player's ability to accomplish something due to the limitations of AI programming and lack of organizational tools.