Just some misc stuff about decorations, while I'm at work…
Each decorator expects a WorldData to be passed into the constructor. This will be changing (er after the terrain generation is done, of course :). Instead, the WorldDecorator will just pass in its reference to WorldData to each decorator. IDecoration.Decorate() will be changed to expect a WorldData parameter. This should make setup a little cleaner.
Only one decoration will be placed at a block. Right now, multiple decorations could be placed at the same location.
I'd like for decorations to be able to say "After I am placed here, don't place anything else within a certain distance." This could speed up the decoration placement process and prevent unwanted clutter.
Some other rangom thoughts:
It might be a good idea to have a base decorator class that all decorators are subclasses of. This decorator base would have common functions like:
IsEmptyArea() - determines if an area is just air.
CreateSphere() - creates a sphere at the given location of the given blocks. Trees use this a lot.
CreateDisc().. create a disc shape, also used by trees.
(other shapes can be added also)
I'd like to eventually have the ability for decorations to be something besides just blocks. For example, you might want a fruit tree. The tree would be made up of blocks, but you might want an actual Unity gameobject and models to represent the fruits that could react to collisions, drop, explode, whatever. They could have physics, the whole deal.
I haven't put a -lot- of thought into this, but essentially the decorators would have access to a list and would add information to that list. The information would specify the object type, location, orientation, etc.
Somewhere in the game Update loop, it would monitor this list, and be responsible for creating Unity gameobjects of those types.
Anyway, just some food for thought.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rather than a derived class, I think the interface setup is a better option. That way, so long as it meets the criteria, it doesn't matter what you're putting in place.
I will definitely by putting non block objects into the world, so that is a big yes! Putting in base sets of shapes would make it easier to mod in more complex ones later.
A decorator manager list would be good, with the ability to add decorations on scene change (for example, from an overmap into a map zone with a specific biome).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think decorators will ultimately be responsible for adding anything to the world other than terrain or player created stuff. You would have an enemy decorator for adding creatures, trees, etc.
Maybe the list would be a list of <Entity>, where the entity class would contain
string type ("Blob", "Apple", "HealthPowerUp", etc)
Vector3 : Location
Vector3 : Orientation
or maybe a matrix for this instead.
At the "Top", Unity would have a script responsible for actually creating gameobjects for these entities. It would have a dictionary of prefabs by entity type. So it would look something like this:
<"Blob", BlobPrefab>
<"Apple", ApplePrefab>
If Unity can handle dictionaries in the inspector. The game designer would just add a new element to the dictionary with the correct entity type, and the prefab to create for that type. Wallah!
How does that sound?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just some misc stuff about decorations, while I'm at work…
Each decorator expects a WorldData to be passed into the constructor. This will be changing (er after the terrain generation is done, of course :). Instead, the WorldDecorator will just pass in its reference to WorldData to each decorator. IDecoration.Decorate() will be changed to expect a WorldData parameter. This should make setup a little cleaner.
Only one decoration will be placed at a block. Right now, multiple decorations could be placed at the same location.
I'd like for decorations to be able to say "After I am placed here, don't place anything else within a certain distance." This could speed up the decoration placement process and prevent unwanted clutter.
Some other rangom thoughts:
It might be a good idea to have a base decorator class that all decorators are subclasses of. This decorator base would have common functions like:
IsEmptyArea() - determines if an area is just air.
CreateSphere() - creates a sphere at the given location of the given blocks. Trees use this a lot.
CreateDisc().. create a disc shape, also used by trees.
(other shapes can be added also)
I'd like to eventually have the ability for decorations to be something besides just blocks. For example, you might want a fruit tree. The tree would be made up of blocks, but you might want an actual Unity gameobject and models to represent the fruits that could react to collisions, drop, explode, whatever. They could have physics, the whole deal.
I haven't put a -lot- of thought into this, but essentially the decorators would have access to a list and would add information to that list. The information would specify the object type, location, orientation, etc.
Somewhere in the game Update loop, it would monitor this list, and be responsible for creating Unity gameobjects of those types.
Anyway, just some food for thought.
Rather than a derived class, I think the interface setup is a better option. That way, so long as it meets the criteria, it doesn't matter what you're putting in place.
I will definitely by putting non block objects into the world, so that is a big yes! Putting in base sets of shapes would make it easier to mod in more complex ones later.
A decorator manager list would be good, with the ability to add decorations on scene change (for example, from an overmap into a map zone with a specific biome).
I think decorators will ultimately be responsible for adding anything to the world other than terrain or player created stuff. You would have an enemy decorator for adding creatures, trees, etc.
Maybe the list would be a list of <Entity>, where the entity class would contain
string type ("Blob", "Apple", "HealthPowerUp", etc)
Vector3 : Location
Vector3 : Orientation
or maybe a matrix for this instead.
At the "Top", Unity would have a script responsible for actually creating gameobjects for these entities. It would have a dictionary of prefabs by entity type. So it would look something like this:
<"Blob", BlobPrefab>
<"Apple", ApplePrefab>
If Unity can handle dictionaries in the inspector. The game designer would just add a new element to the dictionary with the correct entity type, and the prefab to create for that type. Wallah!
How does that sound?
I think that would be a good way to go.