Unity Scene design.

Recommended Posts

Nickie    322

Hello everyone,

I currently need to decide what type of scene will my game need.

a/ A root and only one level of children.

b/ Not only the root but all objects can have children

What is making my decision harder is that I don't know what the physics engine will do.(I guess bullet physics)

If I didn't have physics -> I've got bus and a character. Bus is parent of character -> character's matrix is being multiplied by its parent to find where I should draw it.(and where should the logic process it)

I don't know how physics handle these stuff. I don't know can there be any connections like this(I've been playing with unity3d. I know just the most basic stuff about physic's objects)

For the design itself I'm following ( http://software.intel.com/sites/default/files/m/d/4/1/d/8/Designing_a_Parallel_Game_Engine.pdf )

I have an universal scene. I create the bus and character there like I said above. How should I recreate this in the physics system's scene?

Should it be flat? Do I need some connection between a parent and a child(like the transform multiplication like I said above)?

Note: I don't need really advanced physics simulations, just rigid body and collision.

So...how would you do this?

Share on other sites
Helo7777    693

In my opinion it would be best to have all scene objects capable of being a parent and to hold children. It will just make object handling a little easier. Something like the following maybe?

class SceneNode
{
std::list<SceneNode*> children;

nodes and any other common node methods too*/
};

class Bus : public SceneNode
{
/*Bus related methods*/
};

class Character : public SceneNode
{
/*Character related methods*/
};


As for physics, you mentioned Bullet...It holds it's own scene structure and feeds your scene objects with updated transforms. So it basically runs independently to your scene graph and you'd be using Bullets interface to move objects around. To create rigid bodies you feed Bullet with raw geometry (or use simple primitives) and positional data. You'd then tell Bullet what rigid bodies are attached to each other (parent/child relationships).

Note: I don't need really advanced physics simulations, just rigid body and collision.

Unfortunately once you start colliding multiple objects together and want correct collision detection and response, it becomes rather tricky, and implementing your own solution basically ends in recreating the wheel so to speak. Bullet will only do what it needs to do in terms of calculations so you wont be loosing out by using it.

Edited by Nyssa

Share on other sites
Nickie    322

Thank you for the answer. Pretty much everything I need. I already have experience coding such things(however without physics) and I usually do the same thing you suggested.

I'll just make my universal scene which support parent/children, create a function which will iterate through parents to get the real world position of the node. Then I'll create the physics system like a wrapper to bullet physics. Bullet will take care of its own structures.

Share on other sites
turch    590
Don't think of it as a monolithic structure. Keep as many copies of the data as you need. Graphics system needs to cull geometry based on visibility? Keep a quadtree/bsp tree/whatever around. Need to quickly look up certain game objects based on string keys? Keep those in a dictionary. Need a data structure specialized for physics? Have one of those around (if you're going to be using a 3rd party physics api then it will keep it's own copies of the data it cares about).

A general purpose scene probably doesn't need to support parent-child relationships. You only really need that for calculating world transforms (and you've got another class for that right?). If this is the "master list of all game objects" type of scene, then really all it needs to be is an array or some sort of dictionary if you have unique ids. Edited by turch

Share on other sites
cr88192    1570
my strategy:

the large scale world is divided up into "regions". each region is a fixed sized space (basically like a big cube), and they are laid out in a giant grid. as-is, the regions are 512x512 meters (or 16384 ~1.25 inch "units").

an idea here is that a player may only see into at-most the 4 nearest regions, and anything beyond this can be saved to disk and unloaded (or reloaded again if it comes back into the visible list).

within each region (apart from voxels), objects are sorted according to a dynamically build BSP-like structure.
this tree is rebuilt as objects are added/destroyed or move around.
the advantage of a tree like this is that it allows quickly answering questions like "what is the nearest X" or "is there anything in this particular area of space?", without needing to check against every object in the scene.

say, an object is running or falling, do we really want to check against every object in the scene every tick? typically not.
a tree allows quickly identifying and eliminating the vast majority of objects for which there is no chance of colliding with them.

