Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411472 Posts in 69369 Topics- by 58423 Members - Latest Member: antkind

April 23, 2024, 11:35:11 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperDesignDesign dilemma with prop behaviour
Pages: [1]
Print
Author Topic: Design dilemma with prop behaviour  (Read 816 times)
PeterPixeleap
Level 0
**


View Profile
« on: January 20, 2015, 02:08:07 AM »

Hi guys and girls,

We have encountered an interesting design challenge that will have a big impact on both gameplay and the implementation of the game and I would like to present that to you, I will also talk about my own thoughts on it and I would love to hear yours as well!

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 people how you would approach 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
Logged
bdsowers
Level 3
***



View Profile WWW
« Reply #1 on: January 20, 2015, 07:44:22 AM »

It sounds like some of your issue can just be resolved via a clear animation:

Quote
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.
Don't have it just vanished. Create a 'melting' or 'dissolving' animation that starts at the block and extends outward to the objects. Then it becomes clear that things touching the block vanish.

With a gravity-enabled approach, it's not very clear what happens when a block reappears. What happens to objects that fell into that space?

Here's how I'd approach the problem:
Don't make the block vanish. Make the block semi-transparent (with some kinda nifty shimmer effect) such that it's clear that the player can walk through. All props/decorations are still impacted by it physically, just the player can pass through.
Logged

PeterPixeleap
Level 0
**


View Profile
« Reply #2 on: January 25, 2015, 12:52:18 AM »

Hi bdsowers,

Thanks for your input, I think you are spot in! We were already talking about making the block that is removed in to some shimmering magic effect, so I like your idea of applying it to the objects as well.

I think we will proceed with that idea and see how it works out, thanks for pitching in! Smiley

Peter
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic