YCP Maps

[TronFAQ]

Yup. You resize the brush, rather than the Switch itself.

[deeahchur]

FAQ, sent ya an E-mail.

[TronFAQ]

I took some time to play the latest Beta version of your map, D. It's shaping up really nicely. But I did have one issue with it. I hope you take this on board as constructive criticism.

I think that sectioning off the levels with compartments, that have doors, won't work so well for a Multiplayer map. They interrupt the flow of the gameplay. Derez is about fast action, moving around freely to both chase and avoid opponents. By putting barriers in the way, players will get frustrated with constantly having to stop, aim for the door, wait for it to disappear, and then make sure they squeeze through the opening before they can continue.

You might not intend your maps to have that kind of pace, but I think players will have a natural tendency to expect faster action in a Multiplayer map. Even if it's somehow Co-Op in nature.

[deeahchur]

I can work with that. All I have to do for that is remove the need to strike the doors in order to proceed through them. I think I'll still keep the doors for the quarters, since those hold powerups.

[deeahchur]

YCP_Beta updated as of 27 May 2012



Download it! http://www.ldso.net/tronwiki/doku.php?i ... roject:ycp

I made mini-packs so certain things will only need to be updated as they are updated!

[deeahchur]

BTW, since I've been dividing most of my free time between UE3 and KA v1.2, I know I haven't been around much to help out with YCP_HQ much lately. I'll try to find some time to take another look at your latest release.

No worries. I'll have another update ready before then.



I spent all this past weekend converting more textures, and I think I have about 20 or so textures remaining to convert. On top of that I will be making some new textures, so I'll be breaking up the uploads even more, and that should ensure that each texture pack will be available. I can then be more specific with the updates for future updates.



Anything more will depend upon playtesting.

Check the wiki for updates!
http://www.ldso.net/tronwiki/doku.php?i ... 9LMqtVtqSo" onclick="window.open(this.href);return false;

[deeahchur]

^ ^ ^ UPDATED! ^ ^ ^

[TronFAQ]

Hey D, just wanted to continue the discussion from our e-mails.

Admittedly, when I played your latest version of YCP_HQ I had my anti-aliasing settings maxed out and was playing in 1080p. That might have been a factor in the slowdown I experienced. But, I can play the retail levels without any slowdown. So I think there needs to be some optimization done.

Now, mind you, the slowdown I experienced was mild and it didn't happen all the time. Only in certain areas when I looked around at certain angles. If I had to guess, I'd say it's the heavy use of textures in your latest release. You considerably increased the number of textures visible at once.

Probably the easiest step you can take that might help remedy this, is to compress your textures. Right now, I don't think you've compressed any of them. So they eat up a lot of memory.

But you have to be careful. Without a backup of the texture in another format like .TGA, if you compress a texture it becomes permanent. And when you do so, the texture loses quality. How much quality is lost, depends on the specific texture. Also, since you are using edited versions of textures from the game: they were already compressed. So you're compressing them again for a second time. But the alternative is potential performance issues in the map.

You'll have to go through them on a case by case basis, and see which ones make good candidates for compression. Which will be pretty tedious, admittedly. Another thing you could do, instead of compression: reduce or eliminate the number of mipmaps that each texture has. This will save a lot of memory. Though, again, this has to be done case by case where it makes sense. Small textures can probably get away with no mipmaps, but big ones should still have at least one or two.

The other option is occluders, like I mentioned to you before. But the design of your level won't really work with occluders that well. The best you could do is put occluders between the levels/floors. It still might help.

[deeahchur]

Hey D, just wanted to continue the discussion from our e-mails.

Admittedly, when I played your latest version of YCP_HQ I had my anti-aliasing settings maxed out and was playing in 1080p. That might have been a factor in the slowdown I experienced. But, I can play the retail levels without any slowdown. So I think there needs to be some optimization done.

Sure. I can certainly understand that. Your opinions are very helpful to me on this matter. I haven’t completed this much of a map before. I have a tendency of having ideas grander than the preferred operational limits.

Now, mind you, the slowdown I experienced was mild and it didn't happen all the time. Only in certain areas when I looked around at certain angles. If I had to guess, I'd say it's the heavy use of textures in your latest release. You considerably increased the number of textures visible at once.

...if you compress a texture it becomes permanent. And when you do so, the texture loses quality. How much quality is lost, depends on the specific texture. Also, since you are using edited versions of textures from the game: they were already compressed. So you're compressing them again for a second time. But the alternative is potential performance issues in the map.

You'll have to go through them on a case by case basis, and see which ones make good candidates for compression. Which will be pretty tedious, admittedly. Another thing you could do, instead of compression: reduce or eliminate the number of mipmaps that each texture has. This will save a lot of memory. Though, again, this has to be done case by case where it makes sense. Small textures can probably get away with no mipmaps, but big ones should still have at least one or two.

Are there any particular areas of note that come to mind? There are some geometry groupings that are sharing objects, and I know that won’t work in the long run. I just need to know where I should cut back. Out of curiosity, does animation on textures or use of sprites impact this much? If it does, then I can try to cut back on those.

Probably the easiest step you can take that might help remedy this, is to compress your textures. Right now, I don't think you've compressed any of them. So they eat up a lot of memory.

Time to learn something new! I admit that I do not know how to compress the textures, hence why that has not already been done. Care to describe the process or shoot me a link for a "how to"?

But you have to be careful. Without a backup of the texture in another format like .TGA,...

There is no problem regarding a backup. I already have them saved elsewhere for that purpose. Several, in fact, even in Cloud storage. I am NOT going to have the same problem or lost projects happen as before.

The other option is occluders, like I mentioned to you before. But the design of your level won't really work with occluders that well. The best you could do is put occluders between the levels/floors. It still might help.

