@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different.

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

I think I'm going with a basic bomberman clone. Writing up the components required now.

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other or changes from the designer are so drastic that programmers get pissed and quit. Instead of accepting that I'm simply trying something different.

Some components "might" be game specific, but the idea is to try and minimize these and make more generic components. Instead of a ghost personality component I could have a hunter/runner component that can be reused in a FPS game. Some enemies will hunt the player some will run from it. Those are traits found in many games. Breaking components into their true functionality vs the game functionality. Then linking them together to get the game functionality.

@phil_t I haven't checked that out yet. Will give it a read now. Thanks for the link!

@Apoch Part of my approach is changing code design to fit project management to get the game finished because that's the goal. If the game has some inefficiencies but is completed and completed quickly, I'll take that over perfect code design but becomes messier and harder to ever complete (again in indie more so). So even if we have game specific components, building those components in isolation is still better for project management. It's easier to make and easier to test/debug and easier to change. It doesn't require waiting on other components and when those components change it doesn't require my component to change just because that one did even if the functionality in mine stays the same. That's my take on it anyway.

@Apoch Your analogies are funny. A little extreme but funny . I wouldn't consider what I'm trying "extreme". It's noted that you don't agree with what I'm doing. Thanks for your thoughts on the topic though as it's always interesting to hear the other side even if I don't agree at this time.

Huh. Message-passing is a very loose form of coupling, but it's still coupling.

I agree. My main approach is about not directly coupling the insides of the components so they are easier/faster to make, less error prone, and more plug and play without dependencies. So programmers aren't tripping on each other or waiting. They make their components to spec and move on. The 1 design master is the one that hooks the components up together. When people come and go on your project it's less damage to the overall project because their roles were making isolated components instead of possibly tightly coupling their code possibly making a mess and making changes bug ridden and "scary".

Part of the motivation is that the connection of components can be abstracted in a GUI (flowgraph or traditional UI elements) allowing designers or non-programmers the ability to create games with pre-designed components.

To track status of the progress I found some time to make basic movement functionality in unity and move my character around for the bomberman clone. I have a KeyboardInput & BasicCharacterController component that are being linked together below via events. Below is an example of what the master designer would be doing. I don't see it as all that complicated. I think it's nice because I could have "farmed" these 2 scripts off to 2 different programmers and they wouldn't even need to know about each other. I can also have them modify the insides and as long as they keep the interface the same this continues to work. This is a simple example to start with of course. It'll get more interesting as I continue

 
public class BombermanGame : MonoBehaviour {
 
// Use this for initialization
void Start () {
 
GameObject player = GameObject.Find ("bomberman");
 
// connect bomberman input events
player.GetComponent<KeyboardInput>().OnKeyW += player.GetComponent<BasicCharacterController>().MoveNorth;
player.GetComponent<KeyboardInput>().OnKeyA += player.GetComponent<BasicCharacterController>().MoveWest;
player.GetComponent<KeyboardInput>().OnKeyS += player.GetComponent<BasicCharacterController>().MoveSouth;
player.GetComponent<KeyboardInput>().OnKeyD += player.GetComponent<BasicCharacterController>().MoveEast;
 
 
}
 
// Update is called once per frame
void Update () {
 
}
}
 

What I gain: 2 very reusable non dependent components that I can plug into many different game types. I could create a more advanced character controller component and still attach it to the same KeyboardInput controller without having to modify it or have different copies of it based on which controller I'm using. Hooking these up is easier than making a copy of it and hunting inside to make it fit the AdvancedCharacterController, or duplicating logic for each specific game.

Next up is dropping "bombs" with the space key. I think I'm going to create more of a PrefabSpawner component that I can assign a prefab GameObject property that I can drag whatever prefab object I want to create at design time (in this case a bomb) and a Create() method to actually create it. This still leaves things fairly decoupled and from specifically making a Bomb game object in a component script and makes it generic and reusable.