Also, in perforce you can set a client ‘revertunchanged’ which cuts out half of step 5, at least.

But yeah perforce’s checkout-to-edit model doesn’t do it any favors in this situation. git behaves more like a filesystem snapshot, which makes this sort of workflow MUCH simpler.

Most of the time we didn’t bother trying to fix conflicts – most of the time one of the involved parties was a non-programmer.

It’s human-readable, but not quite human-understandable, especially once the structures get more complex. You’re basically hacking raw Unity data.

Some of the feedback I’ve gotten on Twitter suggests to me we’re not the only ones taking that approach. A friend suggested making smaller changes before checking in, but that already smells of a limiting workaround to me.

Plain text asset serialization mode will not necessarily address the specific issues you’re running into, but it does help reduce the chance of conflicts when e.g. two people check in changes to the same scene file. (The chance of conflicts with binary assets in that case is probably close to 100%.)

Even if there is a conflict, with YAML files you at least have a chance in hell of fixing it without just reverting someone’s work because you can see and resolve the conflicts with a regular text editor. It might just be that one section of the YAML file needs to be moved or a choice has to be made between a some simple numeric values. The files really aren’t that difficult to figure out, especially if you’ve had occasion to use YAML before.

Maybe something to try, if you haven’t already.

Horror stories like yours make me want to re-think this plan…

I just ended a 2-year project that had 17 engineers working in Unity. Our solution? Don’t do all the things Unity does for free.

Basically, we built a text-driven system to describe a UI and a UI framework. We built an external asset pipeline and a system for loading assets at runtime. And we built most of our code into DLLs that were built separately. The only thing we actually did in Unity was debug.

All that stuff with the IDE — seductive, but doesn’t scale. Neither does Team License.

I never had to quit Unity for things to work; even when checking out other branches, it would reload things sensibly.

When committing changes, “git add -A” picks up all deleted, edited, and newly created files easily, so don’t have to hunt down .meta files in general. On the occasions where I didn’t want to commit everything, I’d selectively add or selectively unstage files before committing.

Merging prefab changes is easier than scenes—changes to them are smaller in scope and they change less often anyway. So I use lots of prefabs for things shared between scenes.

Merging scenes is pretty much impossible. So instead of changing a scene in a branch, I generally create a new one for that branch and make changes to it. When it comes time to merge a branch, I make sure that the bits I want are in a prefab, and I can add that prefab into the master scene. This would kinda work for multiple people too, but it would still be very inconvenient at best.

The real problem you seem to be talking about doesn’t seem to be the techniques per se, but rather storytelling in general. As long as you’re trying to tell a specific story you’re taking control away from the player. You may be able to let the player control in the order in which things happen and such, but ultimately it’s still all scripted in some way. Let the player control the story and you aren’t telling a story anymore, but rather you’re providing a setting for the player to work with (which also means you’ll need to approach it with a completely different mindset).

Mind you, the techniques you describe still can have their place, especially for games which merely have an excuse plot (i.e. where the plot is there just to justify the gameplay rather than being important). In fact that’s where their use originated. You may use cutscenes or scripted events to give an excuse as to why something happens in a specific way and then let the player move on as usual.

We’d like to invite you (Jurie and Andy) to visit our site. We’ve launched 20 days ago.

That means we’re still in the starting phase, and we’ve taken steps to monetize our website. We came by your names due to Twitter suggestions!

We’re in need of enthusiastic, internationally minded programmers who want be part of our tech team our front end developer in innovating our website for an international audience.

At this moment, we ask for volunteering, open minded people who love the world of audiovisual entertainment.

We ‘pay’ our visitors and members with cool prizes (or sometimes plain giving a way) like video games and the like. We offer a knowledge sharing community about videogames, e sports and movies (all within the spectrum of audiovisual entertainment).

We are also Dutch and we also have our minds set to in international stage. Since you’re Dutch and maybe want to set foot in the US, you seem like an interesting party to get into conversation with!

There’s a lot more to be mentioned like the coming Epic Cyber League, an Epic Wiki and more… Please visit us: http://epicdome.com

Kind regards,

Pim Piepers
Executive Creative Director
EpicDome.com