Preparing for an upcomming project with 18 collaborators. Advice is needed.

Hi there Uniteers,

Introduction
As a part of my study, I have joined a danish game development program called DADIU that attempts to prepare students for the game development industry by putting the students into groups of 18-20 and develope a single game over the course of six weeks, supported with lectures. The group consist of a varying amount of proffesions; Game Director, Game Designers, Level Directors, CG artists, Programmers, Audio designers and so forth, also a quality assurance team have been assigned to us for doing bug hunting and perform user testing.

In our group, I have been granded the responsibility of leading our team of programmers, and so I am also the responsible for all the technical aspects. Our six weeks period begins at the beginning of November, and so I am trying to prepare as much as possible before we launch into a heavy production period. Two weeks ago, we had a similar production period launched, however this were only over the course of 6 days, in which we learned a great deal.

We will be using SCRUM as our project management structure, and our target application is a tablet device (Samsung Galaxy Tab 2). The goal for the production should be a complete, polished game that can be launched to Google Play store.

Question
What should we remember, when entering a project with 18 collaborators many with different technical experiences?

Current actions, which we already have thought of or have prepared:

• Versioning: We are currently using Git, however it have some restraints related to big files. In the editor settings of Unity, we have selected asset serialization to "Force Text". I have looked into using PlasticSCM, however we don't have the necessary funds to purchase the necessary licens. The programmers use a mix up of different Git Clients, some being just the terminal other SourceTree and GitHub. For our lesser technical experienced members, we will prepare them a GitHub session.
• Build Server: For better collaboration with our QA team, we have already established a build server, that builds at 12:30 and 17:30 every day for a multiple of platforms, however the android build is our primary focus. Because Unity Cloud Build is still in beta, we have created our own scripts to handle it.
• Folder Structure: I will be setting up a folder structure before the actual project begins
• Scene Structure: I will be setting up a scene structure before the actual project begins (This structure may drastically change as we begin)
• GUI: We have decided to work in Unity 4.6, because of its GUI implementation. We have been discussing NGUI and 2Dtoolkit, however we don't have the funds for them. We are trying to avoid Unity's legacy GUI. However, I am a bit short on the restrictions working in a beta may lead us. Can we publish an android build to google play store if build within a beta version?

Considerations to workflow:

• Working in prefabs: Because only one person can actually work in a scene file, we are instructing all programmers and artists to work in prefabs as much as possible, allowing for easier versioning.
• Public inspector values: Programmers have been ordered to make use of public inspector values when it is appropiated, allowing for both artists/designers for easier value tweaking.
• Editor Scripting: We have been discussing whether to implement custom editor scripting, but I don't think we have the necessary time. This also depends on the size and requirements of the editor script.

I know you can't prepare everything before hand, and other complications will of course come, which I haven't forseen. Are these considerations plausiable, am I missing anything crucial that could break or set production to a halt?

Edit: Maybe I didn't express this clearly enough. A team consist of 18-19 collaborators, consisting of a project leader, a game director, a game designer, a level designer, an audio designer, lead artist, 2-3 artists, 8-9 programmers and a lead programmer. However, on the entire DADIU study, six teams are working, each on their own game.

 

Did you plan for milestone scheduling? This will help you determine if the project is too big or too small for your deadline, and help dictate work among your group as well as give everybody a schedule to work with so they can plan their own schedules to meet the milestones.

 

Do not want to be in your shoes. Six weeks with that large of a group is going to be a nightmare. The hardest part I see is actually making the game with the right scope. I've had similar projects, but they were just by myself, so I could keep busy with something minuscule in scope. With such a large team though, it's going to be very difficult to actually distribute enough work to everyone equally.

The biggest thing I would suggest, don't be afraid of mixing up the team structure. Early on it would be fine to have programmers and artist separate, when all the programmers need to be working on the core mechanics and the artists should be together to work out aesthetics. During the latter half, the heavy programming should mostly be done so I would be dividing the teams into programmer/artist pairs to work on level design.

 

