Blood's engine
Moderator: General Discussion Moderators
Blood's engine
[deleted]
Last edited by Anonymous on Tue Dec 12, 2006 12:58 am, edited 2 times in total.
Um... these guys would know. http://jonof.edgenetwork.org/forum/ Ken even has his own little section of the forum.
Erm... way more advanced? o_O
I think were playing a different Blood... More of just marginally advanced (voxels, basically higher control over entity things so you get stuff like the firing turrets, more sector effects, better sound engine).
Yeah Jonof's would be a good place to hum around at... If you wanted to do a sprite based 2.5d engine like Build but not specifically Build, if you can find a way to make it standalone, which should be doable, Id recommend ZDoom just for editing power and scriptability, but thats only if you decide to forego the creation of the engine and hop straight to gamecode and art.
I think were playing a different Blood... More of just marginally advanced (voxels, basically higher control over entity things so you get stuff like the firing turrets, more sector effects, better sound engine).
Yeah Jonof's would be a good place to hum around at... If you wanted to do a sprite based 2.5d engine like Build but not specifically Build, if you can find a way to make it standalone, which should be doable, Id recommend ZDoom just for editing power and scriptability, but thats only if you decide to forego the creation of the engine and hop straight to gamecode and art.
-The Blood engine has a physics engine for sprites (just like in Descent).scar3crow wrote:Erm... way more advanced? o_O
-The Blood engine can handle dynamic fire.
-The Blood engine can render transparent water surface.
-The Blood engine can render fog.
-And much more...
And I don't want to use ZDoom. It's a Doom engine. And the Doom engine has a lot of limitations.
Erm... what the hell is dynamic fire? Is it some strange thing that is super rare in Blood? Because I dont consider sprites that align viewing plane to the player and loop an animation that dont even do damage to be dynamic.
Unless youre speaking of napalm or things catching on fire, which is simply dealing a certain subset of damage and cueing different animations. Thats gamecode, not enginecode.
Transparent water surfaces are a cool thing, but its hardly revolutionary. You are simply applying the standard sector over sector trick, and when looking from one to the other they apply a middle man of a flat with an alpha of 0.6 or such. This is good implementation of features, it is not a big deal.
Fog or dithering to a grayscale over distance? Im fine with both because I love atmosphere, but once again, not a huge deal, though it is engine related.
Physics to sprites? You mean it has a rudimentary particle system and sprites are flagged to them? That sounds pretty standard to me - it allows for nice details, but nonetheless, not a big deal.
I think Gila was more on the spot with "various knicknacks", none of this is WAY more advanced, its good use of existing engine features and good game code. Yes the engine has evolved between versions, but then I would be looking into the Shadow Warrior version of the Build engine.
BTW, ZDoom is based off of the Doom engine, but it is more powerful than Build. I have seen very impressive stuff done in ZDoom before (scripted events with camera angle changes, rooms flooding, slanted surfaces, scripted ai, doors rotating open, helper ai, swimming, room above room, and more).
Unless youre speaking of napalm or things catching on fire, which is simply dealing a certain subset of damage and cueing different animations. Thats gamecode, not enginecode.
Transparent water surfaces are a cool thing, but its hardly revolutionary. You are simply applying the standard sector over sector trick, and when looking from one to the other they apply a middle man of a flat with an alpha of 0.6 or such. This is good implementation of features, it is not a big deal.
Fog or dithering to a grayscale over distance? Im fine with both because I love atmosphere, but once again, not a huge deal, though it is engine related.
Physics to sprites? You mean it has a rudimentary particle system and sprites are flagged to them? That sounds pretty standard to me - it allows for nice details, but nonetheless, not a big deal.
I think Gila was more on the spot with "various knicknacks", none of this is WAY more advanced, its good use of existing engine features and good game code. Yes the engine has evolved between versions, but then I would be looking into the Shadow Warrior version of the Build engine.
BTW, ZDoom is based off of the Doom engine, but it is more powerful than Build. I have seen very impressive stuff done in ZDoom before (scripted events with camera angle changes, rooms flooding, slanted surfaces, scripted ai, doors rotating open, helper ai, swimming, room above room, and more).
I wouldnt quite consider that dynamic, just decent code...
Erm, Im pretty sure Build already had a basic collision detection, internal networking, could receive user input and supported file types...
The zombie head smashing looks like a case of simple health for the entity, or accruing damage within an instance. Once again, why not the Shadow Warrior version of Build ? Unless it is Windows only, Im not for sure on that.
I didnt read your post carefully because I skimmed it and saw mention of Blood's version being WAY more advanced than Dukes.
And I still say you are wrong on that. Advancements does not necessitate the use of "way" or capitalization. WAY more advanced is Doom to Build, or Build to Quake, or Myst to Doom3. Youre comparing engine versions with gamecode that exacerbated what it can do better than a previous engine version with a previous game.
I will give you that on ZDoom not working on DOS, but I was speaking in terms of engine capability in general, not the platform.
Blood's version of Build is just that, a version of Build. It is better than Duke's version. It is not some Hallelujah Chorus of engine improvements. It is better.
Erm, Im pretty sure Build already had a basic collision detection, internal networking, could receive user input and supported file types...
The zombie head smashing looks like a case of simple health for the entity, or accruing damage within an instance. Once again, why not the Shadow Warrior version of Build ? Unless it is Windows only, Im not for sure on that.
I didnt read your post carefully because I skimmed it and saw mention of Blood's version being WAY more advanced than Dukes.
And I still say you are wrong on that. Advancements does not necessitate the use of "way" or capitalization. WAY more advanced is Doom to Build, or Build to Quake, or Myst to Doom3. Youre comparing engine versions with gamecode that exacerbated what it can do better than a previous engine version with a previous game.
I will give you that on ZDoom not working on DOS, but I was speaking in terms of engine capability in general, not the platform.
Blood's version of Build is just that, a version of Build. It is better than Duke's version. It is not some Hallelujah Chorus of engine improvements. It is better.
Okay, I give up! You're right, Blood's engine is not way more advanced than Duke3D. But I still think it's more advanced than the Duke3D engine. But you're still don't understand I'M NOT talking about the BUILD engine, I'm talking about Blood's GAME ENGINE.
-Bloods player movement is very realistic (that bobbing/swaying is better than any movement system I ever seen in an FPS game). In Duke3D, you feel you're only a sliding camera. 3DR programmers made a horrible bobbing/swaying in SW, too.
-In Blood, the surface determination is also adds more realism to the environment. Duke3D only determines two surface type: water and concrete.
But: The weak point of the Blood engine is the underwater action. That's prettily messed up. Duke3D and SW is much better in this case.
-Bloods player movement is very realistic (that bobbing/swaying is better than any movement system I ever seen in an FPS game). In Duke3D, you feel you're only a sliding camera. 3DR programmers made a horrible bobbing/swaying in SW, too.
-In Blood, the surface determination is also adds more realism to the environment. Duke3D only determines two surface type: water and concrete.
But: The weak point of the Blood engine is the underwater action. That's prettily messed up. Duke3D and SW is much better in this case.
it depends. for example, the most identical game to duke3d is redneck rampage - it even has same palette, same enemy placements (i.e. the tilenumber for duke's assault trooper is the same as the tilenumber for rampage's skinny ol' coot, if i remember correctly), similar inventory items - like steroids=moonshine. the redneck rampage is basically a duke3d professionally done total conversion with some additional features or couple of special effects here and there. i guess monolith wanted to make something of their own.CheapAlert: if BUILD is a complete game engine, why you need to write AI, GUI, event handler, etc., and why you need to use a sound engine for it? (Yes, it has a built in "sound engine" by Ken, but it's prettily useless...)
besides, blood was under development of 3drealms; they had a "blood team" at one point and even richard gray aka levelord supposedly made some levels for it (as various leaked historical txt files and apogee faq proves), then 3drealms sold everything to new company qstudios which took the game and later morphed into monolith productions. in some of the technical documents they always mention "monolith's xsystem". what is it - beats the s*** outta me, but i think it's the name for their modification of build engine.
after all, they have differently working ambient sound effects, they ditched lotag/hitag system and instead made nice convenient gui in build and added "rx/tx channels" which was much more useful than duke3d's and redneck rampage hitag/lotag wankery. they wrote their own physics engine, well, sort of; notice that duke3d basically has no physics - if a pipebomb blows up underneath you, well the player could be pushed back at best a bit; in blood, it throws you up in the air. but that's just some of the minor things to mention. who knows why they did all that? judging by the alpha version and even more early shots of the game (dated back to 1995 i think) - it was waaay different back then and even alpha version doesn't have all that stuff i mentioned.
that it's not a series of frames that are animated (like waterfall, for example), and it just one image that morphs or something, but probably pallette shifting is used (if that's the correct term). it's not that they used it widely, but they used it to immitate 'freezing air' in some of the level's fridges.About the dynamic fire: Hmmm-Hmmm... What's so "dynamic" about the fire in the stove?
despite that i love rtcm, i wouldn't believe that. plus, it has enormous amount of errors... or typos? that information (as is the 'dynamic stove fire' opinion) is based purely on fan speculation. and that 'ketch on fire from burning bodys' - wtf? in blood, none of the fire sprites hurt the player. fire damage can be done only on lava, via flaregun, napalm cannon or lifeleech projectiles. the fireplaces do not hurt, the torches do not hurt, the burning stuff does not damage player either.... The fire used in the game is handled nicely, except for the point you can't ketch on fire from burring bodys. It doesn't even hurt you like it does in Duke3D. The times you can get hurt for sure is from "living" bodys that are set aflame and they touch you, or from Dynamic Fire sources like balls of fire. Duke3D doesn't use dynamic fire, basicly if your touching fire thats burnning you get hurt, but won't ketch on fire. Using both games method combined would provide a much better fire system.
- Willis
Master of the Mask
Lead Programmer- Posts: 872
- Joined: Tue Aug 10, 2004 09:28 am
- Location: Eau Claire, WI USA
- Contact:
Because a game engine itself is not a game. just like a gas motor is not a car. Many different vehicles can be powered by the same type of motor, but it is the manufacturers job to build the rest and sell it. As for the sound engine, that is a true oddity here. There was one included, but as you mentioned, it was very basic. In this case it was probably just easier to license technology than for Ken Silverman to learn how to make something nearly as good. Having seperate sound and motion video engines, and now, physics engines, is quite normal.Escorter wrote:if BUILD is a complete game engine, why you need to write AI, GUI, event handler, etc., and why you need to use a sound engine for it?
In this case, I think they are refering to the Incinterator in the crematorium in E1M1 which was a lava based trigger, not a flame based trigger.Gila wrote:the fireplaces do not hurt