Design dilemma in prop behaviour

General intro to the game:

We are working on a fast paced 3rd person shooter set in a fantasy universe. The game is class based with 5 different classes and we have recently run in to a design challenge regarding one of the classes.

The class is really fun for the team because it enables some different plays, but one of its skills really poses some interesting design choices for how the game behaves.

The game levels will be a square area with a castle at each end and inside the castles there will be some objectives that the teams must attack and defend. (You could put a picture of the famous unreal level "facing worlds" into your mind, it's not the same, but the basic structure of the level should make sense). This game mode is more of a "destroy the flag" than capture the flag.

Each of these castles will have a main entrance and in some cases an alternative entrance. This is where the infiltrator class comes in to play. One of the skills of the infiltrator is creating temporary holes in the walls of the castles to allow for creative play.

How does the infiltrator work:

The infiltrators secondary skill is to use magic to remove a block from the castle for a set amount of time, in this time a character can pass through where the block was before. After the time expires the block reappears.

The design challenge:

Inside the castles there is a lot of props and decorations to set the mood, for example, barrels, chairs, tables, torches, carpets and so on. We distinguish between a prop (something that is placed and have physics on it this could be a barrel or a table) and a decoration (something that is placed that does not have physics on it, this could be a torch or a carpet).

So now an infiltrator or several infiltrators decides to remove one or more blocks in the castle and the big challenge is, how does the rest of the environment behave as a reaction to this?

This may sound like a small thing to some people, but it actually have a big impact on how different part of the system should be coded and also have a big influence on some of the plays that will be available.

I have tried listing up some cases where this challenge poses a dilemma and further down I will try to address them with some of my own thoughts on it.

Case A:

A barrel takes up 1 block of space.

The block is temporarily removed by the infiltrator

What happens to the barrel when the block is removed?

What happens to the barrel when the block reappears?

Case B:

A chest takes up 4 blocks of space.

3 out of the 4 blocks are removed temporarily by a team of infiltrators.

How does the chest behave when the 3 blocks are removed?

Is that behavior different from when 1 or 2 of the blocks are removed?

Case C:

A barrel takes up 1 block of space.

The block in the drawing is filled out to symbolize that it has not been removed, but all the blocks around it has been removed temporarily by the infiltrator.

How does the block with the barrel on behave?

Does this affect the barrel on top of the block?

General:

We have chosen not to let the castle blocks in the game be affected by gravity because the castles are a very important part of the level design, and removing key blocks could effectively cause the entire castle to fall apart if there were gravity applied to them.

So with this decision in mind, does it make sense to let it affect props and/or decorations? Does it look weird if props just hang there in the air? Should the props have physics on them or should you just be able to pass through them? Maybe you can pass through them when their block isn't there? But then what about the multi block cases?

My thoughts:

So far I have been returning to this challenge again and again while doing the other design and I have not yet come to a conclusion on what I think is the right thing to do.

Right now I am leaning towards the solution where an object disappears when a block it is attached to disappears and make it so that if an object is standing on multiple blocks, it will disappear when just one block is removed.

This will make the gameplay a little simpler in the way that when you remove a block, you will always be able to use that new hole as a path and not have to worry about a prop blocking your way.

Another advantage to this is that props always stay in the place where the level designer placed them (they reappear when the block reappears).

But there are also some downsides to this. For one it looks a bit strange when a potentially big object just vanishes in to thin air because a block it was touching was removed and then suddenly reappears later.

This also takes a way some of the creativity of the level designers if they want to use props in a clever way to design paths through the castles because they can just be so easily removed.

Another solution that I am thinking about is letting the props have gravity enabled on the y axis, so that if the block(s) they are standing on are removed, they can fall down to the floor below.

But with this solution there are also a lot of cases to consider. What if it is a big object and as the last block it is standing on is removed, it starts falling and in the middle of that fall one of the earlier removed blocks reappear. What happens to the object then?

And is this gravity only applicable to props and not decorations? Because torches falling of the wall to the floor also feels a bit strange.

Conclusion:

So maybe this turned in to more of a design rant more than a lesson learned post, but one of my motivations for writing this was to hear from other designers how you approach a design challenge like this.

As it is hopefully obvious in the post, this seemingly small decision have a big effect on both implementation and gameplay and therefore is suddenly an important one to get right from the get go.

I haven't reached a decision yet on what to do and would love discuss this with you and hear your opinions. Game design is fun and when you meet a challenge like this I find that it is great to discuss it with others.

Let me hear your thoughts here or come grab me on twitter: @PeterPixeleap