Hello. I originally wrote this article back in 2018 and published it in a Russian-speaking underground group dedicated to Cry of Fear. Now, I’ve decided to translate it into English and publish it on Steam (in fact, I had the same intention back then, but something went wrong).

Sometimes I do reverse engineering of games just for fun, and one day I got my hands on the game Cry of Fear, so I decided to work with it. In this article, I’d like to share some of my personal observations about how the game is structured. I’ll cover various interesting details and describe certain gameplay mechanics in depth.

I understand that most readers of this article likely aren’t familiar with programming in general, so I’ll do my best to explain every detail I mention clearly. Occasionally, I’ll also try to lighten things up with content that’s easier to digest.

Let’s get started.

The number 666 can often be found in the engine's binary code, but there’s one example that anyone can reproduce - the console command unfreeze. It takes a single argument, and if that argument is set to 666, the screen will briefly turn black and return to normal after about a second.

The player's movement speed is 225 units while walking, 300 while running, and 150 when walking backward or sideways. When fatigued, the walking speed drops to 135 units, and backward/sideways movement drops to 90. Pressing the run key consumes 5 stamina points. Jumping and dashing each consume 15 stamina points. The player has a total of 100 stamina points.

Each weapon in the code has its own weight, expressed in some arbitrary units. For example, the mobile phone and flare have a weight of 1, the Glock and rifle weigh 5, and the shotgun weighs 20. The shotgun is the heaviest weapon in the game.

Unfortunately, weight has no actual effect on gameplay - it’s simply defined in the code, so the player’s speed remains the same regardless of what they’re holding.

In the game engine, you can be marked as a "f*ggot" - strange as it may sound. This is because each player has a variable named m_iIsAF*ggot (yes, that's the actual name of the variable), and its value depends on your SteamID. If your SteamID is STEAM_0:1:7832479, STEAM_0:1:33405825, or STEAM_0:1:39527250, the game will instantly disable your ability to move. These SteamIDs most likely belonged to some particularly "problematic" individuals who caused enough trouble in co-op mode to earn a hardcoded ban directly in the game engine. Additionally, the developers themselves can flag a player this way while on a server, using a special console command available only to them.

The game is compiled with optimizations disabled. This is evident from the typical structure of the engine’s assembly code: frequent stack access, constant function prologues and epilogues - even in the smallest functions. This means that the entire engine runs slower and is more bloated compared to an optimized version. Why the developers chose this approach remains a mystery.

It's possible that enabling optimizations caused the game to crash, and instead of investigating the root cause, the developers simply disabled them. However, this would be quite unprofessional, and I find that explanation somewhat hard to believe.

When a double dose of morphine is administered within 35 seconds (the default value taken from the console variable sv_morphinetriptime), Simon begins to experience a trip. It’s specifically Simon who trips - not the police officers, as the effect does not trigger in co-op mode.

The events of the trip are nonlinear and depend on randomness. At the start of the trip, there’s about a 33% chance that Simon won’t vomit at all. However, there’s roughly a 66% chance that he will vomit within 5 to 20 seconds - the exact timing is random.

The blur effect that occurs during the trip always lasts exactly 30 seconds and is not subject to randomness. Additionally, during the trip, the value of the room_type console variable (which controls audio echo effects) is set to 16, and it reverts to its previous value once the trip ends.

The inventory can be managed through the console, and therefore also through keybinds. A bind is a command assigned to a specific key. The simplest list of binds can be seen by opening the keyboard tab in the options menu. The actual binding is handled via the bind console command.

There are a total of seven console commands for inventory management, and I will describe each of them in the following seven subpoints.

• inventorydualwield <slot1> <slot2> – a command used to equip two items simultaneously. Replace <slot1> and <slot2> with the inventory slot numbers, starting from 1.
  Example usage: bind q "inventorydualwield 1 6"
  With this bind, pressing Q will equip the items from the first and last inventory slots.
  
  
• inventorydrop <slotnum> – a command for dropping items from the inventory. Replace <slotnum> with the desired inventory slot number.
  Example usage:
  bind q "inventorydrop 1; inventorydrop 2; inventorydrop 3; inventorydrop 4; inventorydrop 5; inventorydrop 6"
  This bind allows you to drop all items from your inventory by pressing Q.
  
  
• inventorycombine <slot1> <slot2> <result> – a command used to combine two items. Replace <slot1> and <slot2> with the inventory slot numbers, and <result> with the name of the event. There are only two valid event names:
  - glockwithtaclight - for combining the Glock with the tactical flashlight
  - phonewithbattery - for combining the phone with the battery
  
  Both events remove the flashlight or battery from the inventory. However, in the case of glockwithtaclight, the game sets a specific Glock-related variable to 1 to later trigger a separate flashlight attachment event.
  It’s odd that the developers chose this approach instead of simply checking the names of the items being combined to determine which event to call, thus eliminating the need to manually specify the result parameter.
  
  
• inventorycheck <number> - a command that does nothing. Judging by its name, it should check something in the inventory, but instead it calls an empty function.
  
  
• inventorydeletenamed <slot> <all> - deletes an item from the specified inventory slot. However, if the argument all is set to any non-zero number, the entire inventory will be deleted. The deletion works in a strange way: the items are removed, but you can no longer pick up the same deleted items, and if you were holding the deleted item in your hands, it will remain. Most likely, this command is supposed to be triggered after the train crash that Simon experiences.
  
  
  
  
• inventoryequip <slot> - equips the item from the specified inventory slot.
  
  
• inventoryuse <slot> - uses the item from the specified inventory slot.

I’m quite certain that using the alias system, it’s possible to write a script that would allow selecting and combining items from any slot using the keyboard, without relying on the in-inventory combination interface. However, I don’t plan to test this for now.

The maximum length for message text on Simon’s phone, which is read from the file phone_messages.txt, is 254 characters. If the message exceeds this length, the displayed text will be replaced with "Your message is too long. Rewrite it!".

The game’s code includes support for armor, just like all games built on the GoldSource engine (Half-Life 1, Counter-Strike 1.6, etc.), but it cannot be obtained in normal gameplay. Even if you somehow manage to give armor to the player, it won’t be very useful - the engine code specifies that armor protects only against bullets, not against melee or cutting damage, and bullet damage is fairly rare in the game.

Overall, I once attempted to implement an armor system. It turned out very clunky, but I was satisfied with the result I got and decided to leave it as is.

Overall, that’s all. Thank you very much for taking the time to read this article. Sorry if it turned out a bit boring, with no pictures or anything like that - it’s just a plain text article from 2018 that I decided to finally publish on Steam.