Zombie's Skunkworks - Let's have some fun :)

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
I will be using this thread to just drop random Crusader stuff I'm working on / playing around with :)

 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
The final Silencer base model is done. Fully rigged and ready to use. Needs to be a bit less shiny I think, but that depends very much on the lighting. And a few scratches could be nice. And a few bits and pieces, like holster and helmet light.

silencerback.PNGsilencerfront.PNG

Made some scaling tests to determine the tile size. It's pretty much 2x2m, 1m for the half-walls.
The current wall and floor objects are just rough placeholders. First is isometric and second is standard perpective camera.

isometric.JPGperspective.JPG

A buddy made me aware of a neat little 3d modelling program this week thats not as mighty as Blender, but works for me way better. So, since the wall/door ... well *everything* ... geometry is pretty simple I started remaking the actual geometry.

wallstrut.PNG

Got the nice free perk that level geometry can easily be destroyed and exploded, because I can just use the elements as independent objects. Might be useful one day.
 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
A bit of weapon modelling :)
I took some creative freedom on the barrel. Truth be told ... the BA-40 it is a damn ugly gun :D
 

Attachments

  • ba-40_wip.JPG
    ba-40_wip.JPG
    325.8 KB · Views: 6
  • testfit.JPG
    testfit.JPG
    91.4 KB · Views: 6

Candy

Member
Joined
Jan 28, 2008
Messages
74
What software do you use for the modeling, and what file format for the animated things? Reanimating my 11 year old code base and that was one of the big weaknesses; I had no good file formats for animated things, and only Milkshape for modeling (which is 20 year old abandonware now).
 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
The character model (Stormtrooper) was made (not by me) in Blender. A buddy used 3DS Max to modify the armor and helmet, so it actually looks like a Silencer and fixed the bone rig for use in Unity.

The gun model I'm making in "Mol3D". It's pretty similar to Milkshape it seems. Just started using it 1-2 weeks ago and working myself through the trial period. So far it seems we are compatible :D Modeling is something that I've always tried to avoid and Blender is my nemesis.

The animation are made by me directly in Unity using the bone rig. They are saved in Unitys native .anim format, but can be exported as fbx to work in other animation programs like Blender or Maya 3D. Or vice versa. As long as the rig is the same (or with some extra work) I can switch animations/characters around as much as I like. Bone animations are pretty much what everyone uses nowadays. No mesh animations like in the old times (though still used on the regular for specific cases).

But I'm cheating a bit. There are some animations that will not be completely "hand made". Let's take ... pressing a button or drawing the weapon for example. I will be using inverse kinematic (IK) for that. Meaning I can set some basic parameters and just tell the system "right hand reach for that position and rotation, curl fingers until collision with object or do that holding position, point in direction of enemy".
Or just "if button close enough, reach for button position".

The motion itself will be executed by the system. With pure bone animation you'd set "keyframes" and the position and rotation of the bones at each keyframe on a timeline. Steps inbetween are interpolated, so that helps a lot if you "only" need to set start/end and maybe a few inbetween steps.
 

Candy

Member
Joined
Jan 28, 2008
Messages
74
Is there some form of level format I can create from the original files that you can use? I think using Unity is a better bet, but I might be able to help import the original levels and/or physics models / sizes from the original level data, as well as make some form of overview page for which items we still need models/UVmap/textures/rigging/animation for.
 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
I'm kind of fixated in remaking the models and geometry in 3d from scratch based on the original designs.
But if someone else wants to tackle a "more original" port, I would help out :)

To remake a basic level (geometry) from the original we'd need the a list of the tiles and their position. The list needs to include the type of tile. If it is walkable for example. Depending on the coordinates it may be needed to know the actual size of the tiles. I *think* there is no actual height position?

The format of this list doesn't really matter much as long as it can be parsed (simple csv, xml, json ...). With that, a small "import level" script should be pretty easy. The actual tile graphics need to be imported too, of course. But thats not a problem, besides mapping them to the list.

On the 3D side my current goal is to just build up a basic ... let's call it a proof of concept. Basically the first few rooms, 1-2 weapons, civilian & guard NPC models. That will be the playground for creating the new character controller, getting the scaling right and just test things out.
That is about the bare minimum for a first public alpha release to get opinions and determine the right controls. And that would be about the point on which others can join in if they want. The new "3D tiles" can be snapped together and building new levels should be pretty quick, once the elements are done. I don't want only screenshots and videoclips. People need to actually be able to try it out and "touch it". Or even modify it themselves (modding possibility is a given, right from the start. no additional work needed. much work needed to lock people out from modding actually)

Once that is done, I can go deeper into the planning phase on how to go on from there. I'm kinda chaotic, but it works for me ;)
The important part for me is to actually have something to show before making the *big plans*. Talk is cheap
 

Candy

Member
Joined
Jan 28, 2008
Messages
74

This is what I had in early 2011; that's the code base I was updating. I've lost all models and textures from then - I did search.

Happy to help out with models where possible. I was now looking through reverse-engineering the data formats & seeing if they would be hard, and they're quite easy. Was hoping for a more visual thing to show in a talk I'm giving at CppOnSea on binary file formats in 2 weeks.

I have all 30600 images for each tile (some use frames for animation, but some use them for alternate textures or wholly different objects of similar shape, or other parts of huge graphics). Can't send them by email since the virus scanners don't think 30600 files is reasonable.

I also have all the type information (physics sizes & stuff) that comes from TYPEINFO.DAT.

So the github repo has these tools:
- exflx: extract files from flx file
- leveldraw: read extracted files & make a huge BMP with a level in it. Skips drawing black pixels; I have a minor change locally to skip the Regret level coverings too, so you don't get the level covering / object-hiding black bits.
- shapedraw: draws all frames from a shape from shapes.flx to a bmp
- typecount: counts the instances of a particular shape in the given input levels; useful to know which objects happen most often, or which do not get used at all.
- typeinfo: prints sizes and flags for objects.
- usecode (not at github yet): will read usecode info (names&flags), plus mapping the usecode files to particular objects. There are 402 shapes with usecode attached, of which 289 unique ones (both alarm signal boxes have the same, for example).

So the levels require a bit of work to work in rotating third-person camera. The green/yellow/red things you see in my level renders are invisible walls (usually not rendered but taken into account for physics). Mostly to prevent you from getting under a wall and not seeing yourself, but sometimes used to make it impossible to shoot over something. Some objects exist to hide others (there are some fully black floors used to hide parts of the level behind doors). Many objects exist only to attach triggers or usecode to; those don't need a physical instance to render or do physics with, but would need to be represented somehow.
 
Last edited:

Candy

Member
Joined
Jan 28, 2008
Messages
74
Oh, a direct reply. Right.

> I'm kind of fixated in remaking the models and geometry in 3d from scratch based on the original designs.
> But if someone else wants to tackle a "more original" port, I would help out :)


Well, I like to think of a modern remake where you could play the original levels with modern FPS-style controls (on a Steamdeck?). It would have good lighting, nicer physics effects (more satisfying explosions), more gruesome deaths, maybe some levels from No Remorse fixed to have more alternate paths like No Regret does.

> To remake a basic level (geometry) from the original we'd need the a list of the tiles and their position. The list needs to include the type of tile. If it is walkable for example. Depending on the coordinates it may be needed to know the actual size of the tiles. I *think* there is no actual height position?

