Code dependencies
Are you struggling to make a given set of scripts from a project compile error free? If that is true, then you are in the same boat as I am right now. I have come across projects where logic is scattered around to get a functionality out of the pipeline with limited value to object oriented programming, and the most valuable and time saving of all is the plugin architecture. This is as best as it can get. Let me explain..
A producer has an idea and wants to make a quick prototype. He opens a new project, drags and drops the packages he needs and boom the game runs. Obviously you don't expect a producer to code (unless he is from development). The game would not be perfect, but at least it would get the ball rolling and you don't need a developer to assist the producer.
Now, to do this, you would want the packages to follow a common rule. You can do this using an interface and have classes implement them. For example, the avatar package and the pet package can implement the IObject interfaces with a set of rules. The avatar package is responsible for downloading the avatar and instantiating it with per-defined states which the pet package is for the pet. Also it is important to keep the implementation of these packages to the minimum set of features so that anyone can extend it as they want in a particular game based on the design and requirement.
It is common to make use of a state machine in games. The flow is most often controlled using if - else or switch - case statements. A better was to manage this is to define each state like shown below
public interface IState
{
void DoAction();
}
public Jump : IState
{
public void DoAction()
{
if(Input.KeyUp('A'))
{
// Execute jump action
}
}
}
public Idle : IState
{
public void DoAction()
{
// Execute Idle action
}
}
You could have a single IState instance in your state machine and call the DoAction and completely eliminate the switch case statement. The state machine just simply does not care or is not interested to know what it is. It simply executes it.
The second important feature is making the system event driven. You might want to listen to when an avatar jumps, lands or goes to idle. You can achieve this using delegates and events. This way, you don't need class definitions spread across files and thereby resolving dependencies.
A producer has an idea and wants to make a quick prototype. He opens a new project, drags and drops the packages he needs and boom the game runs. Obviously you don't expect a producer to code (unless he is from development). The game would not be perfect, but at least it would get the ball rolling and you don't need a developer to assist the producer.
Now, to do this, you would want the packages to follow a common rule. You can do this using an interface and have classes implement them. For example, the avatar package and the pet package can implement the IObject interfaces with a set of rules. The avatar package is responsible for downloading the avatar and instantiating it with per-defined states which the pet package is for the pet. Also it is important to keep the implementation of these packages to the minimum set of features so that anyone can extend it as they want in a particular game based on the design and requirement.
It is common to make use of a state machine in games. The flow is most often controlled using if - else or switch - case statements. A better was to manage this is to define each state like shown below
public interface IState
{
void DoAction();
}
public Jump : IState
{
public void DoAction()
{
if(Input.KeyUp('A'))
{
// Execute jump action
}
}
}
public Idle : IState
{
public void DoAction()
{
// Execute Idle action
}
}
You could have a single IState instance in your state machine and call the DoAction and completely eliminate the switch case statement. The state machine just simply does not care or is not interested to know what it is. It simply executes it.
The second important feature is making the system event driven. You might want to listen to when an avatar jumps, lands or goes to idle. You can achieve this using delegates and events. This way, you don't need class definitions spread across files and thereby resolving dependencies.
Comments