Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualrpiller

Posted 30 May 2013 - 09:15 PM

@Apoch Your analogies are funny. A little extreme but funny smile.png. 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 smile.png

 

 

 
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.


#1rpiller

Posted 30 May 2013 - 09:10 PM

@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 demon/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 () {
 
}
}
 

 

 

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.


PARTNERS