Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
CravenCoyote

[DEVLOG] Alien Breed 3D 2: The Killing Grounds total conversion for GZDoom

Recommended Posts

On 7/6/2024 at 11:02 PM, CravenCoyote said:

 

Haha, that's actually from the original game. The second one is a semi automatic double barrel shotgun but I've not managed to create that just yet. 

 

First up will be getting the Mine to work

I believe that the TKG shotgun is actually supposed to be break-action. However, the reload animation is sped up to the point where it's basically not there.

Share this post


Link to post

Can voxel models use realtime lighting in gzdoom? One of the visually pleasing aspects of the original game was how the bumpmapped sprites would react to lighting.

Share this post


Link to post
16 minutes ago, Artman2004 said:

I believe that the TKG shotgun is actually supposed to be break-action. However, the reload animation is sped up to the point where it's basically not there.

 

This. I made the animation much more apparent in my mod to the point that if you are crouched, you can't miss it. However, since that anmation goes back to my 040/25 MHz days where I was probably rocking 5-8fps, there are nowhere near enough animation frames for current UAE/PiStorm. 

Share this post


Link to post
Posted (edited)
11 hours ago, Artman2004 said:

I believe that the TKG shotgun is actually supposed to be break-action. However, the reload animation is sped up to the point where it's basically not there.

 

Sorry, I should clarify: Original game being Alien Breed 3D 1 (and sprite taken from Project Osiris)

 

Edit:

Ahh, sorry, I see what you mean! Yes, you're absolutely right

Edited by CravenCoyote

Share this post


Link to post

Short video showing some of the voxel items as well as a test for the voxel Triclaw monster

 

 

Share this post


Link to post
1 hour ago, 0x4BADC4FE said:

Can voxel models use realtime lighting in gzdoom? One of the visually pleasing aspects of the original game was how the bumpmapped sprites would react to lighting.

 

Triclaw floating through red light

RClVDKX.png

Share this post


Link to post

I'm so glad you're doing this. More obscure non-DOS games need to be ported to Doom.

Share this post


Link to post

The voxel pickups look cool. I only just noticed the slight glassy reflection on the light floors too, that looks so cool.

 

I'm a bit confused about the behaviour of the voxel monsters though. It looks like they turn in steps of 45 degrees still, but will render from any intermediate angles as you circle them. I imagined that once they were voxel, they would turn smoothly. Is that just a Doom engine behaviour?

 

Regading the lighting, I probably wasn't clear. I guess what I meant was, do they have normals? Are they shaded relative to the direction of a light source?

Share this post


Link to post

After so long working with the original game engine, I just can't get use to the pixel perfect texturing :D

 

The original game engine has a weird approach to the columnar rendering of walls and it becomes increasingly approximate at closer range, unlike the original Doom engine. In fact the actual columns themselves seem to have increasingly approximate start and end points which manifests itself as gaps that often appear along the edges with the floor and ceiling.

 

It's looking great so far guys.

 

 

Share this post


Link to post
2 minutes ago, 0x4BADC4FE said:

Is that just a Doom engine behaviour?

Yes. At least when reusing the preexisting Doom functions like A_Chase; Doom's P_NewChaseDir function is responsible for choosing in which direction the monster will chase and it only knows the cardinal and ordinal directions. This can also be seen when using 3D models, e.g. in Doomsday.

 

Now with GZDoom it's possible to write your own completely custom AI and movement routines, so if there's a decision to commit to voxel enemies, this could be solved.

Share this post


Link to post
3 hours ago, CravenCoyote said:

 

For the monsters in TKG, they do all seem to attack the player and noone else. It's my intention to allow infighting between them, and with that you should be able to see all sides of each monster. We're hoping to use all voxel enemies at this point and also hoping it isn't too ambitious!

 

Infighting would be a fun addition but you might want to be a bit selective about which ones can and do. The game narrative makes mention of some kind of hive mind, the Breed are not entirely autonomous.

 

I remember reading something in which John Romero said the in-fighting in Doom was not an intented behaviour but they decided to keep it as a feature. I like the cyclical irony of implementing a bug from doom intentionally in a clone of doom that didn't have that bug when reimplementing it in doom...