Besides the standard precautions when working with a beta ("don't be surprised if there are bugs" sort of things), the only limit on distribution in the 4.6 beta is the fact that the webplayer will not be public. On Android you should be fine.

Good policies in general. I will say, however, that I would highly recommend using editor scripting if you have someone that knows the editor GUI API. Custom Editor tools make everything easier, and I believe that on a large team, this will only be more beneficial. The developers can add useful notes, error checking & validation, and use "more correct" variable names that the rest of the team can use. Without editor scripting, developers basically have to actually restructure their scripts around "how will this look in the inspector?", and that's no way to manage a project.

 

Advice?

* Iterate OFTEN
* Iterate EARLY
* Focus on Functioning code.
* Keep Scope SMALL. Add extra if you finish early. (With 18 contributors, this will almost certainly be your biggest problem)

That would mean, that by the 2nd day, you have already created a Unity project, and had Multiple engineers try to add at least one line of code to it, using a shared repository.

Gigi

 

I personally love editor scripting, because of your exact statement, however based on the experience level of the programmers, I am properly the most experienced editor scripter, while three of the other nine programmers actually have additional Unity experience, the remaining programmers learned Unity a few weeks ago, and still have a lot of the common Unity practices to learn. I personally consider editor scripting to be something for the advanced Unity programmer. But perhaps I'll throw an editor task into the pile if the game see fit for it.

Good points. By using SCRUM we are expected to deliver a fully functional and playable game after each sprint (Which we are either planning to be 3-days sprint or weekly sprints). Your points also fit very well for our QA team, because that allows them to user test / bug hunt already in the earlier stages.

 

Keep in mind that the team consist of 18 collaborators, but only 9 of them are actually Unity programmers having to sit in the actual scripting part.
Related to your advice, we experienced the lack of "Mixing" up artists and programming in the later run. We ended up having artists throwing assets to the programmers who then implemented it, and designers sitting next to a programmer in order to add their tweaks to the game design. We discovered this was horrible, as this created a large overhead to all the programmers, who could have been using their valuable time on more pressing matters, such as bug hunting and additional feature integration

 

Not yet. We are so lucky, that we have a two weeks pre-production period, which will be before the actual six week production period. Within the pre-production period we are to come up with a game concept and design of which I am adressed with the technical matters. Within this period, we are also to expect to create milestones.

 

Bare in mind that I'm thinking to be done with the core programming by week 3/4. Build a playground/jungle gym level to figure out specs for levels and try to get the mechanics to be bulletproof for that level. Know what the level constraints are so that the artist/level designers know how to build levels without causing more headaches.

By the second half, programmers should just be bug hunting and level playtesting. Ideally, the only new scripts that should be made are very simple things to help liven up the levels.

 

You should also consider how you're tracking/visualizing project progress.

One way you can do this is with a Kanban board. The one I use at work and for my own stuff is TargetProcess, though for a group of 20, you'd have to buy a license. Alternatively, you can use a white board with sticky notes and drawn lanes.

The reason this is a good idea, is for at-a-glance situational awareness. If you keep seeing the same ticket staying in a lane for a few days, you know it probably took your programmer longer than they expected, so you may want to either consider breaking the ticket up into smaller, more easily achievable tasks, or some other means of doing what needs to be done.

 

That looks like a really interesting tool, and as they state on their own site, very visual. As for project management and progression, we are using Trello. Attached is an actualy screenshot of our Trello board for the programming team during our six day production period, but a quick glimpse at TargetProcess it appears to me this tool is much more programmer orientated, and also much more powerful. This is of course great, when the team you are responsible for are programmers, but our board of study have suggested we use Trello so they can overview our progress, as well as other members from the different groups may get access to it if necessary. However, I'll put that tool into my backpack of awesome softwares to try out one day

 

