|
Location: JBPLAY \ Meteor 2 \ Suggestions \ Facilitating Indoor Area Designing Back to Threads |
Zable Fahr
![]() Joined: 04 November 2004 Posts: 74 |
07 November 2004 01:29 (UK time)
Although M2's map editor is leaps and bounds more powerful than M1's map editor, I have to admit that it was easier to design buildings and building interiors in M1. I'm seeing a lot of incomplete maps in the beta that involve buildings, so I don't think I'm alone in thinking so. And while I do like designing outdoor areas, designing indoor areas is somehow more rewarding :-). Here's a few suggestions to make designing indoor areas easier: - This is the biggest one: rectangular sector drawing. Drawing perfectly rectangular sectors is really time-consuming and error-prone. Snap to grid is useful, but the problem is that it's easy to accidentally set a vector one or two grid spaces off. This may be unnoticeable in outdoor areas, but it's very jarring in indoor areas. Then you have to switch to vector mode and correct it. Rectangular sector drawing means creating/selecting two vertices and automatically drawing a rectangular sector with both vertices as diagonal corners. The regular method of drawing rectangular sectors takes 7 clicks; this takes 4 and you don't have to worry about making sure everything is aligned right. - Sector palettes: This is like the tile palette in M1. I find myself regularly creating sectors with the same properties (walls, doors, keycard doors, etc), and Set as Default Sector doesn't really help, since you have to fish for the right sector, and even then it only stores one set of properties. A user-defined palette with some basic default entries will help immensely. Note that this also makes the map editor MUCH easier to use for beginners, since they can work from a palette of ready-to-use tiles and don't have to immediately know what all the sector properties do. - Roof sectors are cool but are really only cosmetic. What would be neat is if they become transparent when the player walks under them, like a really simple fog of war effect. If you want to get complicated, they become transparent once the player has unobstructed (not blocked by walls or doors) line of sight to a roof sector. - Minor suggestion: Vectors can snap to grid, but why not player starting locations, objects, or powerups? - Not really limited to indoor designing: Is it possible to integrate a text editor into the map editor for editing briefing files and script files? It doesn't have to have fancy editing functions; in fact, I would be happy with a simple screen with a multi-line text box and a "Save" button. This eliminates the need to switch between Meteor and a text editor, because I can't imagine my poor screen liking frequent switching between resolutions. You need to login to create posts in this thread. |
fuzinavl
![]() Joined: 06 October 2004 Posts: 287 |
07 November 2004 14:04 (UK time)
Roof sectors should be 85% transparent if player is on the ground. They should be opaque if player is in the air. Some should be destroyable by air-to-ground bombs / rocket launchers. Destroyable roof sectors would have mapper-defined hit points. We could "cover" a building with multiple roof sections. (to be destroyed piece by piece) I guess a destroyed roof texture would be drawn under the feet of infantry in the render order. Edited: 07 November 2004 14:05 You need to login to create posts in this thread. |
James Bunting
Posts: 1308 |
07 November 2004 20:03 (UK time)
The "draw a rectangle from here to here" thing could be a time saver for those geometric environments, its a nice and practical idea. A text editor, yes we really need this. I am lucky because I use twin monitors but thats no excuse. A basic text editor with tabbing and a save button would do a treat. Perhaps if fuzinavl has the time he could knock up a graphics mode Allegro text editor using the Allegro GUI and I could integrate it into the Map Editor? Indeed roof sectors are purely cosmetic, they add no functionality at all apart from blocking site. They are designed to be used in moderation to promote a 3D effect (eye candy). They are not really designed to be roofs for entire structures and I don't really fancy getting bogged down with the task of making them fancy (transparent). Additionally Allegro won't actually draw transparent textured polygons using the "polygon" function (but that is secondary). Roof sectors do however inherit the properties from regular sectors and will be destroyable as soon as destroyable sectors are implemented. The pre-made sectors list is a nice plan and I may get around to it one day. I initially played with prefab structures (by inserting a small level into another, p_farm.map is a pre-made farm) but this never got off the ground as it is just too much work. Storing single sectors is totally different (you could just right click and select "Add to My Sector List" or something). The reason why only terrain snaps to the grid is purely because I could not build a case to justify writing a bunch of code for the other objects (I could not really see the gain). Perhaps you can talk me around on this one? James. Edited: 07 November 2004 20:05 You need to login to create posts in this thread. |
fuzinavl
![]() Joined: 06 October 2004 Posts: 287 |
07 November 2004 20:26 (UK time)
sorry James, I don't know how to make a text editor. You need to login to create posts in this thread. |
Zable Fahr
![]() Joined: 04 November 2004 Posts: 74 |
07 November 2004 21:21 (UK time)
Well as I said snapping objects to grid is just a minor thing. If it's too much work then I could live with not having it implemented. The main reason I suggested it was so that groups of powerups could look "tidy" (i.e. not scattered all over the place or with jagged alignment) without having to look really closely at the pixels while placing each powerup. And since units move around a lot anyway, I could see why snapping units to grid would be pretty useless. Destroyable roof sectors. Sounds cool. Actually I think there's a way to implement disappearing roof sectors through scripting. Since you mentioned you would implement destroyable sectors eventually, you could have a scripting command called SC_DestroySector(sectorID) that lets a map forcibly remove sectors. Then a map could set each roof sector to have a script trigger that destroys itself. A somewhat more elegant solution would be something similar to SC_SetObjectHidden that works for sectors. Either way, you don't have to implement any complex auto-disappearing roof sector code; just leave that part to us map designers. You need to login to create posts in this thread. |
James Bunting
Posts: 1308 |
07 November 2004 22:42 (UK time)
There is already a SC_SetSectorHidden command so you could use that. Its a bunch of code though. You need to login to create posts in this thread. |
Zable Fahr
![]() Joined: 04 November 2004 Posts: 74 |
07 November 2004 22:51 (UK time)
Yep, you're right. I can't believe I missed it. After some quick tests, it looks like the concept works great. Example: Opening door reveals room - Create a wall sector - Create a floor sector inside the wall sector - Create a roof sector that entirely covers the floor sector (and optionally the wall sector. Call this sector ID 3. - Create a door sector along the wall sector. Go to sector properties and set Use Script Trigger to True and set the Trigger Text to "SC_SetSectorHidden(3,1);" - When the door opens, the roof magically disappears! I think with some custom procedures and a global variable, you could make doors to a room toggle the roof. You need to login to create posts in this thread. |
fuzinavl
![]() Joined: 06 October 2004 Posts: 287 |
08 November 2004 02:03 (UK time)
(oops) Edited: 08 November 2004 13:31 You need to login to create posts in this thread. |
James Bunting
Posts: 1308 |
08 November 2004 23:02 (UK time)
Well I started on an integrated text editor and I can tell you its a total nightmare messing around with a big self-allocating buffer and trying to make it all editable on the screen. You could probably imagine me buggering around with cursors and scroll offsets blah blah blah, not to mention tabs, grrrrr! I really need to find someone who has some hands on experience with the Allegro GUI functions, I am convinced that that has to be a better idea than writing an editor by hand. I may have to put the text editor on hold because its just too much work for a free game (I simply don't have the time right now). So if anyone has seen a graphics mode text file editor that works inside Allegro programs I would love to hear about it. You need to login to create posts in this thread. |
James Bunting
Posts: 1308 |
08 November 2004 23:05 (UK time)
When the "Once Only" feature works (as in when you can run triggers more than once) you can simply put a trigger outside the door that turns the roof back on. I reckon that its now too crude to leave this on all the time (as well as the inside door trigger that turns the roof off). You need to login to create posts in this thread. |
fuzinavl
![]() Joined: 06 October 2004 Posts: 287 |
09 November 2004 05:31 (UK time)
Do pop-up microsoft brand windows work in allegro? I'm not experienced with them, but just a thought. You need to login to create posts in this thread. |
James Bunting
Posts: 1308 |
10 November 2004 10:31 (UK time)
The problem is that would require graphics mode switching (just like alt+tab (or start key). The text editor is shaping up well (finally). Its one of those long boring tasks that should pay off. James You need to login to create posts in this thread. |
|
|
Forums system (C) 1999-2023 by James Bunting.
Terms of Use