Please consider supporting The Cutting Room Floor on Patreon. Thanks for all your support!

Proto:Blood/Alpha Demo

From The Cutting Room Floor
Jump to: navigation, search
This is a sub-page of Proto:Blood.
This page sucks.
If you could make it suck less, that would be awesome.
Specifically: A direct copy-and-paste from another wiki. At least half-ass it by putting in some images and properly formatting some things, rather than copy-pasting and then patting yourself on the back.

The Alpha Demo of Blood was compiled on February 6, 1996, nearly 16 months before the game's final release, when it was still being developed by Q Studios Corporation. Interestingly, this build was copied and leaked from a developer's PC after it got sent to a repair shop.

More info, along with the prototype itself, can be found here.

To do:
Redo the differences if necessary. This is all copypasta from the Blood Wiki.

General Differences

  • Caleb was originally named Micheal, while Ophelia Price was originally named Rachael.
  • There are no Innocents.
  • This build utilizes a different map-file format than the final.
  • While the art for the various armor is present, no armor system is present yet and no armor appears in any level.
  • The crouch function doesn't work, although it does work while using mapedit.
  • The Tilt view functions work, although they have no stopping points and will cause your screen to endlessly spin in a circle.
  • All maps with mirrors have a strange mirror-like function when M is pressed.
  • No key-locked switches, doors, or objects refer to the key they need in the display text.
  • The Diving Suit automatically activates upon pick-up, and is also completely useless since there are no maps with working underwater sectors at this point.
  • A number of weapons are located on different number slots.
  • The Life Leech does not yet exist.
  • An additional "single stick" dynamite mode is available.
  • There is a "Beast" mode that would function under a bloodlust system, fueled by taking massive amounts of damage and/or doing massive amounts of damage to enemies.
  • Connected to the above, there are indications that all four of the chosen were to be selectable and have their own separate Beast mode, which were most likely going to be the boss characters of the retail game.

Weapon Differences

  • The Voodoo Doll alt-fire causes enemy infighting to occur.
  • The Proximity Detonator and Remote Detonator are only usable through alt-fire mode. Attempting to throw them simply turns them into the default Dynamite Bundle.
  • The Sawed-Off Shotgun sprite is different.
  • The Aerosol Can has different sprites for both the object and its projectiles: the can is tinted a dark black, while the fire is represented by a stream of fireballs.
  • An unreleased weapon, the Spear Gun.
  • The Napalm Launcher pick-up sprite says "shadow gun", and is referred to as "EctoBlaster" in the display text.
  • The Napalm Launcher sprite itself seems to be a bit longer, with a strange wire attached to a piece of flesh on its left side.
  • The Flare Gun alt-fire uses up just one flare and shoots them in a round target-ish pattern.
  • A weapon referred to as the "Beast Claws" is located in the "0" slot. It has no alt-fire or attack definitions, and can only be acquired through the "QSAMMO" cheat.
  • An unused pick-up sprite and ammo type called "Armor-piercing bullets".
  • The Guns Akimbo pick-up sprite has dark black-tinted shotguns. The weapon itself has no effect in this build.

Graphical Differences

  • In third-person mode, Caleb is dressed in gray fanatic robes rather than a black cowboy hat and trench coat.
  • There are unused "jumping" and "crouching" Cultist sprite sets.
  • An unused HUD damage sprite set, showcasing the appearance of three bloody scratches onscreen.
  • The wine bottles have an unused sprite set where they bob up and down while in water.
  • All destructible vases have a "destroyed" sprite, and can be bounced around with explosives.
  • Cultist bodies don't melt away after death.
  • The limited invisibility item's pick-up sprite is different.

Unused Items

  • Asbestos Suit - Protects against floor-based lava, which would be useful except there are no lava floors that damage you at this point in development.
  • Clone - No in-game effect.
  • Doppelganger - No in-game effect. Represented by a tiny spherical smiley face.
  • Decoy - No in-game effect.
  • Black Chest - No in-game effect.
  • Wooden Chest - No in-game effect.
  • Raven Flight - No in-game effect.
  • Gas Mask - No in-game effect.
  • Shadow Cloak - No in-game effect.
  • Skull Grail - No in-game effect.
  • Silver Grail - No in-game effect.
  • Wine Goblet - No in-game effect.
  • Wine Bottle - No in-game effect.
  • Rose-colored Glasses - No in-game effect.
  • Rage Shroom - No in-game effect.
  • Grow Shroom - No in-game effect.
  • Shrink Shroom - No in-game effect.
  • Delirium Shroom - Screws with your interface upon picking it up, causing the screen to get hazy as well as twisting and contorting.
  • Red Potion - Restores 2 health upon pickup.
  • Feather Fall - Allows you to fall slower and minimize falling damage.