In regards to public Inspector stuff, I strongly recommend checking out [SerializeField] and what it can do for you. With inexperienced programmers I guess it might not be a priority, but I find that separating the programmer interface and the Inspector interface of a component is really handy. Eg: just because I want a reference to be settable in the Inspector doesn't mean I want other scripts to be able to randomly change it on me - and with 9 other programmers that could be a genuine concern (ie: I'd want to lock my code interfaces down tight, because otherwise you're seriously risking tripping each other up anywhere two things talk to each other).

Having said that, walk before you run - don't fix a problem that's not a problem yet.

 

3 days is extremely short. Each sprint you need time to plan, review and retrospect. With a large team you will probably spending more than a day on these activities each sprint which doesn't leave a lot of time to actually get stuff done.

 

Applying [SerializeField] to private variables is a habit, I have beginning to adapt but tend to forget once in a while. I think this is a good idea, and I'll try to convey this information to the other programmers, and see if we can make a habit out of it within the six weeks period. I think you bring some valid points, and I also believe its a small neat trick that can benefit the team in the long run.

3 days is really short, but we learned from our teachers that one of the reasons that one major company (I simply can't remember, which company it was, I'll try ask our teacher), have had great succese running with 3 days sprints. But as you also state, the schedule will become tight, and because none of us really are experienced SCRUM users, we might benefit more from weekly sprints rather than 3 day sprints.

 

Okay... honestly, I would agree with others that I am looking at a brewing nightmare...

My first thought is the team composition, 18 people on a six week project is unbalanced on it own. A six week project should have a small team that can sit next to each other with a fixed design that is feature locked. You only got minimal possibilities to play "game studio" with such a short project. Things should only be added, modified or removed if you hit a problem that cannot be solved otherwise. Make sure that everyone knows what they should work on before you start, are they UI artists, texture artists or 3D artists? The same with the programmers, make sure that they know whom is the gameplay, ai, network and graphics programmer etc. Make sure that everyone knows whom they must work together with, prepare a system for managing people that cannot pull their own weight or work together with others. Remember that you got an overflow of programmers and take it into account for planning and game design... nothing is more annoying then to work your ass off when the person next to you have half the amount of work to do...

Make sure that one person gets the role of the game designer and someone else gets the role as the project manager.
The game designer makes calls on game features, graphics and such... the project manager manages time, gets coffee and helps the game designer with talking to people that doesn't behave during the project time.

Keep the overall project small and simple. Like I said earlier, lock the features before you start and do any research before you begin the project. If you do not manage to figure out if a feature is possible before the project starts, cut it loose. Keep meetings short and effective and make sure that everyone is aware of the deadline.

 

Angry, Can you expand on that? I'm curious.
Gigi

 

Do you not know about serialize field, or something else? It actually wouldn't surprise me since no one seems to talk about it. It would be a good candidate for the next learn tutorial, but for now manpages FTW http://docs.unity3d.com/ScriptReference/SerializeField.html

 

Can you tell me more about the benefit? I've used the keyword, for example to save to a data file. Otherwise, I think I'm missing something here.

Gigi

 

I think you are probably talking about something else, one of the other serial/ize/able things. I'm pretty sure there are about a dozen different functions/classes/attributes that use serial in some form and almost none of them are related, except two or three that are about the inspector.

 

OMGGBBQHAXSWORDFISH I love you man (and, Angrypenguin too, for bringing that up.) I had no idea you could do that. Instead of having a bunch of public fields for no good reason, I can make my fields private, and only expose getter/setters and methods as needed! I am squeeing with delight!

 

I've seen this mentioned before, and am a bit curious to the reasoning behind this. My logic is, because they can be changed from the inspector, i.e. outside of my class, they should be declared as public. This way, my code reflects that they are changed from outside, and has to take that into consideration.

 

Somewhere in the dark recesses of my brain, I think I remember knowing this once upon a time. And yet, I had clearly forgotten!

Thanks,
Gigi

 

What online tools will you be using for collaboration and bug/task tracking?

If you don't have one yet, take a look at Trello.

 

For a pragmatic example, I often have requirements similar to the following:
1. I wish to create a relationship via the Inspector, ie: give one object a reference to another, and
2. I wish for that relationship to not change at runtime, ie: it shouldn't be exposed in a code interface where it's presented as something that can be changed freely.