I think walkable isn't a concept in the original; it basically counts everything as walkable as long as it's not filled with something else. But:
- Each object has a width, height and length. (I'm 90% sure these are used for physics bounding boxes)
- Each object has a x, y and z position. The floor tiles are 8x8 with a glob of 16x16 for easy placement, where the yellow pole (for the yellow fences) has a 1x1 floor size.
I can make a tool that drops a CSV for this from any given level - for No Remorse I need to find which level files are the actual ones; for No Regret I have already posted that list.


> The format of this list doesn't really matter much as long as it can be parsed (simple csv, xml, json ...). With that, a small "import level" script should be pretty easy. The actual tile graphics need to be imported too, of course. But thats not a problem, besides mapping them to the list.

Mapping already done; they use a 16-bit shape ID and 8-bit frame index.

> On the 3D side my current goal is to just build up a basic ... let's call it a proof of concept. Basically the first few rooms, 1-2 weapons, civilian & guard NPC models. That will be the playground for creating the new character controller, getting the scaling right and just test things out.

Yeah... see also my video above :-D. Never did get my Crusader model to hold together or be animatable.

> I don't want only screenshots and videoclips. People need to actually be able to try it out and "touch it".

Yeah; I used to have the executable with resources on a server but I did take that down ~6 years ago.
 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
Wow ... way too many different topics at once. We really need to sort us, I think.

First: awesome clip! Too bad you don't have the models anymore, they would come in handy. Luckily they aren't very complex. I've never done UV mapping and unwrapping though. So for now I'm working just with different materials and shaders. It does work quite nicely and helps in keeping the "clean" look. Little details like the bolts in the X-strutted walls as actual meshes are no problem anymore. We can rebuild him, we got the technology.


> Happy to help out with models where possible.

Help is always appreciated. Let me get the first basic ones ready and then I can send you the models for reference if you like. No need to rush though. I want to tackle that slowly, but steadily, to minimize the risk of tiring myself out too quick and loosing interest.

> Can't send them by email since the virus scanners don't think 30600 files is reasonable.

Want me to put up a platform for sharing that stuff? Got one or two server available. Don't think Github would like that amount either :Don

> So the levels require a bit of work to work in rotating third-person camera.

Well ... do you want to give it a go?

> Well, I like to think of a modern remake where you could play the original levels with modern FPS-style controls (on a Steamdeck?)

Yeah, something along those lines. Keeping the levels and design as close as possible and then adding all the modern niceties on top. Pretty much what you're video shows. Though I do want to keep the default isometric camera. First person, yes ... but I need to be really bored to create a second character controller for FPS controls. Of course I could just slap a third party controller on it and be done with it.

> I can make a tool that drops a CSV for this from any given level

If you'd do that, I would give it a go. Though I did already take a peek at your github repos. Not a pro(grammer) by any means, but I think I can port most of it over to C# for direct in-engine use. Will definitely take a shot at it.

> Mapping already done; they use a 16-bit shape ID and 8-bit frame index.

I like when work is already done :D Really need to read up on the current game internals. Just have the bare player memory in my head.

> Yeah... see also my video above :-D. Never did get my Crusader model to hold together or be animatable.

Well, soon you'll get the chance to play around. I will probably release the Silencer model standalone once I've finished the smaller details like holster and helmet light.

> Yeah; I used to have the executable with resources on a server but I did take that down ~6 years ago.

Lost to time. Yep, thats how this usually goes.
 

Candy

Member
Joined
Jan 28, 2008
Messages
74
Wow ... way too many different topics at once. We really need to sort us, I think.

First: awesome clip! Too bad you don't have the models anymore, they would come in handy. Luckily they aren't very complex. I've never done UV mapping and unwrapping though. So for now I'm working just with different materials and shaders. It does work quite nicely and helps in keeping the "clean" look. Little details like the bolts in the X-strutted walls as actual meshes are no problem anymore. We can rebuild him, we got the technology.
Yep. I did model them back then but it did drag performance down a lot. Especially adding the later particle emitter & physics caused some issues with performance. Last thing I did was a full rendering rewrite to use a different approach that was at least a decade too early - I tried to do scene culling and full instancing on the GPU. Turns out 11 years ago GPUs were really terrible at that. Ran at 6-10 fps for that first room.

That kind of broke my resolve at the time.

> Can't send them by email since the virus scanners don't think 30600 files is reasonable.

Want me to put up a platform for sharing that stuff? Got one or two server available. Don't think Github would like that amount either :Don

If you have a server I can dump some stuff on that would help. I'll try to get all shapes & level renderings uploaded that I have. Will also see if I can add one more tool to generate a HTML overview of <entity> plus typeinfo and associated usecode.

I did spend a bit of time looking through the files and splitting them up into modeling difficulty/style/knowledgeset. I have the groups eastereggs (which we do not recreate), guns, humanoids, mechanical, effects and objects.

Guns have 5671 bitmaps, which correspond to ~12 different models to be created.
Humanoids have 15952 bitmaps, which will be about one rig to be created, plus ~20 models with that rig, and a bunch of animations.
Mechanical has 3246 bitmaps, which are ~100 different kinds of things (mechs except android, turrets, guns, cameras, chairs - anything that has all vertices tied to one bone, so no real skinning, and simple rigs)
Effects currently has 1514, which will probably be replaced with shaders and some other trickery to make it look nice. I have some youtube videos on what I had then for teleporting, and I think we can do that instead of making an image sequence ;-)

Then objects has about 4200 left, most of which are actual objects. All rotations of an object count separately, so this is still a few thousand but not quite 4000 actual things to make. To use in the engine I'd suggest auto-generating them as bounding boxes with a texture listing the object ID / number, so that we can see which ones we see in the engine to know what to model next. As with the other thread on the secondary thresher gun model, a bunch of these things likely is never actually used.

> So the levels require a bit of work to work in rotating third-person camera.

Well ... do you want to give it a go?

Of course. That's what this discussion is about :-D

If you'd do that, I would give it a go. Though I did already take a peek at your github repos. Not a pro(grammer) by any means, but I think I can port most of it over to C# for direct in-engine use. Will definitely take a shot at it.

It's a bit of bit fiddling. If you want to move it to C# for use in Unity that sounds good to me. I'm a Linux user and I'm not sure Unity caters to working on Linux; no objection to C# though even though last time I used it was in 2009.

> Mapping already done; they use a 16-bit shape ID and 8-bit frame index.

I like when work is already done :D Really need to read up on the current game internals. Just have the bare player memory in my head.

Ah. That's easy to explain.

The levels are laid out on a 64k * 64k grid, with 256 possible height values. Floors are 16 units high. Humanoids (like the Silencer) are 3x3x10 in size. Most floor tiles are modeled as 8x8, and put into a glob to form a 16x16 unit square for making levels out of. Nearly no level actually places things above 48; they instead move to a different part of the map to just place the next floor next to the others.