Share this post


Link to post

Well, this was a tough little cookie to make. The digitigrade legs definitely made it more difficult to get a good walk animation but I think we got there to an acceptable animation.

 

lxkSxiG.png

The original sprite was quite compressed to the point where the eyes looked like they were joined together (or maybe it's a visor of some kind?). It's understandable why people would call them robots, even in the game it was sometimes difficult to see their green skin. The side view sprite of this enemy also has what I think are yellow fangs, but with the original models lost there's no way to tell for certain (as far as I'm aware). Undecided if the 'eyes' will be kept red, or switch back to a yellow mono-eye.

 

8FkQWz5.png

Share this post


Link to post
9 minutes ago, 0x4BADC4FE said:

How does he look in situ?

 

Monsters in Doom when in situ are actually in their walking position and alternate between Frame A and Frame B.

 

If you want to see Frame A in more detail, rotate it, zoom in etc, grab the attachment from this post and view online here:

https://drububu.com/miscellaneous/voxelizer

 

Sorry it's a zip, can't upload .vox here :)

BLUAA-150.zip

Share this post


Link to post

I'm curious what the story here is for the voxels, why not just use the regular enemy sprites from the original game? I am not too familiar with how it looked (I only ever watched videos of the original Alien Breed) but I was curious what prompted these creations.

Share this post


Link to post
Posted (edited)
11 minutes ago, Dynamo said:

I'm curious what the story here is for the voxels, why not just use the regular enemy sprites from the original game? I am not too familiar with how it looked (I only ever watched videos of the original Alien Breed) but I was curious what prompted these creations.

 

From what I've seen of it, Alien Breed 3D 2 visually is a bit weird. Sort of like a Chasm: The Rift situation of being smack between a doom-style raycasting engine and a quake-style polygonal engine (see bellow). It was one of the only Amiga games to require advanced graphics cards, so it's basically the absolute brink of what the Amiga could do.

 

... Part of what makes it an absolute bitch to emulate.

 

Spoiler

 

 

 

So, in other words, they were Voxels in the OG game, not sprites.

There's a reason <20,000 copies of Killing Ground were actually sold, lol. It was a PAL exclusive Amiga game in 1996

For a computer that came out in 1985. AB3D 1 and 2 being able to run on their platforms of choice was basically black magic.

Share this post


Link to post
Posted (edited)
3 hours ago, Dynamo said:

I'm curious what the story here is for the voxels, why not just use the regular enemy sprites from the original game? I am not too familiar with how it looked (I only ever watched videos of the original Alien Breed) but I was curious what prompted these creations.

 

The issue is, there are only sprites for four directions in the original game.  Front, sides and back.  AB3D1 had a similar issue, but since the sprites were hand-drawn it wasn't too hard to draw the diagonals and match the style. But TKG uses 3D renders, so hand-drawing the additional angle sprites and having everything look consistent seems like an issue to me. Maybe it's possible, I'm not sure, but we're looking at options. Craven seems to have taken a shine to working with voxels lately so that's the direction we're taking right now. I do think making new 3D models of the enemies is the dream, we'd be able to generate sprites with them or maybe use them directly, but neither of us are very confident with Blender at all.

 

I can't remember if Craven and I discussed this, but I definitely think having the original sprites or the voxels should be a selectable option. The sprites may look slightly janky if we can't do diagonal frames for them, but still.

 

3 hours ago, Warboss_Gegguz said:

 

From what I've seen of it, Alien Breed 3D 2 visually is a bit weird. Sort of like a Chasm: The Rift situation of being smack between a doom-style raycasting engine and a quake-style polygonal engine (see bellow). It was one of the only Amiga games to require advanced graphics cards, so it's basically the absolute brink of what the Amiga could do.

 

... Part of what makes it an absolute bitch to emulate.

 

So, in other words, they were Voxels in the OG game, not sprites.

There's a reason <20,000 copies of Killing Ground were actually sold, lol. It was a PAL exclusive Amiga game in 1996

For a computer that came out in 1985. AB3D 1 and 2 being able to run on their platforms of choice was basically black magic.

 

 

@0x4BADC4FE is better equipped to address this, but I'm pretty sure TKG is still just a raycasting engine. The 3D bridges you see in some levels is because the engine allows for two floor and ceiling heights per sector, lower and upper. There is also support for 3D vector models, which is used for certain enemies, weapons, items and decorations. There are no voxels used in the game though - enemies are either sprites or vector models. There is some sort of light sourcing system used for most of the sprite-based enemies though, which from what I've gleaned from the asset files (I could be wrong though) seems to overlay the regular sprites with greyscale renders lit from different directions as a brightness modifier, to allow the sprites to react to lighting in a somewhat 3D looking way. It's a cool system but I have no idea how to emulate that in GZDoom, so that probably won't be a thing in our version.

Share this post


Link to post
Posted (edited)

 

10 hours ago, Dynamo said:

I'm curious what the story here is for the voxels, why not just use the regular enemy sprites from the original game? I am not too familiar with how it looked (I only ever watched videos of the original Alien Breed) but I was curious what prompted these creations.

 

TKG uses a mix of sprites and 3D models for monsters, and the 4-directional sprites were made from 3D models which are now lost, too - they're also asymmetrical but the sprites were taken from one side only. Weapons are also 3D models. Pickups are a mix of 3D models and sprites.

 

It's kind of weird to have both in my personal opinion. Using voxels seems like a happy middle-ground between the two. As Arcturus mentioned, we're considering perhaps adding an option to switch between the two.

 

Edited by CravenCoyote : added quote

Share this post


Link to post

I'd recommend rendering out the voxels as sprites and making further adjustments in post (cleaning up, smoothing out, attaching bits of the original art, etc. etc.) for a best-of-both-worlds thing. I feel like attempting to do proper voxel models of every single frame ala Voxel Doom will take a frankly disturbing amount of time that could be spent on the game parts of things.

 

10 hours ago, Arcturus said:

There is some sort of light sourcing system used for most of the sprite-based enemies though, which from what I've gleaned from the asset files (I could be wrong though) seems to overlay the regular sprites with greyscale renders lit from different directions as a brightness modifier, to allow the sprites to react to lighting in a somewhat 3D looking way. It's a cool system but I have no idea how to emulate that in GZDoom, so that probably won't be a thing in our version.

Normal maps are basically just that system but with multiple directions taking up the different colour channels (R, G, B) on a single image, so it wouldn't be hugely impossible to convert into a normal map. That being said, someone can correct me, but I last I checked GZDoom's normal maps and other GLDEFs "material effects" won't work on sprites since they're lit uniformly, so it's all much of a muchness.

Share this post


Link to post
14 hours ago, Arcturus said:

 

@0x4BADC4FE is better equipped to address this, but I'm pretty sure TKG is still just a raycasting engine. The 3D bridges you see in some levels is because the engine allows for two floor and ceiling heights per sector, lower and upper. There is also support for 3D vector models, which is used for certain enemies, weapons, items and decorations. There are no voxels used in the game though - enemies are either sprites or vector models. There is some sort of light sourcing system used for most of the sprite-based enemies though, which from what I've gleaned from the asset files (I could be wrong though) seems to overlay the regular sprites with greyscale renders lit from different directions as a brightness modifier, to allow the sprites to react to lighting in a somewhat 3D looking way. It's a cool system but I have no idea how to emulate that in GZDoom, so that probably won't be a thing in our version.

 

I'm aware it's a raycasting engine, just that it uniquely has a ton of 3D/psuedo-3D assets. Hence the Chasm the Rift (aka "poor man's quake") comparison. A game that famously used 3D models in a raycasting engine and as a result required no external graphics card. Weapon models, enemies, and pickups are all 3D, but then you look up and down and the world goes all fish-eye a la idTech 1 and Build Engine. I phrased it the way I did just to explain why Voxels would be an easier approach both visually and mechanically, rather than ripping and re-rendering the already voxel-based assets for 2D sprites.

 

Especially when one of the big draws of project Osiris (other than being easier to use than an Amiga), was that it looked way, way, WAY better than real Alien Breed 3D even on a fully upgraded A4000.

 

Spoiler

image.png.3f7a1e9c3dc28bd5ebbaceeb095d45fc.png

 

OG AB3D vs Project Osiris w/ viewports TO SCALE. And famously it was fully playable on an A500/A1000, but with a viewport the size of a postage stamp.

 

So going from pre-rendered voxel enemies to actual voxel enemies just seems in-line with the upgrades Project Osiris offered. And as far as the lighting, while the lighting in Killing Ground is SUPER impressive for an Amiga, GZDoom's lighting options runs circles around it. 

 

The main struggle for this is project is going to be getting all the assets over in a way that doesn't make it look like a game for a 1985 machine (be that upscaling, rerendering, touching up, or just redoing them all together) and replicating the AI/weapon behavior. Thus far things look great. 

 

Level design would be pretty straight forward when GZDoom is basically completely unbound by most of idTech 1's limitations outside of environmental X & Z axes movement (eg. Push-walls and sliding doors a la Wolf 3D and Quake). Granted, I say this as someone with 0 mapping experience beyond dicking around in UDB once or twice :P but on a purely technical level the maps aren't anything insane. In fact, that's Team 17's main issue with this game according to interviews. Pushing hardware limits got prioritized over level design and narrative in their eyes... Not that justifies letting this and the original AB3D rot on a dead platform for 30 years.

 

I'm absolutely down to playtest and bughunt (ha!) when things get to that stage though. Albeit, I've never gotten to play the original as a Zoomer in the post-wintel era. 

Share this post


Link to post
Posted (edited)
17 hours ago, Arcturus said:

 

@0x4BADC4FE is better equipped to address this, but I'm pretty sure TKG is still just a raycasting engine. The 3D bridges you see in some levels is because the engine allows for two floor and ceiling heights per sector, lower and upper. There is also support for 3D vector models, which is used for certain enemies, weapons, items and decorations. There are no voxels used in the game though - enemies are either sprites or vector models. There is some sort of light sourcing system used for most of the sprite-based enemies though, which from what I've gleaned from the asset files (I could be wrong though) seems to overlay the regular sprites with greyscale renders lit from different directions as a brightness modifier, to allow the sprites to react to lighting in a somewhat 3D looking way. It's a cool system but I have no idea how to emulate that in GZDoom, so that probably won't be a thing in our version.

 

