Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scene Building vs. Runtime Instantiations #38

Open
antfarmar opened this issue Dec 21, 2015 · 1 comment
Open

Scene Building vs. Runtime Instantiations #38

antfarmar opened this issue Dec 21, 2015 · 1 comment

Comments

@antfarmar
Copy link
Owner

Currently key game tokens (e.g. the Ship) are instantiated at runtime (traditional method) instead of already existing in the scene. This means that there is no instance reference of them to easily drag & drop into the Inspector for other tokens that require them. Rather they are passed around as parameters, or registered, or "found", as is normally done in non-Unity games.

Since this is a Unity game, perhaps it would be best to take advantage of its features, like editor scene building & reference dragging, rather than do things in the "traditional" non-Unity way!?

It would make some things easier, but it may also encourage bad programming habits.

@ghost
Copy link

ghost commented Feb 7, 2016

So I guess one has to consider what the price for a certain solution really is. There are obviously many considerations to keep in mind. Each solution most likely place a constraint on the system. This constraint that developers typically aim to avoid are those that tend to create a "ball of mud", but there are others like harm toward reusability, that may be (for game dev) a secondary target to avoid.

Before you unleash the most complex solution, I guess it wouldn't do any harm thinking along the lines of KISS/YAGNI. If you can get by with a static registration/accessor, I guess you should just go for it. If it cause issues, figure out why and find a solution that solves that particular issue. If the game runs, what harm is there left to fix? How bad is it, really? In reality, when can you foresee your existing solution becoming a proper problem and how hard do you think it'll be to solve it later on?

// KISS variant
static class GameTokens
{
    // Impl. omitted, but easy to figure out...
    // Ofc, OnShipAvailable should callback immediately
    // if ship already has been flagged as available.
    public static void OnShipAvailable(Action<Ship> ship);
    public static void ShipAvailable(Ship ship);
}

And some usage...

public class Ship : MonoBehaviour {
    void Awake() {
        GameTokens.ShipAvailable(this);
    }
}

And some more...

public class ShipDependent : MonoBehaviour {
    Ship ship;

    void Awake() {
        DisableUntilShipIsAvailable();
    }

    void DisableUntilShipIsAvailable() {
        enabled = false; 
        GameTokens.OnShipAvailable
        (s => 
            ship = s; 
            enabled = true
        );
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant