Ideally a reimagining. As much as I seriously doubt any IP DMCA notices will come through, I'd like to avoid any potential CnD's.
Makes sense. Though if it's a reimagining, then there will most undoubtedly be some iterative design to get the style sorted out. I'm not super novel with my artistic abilities. 
No worries. I would have expected an iterative process after all.
Animation would be awesome but I'm generally not expecting it because of the amount of work involved in it.
Idk yet how involved, but I don't imagine simple animations on par with what exists would be too difficult. I.e. lights that blink or comm dishes that spin. If/when we get to that point, we can sort out the file structure. (Or I can just try to make the images and someone else can pack them as desired.)
File structure is fairly straight forward. It's a series of animation frames packed into a single power of two texture. I can handle that, no problem at all.
I guess maybe my question in this area is still misleading. I'm trying to sort out if every building sprite would end up with a standard size, say, 128x128, which would accommodate fitting it within the terrain tile, but also be a standard height for all buildings. So that a comm tower sprite isn't some unique dimensions, which is wholly different from the dimensions of the command center sprite. I know the actual command center portions would be "shorter" than the comm tower, but would the whole graphic be a standard size.
I think you can use the command center as a sort of 'standard' building size. Most buildings will likely have their own unique size and structure so long as their footprint (the area of the base of the building) fits within the dimensions of a tile.
I guess I ask because a standard size means I could set a standard camera setup at a standard distance from the model. That would make scale rather simple. I suppose it ultimately doesn't matter, since I can just render them all to some standard then post-process to crop all the wasted/unused space.
You have the right idea, actually. My suggestion would be to set up a square plane in the scene to set as the 'tile size' and then ensure that buildings don't exceed the edges of that plane. Seeing as they're basically built on top of tubes, start with the tube structure (as you already mentioned) would make sense. Get that scale right and then use that as the base for the rest of the structures.
Lastly, I would suggest rendering at high resolution and then we can scale them down for final inclusion in the game.
Also easy, though having a rough idea of size is good because that will set the detail requirements for the models.
See above.
Thanks for the examples. I think the camera for that was set up in perspective (I think I have that as the default), so sure, I can change to ortho.
Perspective is the default... most renders are done that way anyway.
We just dare to be different in isometric worlds.
... The tubes, in my opinion, are the first thing that really set the scale. They have doors/hatches at the ends, which sets the overall scale of the tube (and by extension, pretty much everything else).
I'm really glad I'm not the only one that noticed all that detail.
You can see here the 'diffuse' map which shows a zombie flat shaded and then the normal map above it. Combined with lighting, you get the resulting image on the right.
This is a cornerstone of 3D modeling, so I'm familiar with the overall concept. I've heard of it applied to 2D sprites, but have not done it myself. Off hand I have some ideas on how to generate the normal maps (some more complex than others).
Sweet!
Sometimes when I talk to people about these sorts of techniques I get blank stares so I find it useful to ask ahead of time before I get into details.
We can certainly give it a try, though I also wonder how noticeable it will be given the likely dimensions of the sprites.
Very noticeable. My thinking is to use it mostly for environment lighting (e.g., sun) to provide a more dynamic looking scene that feels more alive than just the few little animations provided via the sprites. Additionally, lights emitted by buildings can be used to illuminate the scene as well... which means we should consider emissive maps as well (should be simple in modern render packages).
Do you already have a mechanism to implement this in your game engine? (Or concept on how it'll need to be modified.)
Yes and no. It's a fairly basic technique though. OutpostHD uses OpenGL as its core renderer... in order to get real-time lighting simply requires that I set up several frame buffers. A color buffer, a depth buffer and a basic lighting shader to compute light values across the scene and then finally spit out the results into the frame buffer. I've been playing a lot with OpenGL GLSL shaders lately and while NAS2D doesn't natively provide mechanisms for shaders I can still make direct calls to OpenGL to make it happen.
However... it's a low priority and won't run well (or at all) on less powerful hardware, so I'm thinking for now we do it without dynamic lighting and go for normal shading. Later when I'm ready to implement it we can rerender the images without shading, add the normal and emissive maps and provide dynamic lighting as an option.
Tasks Thus Far:
- Establish a scale with tubes
- Initial investigation of animations
- Investigate methods for generating normal maps
- Generate Proof of concept for real-time shadows to determine shadowing detail
- Brainstorm theme and color scheme ideas
- Generate a list of required/desired/optional structures and vehicles (in priority order)
- Identify candidates for animation
Looks good but I would for now stick with scale, animation, theme/color and list of prioritized structures/robots. We'll worry about the fancy stuff later.
Two thoughts on this topic:
1. Couldn't you animate just the dish, and apply transparency so that you didn't have to copy the entire structure in each sprite, for the sprite sheet... thus be able to animate multiple doodads on a structure independently?
Ideally, yes. But there are several concerns regarding this.
First and foremost, I never got around to frame composition in the sprite code. As of right now the sprite code looks up a list of frames and just plays them in sequence given an 'action name' and the speed in milliseconds to display a given frame.
This seems wasteful at first glance but then you have to take into consideration a few things. 1) Since this is a pure OpenGL implementation and not a standard 2D blitter, minimizing pixel over draw is much less of a concern. NAS2D uses stencil buffers under the hood to eliminate overdraw and this is all done on the GPU so few wasted cycles. 2) in terms of OpenGL, it's cheaper to just pull a part of a texture and apply it to a single polygon mesh (in this case two triangles composing a rectangle) than to pull a base frame and apply several smaller frames on top of it. I suppose that could be done via a shader in parallel on the GPU but that's kind of overkill. In this case it's just a matter of rendering a single quad with part of a texture applied to it. Quick and easy. 3) considering modern hardware capabilities, this would be an optimization that has little to no effect in the long run.
2. Even if they had the ability to load tons of stuff on a CD back then, they'd still have the bottlenecks of the slow CPU, the very limited RAM, and the fact that CD-Drives back in those days didn't spin very fast... at best x4. So due to technical limitations storing stuff on a CD, may not have been beneficial back in the early 90s.
At the time this game came out 2x CD-ROM's were the bleeding edge. I remember the day it came out and the day I installed it!
And you're right. The thing is, OP1 was probably the LEAST efficient game I've ever seen. For every single frame of animation it would load it directly from disk (it would install the BMP's to hard drive if you had it). Basically, as I was playing the game, for each frame the HDD would spin up. It was kind of annoying, actually, having the hard drive constantly chirping every second or so. And yeah, that was the frame rate. About one frame per second. And it would blit directly to the video memory (no back buffer) so you had animation that was updated on one side of the screen and you could actually watch the update phase as it would sweep from top to bottom. It was awful.