Enemy Differences

  • Neither the Axe Zombie or Bloated Butcher have alternate death sequences when killed with the Voodoo Doll.
  • The Fanatic can lob singular sticks of dynamite.
  • The Axe Zombie doesn't have any fake death sequences.
  • The Bloated Butcher has no vomit attack yet.
  • The Hell Hound, Stone Gargoyles, and Gill Beast can all be gibbed with explosive weaponry.
  • There are no green or red Spiders, and the Spider enemy has no blinding or delirium-inducing effects.
  • All Stone Gargoyle statues will transform into a Gargoyle when attacked.
  • The Bloated Butcher has an alternate "fire" death animation, although it is not implemented due to fire death issues.
  • The Axe Zombie seems to have an alternate "crushing" death animation, although crushing hasn't been implemented at this point.
  • The Bone Eel has a set of sprites that indicate it was once going to be able to jump out of water.
  • The Gill Beast has a set of alternate-color sprites, showing it with bright white eyes and a more "zombified" appearance.
(Source: Blood Wiki)

Developers' Notes

Present in the NOTES folder are several text files that contain developers' notes about various aspects of the game: ARTTASK.TXT, INFO.TXT, MONSTERS.TXT', STYLE.TXT, and WEAPONS.TXT.

Two other files in this folder, GEORGE.TXT and EPIC.TXT, are of particular interest due to detailing the company's difficulties in dealing with Ken Silverman (creator of the BUILD engine) and a plan for terminating their business relationship with Apogee Software/3D Realms.



I just got off the phone with Nick, who told me he had passed my previous
message about Ken to you.  I hope that you understand that I was really just
venting at Nick, and I didn't intend that my message be passed on to you,
Ken, or his father.  There is still, however, a very significant problem we
(Q Studios) have in dealing with Ken.

Every update Ken makes to his engine turns out to be a major tribulation for
us.  He regularly makes changes that break our code without any advance
warning.  He consistently ignores our requests for fixes or suggestions for
design strategy.  Nick is constantly on me to "Call him.  Just get on the
phone and talk to him," but to be honest, talking to Ken on the phone is
pretty much near the bottom of the list of things I'd like to do with my

The problem is, he's just so completely unresponsive.  I'll ask him a
question, and nine out of ten times I'll either get silence or "I don't know"
as a response.  I know he's highly intelligent, but so are a lot of people I
know, and I can TALK to THEM.  Okay, so perhaps his personality is a bit
different, but he still needs to work WITH us, not AGAINST us.

We've had a resource and memory manager in Blood since last year, and it's
been working well and is very solid code at this point in time.  To get it
working back in December though, I had to completely replace parts of the
engine, no thanks to Ken.  A well designed system would have been built on
the ground up from a good memory manager, or at the very least with hooks
laid in so it could be developed later.  To get our virtual memory system to
work with Ken's engine, I had to spend weeks reverse engineering Ken's code,
documenting variables, prototyping functions -- all things that Ken himself
should have done or provided.

Now in June, he hacks in his "group file" system, and says we have to use it.
In one sense he's right -- he's hard coded the thing into his engine, and it's
broken Blood unless I can figure out which parts of the engine I need to
replace.  By the time we're done with Blood, we probably won't have any of
Ken's engine left...  Perhaps you'll want to reconsider the royalties that
you are paying him.

A few months ago, Ken made a change to the engine that allowed each tile to
have its own origin -- a reference point by which it could be positioned.
This change was a good one, but there were some problems with the
implementation.  When the bit was turned on to enable sprites to be centered
on their origin, animations bounced, and sprites appeared at the wrong

It turns out the solution was one of procedure -- by setting the origin at
the base for sprites that are supposed to be on the floor, everything appears
correctly.  Unfortunately, setting the origin for several thousand tiles
using Ken's EDITART tool was just a bit too cumbersome for us, so I spent a
few days developing a tool that would allow simple tweaking of the tile
origins, among other things.  This tool is integrated with our new sequence
editor, which will be used to create and edit all the actor animations
(walking, attack, death, etc.)

Everything with this system was going fine until we discovered that Ken has
some engine flaws in dealing with sprites that use origin based centering.
The clipmove() function doesn't work, and neither does hitscan().  These two
functions are pretty much essential to doing anything with the engine.  I
could rewrite them, of course, but that would be a few days to weeks out of
our schedule, depending on how many more bugs and design problems crawl out
of the woodwork.

We had waited a few months before switching to the new origin based
centering, so I was quite surprised to find such fundamental problems with
it.  We called up Ken and told him about it, and he said he didn't think
anyone was using it, but he really didn't know.  We asked him to fix it.

Tonight I called up Ken because of the group file problems, and because we
still don't have a fix for the clipmove() or hitscan() problems.  Ken he
wasn't going to fix it and we should go back to using the old centering mode.
This is totally and completely unacceptable.  We've already invested time and
effort (need I say money?) into using something, and we're not about to waste
more regressing.