Alternatively, the requirements may be:
1. I wish for a property to be exposed in the Inspector, and
2. I wish for the property to have some constraints or validation applied.

Neither of those are met by just whacking "public" on something. Outside of Unity, making something public tells any other programmer who sees it that a) this thing can be changed at any time and b) there are no invalid values (or, instead, that the programmer who wrote it wasn't paying much mind to the design of their interface).

The tools at my disposal to best meet those and other sets of requirements are as follows:

• Scope keywords public and private. These specify the code interface to an object, ie: they are how other programmers use it. Typically in programming, you only make something public if you want other people to be able to modify it freely, without constraint, at any time. As steego says, you then need to plan for and handle this accordingly.
  
  
• [SerializeField]. This helps define the serialization interface to an object, which is how Unity sees it and, of particular note here, how it get into the Inspector for use by your designers. If you want something to show up in the Inspector regardless of its code interface, this is how you do it. Much like using 'public', this implies an interface that you need to plan for and handle accordingly - see OnValidate() below to help with this.
  
  
• [HideInInspector]. The counterpart to SerializeField. So we can show something in the Inspector interface without exposing it to code, but what if we want to go the other way? What if we want something public for other coders to use, but we don't want designers or other non-coders to have access? Make it public, decorate it with [HideInInspector].
  
  
• Wrapper properties and OnValidate(). Ok, so now we're solid on how to handle both code and Inspector (design) interfaces. But this is just getting data in and out - often that's only half of the job! What about validation and/or constraints? Wrapper properties solve this on the code side just like they do for any other C# code (remember that the get and set parts of a property can have different access modifiers). For the Inspector, we have the OnValidate() method - whenever something is changed in the Inspector this is called, which gives you an opportunity to do any checks or constraints you need. This could be as trivial as pushing each field through its own property to get its setter to do the work: "XProperty =xField;".

Finally worth mention is custom Inspectors. The above gets me everything I need 99% of the time, but it has one notable shortcoming - there's no built-in way to display properties directly in the Inspector, which means that derived properties (ie: ones that don't come straight from a single backing field) can't be displayed. Having said that, there's a good chance you'd need some form of custom control for them anyway, which is why it's so rarely a practical issue (at least for me).

Sure, but keep in mind that the scope keywords are only one tool in defining your interface. My point of view is that [SerializeField] also "reflects that they are changed from the outside", but helps you more by telling you where and how that change may occur (ie: the Unity serialization system). Something declared as...

Code (csharp):

1.  
2. [SerializeField]        // I can be changed via the Inspector at edit time...
3. private float foo;    // ...but runtime I can only be changed internally
4.  

... tells me far more than this:

Code (csharp):

1.  
2. public float foo;   // I can be changed arbitrarily, by anyone, from anywhere, at any time...
3.  

Plus, the former restricts avenues for change to where they're intended to come from, and prompts people to consider what they're doing if they ever need to change that. ("This is private, so clearly the guy who wrote it doesn't expect it to change randomly at runtime... maybe I should wrap it in a setter and see what else needs to be updated when it changes...")

 

I agree completely with this, by the way. Can you not split it into four or five groups?

Given the time frame you need to be making a near-trivial game. Given that it needs to be a near-trivial game, more people won't help make it better and will radically increase overheads. Teams of 3 or 4 would work better, I think. Plus, then as a group you have four or five projects to share and learn from, instead of one, and four or five people get experience as a project lead instead of just one, and so on.

 

Scrum is very popular so one company having success with extremely short sprints doesn't really mean much (given the thousands having success with sprints in the 1-4 week range).

Your project is short so you want to keep short iterations, but your team is large and from the sounds of it not experienced with SCRUM, so short sprints could very well end up with nothing being done (it takes a while to get large groups of people aligned).