however, this tree is not directly regarded as part of the object (in the same sense as parent/child relationships), but is more sort of a "behind the scenes" type thing, and as an object moves around, the tree might change around under it, or if it crosses a region boundary might actually jump from one BSP to another.

most entities and similar are otherwise treated as more-or-less a flat list. typically, there are not any explicit parent/child relationships, but some relationships may exist informally (for example, projectiles remember who fired them, AIs/NPCs remember who their current enemies are, ...).

during run-time, each entity may also be assigned an "ID number" used to identify it (like, over the network protocol), but this ID number is not persistent.

note though that there is not actually a single unified list of objects for the entire engine, but rather there may be around 4 of them:
the server-side scene-graph, which basically tracks all world objects (and runs all the AI, physics, ...);
the physics-engine graph, which mostly just deals with objects using fancy physics (otherwise, the physics engine is idle);
the client-side scene-graph, which basically contains whatever entities the server is telling the client about (the locally visible collection of entities, which basically holds information like each objects location/velocity/model/frame/effects/...);
the renderer's "modelstate" list, which mostly keeps track of currently-visible scene objects (this may include things like the instance of an entity's skeletal model, its current bone positions, per-frame vertex/normal and triangle-face arrays, ...).

so, for example, if an entity exists on the client, it may be given a modelstate if it is potentially visible, but may not get a full state until it is determined "actually visible" by the renderer (is uses a special visibility-determination pass, employing various checks to try to determine what is/is-not relevant to the current visible scene), and an entity wandering off-camera may well have its modelstate destroyed (the modelstate graph is thus highly volatile, and in some cases the renderer may destroy it at-will, forcing the client-end logic to rebuild it).

the reason for different lists is that they exist in different parts of the engine and deal with different information.
for example, the server-side entities contain lots of fields that have no relevance to the renderer;
and, the renderer contains lots of fields that have no relevance to AIs or physics;
and, for example, the client-side scene-graph knows a model by its model-name, and largely manages communication with the server, whereas the renderer's modelstate knows it via an instance pointer and internal (model-type specific) vtables (and non-visible objects are never given a modelstate);
...

well, and also because my engine is mostly broken up into multiple DLLs, and I prefer not to share structures between different libraries.

or such... Edited by cr88192

Share on other sites
Krohm    5030

What is making my decision harder is that I don't know what the physics engine will do.(I guess bullet physics)

I'm not sure what it's causing you trouble here. Physics representation must totally be separate from others.

It is worth noticing that for anything that is not a dynamic object (Bullet slang) the physics does absolutely nothing, in the sense the objects will stay still by themselves.

Kinematic objects do move according to application, not physics.

You'd then tell Bullet what rigid bodies are attached to each other (parent/child relationships).

Actually no, they are not parent/child relationships. There's no such thing as a "parent" rigidbody. Connecting rigidbodies by a constraint gives them equal rights.

I actually read a lot of possibly premature optimizations in this thread. Last poster even takes a stab at streaming, client-server architectures and such. My personal suggestion is to use iterative design. Add features after you have the need for them. You cannot design a solution for a need you don't understand.

Actually, my "scene" is a std::vector of batches. Yes, you read it right. I don't even need to make it hierarchical. Yes, I do have problems with my most complex data sets on the lowest end hardware I'm targeting (which is 1st gen Intel Atom FYI). Realistic datasets run just fine.

Share on other sites
cr88192    1570
actually, I was mostly describing how my engine works, as an example...

granted, it does itself use a client/server architecture (both in single and multiplayer), and loads/saves parts of the world dynamically.

actually, in this whole design, the server end is the main authority (pretty much everything on the client-end is streamed over from the server).

Create an account

Register a new account

• Similar Content

• Wind Of Fear is a game where we have to kill different kinds of waves of monsters packing weapons. The main goal is to survive the waves and pump up your own weapons. There is a store where you will buy new weapons, scattered crystals that restore your life are also on the map!

