by date
The importance of good tools for productivity
The importance of good tools for productivity
| Name: | Phil Carlisle |  |
|---|---|---|
| Date Posted: | Dec 05, 2007 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Phil Carlisle |
Blog post
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!!!
Recent Blog Posts
| List: | 12/05/07 - The importance of good tools for productivity 11/17/07 - Using the way back machine. 09/21/07 - Juggling cats. 09/04/07 - End of Summer. 08/27/07 - Come work with me!! 08/14/07 - The changing nature of entertainment 07/25/07 - Someone stole my notes!! 07/16/07 - Art pipeline and other things. |
|---|
Submit your own resources!| Hadoken (Dec 06, 2007 at 12:55 GMT) |
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.
Edited on Dec 06, 2007 13:01 GMT
| David Dougher (Dec 06, 2007 at 14:48 GMT) |
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!
| Phil Carlisle (Dec 06, 2007 at 16:53 GMT) |
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.
| Nicolas Buquet (Dec 06, 2007 at 18:37 GMT) |
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/
Edited on Dec 06, 2007 18:39 GMT
| Vashner (Dec 07, 2007 at 19:03 GMT) |
| James Laker (BurNinG) (Dec 07, 2007 at 22:18 GMT) |
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.
| Tony Richards (Dec 10, 2007 at 05:55 GMT) |
Edited on Dec 10, 2007 05:56 GMT
| Vashner (Dec 11, 2007 at 11:08 GMT) |
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.
You must be a member and be logged in to either append comments or rate this resource.