As @angrypenguin mentioned your team needs to be split up. Even if you are working on the same game you should be able to profitably divide the work up in to fairly autonomous chunks (e.g. Tools, Tech, Gameplay). These teams can have their own sprints, which will come together at various touch points.

- John A

 

Interesting discussion related to [SerializeField], didn't know it was such an unknown feature. I have no clue how I learned it.

Related to the large numbers of collaborators. There is no way, the groups can be reduced to smaller sizes. The group size is predefined by the DADIU board. But as @angrypenguin states, the games must be trivial, and so they will be. HERE you can find last years entries, produced on DADIU. All the games can be downloaded from the Google Play store (They are all free). As you can see, these games is of a limited size and all are somewhat trivial with a ranging quality. The board have expressed themselves, that they would like to see an increase of quality in our games compared to last years entries.

Personally, I don't see the big issues with being 18 people, taking into considerations that its a learning process. It is expected that we stumble upon issue, fight a little and ends up in management hell. Based on our 6 days project period, we learned all kinds of problematic holes in which you can fall into, simply due to the lack of proper communication across the team. On a team with 9 programmers, you are required to find and distribute work that allows all programmers to work without stumbling over each others feets. If the teams were smaller, we wouldn't experience these issues. But of course, I would really like your opinion on this as well, do you think the large team sizes inhibits learning? Do you think decreasing the team sizes would benefit us students in another way?

Ps. Maybe I didn't express this clearly enough. A team consist of 18-19 collaborators, consisting of a project leader, a game director, a game designer, a level designer, an audio designer, lead artist, 2-3 artists, 8-9 programmers and a lead programmer. However, on the entire DADIU study, six teams are working, each on their own game.

 

I see were you are heading it. During our six day production period, we even tried with daily scrum, simply just for learning. The short sprints weren't executed very well, and SCRUM was left to die in a dark and cold corner during that production period. However, during that production period, we already split the teams work into two different SCRUM boards, one SCRUM board being the artists boards and the other board being the programmers board. The game director, project manager, game designer, lead artists and lead programmer maintained the backlog. Would it be wise to divide the current team of programmers (8-9 members) into groups of 3 to 4 with separate sprints? One team primarily working on backend systems while the other team primarily works on front end?

 

A team that size on a project that small and short? Yeah, I expect it'll inhibit learning... Having said that, it depends what you're learning. If the intent is to make the overheads clear and obvious then perhaps it'll be effective. Is the point to make the work itself minimal and focus on the project team aspects of things?

 

In full honesty, I am not sure of this. I know phrases such as "Preparing us for game industry" have been mentioned a whole bunch of times. Whether this mean learning the overheads or learn how to make a qualitative game, I am not sure of. But based on my gut feel, yes, I think the idea is to make a minimalistic game and learn how to collaborate on larger team with a bunch of people with varying experiences and professions.

 

SCRUM isn't just an iterative development process with sprints and a standup meeting. If you don't have a product backlog, if you don't have a product owner, if you don't have a definition of done, if aren't holding sprint planning, review and retrospective you aren't doing SCRUM. Which is fine, I'm all for adapting methodology to suit the need*, but it is confusing when you use the term SCRUM (with capitals and everything) if you don't mean SCRUM.

* Personally I find SCRUM tedious and its proponents overly zealous ... despite the fact that I sound like one at the moment

 

All of that is true, but we actually try to cover all of those aspects. We have a product backlog which the product owner is our game director. We didn't have defined a "definition of done". I think this was also a concern within our six day project because we never really defined when an entry in the backlog was considered to be done. We tried do sprint planning, review and also retrospective, but because we had daily scrum our schedule looked like this:

Sprint planning were done in the morning, after launch at midday, we had our standing up meeting and at the end of the day we had our sprint review followed up by our retrospective. As you properly can imagine, 15-20% of a day was filled with SCRUM related items.

 

A "definition of done" isn't about how to tell if a given task is done - the task itself should make that clear. It's about knowing when the project is done so that you can stop adding new tasks to it.

