The importance of good tools for productivity
by Phil Carlisle · 12/05/2007 (11:26 pm) · 8 comments
I was at a presentation a couple of months back about a product one of the thegamecreators.com had been working on. One thing he said was that whenever he starts a project, he immediately thinks of the tools he needs to make it easier.
That got me thinking this last month as I've been scripting missions for Panzer Ace.
The fact is, I think mission "scripting" would be better done in another way. Particularly as the missions we are doing for PA are actually more like a mixture of mission logic and camera/machinema work.
Then I remembered that I was going to write some machinema stuff in 2002 :) so I figure now is actually the time to revisit that idea and turn the absurdly horrid script code (I mean it really is pretty nasty writing a ton of script logic to setup in game cutscenes as it is) into a more manageable set of UI tools.
We already have a lot of the code you'd need (event based systems, triggers, spawners and I've just been doing additional camera control work). So it should be reasonbly easy to get a first-pass system in place to get the core game stuff done.
I'm going to design it over the weekend, but something along the lines of a timeline based system a bit akin to a much-simler version of director's cast/timeline system seems like the way to go. Basically, have multiple timelines which represent a given "take" of action. Each take is either a cutscene or a gameplay section. Add events into the take based on what you want. Add layers to this so that you can have multiple ways of transitioning between takes etc.
I'll draw a diagram over the weekend. But here's a simple example to get us started.
Right now, in one of my test missions, after doing the intro cutscene (driving a tank over a russian plain) you have to fight a few scripted enemies. Now the thing that struck me, is that if I want to actually cut short the cutscene, I post an event to the manager and it goes onto the next "scene". But what I'd prefer to do, is have a sort of timeline, where I could add a layer to it (photoshop style) and right-click "add event->escapetransition" and give it the take to transition to.
Similar with camera cuts. Right now we've got a great big bunch of if(event) changecamera(cameraname) scripts. What I'd rather do, is right-click the camera track and "add->event->cameraswitch" into the timeline at the appropriate points.
Given how much crap I've had to mess around with for a single mission. I feel like getting even a rudimentary version of this together is going to make my life 1000% easier to get my missions done.
So expect some design stuff about this over the weekend. I prefer to use mindomo.com to flesh out my ideas and then usually build some kind of class collab diagram. But I might just mockup something in photoshop this time round :)
Sorry, rambling, but wanted to get this down on paper so I dont forget the frustration of mission scripting :) visual mission design for the win!!!
That got me thinking this last month as I've been scripting missions for Panzer Ace.
The fact is, I think mission "scripting" would be better done in another way. Particularly as the missions we are doing for PA are actually more like a mixture of mission logic and camera/machinema work.
Then I remembered that I was going to write some machinema stuff in 2002 :) so I figure now is actually the time to revisit that idea and turn the absurdly horrid script code (I mean it really is pretty nasty writing a ton of script logic to setup in game cutscenes as it is) into a more manageable set of UI tools.
We already have a lot of the code you'd need (event based systems, triggers, spawners and I've just been doing additional camera control work). So it should be reasonbly easy to get a first-pass system in place to get the core game stuff done.
I'm going to design it over the weekend, but something along the lines of a timeline based system a bit akin to a much-simler version of director's cast/timeline system seems like the way to go. Basically, have multiple timelines which represent a given "take" of action. Each take is either a cutscene or a gameplay section. Add events into the take based on what you want. Add layers to this so that you can have multiple ways of transitioning between takes etc.
I'll draw a diagram over the weekend. But here's a simple example to get us started.
Right now, in one of my test missions, after doing the intro cutscene (driving a tank over a russian plain) you have to fight a few scripted enemies. Now the thing that struck me, is that if I want to actually cut short the cutscene, I post an event to the manager and it goes onto the next "scene". But what I'd prefer to do, is have a sort of timeline, where I could add a layer to it (photoshop style) and right-click "add event->escapetransition" and give it the take to transition to.
Similar with camera cuts. Right now we've got a great big bunch of if(event) changecamera(cameraname) scripts. What I'd rather do, is right-click the camera track and "add->event->cameraswitch" into the timeline at the appropriate points.
Given how much crap I've had to mess around with for a single mission. I feel like getting even a rudimentary version of this together is going to make my life 1000% easier to get my missions done.
So expect some design stuff about this over the weekend. I prefer to use mindomo.com to flesh out my ideas and then usually build some kind of class collab diagram. But I might just mockup something in photoshop this time round :)
Sorry, rambling, but wanted to get this down on paper so I dont forget the frustration of mission scripting :) visual mission design for the win!!!
About the author
Recent Blogs
• GDC AI sessions• Tell me I'm not going crazy!!
• Using the way back machine.
• Juggling cats.
• End of Summer.
#2
If all you are going to do is write your code one time, push it out and have it work I would agree with you Hadoken, but in the real world the fact is the layout is usually never right the first time and every time you have to go back and tweak you will spend much more time trying to make sure every variable is now reset correctly than if you invested in a visual tool.
If anything Indies need to be more concious of their tools and their limitations. Careful tool selection and creation of tools to automate and quickly correct when the design changes are critical. Indies typically have shorter development timeframes when working on small games and they have less time to invest because they are usually not working on games full time. Better to have the tool.
Finally, six months from now when you need to make changes how easy will it be to remember why all that code is there? No matter how well organized, a visual tool would be miles faster.
Yay Tools! Go for it Phil!
12/06/2007 (2:48 pm)
I'm with Phil on this one.If all you are going to do is write your code one time, push it out and have it work I would agree with you Hadoken, but in the real world the fact is the layout is usually never right the first time and every time you have to go back and tweak you will spend much more time trying to make sure every variable is now reset correctly than if you invested in a visual tool.
If anything Indies need to be more concious of their tools and their limitations. Careful tool selection and creation of tools to automate and quickly correct when the design changes are critical. Indies typically have shorter development timeframes when working on small games and they have less time to invest because they are usually not working on games full time. Better to have the tool.
Finally, six months from now when you need to make changes how easy will it be to remember why all that code is there? No matter how well organized, a visual tool would be miles faster.
Yay Tools! Go for it Phil!
#3
Anyhow, long story short, the projects he worked on that were tools driven did FAR better than the projects which were coder driven. Tools after all are far more predictable and productive than coders (who have the human frailties involved).
That guy is now a TD at EA and I think I've bought into his mentality somewhat.
Of course the real trick is to figure out WHEN to write the tool and when to brute force the solution. If its something repetative, iterative and "tweaky", then tools are for the win. In my case, mission scripting and camera/cutscene stuff, tools are probably going to help us turnover missions about 1000% faster. I figure its worth taking a punt.
12/06/2007 (4:53 pm)
Just to backup my own argument a tad :) a friend of mine used to work for a company called Deep Red, who were well known for insane schedules that were really unrealistic. He noticed that most of the time, the projects were failing because programmers simply were too overwhelmed. He started to produce specific problem-oriented toolsets in C# to cater for the designers. This example was a "building entrance layout" toolset that basically had grid which you could mark building entrance and exits on. The games were all sort of sims style "tycoon" games.Anyhow, long story short, the projects he worked on that were tools driven did FAR better than the projects which were coder driven. Tools after all are far more predictable and productive than coders (who have the human frailties involved).
That guy is now a TD at EA and I think I've bought into his mentality somewhat.
Of course the real trick is to figure out WHEN to write the tool and when to brute force the solution. If its something repetative, iterative and "tweaky", then tools are for the win. In my case, mission scripting and camera/cutscene stuff, tools are probably going to help us turnover missions about 1000% faster. I figure its worth taking a punt.
#4
Unfortunately, we don't always have the time to take some distance from our projects to analyze our problem and write tools that will be re-usable and adaptable.
I think writing tools help to analyze and structure the problem, and so, make it clearer.
And you gain experience too.
A program that is a long list of "if" is a proof of a lack of problem structure (AMHA) and is difficult to maintain and prone to error.
Nicolas Buquet
www.buquet-net.com/cv/
12/06/2007 (6:37 pm)
I think it is always better to make tool.Unfortunately, we don't always have the time to take some distance from our projects to analyze our problem and write tools that will be re-usable and adaptable.
I think writing tools help to analyze and structure the problem, and so, make it clearer.
And you gain experience too.
A program that is a long list of "if" is a proof of a lack of problem structure (AMHA) and is difficult to maintain and prone to error.
Nicolas Buquet
www.buquet-net.com/cv/
#5
12/07/2007 (7:03 pm)
I like the power Mommaware (pg's kit) gives you in terms of scripting with python and it's ablity to talk to the engine and sql.
#6
VMS = "visual mission design". I really think you nailed the pin on the head here. Tools are very important. If you've been a member of GG for while, the impact of tools such as Torsion, ShowTool Pro, Constructor made quite a difference in the Torque universe. There's always room for more.
12/07/2007 (10:18 pm)
VMS FTW!VMS = "visual mission design". I really think you nailed the pin on the head here. Tools are very important. If you've been a member of GG for while, the impact of tools such as Torsion, ShowTool Pro, Constructor made quite a difference in the Torque universe. There's always room for more.
#7
12/10/2007 (5:55 am)
#8
The only reason I put that I like the way Mommaware does it is that it's way more powerful than torque script itself for small widgets.
12/11/2007 (11:08 am)
Yea I think Phil's talking more about "widgets". Not really full blown tool applications but just code helpers or snippits of code to accomplish functions. Correct me if wrong.The only reason I put that I like the way Mommaware does it is that it's way more powerful than torque script itself for small widgets.
Torque Owner Hadoken
In most indie games there's a single person (a couple of them maybe) doing all the work. If you're a programmer or scripter, then it's probably almost as easy for you to manage lots of "if(event) changecamera(cameraname)" as right-clicking and adding values.
If you add to that the fact that tools do have a cost (it might take a long time to write a proper tool, and that's time you could spend making your game), it's not always a great idea.
But i don't know anything about your Panzer Ace, it might be a big project, in which case custom tools are really needed. I'm just saying that for most indie games they aren't, in my opinion.
Camera movement can be really hard to get right with scripts alone anyway, in a previous project i was doing I remember getting around that problem by animating my camera in a 3D app (it was blender, but it could be max or anything), as a single "bone", then I exported my animations and attached the in-game camera to that bone. A custom in-game tool would have made it easier, but in the end it worked well.