Propagating Game Design Changes Without Code Duplication?

[mxdubois]

Hey guys,

Lately, I've been thinking about how best to maintain separation of concerns between the unity game implementation and it's mobile counterpart. One of the biggest areas of concern is shared assets and game entities. We've got a pretty great, agnostic solution for passing the game state (model) around in JSON, it's true -- but to actually interpret, render, and update that information on the phones, we need some "insider" knowledge about how it's structured and what it represents.

For example, in order to display a turret, AR needs to know that a turret is a thing that has an x/y/z coordinate. They need to know that it is represented by the turret.h file in the mobile group's assets folder. When it fires a bullet, they need to know what a bullet is, and what file to represent that with, etc.

Naturally, one solution to this problem is that mobile components create internal classes for each entity, as the game group conceives of them. But what happens when the game group decides to change a turret? Perhaps they have a new wireframe for turrets. Well now AR needs to ask the game group to email them the new wireframe so they can replace it in their repository. All of a sudden, everytime the game group wants to change something, they have to propagate their changes to two or three different places. Not only that, AR and Mobile have to know about how the game is designed -- which undermines the modularity Joel expects from us

Is there a better solution? I think so. There are probably a lot of ways to handle this issue. The one I've thought of has the mobile group implement a game update function that downloads assets and game entity templates from the server when the game is launched. I don't yet have a proposal for what the form of these templates would be, but somehow they should define, in a uniform manner, how each game entity behaves -- what assets represent it, what kind of properties it has, how it relates to other objects (esp. child objects), etc.

I foresee the JSON for game entities in the gamestate looking more like this:

    { //Root of gamestate
        ...
        "entities" : { // Representable entites
            "[OBJECT INSTANCE ID]" : {
                "objectType" : "[NAME OF OBJECT TEMPLATE]",
                ... // properties
            }
        }
        ...
    }

I don't know too much about how things in Unity break down, but I assume the turret is in fact two (or more) parts. The base and the head, at least, right? So we will probably need a way to specify parent/child or at least relative positioning relationships between complex objects.

What do you guys think of this? Any proposals for how we could implement such a system? Or alternative proposals?

[d-bahr]

As for the game assets, I propose a simpler alternative that will be a lot less work in the long run. We (the game engine group) can give the AR group what simple models we have (which could be a simple as a cube) simply to use a placeholder. The AR group should be able to do everything they need to do with those model "stubs" while we put the finishing touches on everything. Then, come December, we will give you finished models and you can recreate whatever .h files you need.

This means you only need to do two rounds of creating .h files, and you don't have to spend the time creating an automated deployment process (which actually would be a lot harder than it sounds).

Obviously, both the AR and game groups will need to know the details of each asset -- that the turret has multiple parts and the top rotates, and so forth. I don't see any problem with each side having different (hard-coded) cases for each asset. That's pretty much what we do right now, and while it may not be as robust, it will take far less time since we only have 4 or 5 assets to pass back and forth. Additionally, I don't foresee any of the assets changing dramatically in the next few weeks, so we won't have to constantly revise code.

I realize that all this depends on the AR group getting all of the assets from the game engine group in a timely manner, but I do think that this is the best course of action to take.

~Dan

[matthewcburke]

My gut reaction is to agree with Dan. Since we have a relatively small number models to pass pack and forth, it is going to be simplest to convert them by hand, and have "different (hard coded) cases for each asset."

Michael, I think your solution is a better long term solution, but I don't know if we have the time and resources for it?