I need advice about custom libraries/frameworks and relevant design patterns

[EYEris]

I am in the process of creating a framework used for developing mostly simulation-type games (but, a general game framework is the ultimate goal). As a result, I am attempting to plan out several fundamental systems and subsystems (including Events/Messaging, Actions/Behaviors, Dialog/Quests, Substance/Materials, Inventory/Crafting, Geometry/Graphics, Movement/Animation, Audio, etc.) that will all conform to the same ideology and work together efficiently.

In pondering these systems I realize, while they should each be their own distinct systems, there is some overlap among them I feel could be abstracted.

Within Events/Messaging, sending and receiving could be seen as actions, and be based on the Actions/Behaviors system, but could also be extended to other systems like Dialog, Quests, etc. It would rely heavily on Observer and State patterns but would also likely utilize some combination of Abstract Factory, Object Pool, Adapter, Composite, Decorator, Chain, Command, Iterator, and Strategy patterns as well

Within Actions/Behaviors, you will be paying attention to States (in an HFSM) or to a "Plan" (ActionList, DT/BT), and listening to Events. It would also rely heavily on Observer and State patterns, but also on Command, Iterator, and Strategy patterns, and probably utilize some combination of Abstract Factory, Object Pool, Composite, and Decorator patterns too.

These fundamental systems would support most of the other systems and subsystems in some way because almost every (not all) object is either something that has Actions/Events associated with it or is something that could be abstracted to represent something having an Action/Event relationship. Each of the following systems would be built on top of them to some degree.

The Inventory/Crafting system would use Substances/Materials systems to craft and modify items, as well as define attributes of the item (burnable, meltable, etc.) which, in turn, can affect the item's State. The Inventory System would also be used by the Trade and Equipment Systems. These systems would definitely use Abstract Factory, Decorator, and State patterns, and would also likely utilize some combination of Object Pool, Command, and Observer patterns.

The Substance/Materials system would be used primarily by the Crafting System as components for other items, however, not only could the items properties, attributes, and effects depend on the substances and/or materials it's made from, the substances and materials themselves could be altered through Crafting/Refining or could have properties, attributes, and effects of their own. (i.e. Gold can be looted, mined, refined, crafted into jewelry, or minted into coins. Gold rings can be equipped. Gold coins are currency. Each can be traded, has properties such as density, hardness, melting point, and conductivity). These systems would

... You can see where this can get out of hand. Maybe this discussion should be about the patterns I *wouldn't* be using. lol. Even while trying to describe things simply (leaving much out in the process), it still gets rather complicated and somewhat overwhelming.

Allow me to digress and focus on one abstract concept.

Within the Actions/Behaviors system, there are two fundamental types, or "themes," I can describe. They are very similar, yet have some important distinctions.

For the first type, suppose we can make the following statements about the abstract classes in some of the systems. We could say, "Actions are performed. Behaviors are done by performing actions," or, "Goals are reached. Achievements are achieved by reaching goals." We might also say, "Tasks are completed by performing actions," and, "Quests are completed by completing Tasks," and, "Missions are completed by reaching goals." Each of these represents a, usually one-directional, hierarchical relationship where the state of one object depends on the state of another.

For the second type, suppose we can make these pairs of statements: "A question can be answered and, an answer answers a question," "A lock can be locked or unlocked, while a key can lock or unlock locks," and, "Problems and puzzles are solved by solutions, and solutions solve problems or puzzles." Each of these statements also represents a hierarchical relationship, however, these are usually two-directional and involve at least one specific action or behavior. Yet, only one of the objects in the relationship has a State that can be affected.

As far as design patterns are concerned overall, I see aspects of observer and state patterns most prominently, but nearly all behavioral design patterns could be utilized here, as well as several structural patterns like Composite, Decorator, and Facade patterns, as well as Abstract Factory pattern for Crafting, and possibly Messaging as well.

I'm assuming each of my systems (and subsystems) will want to implement many elements from several of these patterns, in a sort of hybrid approach, but I'm struggling to make enough sense of all of it to get anything done.

As I said in the beginning, I would like this to eventually turn into a stand-alone library of generic abstract classes, interfaces, and static methods that can be used in the development of simulations and games. I personally plan to utilize this in Unity3D, but I prefer this framework doesn't depend on Unity libraries (or any other libraries for that matter) to function. That being said, I don't want to reinvent the wheel if I don't have to, and I know there's a lot of useful tools already built into .Net I can take advantage of (such as Linq, Actions, Events, Delegates, etc.), and Unity has many built-in systems and tools for things like Events, Input, UI, Physics, Audio, Animation, AI, etc. However, developing this framework within a Unity environment restricts me to specific Unity-compatible packages, and I can't use the latest C# and .Net features.

I'm wondering where I can (and should) leverage these tools, and where I can't (or shouldn't). Is Microsoft's concept of Actions/Events compatible with my ideology? Can the state machines used in Unity's Animator be generalized to a Hierarchical Finite State Machine or Behavior Tree? Does its AI System have tools that could be used for Actions/Behaviors? Can I even develop this framework in a way that can be utilized within Unity's workflow without tightly coupling or having unnecessary dependencies? To what degree will I have to create my own custom classes and define my own functionality?

Any advice, criticism, opinions, or any other kind of feedback for any of these topics would be highly appreciated.

 

[Gloops]

Hello,
It is a very good idea to have a well structured code.
That being said, the word "system" raises me an alert.
I recently wanted to select the lens window, to be able to reduce the zoom. Normally you can reduce the zoom with the [{Windows} -] keys (with - from the numeric pad), but many laptops do not have any numeric pad.
You cannot select the lens window with the mouse, as if you zoom on a part of the screen, the lens window has chances to be outside the screen (the lens window is an expression I translate from French, but I imagine you have no difficulty to see what I mean, depress the [{Windows} +] keys to see).
So, I selected the window based on its title. It has to be adapted per culture, but on my machine it ran pretty good.

But my machine has 32 GB of memory and a quick processor. On another machine with 8 GB of memory and a more modest processor, it took more than thirty seconds to do the job. You cannot ask the user to wait thirty seconds to reduce the zoom, and I presume the same is true in a game context.

So, I said the user to depress Ctrl Alt Space, to be able to see the lens window and click on it. I later discovered that having different keyboard drivers could help.

On a Microsoft C# forum, I was said that C# was not an adapted language for this task, C++ had to be considered.

So, maybe the word system has not to be taken too literally, but otherwise you have to take into account this aspect that C# is a several compilation layers language, which induces delays, that are acceptable for some tasks, but not for all.