@Mattn: Sure, you get ALL source files if you want, but I thought it would not be necessary, because:
1. All animations are already split up in layers, so the xcf source files will look the same as the pngs ?!
2. The a versions of the animations are more or less the starting point for the variations, so there you have the source already
... I made this especially, so other gfx-artists can easily build up from there & make new variations if they like. So the a versions are more or less to be used as source files & not for the animations
@H-Hour:
Hey, H-Hour
Very many thanx for the review. I knew there would be some stones coming, flying in my direction
, so I really have to counterattack many of the things you said
But where should I start ?!
It looks like I have to comment everything here:
Alright, finally got a chance to put together something on your animations. First off, I think you've done some great work on these animations. The monitors with the ship and the human model are excellent, and the green glowy panels throughout are really nice. I can see you've done a ton of work, and that's really the only problem: it's excessive!
Maybe I should have stopped my work on 18th of march, because that is the date, when the version you would like to have was finished already
The map is virtually unplayable on my machine (which is probably slightly lower than the minimum the devs are shooting for), and load up times were very long. It looks like you're already doing some optimization, and that's good, but consider also that in future maps the UFOs might not be the biggest part of the map. There must be room for other details in a map.
I already wrote a feature request regarding this & I am all for supporting old systems & slow computers also, that is why I think there should be an additional graphic option to turn off the material system & all new tex_ufo textures (already in trunk) are ready for that (nothing cut out in the standard-texture)
I tried to make the animations as small as possible that is why I even cut out the skins around the smallest buttons to not have to load them into memory for each frame...
So do not worry, Nate, I will optimize this stuff to make it use as
little resources as possible. I have additional plans also, but do not know if this will be working yet, so I will shut up for now.
But I must stress here that we are in 2010 (or 2084
) & we should not make a game that looks like it was made for computers from the year 2000.
Look what competition is doing now:
www.sosnewyork.comFirst, I think you can cut back a lot on size by reducing the number of variations. For each animation, you've often got 5-8 versions that are basically the same, but slightly different. It's good to have this so that screens right next to each other don't have identically flashing buttons, but there will almost never be more than 3 panels next to each other, so you shouldn't ever need more than 3 variations of any given animation. This is the case for almost all of your animations, but just as one specific example, you've got the same little button animations for b2_13-16_1a* to b2_13-16_1h*. Eight different variations of this same very tiny animation is really unnecessary.
Look @ them again:
b2_13-16_1a - 1c are completely different button behaviour animations
& as you know I already agreed with Mattn, that there will be no versions of animations in v3 anymore, which just vary color
...
I just wanna stress here again that
I did this on purpose, because for the mapper who has to adjust the material file, it would allow much easier 'programming', just using a nice picture-browser & surfing through the frames to find the correct colors for his map instead of having to use cryptic 'color 0.5 1.0 0.6' commands for the animation overlays with an outcome that is almost unpredictable...
Or maybe you can tell me which color command I have to choose when I want a red/green combination to become a yellow/blue one ?!
This makes a LOT of work if you want to keep a certain color code through dozens of animations...
But this is already decided anyway.
Also as mapper who is building 1 map all the time you should not forget, that I made animations which will be seen on dozens of maps & my goal was to make no U.F.O. look like another, to create the illusion for the player that each U.F.O. is a special one. That is why I did all of this work, because I realized that this
IS possible via the great material system.
But with the system of 'layered animations' we can make this possible even if we would have no color @ all
Other examples are the screen with the human head (s02_13-16_2*). This is a great animation, btw, I really like the paneling on differnet sections of his body. But there's no need to have dozens of different color variations. The player is not really going to notice or care that this screen is a slightly different color than that other screen. This is an example of what I would describe as "different without difference". The animation is technically "different", but the player does not experience it as "difference". All of the s02_13-16_2* files take up 3.6mb, but just one set of the animation would be 98.1kb. And this really isn't an issue of working on lower systems. If we were going to spend 3.6mb on these panels, it would be better to have them in higher res, rather than have dozens of variations. Or, better yet, to have entirely different kinds of animations rather than these slight variations. It's just a poor use of resources.
Again, stuff is already decided on, I just wanna note here:
1. As 'non-layered' animation & in tga format this one animation had
704 KB2. As 'layered' animation in png format this one animation has 175 KB, maybe I should have used your 98.1 KB, although I do not know where you get that from
3. - so2_13-16_2a: Source File
- so2_13-16_2b: Source File Reverse (not necessary anymore thanks to Mattn & animb)
- so2_13-16_2c: Source + ScreenFlickering
- so2_13-16_2d: Source + ScreenFlickering backwards
- so2_13-16_2e-l: 4 additional different color variations of the HumanScanner in some nice colors
- so2_13-16_2m & o: Changing the color during the animation
- so2_13-16_2q: Defect Screen Animation (unfinished)
- so2_13-16_2s & u: Unfinished Copies
The same is true of all the variations of the UFO, etc, also a great animation. One of my favorite is just the text that appears on the screen, a great example of how a cheap (resource-wise) and simple animation can still be visually attractive.
Thank you very much.
In addition to the excessive variations, I also think perhaps you should consider not animating everything that could possibly be animated. bctex001* is an example of an animation that is barely worth animating. You should think about a better balance between more/less/non animated screens. There is such a thing as overkill here, and empty space is just as important a part of design as filled space. That's why the text screens work so well. The animation is a small part of the screen, but it pops because it's surrounded by all that space.
I leave this decision to the mapper, my friend, that is why I invented those layered animations. Now you can choose if you want a button to be displayed or not, you can choose if you want a button animation for a screen, you can choose the speed of each of the animations, so you can have a fluently moving screen animation with 8.0 fps, while @ the same time the buttons beneath the monitor 'move' with 0.2 fps.
Also it is now possible to combine the animations of the buttons or displays for example with the 'pulse' command which was not possible before.
It was also not possible before to have buttons & displays, which do not use the maps lightmap & have their own 'glow' even when it is completely dark...
You would not write all this stuff, if you had understood the new system I am introducing here.
Please take a look @ the tropic.mat file to get a small overview & also try to make some experiments there if your time allows it...
If it were my UFO/map, I would use your green glow stuff and the main screens (ufo, human, text). I would leave all but a very few of the button animations out, simply because I think they're unnecessary, they add less than they cost.
I would enjoy seeing you 'program your individual U.F.O.'. If you like I invite you to take over the material definitions for some of the U.F.O.-maps, when v3 of this is finished, you can be 100% sure, you can make your own individual style now
Man, if you like, everything can be turned off in the U.F.O.s on your map, or you can make a U.F.O. land, which only has different kinds of text animations on all of its screens...
Ok, now let's talk about the so2_med* animations. If I remember correctly, you just started on these, and I don't like them as much. I'm only commenting on the ones in the corrupter. I see you've got some human ones that look like they might look nice. The bright green one doesn't really look good or seem to make sense. Also, it could all be done with one file, no animation, just a scroll.
These are not finished @ all. This is in a first test phase, I somehow also have problems to clear the screen first there...
Quote from tropic.mat:
/* Widescreen 1 TODO: everything */
/* Widescreen 2 TODO: everything */
Quote end.
I have some additional concepts & ideas for those, but I do not know yet if everything I imagine here is technically possible, but it should be...
The stars one is a good idea and looks good, but it should be optimized in some way. I think you can make the stars static and blend the shining over that image, then animate the blended texture. That may not make much sense when written... Also, it would be cool if there was some text added, like it was saying something about the stars.
Not sure how the devs feel about nudity. It would be worth running that one by them.
And now see the attached images for more details that were better described with images.
See above. Thanx for the review.
