Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: Mobius on July 19, 2010, 02:01:44 pm
-
What the title says. I'd like FREDders who've done this before to share their experience here. :)
It happened to me quite a few times, and I'm pretty sure I'll have to do it again in the next few months. Can't really describe the typical situation that calls for mission (re)design because there are various possibilities; perhaps, most of the times it's necessary to redo a mission from scratch because concepts evolve at impressive rates and certain missions of a WIP campaign became obsolete enough to force FREDders to redo them from scratch to "save time". Why would a FREDder do that? Is it possible to define the border between major editing and total redesign? Excessive bugs in mission design, hard-to-explain crashes, personal satisfaction, someone else's request, need to match the quality of other missions (as specified above)... well, looks like there are many reasons.
In the future, I'd like to test new approaches to mission (re)design: I intend, in fact, to use Notepad to copy and paste the content I'd like to keep to save time and unnecessary pain. Has anyone ever tried to do that? What are the pros and cons?
Discuss. :D
-
A bit more than a year ago we started redoing every mission in War in Heaven from scratch because...we wanted to, I guess; we decided to start over from a clean slate so we had 100% control of a new approach. After that a few of the missions were again iterated a few times, mostly because the original concepts just didn't pan out into a fun experience.
But by and large we managed to avoid the 'restart the mission' trap, and I think that's down to excellent iterative testing during early development and good pre-design. If the mission gets played to death at every stage of development, you catch problems early. When finished missions didn't live up to the standard of the rest of the campaign we were able to go back and enhance them pretty easily.
Usually the only good reason to redo a mission from scratch is because the concept changes. Crash bugs aren't a great reason to redo a mission - you should haul the file over to Mantis and get it fixed. We solved a lot of SCP bugs that way; just yesterday we found out that is-ai-class...doesn't work, and got it repaired (I think.)
If you have to redo missions from the ground up frequently, though (looking at you, Earth Defense), you're doing something wrong in your development. Something's going wrong in the design and outlining phases that's wasting your time and effort. You should be thinking harder about what each mission is going to be, what gameplay verbs are going to be deployed, what the mission needs to say and do.
By and large FRED is powerful enough that if the fundamental concept hasn't changed you should be able to massage the mission into what you want it to be without restarting. And if you're slick about it it's not hard to retrofit missions; we squeezed major, major features into a few WiH missions very late in the development process because the missions themselves were designed to be modular and expandable.
EDIT: oh and I've used notepad copy and paste to move shared SEXPs and variables between missions before - it's really useful for capship command stuff.
-
I've only completely redone a mission from scratch once, and that was mostly because I wanted a fresh start of sorts. I still copy pasted this very complex bunch of sexps, and thanks to none of the ship names changing, everything worked out.
Normally I'll grow unhappy with a mission and extensively rework it, or modify how the mission goes. There's this one mission that I did for Dirge that changed so much from the original that the only common thing was the premise. Every other mission had a similar reworking but it retained a lot from the original form. That led to a lot of objectives that will never trigger or have and (<normal trigger> false) to disable various events. In one I completely reworked all the fighter waves, so I had Second Wave Cue and 2nd Wave Cue. One was triggered to false and the other was the normal one.
-
I'll be redoing High Noon from scratch shortly, because I've taken a bit of a new approach to that mission set (as well as including a third mission, should the Colossus fall). I contemplated redoing Bearbaiting so I could split the smashing of the Gamma Draconis Blockade into its own mission (as some had suggested), but decided against it.
-
At some point in development if you keep changing stuff in a mission, then a complete remake might be a good approach, but generally that's not necessary.
Other powerful reason to remake a mission is to have learned a lot of stuff about feedding techniques, thus making most of your old sexps look ineffective or too bulky.
I've seen a lot of different fredding techniques, and I must say the most impressive one I've seen so far is Goober's way, I remember checking a particular mission featured in DEM Interlude.... he made all his events listed in grammatical order from top to bottom, and consistently named, using an uppercase for the first letter on all events and some other details, all so neatly organized... and then it stroke me:
****....I suck at fredding
-
:lol:
-
Crikey ****, FREDing can take long enough as is, I couldn't be arsed to order it alphabetically at the least. :P
-
I think chronological order is more useful, and in any case re-ordering events is extremely risky.
-
Well, I think it is perfectly ok to remake a mission in FRED from scratch. If anybody has been playing VI then you would understand why we are going to take mission 1 and start it from scratch (it is 5 years old and does not match our current campaign at all - plus it has continuity errors). To try to take the mission as is and re-work it into a working mission actually has more work involved than just making the mission from the start with the idea fresh in our heads.
Generally I don't organize my sexps, sometimes if I feel like making a mission look neat and tidy I would group my events based on what they are, I would group directives together, put in game messages together, put all the waypoints and ship orders and all sorts of other simular stuff in the same little chunk with the occasional exception for if something is chained. But most of the time I leave the sexps in the order in which I added them (I made the mission I know which event does what and where I put it, somebody else may not know how to find their way around... but they shouldn't be messing with my mission should they :) ).
-
I think chronological order is more useful, and in any case re-ordering events is extremely risky.
:shaking:
-
It's not clear to me under exactly what circumstances reordering events will **** up is-event-true SEXPs, but it can definitely happen.
-
It's not clear to me under exactly what circumstances reordering events will **** up is-event-true SEXPs, but it can definitely happen.
Not only ****s up is-event-true sexp's to my knowledge.
I can give you some hints.... but I'm not sure about what causes the problem, let me see:
-Moving events that are immediately close to other chained events
-Moving events that use variables.
-Moving events after renaming them.
I will try to get an example and put it in mantis IF I can get it again to fail today.
-
I just try as hard as I can to make my Events chronological. That takes a little doing though, sometimes.
-
This also goes for programming or most software projects:
I notice that when I make a mission and see that it's a mess, it's generally better to redo it. Remaking it is a lot more painless than it was to make it the first time because you have the logic planned out in your head and you know what to do. Sometimes when I try to salvage what I have, I end up taking more time only to realise that I am trying to pick up after a fecal storm. Now for BIG projects well... you have to pick the lesser of two evils. Maybe this explains why many people never quite finish that TC mod they were planning on creating alone.
Redoing missions does not mean you wasted your time with the first attempt though. I like to think that it's all part of your progress.
It's when you accidentally delete something you later found that you needed... well then you can be pissed.
-
When you say "Redoing" are you talking about starting over from scratch with a brand-new mission file, or just scrapping the whole event tree and moving/adding/adjusting everything else that goes into the mission?
-
It's not clear to me under exactly what circumstances reordering events will **** up is-event-true SEXPs, but it can definitely happen.
Here's a little but effective example of this issue.
Try moving "Event 1" from the top to the bottom of the Event List.
This was Mantised.
(that's how it's said?)
[attachment deleted by ninja]
-
When you say "Redoing" are you talking about starting over from scratch with a brand-new mission file, or just scrapping the whole event tree and moving/adding/adjusting everything else that goes into the mission?
It depends on the situation really.
I'm not saying that if your event script is messed up you should scrap the mission file and lose all your ship coordinates, but if the entire mission is plagued by errors you just can't work out or you see a fundamental design flaw that's unmanageable to fix or something like that... yeah scrap it.
Oh, saving multiple files for the same mission is a good idea BTW. Mission[0.1], Mission [0.2] ... etc. Sometimes it's best to simply revert back to an older file.
I guess I was being general. I just wanted to say that redoing a project is not the same as starting from nothing.
-
I think chronological order is more useful, and in any case re-ordering events is extremely risky.
I think by grammatical he meant chronological. And I only re-order events in a text editor.
-
I generally leave events in the order I've done them. That way if I've made a change that's ****ed something up, I know where to look. :P
-
And I only re-order events in a text editor.
Your knowledge has been recalled and stored in my memory banks.
-
I can't recall a time I ever had to build from scratch.
At worst I had to go back and de-subspacialize in a text editor once...