If you don't know where your finish line is then you'll almost certainly get scope creep as people come up with cool new ideas that weren't in the original scope. If you don't know where 'done' is then you can't effectively evaluate when to stop adding new stuff and instead start polishing what you've got.

 

Oh, guess I misinterpreted that part during our SCRUM lectures. I always thought definition of done were related to the specified tasks in the product backlog. But as you mention that, that was also a problem we encountered during our six day production, guess I'll have to look it up some more.

 

No in this case @angrypenguin is wrong. A definition of done can apply to a whole project but it is more frequently used to refer to the criteria for completing smaller units like tasks and sprints. Is a task done when the coder writes it? When the unit tests are passed? Is a release done when the testers accept it or the product owner signs off on it? Is a task done if regression testing has not been passed? Is it done if it hasn't passed your static code analysis? Does a sprint need documentation to be done? How about the task definition, if the task definition is not clear how do you say it is done? You get the picture

Of course with a six week project you don't want to be too over the top, but establishing clear criteria is to the benefit of all involved.

 

Fair call. I'll agree with you on releases. In my experience there's always been pre-defined unambiguous terms for all of those things in regards to tasks, though. A task isn't "done" until it has gone through all of the task-related check points in whatever system you're working to, so that concept in and of itself doesn't need any special management. Project scope, on the other hand, most certainly does.

 

Defining those checks is what the definition of done is about though

 

On larger teams, we used the terms, 'Done', and 'Done-Done'. One means, 'Yeah, it's mostly there ... maybe checked in.' The second means, 'Yes, I finished EVERYTHING in our process, I checked it in, it's been reasonably tested. It's done-done.'

The difference is significant and useful, whether the team has one or 20.

Gigi

 

Seems like a nightmare. But I guess you would have each person work on there own section, partition it out. You work on ai, the other does physics, inventory, menus etc

 

I have always found this transition difficult to execute. When are entries considered 'Done-Done' and not just, 'Done'. Is an entry only 'Done' if minor tweaks are missing? If you realise after you have moved an entry from 'Done' to 'Done-Done', that the item wasn't finished tweaked, would you open up a new backlog item for this, an item on the scrum board or would you simply just ignore the practices and just tweak it without informing this anywhere?

Edit: @JohnnyA what is regression testing and static code analysis?

 

Bugs found in something that is 'done-done' are new tasks. Bugs if you have a bug tracking system, or just task-cards, if that's what you're using. On a solo-project, new bugs are new lines on a sheet of paper .

Regression testing is how you verify that older code is still functional. Take a game like Sims (mobile), where they release new versions every 6 weeks - they need a suite of tests to ensure new feature XYZ isn't breaking the whole game! These can be manual, or automated.

Gigi

 

See above for regression testing. Technically static code analysis is analysing code pre-compilation; you can use it for determining metrics like test coverage, or to pick up coding errors that are valid code but are still likely to be errors.

For example you might have a rule which raises an error if it finds a call to Find or FindWithTag that is made on a per frame basis.

 

There are other cool stats like cyclomatic complexity that are useful. Visual Studio often allows you to test the big, general ones out of the box.

 

Is this something which can be done on an automatic basis? Putting up some constraints or parameters in Visual Studio or Monodevelop, or isn't that what we have our profiler for?

 

Oh my, this is very interesting and also a bit scary. I have worked on a rather large project for around 1½ year, and I am a bit afraid of the cyclomatic complexity result on this project. I'll surely take a glance at this, and see if I can make something beneficial out of it.

 

Yes it can be automated:

http://forum.unity3d.com/threads/gendarme-for-unity-a-code-analysis-tool.112552/ (technically it runs against the IL)

http://research.microsoft.com/en-us/projects/specsharp/

and hundreds more, talk to Google

Note that I'm not recommending any of this for a 6 week project, just for discussion purposes.

 

Alright, thanks for the hint though. Didn't knew these type of code analysis even existed
Edit: Why don't you recommend this for a 6 week project again? To me this sounds like a tool which can identify bad practices / habits which potentially can lead to bad and difficult code to read.