@JHaywood:
We do share tools - yes - although not extensively. A lot of the tools that we’ve created are very project specific. We’ve documented all of the general tools that we’ve written here and shared them around with the guys up north. We’re using a lot of the processes and methods here for various things that they developed up there. There’s a pretty good amount of sharing, but we’re not working with them closely on a daily basis.
I asked the question of the Bioware folks in the introductions thread, but as per Rob’s request, I’ll open it up to the larger audience.
If you work at a company with multiple offices, or multiple teams within one office, or are a first party developer for one of the console makers, do you share tools between teams/developers?
While I was at Treyarch, we had multiple teams in the same building, different floors, but didn’t share much tech at all between them. Everything was pretty much project specific. I remember even being involved in some sort of trade agreement where I wrote a tool for the animators on another team, and we got one of their artists to help create content.
And I can’t think of any instance where there has been any sharing with other first parties here at Bungie. I think there were some attempts to start up some inter-developer discussions before I got here, but they didn’t last long.
I remember hearing at one point, and maybe Judd can comment on this, Naughty Dog and Insomniac sharing engine code for their platformers, at least in the past.
So in general, what are your experiences, and if you have been involved with sharing tech between projects has it been more of a help or hinderance, and what level of technology was involved?
Here at Volition, we try to do as much sharing as possible, however a lot of the time, little to no communication between teams/projects is the biggest culprit of missed opportunity. Having said that, a lot of the tools we write are project and pipeline specific, so it can be difficult to abstract out a particular tool.
Most of our sharing comes from a set of common libraries we build that project specific tools use. I would say that this has been pretty helpful.
The primary problem we run into here (which we have been trying to be much better about) is hardcoding paths and other things like a project name. This is when the sharing of tools has become a hindrance, at least initially.
While we share some of the higher-level stuff and workflows, the tech exchange between projects has been non-existent on the tech art side. Much of what we do IS project-specific, yes, aside from the hardcoded paths issue (which we’ve primarily solved, I think). But there are many tools we’ve written that aren’t project specific that we’ve been trying to encourage Edmonton pick up.
Two main categories are PuppetShop tools, some specific tools such as my weight tool, and generalized libraries. In retrospect I find it a bit strange there was never a discussion of sharing those generalized functions between studios, assuming they exist. We have some pretty good structs we’ve developed- especially for arrays, strings, math, skinning, etc- and there’s been no word on sharing what we have or getting what Edmonton has written. And on the other end, we have some pretty sweet Puppetshop stuff (such as an awesome Listview that replaces the default Timeline listbox) that I’ve been trying to get Edmonton to evaluate, but it’s been slow.
I see three problems: first is different software versions. We are using 2008 and a later version of Puppetshop, which excludes pre-Max9 projects. This has been a problem. Second is, bad code. Tech arts are not coders, and lots of what we write isn’t good code. And sometimes, even the good coders just write code to get it done ASAP. I don’t want to use someone’s code library that is dirty, that I can’t debug, that there’s no support for. Which is the third problem- support. The infrastructure required to have successful tool sharing is significant to do it at any larger level. Updates need to be distributed well, need to happen from both ends.
This is really a murky topic and is one of my mid/long-term professional goals, to improve the sharing of information and reduce the redundancy of work. We’re now part of the EA family, and I’m looking at CGTalk for info/samples of parsing XML with maxScript and DotNet. The absurdity of that occured to me- probably every studio has had to do this, and I’m looking on CGTalk, because I have no idea where else to turn and don’t know who to ask. The sharing of tech and info needs to improve as a discipline, which can be improved by a greater awareness and dialog and the push for improved sharing between brother and sister studios. There are lots more things to discuss about this, but my thoughts aren’t solidified enough to get there, yet…
XML - Hey Rob, just wanted to offer some max xml parse help if you need it…
As for sharing of tools, Often it is hard because of software sync issues but I think its better to share workflows , best practices and share the people as resources for help than it is to share software.
Most teams I have worked with start off thinking sharing “code” will save all kinds of time/money/etc… and it ends up not being done very well and causes waste instead of savings.
It has to be planned and have some one keep track of each group and for Tech artists, any time you want to share code , its easy to talk to your lead programmers and ask them how they would approach it since they have experience dealing with shared code.
Like anything it can be done right and be great or done wrong and end up a mess.
Rob: One thing we did to try and address the inconsistencies in coding styles, and just general bad programming practices was we came up with a coding standards and best practices document for only Tech Artists in the company. The programmers in the company have something similar, and we closely modeled theirs so that we maintain some consistency. Even with that document, getting people to buy into it and follow it has been difficult, mainly because most of us are self-taught and it’s hard to break old habits. Having said that, the TA’s here have come a long way since the document was first introduced (~2.5 - 3 years ago)and I would say that a large majority of our code is fairly consistent. We’ve also tried having code reviews, and those have helped.
When your team grows to a certain size, I think that is definitely a wise thing. I saw some docs on the internal Tech-Art wiki that Edmonton used, they may have/have had something like that for a while, no idea if anyone uses it, but we don’t here. But we are few enough tech artists that it probably wouldn’t be much benefit yet anyway.
The code layout/format/etc., while it is surely a factor, I don’t think is really one of the important roadblocks I was thinking about. I don’t consider dirty code someone that has a different tabbing or parenthesis layout- annoying and I wish it’d conform to mine, sure, but what I really meant was code that was written with, for example, sloppy use of globals (using globals to store UI information, for example, instead of referring to the control’s value directly), redundant code in several places that should be broken into different functions, etc. The bigger the refactoring, the more likely to introduce bugs- in more than a couple cases, I’ve done a refactoring that turned into a rewrite, because it was easier to rewrite much of the simpler code aspects, rather than change so many things.
Yes I think you are definitely right. I don’t think the problem is people don’t want to share code, the problem is, like you say, that we aren’t set up to share code. I love the idea of sharing code, but there just isn’t any infrastructure set up to facilitate it… hopefully, with more education and learning and exchange of information, that will improve.
It may also be worthwhile to bring up coding standards more precisely in the way Jason meant… perhaps there could be some community input into what they perceive as good ‘coding standards/styles’, that TA’s could choose to follow (it would at least provide some guidance for those that are looking for it).
Just like Jason said, for the most part it’s hard to share tools across projects. In an effort to improve that we have “Art Councils” that are basically groups of discipline specific artists that get together once a month to share and spread their knowledge regardless of what project they’re working on. Concept art has their council, animators have one, environmental artists have one and so on. For the standard art disciplines, they mostly try to share ways they can improve upon their art skills.
For the Tech Art discipline, TAs often show off new tools they worked on or show examples of code or problem solving they have recently done. Because a TA mostly works on project specific tasks ools\pipelines, this is a way for us to share our knowledge that might otherwise go unshared without the monthly council meeting. Each council is run by a different artist each year to help get everyone involved. Jason and myself have run the Tech Art council in years past.
We also have the standard entire company TA email alias where we can easily email all TAs for questions or support that is more studio wide. Often a TA will email this alias with a previously unknown or a new method for getting something done, just to spread the knowledge.
I just wanted to add to this talk briefly. During the last while at Acclaim Austin, Steev Kelly and I became the non official , official character TDs for both 100 bullets and The Red Star.
The two teams were sharing core engine tech but had customized it for each project, that said we knew we would want to try and share and standardize as much as we could for our rigging scripts and tools.
Our approach in the end I think worked out very well and much later I learned we did a form of Extream Programing (where two people work on one bit of code).
The breakdown worked like this.
I build a prototype rig by hand, as I went I would walk Steev through the rig and what I was doing. If I got stuck or we had a diffrent type of rig that was needed he would work on that.
Once that was done , Steev started the script for the auto rig system, He and I planned how to break up the scripts and how we would have them run in the build process.
Steev would write the maxscript to automate what I was building by hand , in the morning we would meet, he would run the code, we both would check if it worked (not always) and then I would sit next to him and he would script while we both talked out the code, I would be watching for errors and or just be there to help with extra code information and he would be doing the typing. Once we had the code working for the day I would take on a diffrent script section and following his code layout and useing it as a template I would write up new rig code or add in fixes or change/troubleshoot problems.
Etc… Then as he finished up the final pass on the scripts I went off and wrote animation tools to work with the rig, keyframe tools , weapon rig scripts , and both of us could read the code because it was in the same format.
Once we were in to production, any shared fixes would get tested, and updated and pushed to the teams, we had a separate set of team only code that fit the local issues to the team that the shared code did not need. We could always look and see what that was though so we could see if there was some cool new tool that we could use from each other.
The positive side effects this had was that our code got done faster and with less errors. Fixes could be shared and either TD could fill in for the other on bug fixes if the teams needed.
Our max exporter could finally be fixed and have scheduled programing time assigned to it because the programing staff knew it was going to get art data in the same way for each character, letting us get more fixes and improve the export pipeline for the game, saving every one lots of work…(before there were lots of hacks on both files and in the export code because of lack of automated checks and standards for rigs, files etc…)
As most people in Austin know, Acclaim was shut down before 100bullets got released but The Red Star was published buy some crazy act of luck.
I think in a small scale we were able to work out a very good way of working that might not scale well to multiple teams in diffrent locations but I just wanted to post this as a case study for what worked very well for us at the time.
The information you provide is quiet helpful, why I was not able to find it earlier. Anyways I’ve subscribed to your feeds, keep the good work up.
[QUOTE=Alfreda99;7717]The information you provide is quiet helpful, why I was not able to find it earlier. Anyways I’ve subscribed to your feeds, keep the good work up.
Custom essay[/QUOTE]
^
^
^
^
I smell a robot.:sigh: Is there an Admin in the house?