Cells, cells, cells

[overdhose]

@woodspeople

don't stop posting, please don't... and do understand that if I would make a game about a purple monster pimp, it would gladly label it as an R game even if the esrb wouldn't agree with it, I respect our younger minds. My game would be oriented to a very specific segment of people from my own generation, to create a feeling of nostalgia. I realize that well.

If I were to make a kids game, I would mix the gameplay of monster rancher with dungeon keeper, which would be a complete other niche market. Given time and effort, I might actually get that some day, hopefully within terasology.

basically, my ideas never make any monetary sense, yet i keep persuing them. And just like you, I see the potential in Terasology, that's why we're here.

It actually opens the discussion of how much Terasology as a project should commit itself to label mods etc as kid friendly etc. I certainly do believe that, as an open source project, it should bare some of the responsability, and I'd gladly volunteer as a childless and uninvolved contributor to include a rating system within the game by default, so parents who are involved at least have an option to make sure their kids enjoy playing their game, be it by enabling some admin option as "parental control". Then again, i was a (weird?) kid myself , and I never did pay much heed to parental advisory stickers and the like, and as my parents never knew just what I was doing, I never had much trouble circumventing those options myself given a little effort, so i do realize it's a fight against windmills, if your kid is really determined to play mod xxx

 

[ironchefpython]

I've argued on this forum for TS to have flexibility in its gameplay so its players can make choices.

I disagree a little. I want to distinguish between Terasology the engine, and any Mod that runs on that engine.

The goal for the engine (in my opinion) should be for the modders can have maximal flexibility. If you want to run a mod on that constrains the playing into a storytelling experience that offers no choices, you should be able to build a mod that can do that. If someone else builds on that mod to turn it into an open-world sandbox, that modder should be able to do that.

The goal for the mod we have occasionally discussed in the development forum (variously called "Genesis" or "Untrue Tao") and what you're thinking of the TS gameplay, could be to offer the player maximal choice and an open-world sandbox. I'm fine with that, but I only care insofar as I want to make sure the engine will support such a mod.

What TS ultimately becomes depends on the whole group, as it should. So let the group choose.

I strongly disagree. I want to work as a group to build a maximally flexible engine, and provide a baseline set of assets in the form of meshes and textures and basic gameplay, and give everyone the tools they need to build their own vision based on those assets. If your vision for the game is based less on teraforming, and more on npc interactions, you can make a mod that favors that gameplay. If I want to make a TF2-like mod that lets players teraform a base, and then defend it against attackers with guns and rockets, then I can make that mod. My goal is to make sure that we have an engine that supports all kinds of gameplay, and that we have a modding language expressive enough to be able to define these mods in a simple fashion.

 

[Cervator]

I'm sort of figuring that what the group is choosing is the flexible engine plus mods that can make all our individual flavors possible

No way we could ever choose one specific set of gameplay concepts + content as a group, and we've hardly started growing as it is

 

[metouto]

....is the flexible engine plus mods that can make all our individual flavors possible

I am glad to hear this Because I was leaning the way of woodspeople myself . (NOTsaying everyone else is wrong).

When I play the rougher style I find that I just plain stink at it and in the end get made because I can’t handle the pace at times or a evil enough to live long.

So, I find that I like the easy going ….find a way to live without killing or being killed and explore the land and find out what secrets it hold for your discovery.

Again this might be my age and my upbringing because I find this idea does not appeal with the “younger” generation that I am around.

Woodspeople … hang in there with your ideas … I for one would like to hear more.


Edited ... and again I will step up and put my 2 cents worth in for always keeping the single player mode. I have most of the time played this way because no one else was a round or wanted to play a "kids game" or a game that was "just a waist of time".

I understand the team idea and know many love that way of play so go both ways if you can but always remember the lone player for what he/she is also worth to the game.

**** gets of soapbox & stands back on floor ****

 

[woodspeople]

Pleasantly surprised that anybody responded at all, except with "yes do go away and be quick about it". Cervator, I do worry too much, this is a fact known for decades. And I may have over-reacted to the description of Dungeon Keeper on their web site (mother bear instincts kicking in). And I am an unabashed magic nature hippie. And an older game player, like metouto, so looking at things from a different perspective (and with slow reflexes, I hear you there metouto).

I'd gladly volunteer as a childless and uninvolved contributor to include a rating system within the game by default

I think this is an excellent idea. If it was to work well it should be a rating system from the POV of both parents and kids, and be not just about what the parents want to allow but what the kids feel ready to handle in terms of scariness. We don't do edicts around here, we discuss and negotiate, and ratings systems are a big help in that. It might be worth thinking of things parent AND kids would want to know about a mod to rate it.