Controls:
WASD - Walking
Shift - Running
Mouse1 - Attack
Space - Jump
ScrolDown - weapon change
T - Deceleration of time
Esc - Exit, pause

• Continuation of the first part of the game, Invention. While you were on the island exploring the underground laboratory, the infection was busy spreading throughout the world. In this episode, you have to go through a city populated by monsters in search of salvation aided by weapons that you will find during your travels. The gloomy atmosphere, music and atmosphere and a crowd of walking meat will keep you on your toes!

•
Intro - "The challenges of dynamic system design"
Custom Quest evolved during development, from a minor quest system used for our own needs in our own game production Quest Accepted, to something entirely more dynamic and customizable, now finally released, these are our thoughts on quest design and developing standalone subsystems.
Splitting what is a major production for a small indie team, into smaller installments such as a quest system was a good idea we thought, this way we can get some releases out there and fuel the development of our game. But building a system that works for yourself is one thing, building a unity plugin that will let other developers create quests, missions, and objectives, you would never have thought of is something else entirely.
The first thing we had to realize was that when building a quest system, the task is not to design great quests, the task is to enable the users to create great quests.
That still meant we had to find out what good quest design is and what a quest really is.
Our task was to create a system where the user is free to create creative engaging and rewarding mission experiences for their players.
What is a quest? - "Cut to the core"
First off, we need to know what a quest really is.
A quest is the pursuit, search, expedition, task or assignment a person(s) does in order to find, gain or obtain something.
In games, quests and missions function in many different ways depending on the genre.
A single game can contain a multitude of different types of quests put together in just as many ways. In an MMO, for instance, quests are vehicles for the story and the player's progression. In many cases they are formulaic and simple, some can even be repeated, there are hundreds of them and everyone can do them. In other games quests are for single player campaigns only, here they shape each level giving the player a sense of purpose.
Quests can span the whole game or just be a minor optional task on the way, there are so many design philosophies and creative quest designs that we had to narrow it down and really cut to the core of what is needed for good quest design.
What all quests have in common is the task, the criteria for successful completion of the quest, and the reward, the goal of the quest, what the player gets out of doing what we ask of him.
Quests cover an incredible variety of tasks so it was important for us to base our decisions on thorough research. In our research, we found that there are three layers to quest design.
The type, the pattern and the superstructure.
Quest types exist within quest patterns and quest patterns exist within the quest superstructure.
We found that there are 8 basic types of quests these are the various tasks/criteria the player must do in order to complete the specific quest.
There are 12 quest patterns. These are ways designers can use their quests, connect multiple quests set them up in engaging ways or teach players how to interact with and get the most out of the game world creating variety and engaging the player.
Enveloping the patterns is the quest superstructure, the overall structure of quests in the game, we found that there are two main ways of structuring your quests.
Historically quest have a quest giver, an NPC or object that informs the player about the quest, what they need to do, the story behind it and perhaps even what their reward will be should they complete the quest.
Quest types - "Do this, do that"
The core task each quest consists of, the criteria for completing part of or all of a single quest. These are the actions we want Custom Quest to be able to handle.
Kill
Probably the most basic quest type, the task is to kill something in the game, for example; kill 10 goblins. Gather
Again very simple, the task is to gather x things in the game world, collecting berries or the like. Escort
The player must escort or follow a person or object from point A to B while keeping it safe. FedX
The player is the delivery boy, they must deliver an item to a person or point. Defend
The player has to defend a location from oncoming enemies, often for a set number of waves or time. Profit
The player must have a certain amount of resources to complete the quest, contrary to gather quests these resources are resources the player would otherwise be able to use himself. Activate
The player's task is to activate/interact with one or more objects in the game world or talk to a number of NPC’s. In some cases, this must be done in a certain order for a puzzle effect. Search
Search an area, discover an area of the game world. This is useful for introducing areas of the map to the player and giving them a sense of accomplishment right off the bat, showing them a new quest hub or the like. Quest Patterns - "An engaging experience"
Tasks are one thing, and in many games, that might be plenty but we wanted custom quest to let the users create chains of quests, specialize them and set them up in ways that draw the player into the experience, there are many ways to go about this.

