Design Project Planning: QwerZoo (name pending?)


New Member
QwerZoo is my planned series of modules relating to hunting, farming, cooking, and ecosystems. It can be summed up with the creed, "functional variety". The player should have many options to find, breed, or create whatever creature, plant, pet, or meal is the most useful to their desires.

I aim for the full QwerZoo experience to include full genetics, with the ability to breed domestic varieties of wild animals and plants that can only be found in specific varieties of biomes. I also aim to have a balance between the realistic, scientific approach (genetics, real-world creatures and behaviors, and true-to-life methods of obtaining objects) and the fantastic, fun approach (no grinding, no overly long processes when a couple steps will do, unrealistic creatures such as from fossils or mythology, unrealistic cross-breeds of different species, unrealistic breeds with useful abilities more akin to Pokemon or Forestry Bees than to real animals).

But just as with Terasology as a whole, I also aim for the player to have full control over what aspects they would like to use, so that they may have simplified animals rather than advanced genetic animals; so that they may choose which types of animal to play with; so that they may decide upon a more fantastic or more realistic balance.

This will require either a large number of modules, or a large number of configuration options. As Terasology is built with automated modularity in mind, that seems to be the better approach, but I am open to all the suggestions and help anyone is willing to provide!

Speaking of which, the name is totally just made up on the fly to describe the whole project. Better ideas are welcome :p And if any of my ideas or features would be better combined into the existing modules or branched out into separate projects, point me in the right direction and I'll go that way.

I've also considered "Terafauna" and "Teraflora" for animals/plants with this system, but again, totally on the spot, suggestions are great.

API MODULE: QwerZoo API. This module includes the frameworks for all of the content modules to register themselves with, so that non-QwerZoo modules may easily query QwerZoo animals or blocks or items for compatibility, and only require this API module as a dependency.

CORE FRAMEWORK MODULES: Built on top of the API will be the modules which implement the primary features of QwerZoo. They are integrated with the QwerZoo API so that all other modules may interact through that base API, rather than requiring any of these modules to be present. They would be separated only to allow the player to choose which aspects to activate, and therefore it might be reasonable to include them all together instead, and use configuration options to enable or disable features.
  • QwerZoo Framework-Behaviors: This module handles the registration and distribution of animal AI beyond the basic "flee, attack, breed" behaviors. Without it, animals will not have advanced features such as flocking, nesting, playing, opening doors, etc.
  • QwerZoo Framework-Genetics: This module adds the genetic system, built on the Genetics and Physical Attributes modules. Without it, all animals of a certain type will be the same, and cannot be bred into other types. If Behaviors is present, Genetics will also allow unique behaviors to be bred into animals that do not have them by default.
  • QwerZoo Framework-Journal: This module bridges the QwerZoo API and the Journal API. Without it, there will not be journal pages for QwerZoo animals.
  • QwerZoo Framework-Spawning: This module handles the addition of animals to the world. Without it, animals will not appear in the world without the use of commands or non-QwerZoo modules.
  • QwerZoo Framework-WorldlyTooltip: This module bridges the QwerZoo API and the Worldly Tooltip API. Without it, there will not be advanced tooltips for QwerZoo animals.
ADDITIONAL FRAMEWORK MODULES: These modules require at least one of the framework modules to be present, as their functions would be useless without them.
  • QwerZoo Framework-Biome-Specifics: This module requires the Spawning module. It changes the system from "spawning animals anywhere" to "spawning animals only in specific conditions, such as types of biome".
  • QwerZoo Framework-Cloning: This module requires the Genetics module. It adds methods of modifying DNA to create new crossbreeds of animal that are not obtainable by normal breeding.
  • QwerZoo Framework-Archaeology: This module requires the Cloning module. It adds fossils which can have DNA extracted to clone extinct varieties of animals from their bones.

: These modules exist solely to collect all the modules above into a single button click for the player.
  • QwerZoo Base: Requires Behaviors, Genetics, Spawning, Archaeology, Biome-Specifics, and Cloning. If configuration is chosen over modularity, those are the modules that would be combined together.
  • QwerZoo Compat: Requires Journal and WorldlyTooltip.