This is correct - though raycasting is not quite the technique used in either Doom or TKG (that's more a Wolf3D concept). The rendering uses pretty conventional column plotting for walls and horizontal spans for floors and ceilings (flats, I guess is the doom parlance). Unlike Doom, there's no BSP. Instead, you bascically do that by hand when making the map. Maps are composed of connected Zones, which are essentially the closed, convex polygon you'd get from an automatic BSP process. There are a number of rules that have to be observed, e.g. the Zone has to be convex, have no more than 10 (IIRC) vertices. must not be too pointy. There are also some along the lines of a Zone cannot be visible from either side of a hole in the map. Suffice to say, map building can be tedious and the slightest infraction will completely wreck the runtime visibility. It can be extremely frustrating and I've had to abandon hours of effort over it on numerous occasions*. Zones can have an optional upper level which is how you get bridges and things. There's also a water level for that neat refractive rippling water layer.

 

* This is probably part of the reason why the game became so known for poor level design - implementing levels can be extremely difficult and error prone.

 

Regardig the HQN format (no idea what the initialism stands for), this is  a set of 5 different sprite layers, each of which is a 32-colour image. The first layer is a basic colourmap. This is the 3D model rendered with full ambient lighting (i.e. no shadows anywhere) and you can't use all 32 colours, just 8. However, It's divided into 4 different colour variations, so you can have your blue, red, green guards etc. The other 4 layers are 32 greyscale (index 0 is reserved and often some bright colour for pixelling visibility) renderings of the same model without any colourmap information, lit from left, right, top and bottom respectively. At runtime, the engine blends these in an approximation of normal mapping, turning the colourmap into the directionally lit sprite you see in game.

 

On the point of this, I think the basic 32-colour sprite versions are for the 2MB version of the game and as such may also be scaled down slightly relative to the 4MB versions. 

Edited by 0x4BADC4FE

Share this post


Link to post
21 hours ago, Warboss_Gegguz said:

So, in other words, they were Voxels in the OG game, not sprites.

There's a reason <20,000 copies of Killing Ground were actually sold, lol. It was a PAL exclusive Amiga game in 1996

For a computer that came out in 1985. AB3D 1 and 2 being able to run on their platforms of choice was basically black magic.

 

Not voxels, bump maps (sort of). At the risk of being like the comic store guy from the Simpsons, the game was only release for machines from 1992 and the "full" version of TKG needed a 68060 unless you don't mind crippling slowdowns. The current builds we have are significantly faster now and we also have support for RTG cards but it has taken 2 years of deciphering the original code and a lot of experimentation to get this far.

Share this post


Link to post

@Warboss_Gegguz Just to clear it up by the way, AB3D would not have run on an A1000 or 500, it needed a machine with 2mb of RAM, an AGA chipset and at least an 020 CPU, so it needed the A1200 or A4000 from 1992.

 

Thanks for the kind words about Osiris though!  I am hoping we can get TKG up to a similar level. I also aim to address some of the atrocious level design throughout TKG, such as the interminable keycard-based back-and-forths. We likely won't be accurately modelling the original AI behaviour as that sounds like a ZScript nightmare and doesn't serve to make the game more fun anyway.

 

@0x4BADC4FE Thanks for the run-down. Interesting!

Share this post


Link to post

Yeah, definitely appreciating the tech rundowns from @0x4BADC4FE. Game's a fascinating blend of technical ingenuity tempered by some inexplicable decision-making of the oh-crap-our-deadline's-approaching-and-also-our-platform-is-dying-and-we-don't-know-which-one-will-happen-first kind.

Share this post


Link to post
Posted (edited)
18 hours ago, Arcturus said:

Thanks for the kind words about Osiris though!  I am hoping we can get TKG up to a similar level. I also aim to address some of the atrocious level design throughout TKG, such as the interminable keycard-based back-and-forths. We likely won't be accurately modelling the original AI behaviour as that sounds like a ZScript nightmare and doesn't serve to make the game more fun anyway.

Another +1 to Osiris from me, it was a great comversion.

 

I know what you mean about the keycard hunting. As early as Level C you enter the realm of incongruous, confusing levels that have no theme, random maze layouts and require a a relentless hunt for keys. In my mod, this has been transformed into an engineering section of a large orbital station that the ship is docked with. It still has the same overall 2D plan (almost) but with a consistent theme and a bit more verticality. There's also an AB3D1 easter egg in it 

 

The big lag at the 1min mark was something to do with the capture, it was playing just fine.

Edited by 0x4BADC4FE

Share this post


Link to post

Haha, lots of familiar textures in there! Also some suspiciously familiar sprites. :D

Share this post


Link to post
7 hours ago, 0x4BADC4FE said:

Another +1 to Osiris from me, it was a great comversion.

 

I know what you mean about the keycard hunting. As early as Level C you enter the realm of incongruous, confusing levels that have no theme, random maze layouts and require a a relentless hunt for keys. In my mod, this has been transformed into an engineering section of a large orbital station that the ship is docked with. It still has the same overall 2D plan (almost) but with a consistent theme and a bit more verticality. There's also an AB3D1 easter egg in it

 

This looks cool! We will probably try to stick closer to the original looks wise, but will definitely be tweaking the routing for sure. Not looking forward to tackling Level K though - that level is absolutely unforgivable.

Share this post


Link to post
Posted (edited)

Red gunner, comin' through! (Yes, it's just a re-skin at this point - trying to figure out a light solution!)

 

bUj0JDd.gif

 

 

Share this post


Link to post
2 hours ago, 0x4BADC4FE said:

I guess transparent voxels for the headlights are not an option?

 

I can't find anything at the moment, but it's something we considered. I'm not sure if models can support built-in lighting, but that's something we'll be looking at as well. Apparently it's quite easy to convert a vox model to an obj

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×