The most basic quest pattern, the quest chain starts out broad and easy, the player has to kill some low-level cronies. The next quest is narrower, the player must kill fewer but tougher enemies, lets say the boss' bodyguards. The last quest is the boss fight, the player has killed the gang and can now kill the boss. This quest pattern is very straightforward and works well, giving rewards either at every stage or only when the boss is dead.
Side stub
A side stub is an optional part of the overlapping quest. Lets say quest A leads to quest C but there is an option to complete a side objective B, which makes completing C easier or it changes the reward, for example. The player must escape prison, the side stub is “free the other prisoners” in this example escaping with all the prisoners is voluntary but it might make it easier to overpower the guards or the prisoners might reward the player when he gets them out. The side stub differs from a generic side quest in that it is tied to the main quest directly.
Continuous side-quests
These are side-quests that evolve throughout the game, one unlocks the next, but they are also affected by external requirements such as story progress. This pattern is often found with party members in RPG games, where the player must befriend the party member to unlock their story quests.

As the name implies these quests are time sensitive. The task can be of any type, the important thing is that the quest fails if time runs out. This could also be used for a quest with a side quest where the side quest is timed for extra rewards but the main objective is not.

Deja-vu quests
This kind of quest pattern gives the player a quest they have done or seen before. In some cases, this “new” quest will have a twist or something that sets it apart. It can also be the same sort of quest that exists in different areas of the game world, perhaps there is more than one goblin camp? or perhaps the player has to pick berries daily.

Delayed impact
Delayed consequences of a previous decision. Often used in games where the story is important and the players’ choices matter. These quests are tied together without the player knowing. Let's say the player is set the optional task of giving a beggar some gold to feed himself. The player gives the beggar a few gold and is on his way. The next time he meets the beggar the beggar has become rich and rewards the player for his kindness with ten times what he gave.
One of many
The player is presented with a number of quests, they have to choose which one to complete, they can only choose one. The others will not be available.

Hidden quests
Hidden tasks that aren’t obviously quests at first glance or are hidden away for only the most intrepid players to find. This could be an item the player picks up with an inscription in it if the player then finds the person the inscription is about he can get a reward for delivering it. A good quest pattern for puzzles, these kinds of quests can really make the game world come alive and feel a lot more engaging, allowing the player to uncover secrets, Easter eggs and discover all of the world created for them
Moral dilemma
Punish the bread thief who stole to feed his family? often used in games that have a good/ evil alignment level for the players, these kinds of quests make the player make a choice about what kind of character they want to play, they get to choose if their character is good or evil.

Side quests
Optional quests, these quests are often found in level based games where the overall quest must be completed to get to the next level, the player can optionally do some extra tasks to get more points. The important part is that these are optional but they give the player a reward for, getting everything they can out of the game.

Tournament
Tournament style quests, a series of quests that get harder as the player progresses. An example could be a gladiatorial arena if the player defeats five enemies one after the other he gets rewarded as the champion of the arena, but if for example, he fails at the third, the whole tournament is failed and he has to start all over from quest 1.

Vehicle missions
Despite the name these quests are not confined to being about cars, these are simply quests where the players control scheme changes to complete the quest(s). An example could be; changing from running around in the game world to driving a tank to destroy a fort.
Quest superstructure - "The whole package"
With quest superstructures, we are venturing into general game design. The superstructure is how the player is allowed to complete quests in the game world. It's basically a question of whether the game is “open world” or a linear experience.

The diamond structure
The open world model, think games like The Elder Scrolls V: Skyrim, the player is introduced to the game through a quest, but after that, they can go wherever and do whatever quests they want. There are tons of quests of the above types and patterns, the player is free to pick and choose which to do, giving the player the illusion of freedom within the game world (the diamond). However, the game still ends by completing a quest that is locked and always a requirement to complete the game. This can, of course, be varied by different choices the player has made throughout the game or even have multiple endings. Quests can be concentrated into quest hubs, i.e. towns with lots to do or the like, but they don't have to be completed in a linear fashion