To be honest, I barely researched occluders early on in my map-making experience. I know enough to realize many of my level designs are not conducive to their use. Even if I implement them between the levels, that may detract from the reason to have windows in the center of the level.

YCP_Containment would be even worse, since almost all the textures would be transparent for monitoring purposes. I have already considered some ways in which I can scale back the complexity of that level, though.

There’s a sadistic side of me that wants to test the limits of the engine as far as complexity and size of levels.

[TronFAQ]

Regarding texture compression, it's currently more or less explained in the Wiki. The essentials of it, anyway.

http://www.ldso.net/tronwiki/doku.php?i ... xture_file" onclick="window.open(this.href);return false;


Start with compressing your textures. We'll see how it goes, before doing something more radical that requires more work. If texture compression helps performance, then you may not need to do anything else.

[deeahchur]

Regarding texture compression, it's currently more or less explained in the Wiki. The essentials of it, anyway.

http://www.ldso.net/tronwiki/doku.php?i ... xture_file" onclick="window.open(this.href);return false;

Start with compressing your textures. We'll see how it goes, before doing something more radical that requires more work. If texture compression helps performance, then you may not need to do anything else.

Thanks, TronFAQ. I appreciate the link! Working on it; see below for progress.

Compressing Textures

• BINS (Completed)
• BUILDNOTE (Completed)
• CONSOLES (Completed)
• DECALS (Completed)
• ENERGY (Completed)
• FLOORS_WALLS (Completed)
• HEXCOLUMN (Completed)
• INTERFACE (Completed)
• IONODE (Completed)
• LIGHTS (Completed)
• SIGNS (Completed)
• SOCKETS (Completed)
• SPRITE_BASES (Completed)
• VEHICLES (Completed)

Actually, that didn't take as long as I expected. I started compressing each one individually, but then I tried, and succeeded, to compress multiple files by highlighting more than one and then just selecting the desired compression (DXT5) for the batch. I then checked various textures through the entire selection, and the compression appeared to be successful!

All 905 files changed from 505 MB to 126 MB; quite the considerable difference!

I then backed up both compressed and uncompressed files and copied the compressed textures into Custom folder as appropriate.

[deeahchur]

YCP_Beta updated as of 7 July 2012



Download it! http://www.ldso.net/tronwiki/doku.php?i ... roject:ycp" onclick="window.open(this.href);return false;

Here's an update on functionality and details added:

• Windows will derez when hit, making a sound, and return (rinse and repeat)
• Select doors will derez when hit, making a sound, and return (rinse and repeat)
• Temporarily derezzable datablocks, with randomization for rerezzing (Thanks TronFAQ for the assist!)
• Teleporter "prefab" functional
• Loading Screen recreation node Jukebox has three (3) different tracks and a null all tracks switch
• I/O Node consoles are decorative
• Converted and compressed textures to B/W (with appropriate alpha layers) Completed!

Level Errors

• Medium Duplicate Object Name on imported SKYBOX objects
• Low Points off grid; majority of brushes and can be ignored

[TronFAQ]

Answering a couple of e-mail questions:

I have prepared the geometry for randomization in the Loading Screen Club area. How do I make them randomly appear and disappear?

There's more than one way to accomplish this. But, here's what I think is probably the best way.

Create a new Trigger object. In its properties, set TimedTrigger to True. Set MinTriggerTime and MaxTriggerTime to low values, maybe even make them the same. Like a value of 1 second or less, for both. Set NumberOfActivations to 0.

Then in the Commands, on each line add a Rand2 statement for each piece of geometry you want to appear and disappear. So it would go something like this.

Code: Select all

Rand2 (msg Piece1 (hidden 1)) (msg Piece1 (hidden 0))
Rand2 (msg Piece2 (hidden 1)) (msg Piece2 (hidden 0))

And so on, for every piece of geometry. Each piece needs to be bound to a WorldModel for this to work.

So what will happen, is you've set the Trigger to fire at the minimum and maximum times, and anywhere in-between. When it does fire, it goes through all the commands and then randomly hides or shows each piece of geometry. There's a 50/50 chance each piece will be hidden or shown. If it hides twice in a row or shows twice in a row for a particular piece, it creates even more random behavior in the pattern.

Since I know how to make a damaging zone for the central energy column. What is the process for making a healing zone?

Change the Damage value in the HealthZone object to a negative number. Despite what its name implies, the HealthZone hurts the player by default if a postive number is used. So it would have been better to call it a DamageZone. But a negative value will indeed give the player health.


EDIT: Forgot to mention a couple of things, which have been added.

[deeahchur]

Here's an update to the YCP_HQ map in preparation for the next and final public release, due at the end of the month!

To Do List

• YCP SecRezzer (Prefab; prop-only) Completed for next release!
• Optimize geometry and folder hierarchy Completed for next release!
• L1 Command loft consoles Completed for next release!
• L1 Monitor consoles Completed for next release!
• L1 Modify and add health, energy, and power powerups. Completed for next release!
• L2 Chambers re-texture (adds 2 sprite textures and makes 1 sprite) Completed for next release!
• L2 Animated sprites for Loading Screen recreation node and randomized Completed for next release!
• L2 removed Th0m and GUI, due to unnecessary processor use; they were scenery, anyway. Completed for next release!
• L2 Loading Screen Club: Multiple sound sources for playing active track. Completed for next release!
• L2 Move music selection triggers into DJ loft. Completed for next release!
• L3 Slow healing and energy zones in L & R cleansing capsules Completed for next release!
• L3 Data Processing node requires new design Completed for next release!
• L3 Data Processing console re-texture (adds 2 console textures) Completed for next release!

Edits as of 26 July 2012

[deeahchur]

One last play-through before making the final decision that the map is FINISHED!

STAY TUNED!