For example, level 1 from No Remorse has some bits of the level at the top of the map (x 511 y 511) that are not actually used; looking only at the real map bits finds entries with an X between 0x37ff (~14300) to 0x5fff (~25000), and a Y between 0x2dff (~11000) and 0x7bff (~31760). This includes all 4 floors, side by side.

Looking at the byte data, I do see large Z values - up to 192 - but most are either at 0 or 96. Whelp, that has me surprised.

If you take one of the fixed.dat files and hexdump it with 16 columns, the X is the first two, Y is the next two, Z is the 5th, type is byte 6/7, frame is byte 8, and the field I call "count" is byte 11-12. Each of these refers to the actual type *one less* than the one listed, unless the type in here is 0x10 - in that case, the count is the glob ID to fetch. Globs are just a bunch of objects that level editors place in one go, and that are used as a set. They speed up the game by unloading objects when you get further away from them.

The other fields probably say which thing something teleports to, what value to use in a keypad, when to switch levels etc - I have no idea about those yet. Most of the what-is-this of a shape is in typeinfo.
 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
> If you have a server I can dump some stuff on that would help.

Not a problem. Just need to look up a decent "sharing script", so we don't need to go back to FTP and can make it public until it gets picked up by archive.org.
Though archive.org wouldn't be the worst idea in the first place. How much space is needed? (roughly)

> Of course. That's what this discussion is about :-D

Well, there is the problem with "too many topics" :D
I don't want to fiddle around with the original sprites, except for using them as a reference, in my project. Like I've said, the model geometry is easy enough to replicate completely in 3D.

Getting the sprites into Unity was an offer to help if you want to work on some thing with it or just play around.

> I'm a Linux user and I'm not sure Unity caters to working on Linux

Don't worry. It's very well supported on Linux. For development, as well as for actually "playing". C# is just what it uses as it's scripting language. Not much that can be done about that except using another engine. But since I do have most of my experience in Unity ... uhm yeah, not worth it.



I think I'm somewhat done with the first gun. Not quite happy, but that will probably never be the case. But now I got everything together to actually start on the character controller and the animations. Shouldn't be too bad and a big part to make something public to actually test out. And for tweaking of course ... ohhh the tweaking.
 

Attachments

  • 1.jpg
    1.jpg
    515.8 KB · Views: 2
  • 2.jpg
    2.jpg
    292.4 KB · Views: 3

Candy

Member
Joined
Jan 28, 2008
Messages
74
I'm pretty sure I can extract the bounding boxes from the original items & auto-generate placeholder art, that we can then use to work on gameplay without being blocked on 3d models, and that we can use to load the original level files and start patching them up.

The shapes are 30600 files, which are officially 25MB of space, but practically each file will occupy 4k (because filesystems) and so I expect it to take 120MB - probably 300.

Which is much smaller than the level files, which are around 25MB per level (times 37 for Regret or 63 for Remorse) in PNG. total about 2.5GB.

I got Unity to install - which officially supports Ubuntu 18.04 at best, which is a bit like not yet supporting Win10... but it works fine on 22.04.
 

Digitalzombie

New member
Joined
Jun 3, 2022
Messages
15
> without being blocked on 3d models
Not convinced yet :D 3D placeholder items are easy. But if you just count the amount on different items, wall and floor tiles ... it's not much. And we don't even need all of them at once. A handful replications of walls, floors, pipes and boxes ... more than enough to play around with the basic gameplay elements. Later level building will take up most of the time I think.

> but practically each file will occupy 4k
You and I have different interpretations of the word "roughly". So ... 5GB it is. Got the upload/sharing script installed, but still need to fiddle around with the access rights. Will post the link here tomorrow and send you the login details for uploading.

> Ubuntu 18.04 at best
Ah well, you know how it is. But it works. I recommend using Unity Hub for managing the installation and go with editor version 2021.3.4f1
Thats what I've been using to create the project. Transfering assets and scripts between different version gets annoying fast.
 

Candy

Member
Joined
Jan 28, 2008
Messages
74
> Not convinced yet :D 3D placeholder items are easy. But if you just count the amount on different items, wall and floor tiles ... it's not much. And we don't even need all of them at once. A handful replications of walls, floors, pipes and boxes ... more than enough to play around with the basic gameplay elements. Later level building will take up most of the time I think.

I've made a script to auto-generate boxes of the correct size with the shape image plastered on the sides so that we can load the levels and have a reasonable indication which object goes where. Milkshape doesn't like a material file with 30k textures :-D

Code is in shapegen/src/main.cpp. All objects are centered around (0,0,0) so you'd need to correct in the loader for the level format (or in the level exporter).
 
Top Bottom