Linear hub structure
This structure consists of a number of required “bridge” quests that need to be completed in order to unlock the next area or “hub”, each hub can have any number of quests, this could be a town full of people in trouble, each with their own quests and quest chains to complete, when they are all done, the player moves on to the next hub through another bridge quest. Limiting the quest size of the hubs will make the quest structure feel more linear and thereby the game linear, and creating larger more open hubs can make the player feel freer.

Outcome - "So many options!"
The development of custom quest has been the quest to allow game developers to create quests and missions that use these types. However, no matter how well we have researched, some one will come up with a new and creative way of doing quests.

The solution for us was to make the system more customizable. Letting users convert their quest prefabs to quest scripts that automatically inherits the core functionality, so the user can freely add their own additional functionality on top of the existing core
Asset development as fuel - "A learning experience"
Developing this way, splitting the production into sub systems that can function on their own and even be used by others is not something that should be taken lightly, but if you can build something lasting, something others can find value in using, then the final product will be all the better for it. Custom Quest started as a project we thought could be completed in a couple of months, it ended up taking 7.
In part this is because we realised that if we were going to release the system, we might as well do it right, that meant creating a system that was customizable and robust, a system that can be added to the users game and not the other way around, a system we could be proud of.
The experience of developing for other developers is quite different to developing a game. One that has made us much stronger as programmers and as a company, it forced us to think in new ways, in order to create a dynamic and customizable solution. Custom quest has evolved from an asset we could use in Quest Accepted, into a tool others can use to create a unique game experience. All in all, the experience has been a good one and Random Dragon is stronger for it, I would, however, recommend thinking about your plugin and extra time before you start developing.

Sources:
www.pcgamesn.com -"We know you aren't stupid" - a quest design master class from CD Projekt RED
http://www.pcgamesn.com/the-witcher-3-wild-hunt/the-witcher-quest-design-cd-projekt-masterclass
http://www.gamasutra.com/ - Game Design Essentials: 20 RPGs - http://www.gamasutra.com/view/feature/4066/game_design_essentials_20_rpgs.php?print=1
Extra credits - Quest Design I - Why Many MMOs Rely on Repetitive Grind Quests https://www.youtube.com/watch?v=otAkP5VjIv8&t=219s
Extra credits - Quest Design II - How to Create Interesting MMO and RPG Quests https://www.youtube.com/watch?v=ur6GQp5mCYs
Center for Games and Playable Media - Situating Quests: Design Patterns for Quest and Level Design in Role-Playing Games - http://sokath.com/main/files/1/smith-icids11.pdf
Center for Games and Playable Media - RPG Design patterns https://rpgpatterns.soe.ucsc.edu/doku.php?id=patterns:questindex

Special thanks to Allan Schnoor, Kenneth Lodahl and Kristian Wulff for feedback, constructive criticism and background materials.

• When we last saw the sunshine? ... It seems that ten years ago ...
We both wanted to live under the warm sun, so we want to go ...
Having spent ten years in bins, people start an uprising. Rebellion for a place under the sun, which is now occupied by scary creatures .. When people are cornered, patience may be over. And it was over. Without hope of salvation without faith in victory, people are going to fight for own world
You - one of them, clean your city from hundreds of monsters and give of humanity hope of salvation on this night, full of hardcore and aggression!

• By Ahrakeen
Hello we are looking for a second coder to assit with our strategic roleplaying game. it's a unity based engine with the ORK framework.
we hope to have someone help complete our prologue so we can turn this into a complete game.

we are aiming for something close to children of zodiac or fire emblem. but heavily focused on magic and urban legends.
main issue we are facing is getting the combat aspects in place and tie it together with a visual novel package we aim to fit with this

• 15
• 10
• 18
• 9
• 10