Mission Editor for User, Not Developer
by Michael Perry · in Torque Game Engine · 10/06/2006 (11:59 am) · 6 replies
Greetings again everyone. I've been spending quite a few hours going through the forums and resources to see if anyone else posted information on this idea. I thought about posting in the mods section, but I have this feeling some engine discussion is going to take place.
First, let me say I love Torque's mission/world editor. In its class, it's the best I've ever used. I wish to distribute a game containing two tools: a level editor and a mission editor. However, instead of giving them the full power of Torque's default WorldEditor, I want to give them tools more closely resembling the ones shipped with RTS games like War Craft III and Rise of Nations. Basically, and forgive me for using the term, a "dumbed down" version of WorldEditor is what I'm seeking. Ok, on to the tools. Here is a brief example of a few features each tool should have.
Map Editor Should Allow:
Template Choice (desert, forest, city, mountainous, ect.)
Placement of trees
Foliage
Water
Buildings (both interior and non-interior)
Roads
Non-Useable Objects (wrecked cars)
Saving map out for future loading
Map Editor Should Not Allow:
Terrain modification
Objects places below or inside terrain
Gizmos
Mission Editor Should Allow:
Player spawn
NPC spawn
Mission goal selection (death match, survival, ect)
Squad/Team alignment toggle
AI node placement
AI node options (wait here, smoke break here, ect)
Vehicle placement
Time of Day
Weather
Camera view choices (overhead, RTS view, FPS view)
0 to no scripting required
Trigger points, areas
Saving mission out for future loading
We all know these features can be done using Torque's WorldEditor and some scripting. I just want to make these features more accessible to the average gamer in the form of simple check boxes, radios, drop downs, and mouse movement.
So here's the big question, and I need your opinions. Should I create a new class derived from WorldEditor and modify it to my liking? Or, should I create a new GUI and pick WorldEditor as its class and perform everything in script?
Jeez, why can't I ever make a short post????? =)
Advice, comments, rants?
*EDIT for grammar*
First, let me say I love Torque's mission/world editor. In its class, it's the best I've ever used. I wish to distribute a game containing two tools: a level editor and a mission editor. However, instead of giving them the full power of Torque's default WorldEditor, I want to give them tools more closely resembling the ones shipped with RTS games like War Craft III and Rise of Nations. Basically, and forgive me for using the term, a "dumbed down" version of WorldEditor is what I'm seeking. Ok, on to the tools. Here is a brief example of a few features each tool should have.
Map Editor Should Allow:
Template Choice (desert, forest, city, mountainous, ect.)
Placement of trees
Foliage
Water
Buildings (both interior and non-interior)
Roads
Non-Useable Objects (wrecked cars)
Saving map out for future loading
Map Editor Should Not Allow:
Terrain modification
Objects places below or inside terrain
Gizmos
Mission Editor Should Allow:
Player spawn
NPC spawn
Mission goal selection (death match, survival, ect)
Squad/Team alignment toggle
AI node placement
AI node options (wait here, smoke break here, ect)
Vehicle placement
Time of Day
Weather
Camera view choices (overhead, RTS view, FPS view)
0 to no scripting required
Trigger points, areas
Saving mission out for future loading
We all know these features can be done using Torque's WorldEditor and some scripting. I just want to make these features more accessible to the average gamer in the form of simple check boxes, radios, drop downs, and mouse movement.
So here's the big question, and I need your opinions. Should I create a new class derived from WorldEditor and modify it to my liking? Or, should I create a new GUI and pick WorldEditor as its class and perform everything in script?
Jeez, why can't I ever make a short post????? =)
Advice, comments, rants?
*EDIT for grammar*
About the author
Programmer.
#2
If anyone else has an opinion, or helpful advice, let me know.
10/11/2006 (5:51 am)
Thanks for the input Kevin. After reviewing all the custom implementations that will be used, I have decided to create a custom class derived off of WorldEditor. I'm trying to follow the GG lead by reading through the script implementation, and while I normally follow script flow pretty well, reading through editor.cs, editorgui.gui, and editorgui.cs has me all turned around. It'll be a while before I have much to show, I'll post a plan and resource as I progress. If anyone else has an opinion, or helpful advice, let me know.
#3
Any ideas?
[EDIT]
After putting on the "Dead Man" soundtrack, I got inspired. After digging through the engine code, I found a great function called Sun::inspectPostApply. This took care of my relighting issue, so all I have left is figuring out how to update the Sky.materialList.
i r stupid
[/EDIT]
10/16/2006 (8:46 am)
So, I've set up a few GUIs and the foundation for the Mission Editor. Right now, I'm working on a GUI that allows the user to change the weather and environment. I've hit a small snag, though. I can grab environment objects such as precipitation, Sun, and Sky, and change their variables to suit the user input. My only problem is updating the world to reflect these changes.function changeToNight()
{
Sun.color = "0 0 0 1";
Sun.ambient = "0.1 0.1 0.1 1";
Sky.materialList = "creator/data/skies/sky.dml";
lightScene("", forceAlways); RelightMessage.visible = false;
}After calling this function, all the variables change. However, I have to open TGE's WorldEditor and click on each object (Sun, Sky, ect). Finally, after hitting all the "Apply" buttons, I have to call lightScene again to get what I want. I know this has something to do with the Inspector, I just can't figure out how to bypass this and have my script changes take effect immediately.Any ideas?
[EDIT]
After putting on the "Dead Man" soundtrack, I got inspired. After digging through the engine code, I found a great function called Sun::inspectPostApply. This took care of my relighting issue, so all I have left is figuring out how to update the Sky.materialList.
i r stupid
[/EDIT]
#4
08/10/2009 (7:16 am)
This is looking like a really cool resource. I can see all kinds of ways to use it. (think, grabbing a rock and placing it on a plate Uru style). :-) It makes me quite happy to see this getting some work.
#5
so...can you give me more clue, or resource ???... thanks
08/13/2009 (4:03 am)
i want to player can move their house properties with mouse, like onverse, then i follow your clue.... it's so hard and difficult.so...can you give me more clue, or resource ???... thanks
#6
many mission objects were not build with dynamic ghost updating in mind. their properties only get ghosted to each client once. (well, once per period of being in-scope)
for properties like sun color etc like these which are being changed on a fairly low-frequency basis, i would go ahead and just give them a new netmask like "LOW_FREQUENCY_PROPERTIES" or something, lump all these new properties into it, and then write setter() functions which touch the netmask when the value is set. (or use the dynamic object fields introduced w/ tge 1.4, i believe)
an example of the process of changing a Ghost-Once property to a Ghost-Whenever-It's-Changed property is here.
also, i dunno if you're planning on using this in a networked game or strictly single-player, but i have some faint memory of inspectPostApply only being applicable in standalone instances. i may be wrong on that tho.
08/13/2009 (10:26 am)
> I just can't figure out how to ... have my script changes take effect immediately.many mission objects were not build with dynamic ghost updating in mind. their properties only get ghosted to each client once. (well, once per period of being in-scope)
for properties like sun color etc like these which are being changed on a fairly low-frequency basis, i would go ahead and just give them a new netmask like "LOW_FREQUENCY_PROPERTIES" or something, lump all these new properties into it, and then write setter() functions which touch the netmask when the value is set. (or use the dynamic object fields introduced w/ tge 1.4, i believe)
an example of the process of changing a Ghost-Once property to a Ghost-Whenever-It's-Changed property is here.
also, i dunno if you're planning on using this in a networked game or strictly single-player, but i have some faint memory of inspectPostApply only being applicable in standalone instances. i may be wrong on that tho.
Torque 3D Owner Kevin Rogers
Definitely a cool idea -- I love games that give this level of control to the user! (For example, Farcry's editor is the best I've seen so far -- you can place items and AI, or adjust the terrain, all in real-time. You can practically play the game in the editor.)
Anyway, good luck! Hope to see what you come up with...