Lo i bought the game… no wait actually i guess I pre-ordered it and am playing the beta but you get the idea… so anyhow i have some questions / confusions and suggestions and so on. This is going to get fairly technical too (i am a gfx guy so this is going to become very geeky)
Is there directional damage of modules (Damage depending from where the fire comes)?
Does it matter where armor plates are in the modules placement (i mean location wise) (And if not, maybe it should ,p)
In the particleconfig txt files - sometimes particles have a “TextureName” entry , is that one overwritten by the UV commands at the end of the file or hardcoded? Because some files have texture names of dds files that are not present, yet they still work… thats very weird.
Could be added (maybe as a modder feature) to have actual dds file sequences (so 01.dds to 09.dds) and a framerate setting? (because those animations all in one file really are bad karma for modding them to have… ehm, higher resolutions (needed for overglow and over-coverage of smoke/fire).
Suggestions (Might not be viable , just wondering ,p)
I noticed that the fire and blend “holes” of the damage texture of ships are placed per coordinates, so they are always set at specific locations… somehow it strikes me as odd since you already have a damaged.dds loaded (with alpha map!) not to simply apply a damage effect at a random “on hull” location (defined by the original sprite alpha map) - meaning dynamical damage and fire/smoke/sparkle emitters placed by the actual weapon that causes the hit so that each weapon could potentially have a different damage texture and particle effect placed randomly (or where it hits, if the game actually knows where it hits)
The other thing is that i think its odd that the damaged.dds alpha map is ignored - it would be kinda cool to have “holes” caused by damage (even better it if were directional or random/dynamic placed!)
Concerning the particles.dds … is there a particular reason the particles are all in one file? They are fairly low resolution and to have overglow they would need to be about… ehm 4 times larger or so. Not only that but one can not define different mipmap algorithms when they are all in the same file, (sharper/blurry etc.) - Also the smoke particles are too small to allow for full usage of the alpha maps 256 grey values range (hence why i ask ,p) This is mainly a “graphics fluff” thing.
Yeah thats it for now Its a pretty fun game and maybe some of these ideas can come about to increase the graphic and gameplay fluff
I am not sure what the reaction to suggestions is, i guess i am going to a fairly geeky level with these…
I’m not developing this game by any means but I have a guess how game deals with the damage stuff.
I’m guess that the game can’t understand what kind of sprite to apply in which area when ship gets damaged from that area. So Cliffski decided that it would make it look a lot more beautiful to have a totally damaged hull and totally intact hull so game won’t draw damage sprites to random locations which wouldn’t look correct at all.
Thus the game uses coordinates to apply the alpha blending between the damaged hull and intact hull and those same coordinates are also used to place explosion and smoke sprites correctly.
(Not to meantion that game would require a very complex piece of code which could understand where on that 512x512 picture the ship actually is and where it isn’t so it wouldn’t start to draw the damage sprites in thin air.)
Well it might be more beautiful at first but the problem is those explosions and damage sprites are a pattern and after 400 or so battles i know every single one of em and… well … yeah… patterns tend to repeat and if you have 50 evenly damaged frigates they all the pretty much identical damage pattern Of course random locations is a bad idea (know that ;p) hence why i asked if the game knows where it hits with shots… if it does or can, then dynamically damage will look much less “scripted” and added that with the alpha mapped damaged.dds of the ship sprite cause a lot more realistic “chipping away” of a hulls actual sprite to the damage sprite, also it would allow for (and here is where this links) regional damage damaging a module at that location if the hull is gone.
Those coordinates only have to be assigned by where the shot hits, i don’t think it would be difficult to code that (sounds to me like a variation of collision detection) but i am no professional coder, just graphics guru ;p As you say the coordinates for effects interlink with the damage location and if it were dynamic this would open up much more advanced damage effects (different ones for different weapon types, for example)
i think it wouldn’t be hard at all to code something similar to what you are suggesting that would look completely terrible. i also think it would be possible to make it look really nice…however for the value added i am guessing the amount of work that would have to go into it would be pretty terrible. in fact, it’s possible it could be easier to recode the entire game in 3d, given that in order for dynamic damage sprites for every part of every ship to work, you would pretty much need a 3d render of some form or another in order for it to look half decent. because his ship graphics are 2d artwork representing 3d objects, his pre-drawn damage effects are going to look much better then anything the computer can generate, because the code doesn’t know anything about the perspective or the angulature of the ships. (imagine generic “damage” sprites being drawn at the tips of alliance ship spikes, or on top of rotating components)
I considered both approaches. It’s obvious that the one I took was easier, and quicker to implement, but has drawbacks. The problem of writing code to find an appropriate target point on a ship to fire at, and to splat a damaged decal is one that sounds easy, and its true that such code works in FPS games with wall shots etc just fine. The problem is partly (as others suggested) finding an opaque chunk on an existing sprite so the shot does not ‘miss’ and secondly, one of scale. There can be a lot of ships on a map, maybe 300+, and if each ship is doing calcs for every shot to determine this stuff, that means reading data from textures to find valid targets every frame, or duplicating all the alpha maps in system memory, and still reading them.
Many approaches to a game like this seem fine with a brand new PC and 20 ships, but fall apart with 300 ships on a laptop.
I do agree that the ‘patterns’ can be jarring, and maybe I could one day have a hybrid system that spots out the target positions, but applies a different damage splat each time. One good thing about the current system is it lets you do location specific stuff, like knock out the nearest engine glow or lights.
True … ah sorry… i forget sometimes that there are less powerful computers
I see the points though while its certainly easier to implement and saves cpu cycles, i don’t even want to know how long you had to work to get all these damage sprites coordinates lined up perfectly with the damage.dds even if you have a tool for that (do you have a editor for that? Can we have it? ;P) this doesn’t sound like much fun to do.
I guess if its possible i’d still want to point out the other questions and suggestions (damage.dds alpha map overriding the original sprite alpha map for example) imo that alone would be a pretty impressive increase in abilities modders have to tune the damage effects to their hulls.
Though is it atm possible to specify new dds files for particle effects via Texture_Name entry? Or is this hardcoded? (because some files seem to have texturename entries with no dds file existing for it and a UV shift thing at the end - it seems as if this is overwritten by code.
Also one other thing, is there a way to change the blend modes of sprites (or is that what “Type = X” ) does in the particleconfigs files ?
| Ah yes, Burn is additive and Default is normal - are there more Types of blend modes?
Well enough geeky questions ;p
Edit: Apparently the texturename entry does work, but turns all colors orange, bummer ;p (tried deleting the UV part and insert own dds which turned out to be orange even though color is grey. (in game, that is)
Can’t you just do a very simple tweak to the code?
Like… Instead of one damage sprite, why there couldn’t be multiple damage sprites? Like, currently we have this one totally damaged up ship sprite where the game takes the damage sprites on top of the intact ship. NOW if we had multiple totally damaged up ship sprites, the game could quickly roll a random number and based on that number pick a corresponding damage sprite and apply damage from that sprite to the ship. In different location. This would add more randomness to the damage sprite patterns and it would be less likely to see two exactly alike damaged ships even if we had only two different damage sprites.
Only thing which you would have to take into account here is that the damage sprites shouldn’t have overlapping damaged areas or the game may apply two damage sprites on top of each other and this could result in clear clipping image which wouldn’t look nice.
Well technically that wouldn’t be a problem, you’d just need to create layers of sprites for damage - light damage, medium damage, heavy damage, destroyed damage. And every hit would blend (and it can even overlap) down to the next layer and so on. This is very possible, though memory intensive (Though the game isn’t really memory intensive, i multiplied all particle emitter rates by 4 and still do not see any lag or delays… )
When downwards blending does not overlap one could have blend sprites becoming slighter smaller each layer so that you have a nice layered hole (one can even apply fake shadow casting to that when they are fixed)
The reason the particles all sue the same texture is so the engine can sue atlasing and prevent texture swaps. In very very busy fights there are a LOT of emitters, and its at least a slight optimisation if you can reduce the number of texture swaps down to the lowest possible.
yeah - but its possible to specify large textures per emitter (in the particleconfigs) and they turn orange if you do (is that a bug?) it would allow for a much more fancy graphic mod ;D
Its a pretty fun game and maybe some of these ideas can come about to increase the graphic and gameplay fluff 