FULL MODULES: Animal or plant types are grouped into modules by their genetic family. For example, chickens, peacocks, and turkeys would be in the same module, as they are all in the Phasianidae family. But ducks would not, as they are in the Anatidae family.
- QwerZoo Full-Phasianidae: An example of a full module, containing the full variety of chickens, grouses, peacocks, pheasants, quail, and turkeys, and the subspecies and breeds thereof.

SIMPLE MODULES: The Simple modules each add a single species of animal, with no subspecies or breeds, and which cannot be interbred with each other. Intended for players who do not want to use the Genetics module. Not intended to be used alongside the equivalent full module, but simple and full modules of different types can be used interchangeably.
  • QwerZoo Simple-Phasianidae [Chicken]
  • QwerZoo Simple-Phasianidae [Junglefowl]
  • QwerZoo Simple-Phasianidae [Peacock]
  • QwerZoo Simple-Phasianidae [Pheasant]
  • QwerZoo Simple-Phasianidae [Quail]
  • QwerZoo Simple-Phasianidae [Turkey]: Examples of the simple modules that would be available as alternatives to the example full module.
GROUPING MODULES: Grouping modules are collections of plants or animals gathered by similarity, allowing for many of the content modules to be installed at once.
  • QwerZoo Group-Full-Birds
  • QwerZoo Group-Full-Ungulates
  • QwerZoo Group-Full-Rodents
  • QwerZoo Group-Simple-Lizards
  • QwerZoo Group-Simple-Fish: Some examples of the groups.
OMEGA MODULES: The two Omega modules contain all the group modules and some of the functional modules, allowing the full QwerZoo experience without needing to hunt everything down.
  • QwerZoo Omega-Full: Requires Core, Compat, and all Group-Full modules.
  • QwerZoo Omega-Simple: Requires Behaviors, Spawning, and all Group-Simple modules.
Naturally, this is a lot of modules. Quite possibly, it's too many modules. It may be easier to instead remove several stages [such as the framework stages or full/simple stage] and use configuration options to enable or disable the features within, rather than having so many separately maintained downloads.

  • Less hassle to maintain when it is kept together in one repository as one module
  • Less clutter in the module list
  • Less intermodule communication required
  • Larger downloads required if the player does not want all the features
  • Separate configuration screen required, not just module installation
  • More if/then checks inside the code, and if parts are disabled, more code loaded into memory but not used
Ideas, additions, corrections, reductions, anything is welcome!


No need to re-invent the wheel for everything. there are already some existing framework modules that can do some of what you are asking. you just need to : I think it would be a better use of your time trying to integrate some of these framework modules together into something cohesive.


New Member
That's the plan, but some of them need to be fully integrated with each other in some way before they are what I need. Genome is a good base API, PhysicalAttributes has good stats, but they don't combine with each other on their own. It's possible that some of them could be integrated by modifying the modules rather than building a bridge module, and if that's the case, I'd definitely want to start there instead of adding extra layers that aren't needed.


Org Co-Founder & Project Lead
Finally had a chance to read the full thing, and this really is the exact kind of thing we need to flesh out more best practices and make sure we have solid foundation style modules in general. Definitely consider reworking existing modules that seem relevant to your interests as in most cases they likely just have been pushed along far enough to serve some single contributor's purposes once possibly quite long ago. For instance the original "Spawning" module was started with all kinds of good intents to serve in a variety of places but its author then got busy instead, uh, project managing ... ;)

You probably would want to closely follow a few of our GSOC students over the summer, particularly @Soundwave since he's outright working on genetics with bees. While thanks to GSOC he's meant to follow a specific project outline we wouldn't be able to outright merge all the things into a bee-filled zoo you probably should catch up when able to share ideas and review code & architecture. The Behaviors project and Health system may also be relevant, for the AI and the potential of Health getting into more module and architecture best practices.

Bees is additionally meant to help sort out more wisdom around modularity and how to organize, plus one of the mentors had an initial GSOC plan for last year that likewise involved how to better provide more fundamental systems for better supporting modders in creating solid content :)

Should we maybe throw you into the mix for Bees just as an interested observer if nothing else? Might be a good way to stay aligned. Ideally you'd be able to make the weekly catch-up session to talk design and such.

Edit: Oh, for module sizing then yes smaller modules and more magic in gluing them together. @jellysnake would likely love more excuses to get into optional dependencies and fun stuff like that. Ultimately we need more configuration / UI work around larger groupings of modules.