The goal for the engine (in my opinion) should be for the modders can have maximal flexibility.

I do agree with that, ironchefpython. When I said the players should have choices it was mainly in what constellations of mods they select for their use, but the flexibility of their mod choices is maximized when the modders have maximal flexibility. Attempting to make it so that every player can build every mod would mean building something that can't be built. You can't make clouds touch the ground, unless you turn them into fog, which is not clouds.

I want to work as a group to build a maximally flexible engine, and provide a baseline set of assets in the form of meshes and textures and basic gameplay, and give everyone the tools they need to build their own vision based on those assets.

On this I agree and disagree. To some extent we can do that, but it is almost impossible to build an engine into which some elements of thematic orientation, however slight, creep in. For example, when we were talking about minions and I said "I'd like to play as a minion" (both to trick/steal and to help) that might require some changes to the basic infrastructure, like how you can relate to NPCs, and how you can appear to other players, and whether you can appear to be something you are not (like a chest with feet). Usually at some point even in a very open system decisions get made after which it is impossible (or very hard) to go back and change them. If you don't make ANY assumptions you end up with an engine SO flexible it's essentially just a programming language, and then you haven't made anything new at all. To give one quick example: no MC mod can make an "undo" command, because it isn't supported in the infrastructure of the game. In creative mode multiple undo would be a KILLER function (imagine undoing hundreds of actions). But it's impossible to add because the MC folks made a choice early on not to put that structure there. (Yes you can do rollback but it's not the same; think of the complex undo systems on some graphics systems where you can choose which items from the list to undo.) Undo systems are actually quite easy to include, but you have to put them in early; they become almost impossible to bolt on later. This creates a limitation on flexibility that has impacts on all forms of gameplay. It is without a doubt that some such limitations already exist in TS. This is perfectly fine! What I am saying is: we should be aware of these, and sort of "test" them against some of the modded gaming experiences we want to be able to support. So to some extent the visions have to be in mind from the start.

My goal is to make sure that we have an engine that supports all kinds of gameplay, and that we have a modding language expressive enough to be able to define these mods in a simple fashion.

On this point I completely agree

Sorry to rock the boat folks. To some extent I was "just checking" whether this was the right play group for me or whether I should take my toys and go home I'll plop down on the carpet again... (Final disclaimer: the child was not in on that earlier post and would have stopped me if he had: he edits out all whining...)

 

[metouto]

....... I'll plop down on the carpet again...

GOOD !!!!

 

[Cervator]

(Final disclaimer: the child was not in on that earlier post and would have stopped me if he had: he edits out all whining...)

That makes me smile for some reason

That undo example is a good one. Yeah, I think that would be one of those things you have to plan for at a fundamental level, this one probably at the multiplayer / DB level coming up a little down the road. There is a way in MC to log per-block actions, tho I can't remember if that's core or mod (bukkit?). That would be a good thing to have as well, and expose in a creative-style mode to where the player could review actions, undo some, or even put together a series of actions that could possibly be re-used akin to a blueprint

 

[woodspeople]

Actually undo in combat would make it far more interesting, I think. Braid has that and it is SUPER cool. Loving Braid in general though some of the puzzles are come-back-tomorrow hard.

 

[Cervator]

Oh wow, I had never heard of Braid, and reading up on it makes it sound pretty mind bending. I get what you mean with the time warping undo stuff now