Ken understands algorithms, and he understands graphics.  What he doesn't get
is how to design SYSTEMS.  Everything he does to the engine is a piecemeal
enhancement to something that should have been designed right from the
beginning.  The memory system is a poignant example of this.  It is a hack,
like most of his code, and not very robust.  From what I've disassembled of
the group file code (trying to figure out a way to eliminate or replace it),
it too demonstrates plentiful opportunities for crashing the system --
pointers being freed without validation, files being closed without
verifying the handle, etc.

Our resource and memory manager are quite superior to Ken's (no bragging),
so to abandon our body of code would be a step in the wrong direction.  When
I mentioned to him that our resource manager used an LRU list to handle
purging of resources, he said that he didn't understand how they worked and
he didn't want to undertake something that complicated.  It isn't that
complex; it's just outside the realm of Ken's experience.

I usually end my phone conversations with Ken with something like the
following: "Ken, is there anything I can do, anything I can provide to you,
that would help you make these fixes or changes?"  The answer is invariably
"No."  After we hang up, I usually bang my head on the desk for about ten
minutes.  I've tried to explain to Nick that this is why I don't like to call
Ken, but I think he already knows.

Tonight I tried to explain to Ken what a library file is.  I told him how
linkers work, and how they resolve symbol name when producing an executable.
I tried to impress on him the benefits of "code granularity" -- breaking a
system up into as many small discrete modules as possible so that the linker
can efficiently pack only used code into the executable.  I informed him
about "dead code", and why there was so much of his in Blood.  I don't think
I made any impression at all.

George, I want you to understand one thing.  When I ask Ken to make a fix or
enhancement, it is most surely something we absolutely need for Blood.  I
wouldn't force myself to make the phone otherwise.  However, everything that
I ask for would benefit not only Blood, but EVERY OTHER build project.  I've
spent enough time as a Project Manager for commercial programming tools that
I know what makes a good API, and I know what makes a system extensible.  The
things I've been asking for are "hooks" so we can implement our own features,
not have him do them for us.

I sometimes wonder, though, if I'm going against the flow.  Perhaps Ken added
his cache system in response to other teams request for a memory manager?
Maybe the group file code was asked for by the Duke Nukem team?  These fears
usually turn out to be unfounded, since other teams report similar problems
as a result of Ken's "updates."

I realize that most of the problems I've been describing with Ken are highly
historical in nature, and there's no way to change the past.  What can and
must be done though is to make Ken more responsive to our needs.  He needs to
work WITH us, not against us.  I don't know why he is so combative, but I can
guess -- ego.  He probably feels about his code the way a lot of programmers
do: it's okay to criticize your own code, but for anyone else to do so is
blasphemy.  I used to be that way until I realized that a lot of the
suggestions people were making to me were actually right.


Termination contract - Release agreement

Send them a letter saying why we want out - make it clear that we will no
longer continue our business relationship under any circumstances.  Try to
separate Scott and George from Apogee.  Avoid personal attacks.

Intro- recieved draft agreement.  Doesn't follow intent of agreement.  We left
higher paying jobs.  Apogees priorities changed.  We lost creative control,
potentional income.  We can't work under a situation like this.


* stole development teams

* quote emails

* "mission of Apogee West is to ...."

* "all games produced by AWD recieve xx%"

* recruited Richard away from us

* withdrawn Sonic Holography agreement

* Promises about ports to consoles

* "Nick met with people from several console platforms - Atari, Goldstar,

* AWD was supposed to receive 70% of console

* Apogees failures to produce a Blood contract despite frequent promises

* Georges recommendation to defraud IRS


* 35% on sales of ruins

* Severence

* compensation for amounts that would have been made through ports


We want to be fair, we want a clean exit

We should to be free to get back on track with the project, but this may
not be possible due to the damage you have already caused.  We feel that you
owe us at least this.

Avoid any mention of personality conflicts, i.e. Greg Malone.

Prototype BUILD Game Screenshots

Present in the PICS folder are various pictures of prerelease versions of Shadow Warrior, Duke Nukem 3D, Ruins: Return of the Gods (Powerslave/Exhumed), and Blood in .PCX format.

Unused Sprites

Present in the PICS/MISC folder are some unused sprites of the Spear Gun, Tommy gun, and what looks like a remote detonator are to be found here.

Blood (Alpha) - SNEW1.GIF Blood (Alpha) - SGUN0609.GIF Blood (Alpha) - REMOTE.GIF Blood (Alpha) - TOM0627.jpg

Unused HUD

Also present in the PICS/MISC folder is a picture of an unused HUD, likely an earlier iteration rather than an alternative that was being considered at this point.

Unused Used
Blood (Alpha) - STATNEW.jpg BloodAlphaUsedHUD.png