(For others that are interested: http://en.wikipedia.org/wiki/Braid_%28video_game%29)

Yeah that really would be a hugely fundamental part of any game made to support those mechanics. I had considered that maybe if we reached multiplayer DF-like gameplay we could allow local pausing of time independent of distant fortresses, but that's one thing. Maybe if you really wanted you could reach a point with limited time-based magic, but whoa on the likely complexity. Yeah, would definitely need to plan that up front.

I don't think there's any feasible way to do Braid-level time manipulation in relation to puzzles and interactions in a multiplayer 3D cube world. Something more limited might be possible, and definitely would need the supporting systems fit into the multiplayer milestone at the latest, or yeah, it would be nigh impossible to attach later. Very interesting concepts

Also, missed a chance to respond to the minion example earlier - I think it would be awesome to be able to assume the position of a minion to infiltrate another estate or stuff like that. And not very hard to do (relative to having a creature/minion system in the first place). Swearing fealty / becoming a sidekick has been done in other games as is, and should be doable. Maybe you can organize a revolt among the peons to overthrow a cruel NPC overlord

 

[ironchefpython]

Maybe if you really wanted you could reach a point with limited time-based magic, [...] Yeah, would definitely need to plan that up front.

If something is so complicated that it needs to be part of the initial engine design, then it's not a viable feature, and you put it on the wishlist for version 2.0.

 

[Cervator]

It isn't so much a single super shiny feature as a thorough backing system for logging/auditing actions. We'll probably need that to a degree for multiplayer anyway (anti-griefing, maybe historical flavor stuff). I suppose in theory you could do an action logging system as a mod attaching to every substantial event in the world, but something like slowing down time I'd think you'd need early tweaks to the engine to expose that as possible functionality (change the time flow of the main game loop).

There are other legitimate uses for it such as time dilation (a major new lag-fighting technique in EVE Online) also.

I suppose you might be able to use mods for all that, but some heavy systems might be better off in core for performance reasons, like the very basic block system. I currently wonder if basic functionality behind advanced liquid systems and growth simulators would be other examples like that. Still very low level and generic, of course.

I'm not saying we should do it, planning something like that for a major sequel might also be very valid, but either way I do think it holds water as something that could benefit from (or require) thought early on in the engine

 

[woodspeople]

I agree that things like time dilation could be a huge can of worms possibly better left alone. Especially local time being different and times clashing... eeeek.

However a simpler command-based multiple undo stack system isn't anywhere near as hard or complicating, and it's just as cool. Imagine being able to back all the way out of a fight and start it all over again with a different weapon, or jump back onto a cliff, or undo breaking that block above your head... It's something that could actually be pretty differentiating in terms of gameplay. You could also make undo functionality only available after months of arduous effort learning how to be a master mage or high level steampunk technologist... This is the kind of "magic for free" thing that adds depth to all possible mods with relatively little effort, but it can only do that if it's built in at the bottom.

At the severe risk of telling you what you already know, I will describe the multiple undo systems I have created/used in the past. Basically everything a player can do is carried out by a hierarchy of classes that inherit from the command class, and all commands have do, undo, redo, and some description methods. So for example a "move" action would change the player's position in its do method, put the player back in the undo method, and do it again in the redo. (The reason for a redo method is that sometimes there is a time-consuming or memory-consuming operation that only has to happen in the do, and there is no point doing another time-consuming operation or freeing the memory in the undo, in case they end up redoing it again. If the operation is simple the redo method can just call the do method.)

Anyway so there is a stack of these commands, and you just push and pop them as the user requests. You can also do more funky managment things like ask the commands how much memory they need or how long they think they will take. In one such system we kept track of how much memory the command objects in the stack needed, and we expanded or reduced the stack size to make sure we never overrode what was available to the program (this was more of an issue back in the day). For things like TS frame rates and lag are more important, so you could imagine managing the undo stack to make sure lag is minimized. Of course in multiplayer software managing multiple conflicting undo stacks gets somewhat more tricky, but you could put in place some basic rules that resolve conflicts.

ironchefpython, I agree that v2.0 is often when such things happen, and it makes sense to put off "nice to haves" until then, and this probably is a nice-to-have. Sounds cool though

 

[eleazzaar]

...Volume restrictions that make sense I think are important. Not arbitrary cells, but no putting a grand piano in a backpack, even if you have the weight allowance. Russian nesting doll-based inventory

Shouldn't be too hard assigning rough width/height/depth to objects and the same to containers - but displaying it in a way that looks nice and makes sense, dunno, that might be harder.

I have a different plan for being able to move bulky objects more easily. Gotta catch em all...

I'd argue that inventory limits should be based on a single aspect: either number of slots/items as in MC, or total weight. As soon as you add a second limiting aspect, especially length/ width you have increased the amount of time the player will need to spend shuffling his inventory. Realism be hanged-- nobody buys/ downloads a game excited by the prospect of managing a complex inventory. Managing inventory is the neccesarry evil that should get out of the way as quickly as possible, so the player can have fun.

If the game has grand pianos-- you gotta move them somehow. Or if there's something the players is not supposed to move--- why not prohibit via weight limits? I know in the real world there are some items of small weight that are impractical to move-- but those are unusual cases, which can IMHO be ignored in a game like this.

A weight limit could also be in practice a soft limit. The more weight the player carries the slower he goes. If he needs to move a piano-- he can-- but he'll move very, very slow. He certainly won't carry a piano around while adventuring.

 

[Cervator]

Yeah, granted, I'll give you that. Mostly I was wanting nested bags to make more sense so in theory you could fit a smaller container inside a larger one, even if it contains items itself - but then it would seem goofy to have the smaller container hold something large.

 

[eleazzaar]

Yeah, granted, I'll give you that. Mostly I was wanting nested bags to make more sense so in theory you could fit a smaller container inside a larger one, even if it contains items itself - but then it would seem goofy to have the smaller container hold something large.

Does the game really need small containers? Or containers of a limited size capacity? What are "pros" that justify the "cons" of additional complexity for managing all inventory, and the need for an inventory managing AI for minions?

For two RPG-type projects, (both that died ) i put a lot of consideration into the inventory system and it's GUI. One thing i learned, is while it is easy to make a computer understand multiple nesting chambers, going beyond containers in the general inventory adds much complication to the GUI, and makes it more of a pain to use. And unless you have a crack coder who loves nothing better than coding GUIs -- GUI complication is a real issue. I've found over the years that coding the GUI is very often the bottleneck for new stuff.

I'd strongly recommend not allowing containers in containers. Or if you count the general inventory as a container, no more than two levels of containers. This IMHO is the sweet-spot of lower GUI complexity and higher player customizability.

 

[Cervator]

I yield, no more good sir!

If somebody wants super duper inventory with nested bags and constrained volume they can do it as a mod

I suppose I can rest easy knowing that at least we have containers you can move while full...

 

[B!0HAX]

I'd strongly recommend not allowing containers in containers. Or if you count the general inventory as a container, no more than two levels of containers. This IMHO is the sweet-spot of lower GUI complexity and higher player customizability.

Containers inside Containers sounds good (to me) and limiting subcontainers was in my mind from the start, I think none of us want a game where the players experience situations such as:
"A crate that holds a <bag>, that holds a < pouch>, ... < treasure chest>, ... <cigarrete-box>, that holds a pickaxe"

If the game has grand pianos [...] He certainly won't carry a piano around while adventuring.

But if the player wanted to carry a grand piano he could simply boost his/her strength chugging a good strength boost potion
(or eat some spinach)...
[EDIT: Maybe he wants to play the piano somewhere with the gel cubes...]

Regarding small containers, think about it as in RL, if a player wants to have a little pouch to carry herbs around, he can...
If you tried to put pickaxes in a pouch (too small) you will find out you aren't able of making it fit...
The player actually decides if crafting a simple little bag that weighs less and can hold what he actually wants it to hold...
Therefore you have more weight-capacity ("inventory space") for collecting herbs.

IMHO leave the player "do" whatever he wants, he will know if its usable/suitable (or not) for his/her own gameplay.

 

[eleazzaar]

I suppose I can rest easy knowing that at least we have containers you can move while full...

That's a good thing. I hated it in MC when my organized chests needed to be moved for some reason.

I think none of us want a game where the players experience situations such as:
"A crate that holds a <bag>, that holds a < pouch>, ... < treasure chest>, ... <cigarrete-box>, that holds a pickaxe"

We agree there.

If the game has grand pianos [...] He certainly won't carry a piano around while adventuring.

But if the player wanted to carry a grand piano he could simply boost his/her strength chugging a good strength boost potion
(or eat some spinach)...

I don't think pianos will be in the game, and if they are, i don't care if they are moveable or not. The point i was trying to make was, if you want to prevent players from adding them to inventory, or if you merely want to make it impractical to carry pianos long distances, a weight limit (soft or hard) can do the job without an additional volume limit.

Regarding small containers, think about it as in RL, if a player wants to have a little pouch to carry herbs around, he can...
If you tried to put pickaxes in a pouch (too small) you will find out you aren't able of making it fit...
The player actually decides if crafting a simple little bag that weighs less and can hold what he actually wants it to hold...
Therefore you have more weight-capacity ("inventory space") for collecting herbs.

But why should this bit of the game follow Real Life? Real life can be tedious, complicated and boring. Don't copy it unless it improves gameplay.

If the player wants to put herbs in a pouch, or any other container, that's fine with me. The player will have a weight limit for his total inventory, so if he wants to organize his stuff with many sub-containers, i see no reason to penalize him in any way. Why should empty sub-containers have weight? Why should they have limited capacity? That limits the player, and forces him to shuffle inventory around when a container gets full, and thus messes up his organization system.

:arrow: It would be simpler, and IMHO more fun if all sub-containers could hold at least as much as the player can. And for the compulsive organizer who wants many subcontainers, the containers themselves have no weight, and thus doesn't cut down on his total capacity.


I'm not trying to be a pain about this. IMHO an important part of forum game design discussions is not only to think up cool ideas, but to put those ideas through the thresher, to weed out ideas and elements that don't really contribute to the game. Otherwise a coder's time will be wasted when it might have been put to something better.

 

[B!0HAX]

Player Inventory, Subcontainers, Weight, Stamina & Fatigue..

I think about it as a free experience for the player not being limited by cells and having a more realistic load restriction upon his player's : total weight max. capacity.
My conclusion about the player's inventory limiting factor is : weight limit is much more flexible than cells.
(specially combining weight limit with a x,y positioning in container system.)

Then I think of subcontainers having a total weight capacity,and also a weight prop...
(weight prop = "mass" because they are items and have physics).

Then adding some type of "easy & logic"-size restriction handler properties/rules for them:
(example) Small Bags can't hold items with a "mass > x" or subcontainer with a bigger mass than theirs.

Small Bags (subcontainers), Big Sacs (subcontainers), Wooden Crates* (world containers / subcontainers),
being Chests (world containers) the only ones that aren't accessible from the inventory screen.
[*The wooden crate could be a hybrid between a Chest and a subcontainer, existing the possibility of placing it in the world for multiplayer access (for example leaving the crate in the ground for a friend to restock some potions or whatever).]

#Now moving onto explaining how I see the players characteristics for those that want to understand better my point of view:
A player has a property (component, like health) that is called "Stamina", that is what we are going to use to determine how the player handles the fatigue... Stamina regeneration could be connected to Hunger, Poison, and many other nice game mechanics.

Fatigued status would be an effect that act differently upon certain parameters (lets talk in total stamina %):
if the player has +50% then no problem, if the player has between 50 > 30% he's speed is affected by x% because he's getting tired and if it is under 30% he's speed is affected by x(+c)% and if he has 0% Stamina he can't move at all...

Q: What if you have a Chest that its total weight goes over the Total Weight Allowed Player "Cap" and you want to move it somewhere / change its location?
A: When a player's weight capacity is "overweight" he enters the [extreme-fatigue status = stamina 0%] not being able to move, but being able to rotate the camera and place the chest in another point, repeating the action until you get to the place you want to drop that heavy chest. Maybe ordering a minion to pick a heavy chest and transport it somewhere would fix this issue.

Overweight could be dealt also like something that if it exceeds the cap by +200 then you can't move at all and if you have lets say +50 above the cap you only loose stamina as you walk, making the player get tired because he's moving something thats on his endurance limit...

Regarding nested containers:
Q: What if you have a plant(0) inside a bag(1) inside a big sac(2) inside a crate(3)
and then you place the crate(3) inside a Chest(4)? Would you be able to pick the plant from the chest placed in the world?
A: Well in this case we would limit subcontainer accessibility to lets say 2?
container > subcontainer > sub(x2)container
and send some message like "That is not accessible" if you try to open beyond the 2 subcontainer.
So to pick the plant up you would need to take the bag out of the big sac and then access it to get the plant.
[Why would anyone want to put a plant inside such a nested container maze in the first place?]

SubContainers will be used for different situations and I believe having different sized subcontainers just makes the game look nicer add up some realism that really doesn't affect (IMO) the player in a manner that drives him nuts, because its fairly simple and logic to understand that you can't put a chest inside a little bag or try to access a plant thats inside a sac thats inside a bigger crate thats inside a chest (In RL you would take the sac out and access it to get to the plant, at least I would).

Q: Why do we want little bags? if we already have big sacs or crates why not use them instead?
A: Well you might like to grind the plant harvesting spots by optimizing your inventory.
·Example Case:
Little bag [empty] (mass: 0.5), (total weight allowed inside: 100)
Wooden crate [empty] (m: 5), (tot. w.cap: 500)
·Conclusion:
Carrying 5 little bags weighs less than a wooden crate and you would have the same amount of weight allowed in total, then little bags would be more useful than crates for this case and allows the player to pick more herbs :]

I hope that I didn't explain this in a confusing manner.

 

[eleazzaar]

Re: Player Inventory, Subcontainers, Weight, Stamina & Fatig

Regarding nested containers:
Q: What if you have a plant(0) inside a bag(1) inside a big sac(2) inside a crate(3)
and then you place the crate(3) inside a Chest(4)? Would you be able to pick the plant from the chest placed in the world?

My answer:
You don't. The game doesn't let you put containers in containers. (The exception being the player's general inventory-- if you consider that a container)
Why implement a GUI for something you don't think people would want to do in the first place? Good game design is as much about what you leave out-- as it is what you put in.