Skip to content

LegendaryGuard/BFP

Repository files navigation

Bid For Power (BFP) source code

Stars Forks License Build actions Visits

A legendary Quake 3 Arena mod from the late 90s to early 2000s.

bfpq3logo

TODO list

Pending:

  • Attacksets (bfp_attacksets.cfg)
  • Skin Config File (explosionModel, explosionShader, missileRotation, missileShader, ... look old docs and cfgs about that: Custom plugin models - default.cfg for each player model)
  • Weapon Config File (bfp_weapon.cfg & bfp_weapon2.cfg)

Done:

  • Animations as listed on the old docs
  • Auras
  • Balanced player physics movements (different from the original BFP, but balanced for gameplay)
  • Beam trails
  • BFP config file (bfp.cfg) (a sample of how the game saves general binding and BFP cvar stuff in a cfg file)
  • bg_ weapon properties: weaponTime, randomWeaponTime, kiCostAsPct, kiPct, kiCost, chargeAttack, chargeAutoFire, minCharge, maxCharge, loopingAnim, noAttackAnim and movementPenalty
  • Bind key to recover ki energy
  • Bind key to toggle speed (ki boost)
  • Blinding Flash (blinds opponents during 6 seconds)
  • Blocking (consumes ki energy, transfers all damage to ki instead of health, deflect missile attacks, more info on old docs)
  • Breakable map entities ("func_breakable")
  • Bots behavior
  • Bounce features (bounces, bounceFriction, noZBounce)
  • Cone of fire feature (coneOfFireX and coneOfFireY)
  • Cvars
  • Damage calculated by attacker powerlevel, modified knockback and melee knockback (pushing opponents after receiving impact/damage, also loses altitude while flying/underwater/on slopes)
  • Charge multipliers and maximum damage for weapons (maxDamage, chargeRadiusMult, chargeDamageMult, chargeExpRadiusMult)
  • Extraknockback for weapons (extraKnockback)
  • Forcefield feature
  • Gametype: Survival (g_gametype 3)
  • Gametype: Monster (g_gametype 4)
  • Gametype: Team Last Man Standing (g_gametype 6)
  • Homing weapon feature
  • Hit Stun (makes player can't use ki, melee, block and charge)
  • Illegal player model server handling
  • Instant character model changing
  • Ki shockwave (or Tornado Blast) weapon (a shockwave to push opponents)
  • Ki trails
  • Load player models only by prefix
  • Multishot feature
  • Melee feature
  • Offset features (randXOffset, randYOffset and alternatingXOffset)
  • Particles
  • Power Struggles (when two beam attacks collide)
  • Powerlevel and Power Tiers indicated on old docs
  • Playable third person mode and first person vis mode
  • Priority for projectiles
  • Missile properties (missileSpeed, missileDuration, missileGravity and missileAcceleration)
  • railTrail weapon property
  • Radius feature (radius, maxRadius, maxExpRadius)
  • Razor disk weapon (fires a cutting disk which can pierce beating low health opponents)
  • Reflective feature
  • Remove some items like powerups and health pickups
  • Remove weapon visuals (models and stuff)
  • Replace ammo to ki energy stamina
  • Rocket jumping (applicable if jumping is pressed at the same time)
  • sbeam attack type feature
  • Short-Range Teleport - Zanzoken (when pressing 2 times left or right)
  • Spectator can stop following the last player
  • Splitting ki ball (rdmissile attack type) feature
  • Third person traceable crosshair
  • Toggeable flight (bind key)
  • Transformations (related to Power Tiers)

Table of contents

  1. History
  2. About the repository
  3. References and clues to know how should be the game
  4. How to build

4.1. Introduction
4.2. Windows

4.2.1. Building QVM (using .bat)
4.2.2. Building QVM (mingw)
4.2.3. MSYS2 (mingw) (Building dynamic libraries (.dll))
4.2.4. Cygwin (mingw) (Building dynamic libraries (.dll))
4.2.5. MSVC (.dll))

4.3. Linux

4.3.1. Building QVM (make)
4.3.2. Building QVM (using .bat)
4.3.3. Building shared libraries (.so)

4.4. Optional

  1. Notes
  2. Legal
  3. Credits

History

BFP_ZEQ2_history

Started: 1998
Ended: 2002

Bid For Power is a total conversion for QuakeIII that plays nothing like the original game. Players take control of Ki-powered superheros and battle it out in a mostly aerial fight. The game is highlighted by the work of a great art team and an original style, and the gameplay is extremely fast paced. It can be difficult to keep up with until you get the hang of it.

The project was started on Quake 2, that's where they were getting organized playing Quake and learn some programming there.

The source code is said to have started from SDK 1.15c released on January 14, 2000. It continued to be updated, including the addition of cg_particles.c in 1.29, until 1.31. More info can be found in Quake 3 Arena changelog version history.

The original source code appears to be lost, but the assets and some docs are available in various places. Nonetheless, not all sources are accessible.

Old dev journals (1998 - 2002)

The original URLs can be slower to load, so it's recommended to use markdown edition ones.

NOTE: Some URLs and images within these contents may be broken or partially recovered. The final parts of Chris and Yrgol dev journals were found here:
Chris: https://web.archive.org/web/20011202065630/http://bidforpower.com/
Yrgol: https://web.archive.org/web/20020520060044/http://www.planetquake.com/Bidforpower/
On markdown editions, the data log is complete.

... And more dev journals can be found here.

About the repository

We're making a replica of the lost source code.
The highest priority goal is to copy and recreate the complete logical structure of the BFP game. It would be a game SDK that'll provide a structured and standardized way to modify the mod.
You'll notice some differences and things that the original Bid For Power didn't have/were forgotten, incomplete or poorly made such as:

EFFECTS:

  • how particles move (e.g. bubbles are handled underwater and touching something solid vanishes to save performance)
  • explosion dynamic lights are back (these were broken after RC/beta versions)
  • real impact crack mark, when projectiles/ki attacks impact something solid on ground, walls or slopes (on original BFP, that hasn't been fixed)
  • particle aura is almost implemented
  • beam trails are bendy, almost similar to original BFP though
  • while charging ki near water, bubble particles appear
  • when player is still moving with/without friction and charging ki, antigrav rock particles appear
  • when antigrav rock and rock debris particles fall in a slope or inclined places, bounce and slide, that makes the movements more realistic
  • 3d particles for bubbles, antigrav rock and rock debris, that can be enabled with cg_3dparticles cvar. For 3d rock particles, you need 3 models inside models/effects/ directory: pebble1.md3, pebble2.md3 and pebble3.md3; otherwise, it will appear the standard ones. That option is included in BFP OPTIONS menu in VIEW & FX, also with a new explosion type option in EXPLOSIONS: Ultra Hardcore
  • piercing weapons, like Razor disk, emit spark particles when hitting a player
  • beam struggle emits spark particles in the middle of both beams (in original BFP, emits in the zeroed origin)
  • new particles: charge smoke, which appears when charging ki near the ground
  • new cool missile trails (that replaces original Q3 missile smoke trails), includes rainbow option (it can be disabled by setting cg_oldRocket 1). These trails are quite similar to the Rocket pod weapon from Bazooka Q3 (BQ3) mod

PMOVE:

  • balanced player pmove physics:
    • players can interact bounce pads like Q3 does (on original BFP, the physics are like you're sliding heavily on the ground and not bouncing as usually do, you're being pushed when touching bounce pads)
    • no weird underwater movements while going intentionally down and moving crazily fast touching the ground (this might be a bug/glitch from original BFP)
    • no specified stuck animation, so any animation is correctly handled when being stuck (on original BFP, when the player is stuck or pretty near to something solid, the reason is still unknown though. It does a jumping forward/backward animation, that doesn't make sense)
    • water movement handling is different from original BFP, but it works similarly

ATTACKS:

  • beam with chargeAutoFire can fire correctly by holding the attack key (on original BFP, beam is detonated at the first instance and player gets damaged by the detonation)
  • the owner who fires rdmissile with chargeAutoFire, can fire without dealing damage (on original BFP, every time is being used after some charge, player gets damaged after firing per weaponTime)

GAMEMODES:

  • survival gamemode is pretty well balanced (on original BFP, when everytime the player changes a different character model from their own prefix, dies and respawns during warmup, the warmup resets. So, that's unfair)
  • monster/oozaru gamemode has the following in-game differences compared to the original:
    • the player monster is labeled 'MON' on the scoreboard
    • the player monster has a larger floating sprite chat
    • the player monster has a larger shadow effect similar to regular players
    • the player monster has a large dynamic light when charging or using ki
    • the player monster's ki trails are larger than other players'
    • the player monster generates bigger bubbles, smoke, and antigrav rock particles when charging/using ki boost
    • the player monster can pick up items on the floor or where its hitbox can touch
    • the player monster can use teleporter without getting stuck on most maps, but that may not work 100% on all of them
    • player monster's first-person and first-person vis mode viewpoints work properly
    • player monster's third-person camera has improved focus in the code (similar to BFP's standard third-person view but scaled for giant characters), it can be enabled by setting BFP_MONSTER_CAMERA_VIEWPOS macro to 0 and recompile the code, although the traceable crosshair looks a bit jerky
    • g_monster cvar enables the monster/big monkey feature (that happened in the RC/beta versions)
    • available in the UI, maps marked as monster besides oozaru can be viewed in the GAME SERVER menu
  • team last man standing has the following in-game differences compared to the original:
    • players cannot switch teams after joining a team (on original BFP, the dead player -who was forced to spectate- can join during the match, that was against the rules)
    • players cannot voluntarily switch to spectator after joining a team
    • players attempting to switch teams/spectate receive centerprint messages
    • maps marked as tlms besides lms can be viewed in the GAME SERVER menu

UI:

  • some adjusted UI buttons
  • BFP OPTIONS menu is upgraded, big explosions and smoke options are back (these were removed after RC/beta versions), also shell and ring options are available and these are options are interactive with explosion type option. Sprite and particle aura types are available on aura type option
  • in the first GAME SERVER menu has a horizontal scrolling description about the selected gametype
  • GAME SERVER menu has pagination
  • PLAYER SETTINGS menu has pagination
  • SERVER INFO menu displays all server info (on original BFP, the info was badly displayed and nothing was shown) and it has pagination
  • DRIVER INFO menu is fixed (on original BFP crashes) and it has pagination on extensions
  • CHANGE MAP button is added in in-game pause MENU, allows you to change the map without restarting the server and making everyone reconnect

MISC:

  • cg_drawTeamOverlay 2 is fixed on the lower right corner (on original BFP looks non-visible)
  • g_allowSpectatorChat cvar is functional, spectators can't send messages if the cvar is disabled
  • cg_forceSkin forces the default skin for each model correctly when changing models/skins (on original BFP, that changes to the first model of the prefix with default skin)
  • some cvars didn't save changed values after quitting the game that happened on original BFP (means that CVAR_ARCHIVE wasn't on them), but these are now applied on replica
  • kiCharge, boostCost and blockCost cvars work differently
  • removed some unused cvars
  • spectator mode can toggle ki boost as if the player is flying
  • ki boost consumption is applied in msec if timescale is different from it (on original BFP only applies until 0.89 and from 0.89 until 0.80 reduces one per one very slowly)
  • file size differences between the QVM and the original BFP QVM can be quite significant
  • configstrings in CS_PLAYERS like "c1" and "hc" are removed to be optimized, handicap is disabled logically because it isn't used at all
  • some Q3e patches are applied, like events and function stuff...
  • ...

Any fixes, improvements and contributions are welcome. But we can't accept secondary things and other stuff that don't reach the goals.

References and clues to know how should be the game

Documentations, references and extracted stuff will give us clues to reach the goals.



  • cfg files:

A sample inside models/players/player_name/default.cfg:

Server config:

Attacksets:

Weapon settings:

BFP config (a sample of how the game saves general binding and BFP cvar stuff in a cfg file):

How to build

Introduction

IMPORTANT NOTE TO THE DEVELOPMENT: all source code files must be UTF-8 without BOM and Unix (LF), otherwise, it will cause compiler errors when using MakefileQVM (most likely, syntax error will be displayed).

  • .map file is a linker map file, which is generated by the linker when it links together multiple object files into an executable or shared library. It contains information about the symbols (such as functions and variables) defined in each object file, as well as their addresses in the final executable or library. The information in the map file can be useful for debugging and performance analysis. For example, it can help you identify which functions are taking the most time to execute, or which functions are being called from which parts of the code.

  • The external JTS (Jump Target Segment) (.jts) files are used to improve the bytecode generation in the Quake 3 engine. The JTS file contains information about jump targets that are used by the VM (Virtual Machine) to execute the bytecode. It helps to avoid bugs, improve performance and it can be beneficial for better stability. JTS files are obtained compiling from q3asm, which can generate 1.32c-compatible QVMs along with the external JTS file.

  • Windows:

    • Building QVM (using .bat):

    1. Keep in mind you must be in the repository directory. Execute build.bat to compile qvms.

    2. Once compiled successfully, look for pak9.pk3, copy and paste into baseq3/ or mod Q3 game directory.

    Alternatively, in build.bat, you can set NO_MAP=0 to obtain .map files, you can see them in binaries and intermediate directories.

    You can set NO_JTS=1, if you don't want to obtain .jts files inside pk3 file.

    • Building QVM (mingw):

    Note: that also uses 7z tool to compress them in a pk3 file.

    1. If you're using MSYS2 and you didn't install the prerequisites, follow the steps (from step 1 to step 4) on MSYS2 (mingw) section.

    If you're using Cygwin and you didn't install the prerequisites, follow the steps (from step 1 to step 2) on Cygwin (mingw) section.

    1. Keep in mind you must be in the repository directory. To compile qvms, execute:
    make -f MakefileQVM
    1. Once compiled successfully, look for pak9.pk3, copy and paste into baseq3/ or mod Q3 game directory. You can look vm/ where you can see the objects and compiled files.

    Alternatively, you can execute:

    make -f MakefileQVM NO_JTS=1

    If you don't want to obtain .jts files inside pk3 file.

    Clean the compiled objects with:

    make -f MakefileQVM clean
    • MSYS2 (mingw) (Building dynamic libraries (.dll)):

    IMPORTANT NOTE: Not tested on Windows 32-bit. MSYS2 comes with multilib disabled in gcc (means you can't compile for x86 in a 64-bit system), more info here.

    To build, follow these instructions:

    1. Install msys2 from https://msys2.github.io/, following the instructions there.It doesn’t matter which version you download, just get one appropriate for your OS.

    2. Start "MSYS2 MinGW 64-bit" from the Start Menu. If you're using 32-bit system, use "MSYS2 MinGW 32-bit".

    3. Install mingw-w64-x86_64-gcc:

    pacman -S mingw-w64-x86_64-gcc

    32-bit:

    pacman -S mingw-w64-i686-gcc
    1. Install make:
    pacman -S make
    1. Go to the directory where you cloned the repository and compile with make
    make ARCH=x86_64

    32-bit:

    make ARCH=x86 WINDRES="windres -F pe-i386"
    1. Find the dlls in build/release-mingw64-x86_64, for 32-bit: build/release-mingw32-x86.

    If you can't compile 32-bit builds with MSYS2 MinGW, try Cygwin section.

    • Cygwin (mingw) (Building dynamic libraries (.dll)):

    Detailed guide based on a post by MAN-AT-ARMS.

    1. Install Cygwin

    Download the Cygwin setup package from http://cygwin.com/install.html.

    Choose either the 32-bit or 64-bit environment. 32-bit will work fine on both 32 and 64 bit versions of Windows. The setup program is also your Cygwin environment updater. If you have an existing Cygwin environment, the setup program will, by default, update your existing packages.

    Choose where you want to install Cygwin. The entire environment is self-contained in it's own folder, but you can also interact with files from outside the environment if you want to as well. The default install path is C:\Cygwin. Choose a mirror to download packages from, such as the kernel.org mirrors. Choose a "storage area" for your package downloads.

    1. Package selection

    The next screen you see will be the package selections screen. In the upper left is a search box. This is where you will want to search for the necessary packages.

    These are the package names you'll want to search for:

    1- mingw64-i686-gcc-core (For building 32bit binaries)
    2- mingw64-i686-gcc-g++ (Also for 32bit... C++ support... not required for the game, but useful for compiling other software)
    3- mingw64-x86_64-gcc-core (For building 64bit binaries)
    4- mingw64-x86_64-gcc-g++ (For 64bit, same as above)
    5- make
    6- bison
    7- git

    1. Open Cygwin, go to the directory where you cloned the repository and compile with make
    • MSVC (.dll):

    Requires MSVC (Microsoft Visual C++) 2005 or newer (Visual Studio Community) to be installed.

    1. Run bfpq3.sln

    Open the solution in win32-msvc directory. If you're using a newer version of MSVC and it's appearing a dialog box that tries to migrate the solution and their stuff, continue by clicking Ok. After the browser will open about the solution migration details, you can close it and ignore the warnings that comments about the old MSVC stuff from 2005.

    1. Build the solution

    In the Solution Configurations tab, you can switch Debug or Release and Win32 or x64.
    Right-click to the solution in the Solution Explorer and click Build Solution, check the log until the build is succeded. Go to Win32 or x64 folder in win32-msvc, look inside Debug or Release and get the dlls you built.

    1. Debugging

    You need the dlls built with Debug and running in-game.
    In the MSVC tab, Debug > Attach to Process or press Ctrl+Alt+P and use the Attach to Process dialog to attach the debugger to the process (in that case select Quake3.exe / ioQuake3.exe / Quake3e.exe or any Quake 3 executable launcher). After, while that's running, add some breakpoint in some line of the code where you want to debug and test.

    Some old MSVC tutorial can be found in Focus on Mod Programming for Quake III Arena in APPENDIX A - Debugging Your Mod in Visual Studio section.

  • Linux:

    • Building QVM (make):

    Note: that uses 7z tool to compress them in a pk3 file. If you don't have 7z tool, install with:

    sudo apt-get install p7zip-full
    1. If you didn't install the prerequisites, follow the step 1 on Building shared libraries (.so).

    2. Keep in mind you must be in the repository directory. To compile qvms, execute:

    make -f MakefileQVM
    1. Once compiled successfully, look for pak9.pk3, copy and paste into baseq3/ or mod Q3 game directory. You can look vm/ where you can see the objects and compiled files.

    Alternatively, you can execute:

    make -f MakefileQVM NO_JTS=1

    If you don't want to obtain .jts files inside pk3 file.

    Clean the compiled objects with:

    make -f MakefileQVM clean

    Optionally, you can set the destination directory, so the pk3 file will appear on this directory:

    make -f MakefileQVM DESTDIR=/your/path/q3/baseq3mod
    • Building QVM (using .bat):

    1. The alternative to execute and get the compiled qvms with build.bat requires wine package. So, in that part, needs the i386 package:
    sudo dpkg --add-architecture i386 && sudo apt-get update && sudo apt-get install wine32-development

    But it could be executed without using 32-bit package, if your system supports 64-bits. Go to WineHQ page anyways.

    1. Keep in mind, you must be in the repository directory to execute the script:
    wine cmd /c build.bat
    1. Once compiled successfully, look for pak9.pk3, copy and paste into baseq3/ or mod Q3 game directory.
    • Building shared libraries (.so):

    1. If you don't have gcc tools, install the build-essential packages, which is also known as a meta-package, it contains the GCC compiler all the other essentials used to compile the software written in C and C++ language. Also, requires libc6-dev-i386 for x86 builds and g++-multilib and gcc-mingw-w64 for cross-compiling. More info about MinGW question in Linux here.
    sudo apt-get install build-essential libc6-dev-i386 g++-multilib gcc-mingw-w64
    1. Simply execute (-j4 is the number of parallel jobs you want to run during the compilation, in that case is set to 4):
    make -j4
    1. And find .so files in build/release-linux-x86_64, for 32-bit: build/release-linux-x86.

  • Optional:

    You can use the optional part, if you followed and used some of these sections:

    You can execute optionally the parameters using the following ways:

    • To compile debug x86 .so builds:
    make debug ARCH=x86 PLATFORM=linux # compiles debug x86 .so builds (creates "debug-linux-x86" directory inside "build")
    • To compile release x86 .dll builds:
    make ARCH=x86 PLATFORM=windows # compiles release x86 .dll builds (creates "release-windows-x86" directory inside "build")

    ... Optionally, you can play the parameters like ARCH=x86_64 (compiles 64-bits builds), PLATFORM=windows (compiles dlls), PLATFORM=linux (compiles shared libraries (.so files)) ...

    • To compile and copy release builds at the destination directory, DESTDIR parameter is mandatory:
    make install DESTDIR=/your/path/q3/baseq3mod # compiles release builds and copy the builds to the destination directory (you can also put ARCH=x86 PLATFORM=windows if you want)
    • To compile and copy debug builds at the destination directory, DESTDIR parameter is mandatory:
    make install DESTDIR=/your/path/q3/baseq3mod # compiles debug builds and copy the builds to the destination directory (you can also put ARCH=x86 PLATFORM=windows if you want)

Notes

IMPORTANT NOTE: This repository was initialized from https://github.com/marconett/q3a.

Added source code files:

  • ai_bfp.c
  • ai_bfp.h
  • bg_events.h
  • bg_meansofdeath.h
  • cg_cvar.h
  • cg_trails.c
  • g_cvar.h
  • ui_bfpoptions.c
  • ui_cvar.h
  • ui_mem.c
  • ui_mp3decoder.c
  • ui_mp3decoder.h

Removed source code files from the build tools:

  • ui_cinematics.c
  • ui_mods.c
  • ui_playersettings.c
  • ui_splevel.c
  • ui_sppostgame.c
  • ui_spskill.c

Unused source code files and unavailable in the build tools:

  • g_rankings.c
  • g_rankings.h
  • ui_login.c
  • ui_rankings.c
  • ui_rankstatus.c
  • ui_signup.c
  • ui_specifyleague.c
  • ui_spreset.c

Legal

The mod source code is GPLv2 licensed, the contents are based on Quake III Arena.

The ancient abandoned MP3 decoder (ui_mem.c, ui_mem.h, ui_mp3decoder.c and ui_mp3decoder.h) uses Open Source Modification License (OSML) v1.0 and is based on code from various contributors:

  • Copyright (C) 1993 Sun Microsystems
  • Copyright (C) 1995-1997 Michael Hipp
  • Copyright (C) 1999 Aaron Holtzman
  • Copyright (C) 2000-2001 Tim Angus

The images, screenshots, and URLs, even in the docs, included in this repository are used for reference purposes only and are not covered by the GPL license. They're sourced from various locations and are subject to their respective copyrights and terms of use.

Warning

Any derivative works must follow the same rules and disclose their code to the public as to encourage fan projects based on Bid For Power.

Bid For Power name

Nobody owns the "Bid For Power" name. Bid For Power was founded by Chris James and likely ended up in the palm of Yrgol's hand (although Yrgol doesn't own the assets). The owner, the maintainer and the contributors of the repository don't own this name.
This does not give any single person or a group of people to sell the name, basically it belongs to the original community.
The Bid For Power team may provide sufficient security against any claims or improper use of the name.

Disclaimer

The game elements such as characters, and events depicted in this game are fictitious. Any resemblance to actual persons, living or deceased, or real events is purely coincidental.

Credits

Bid For Power is made by these staff members. We don't own materials such as art designs, maps and character models from their assets.

Bid For Power Staff Members

Ansel
Skin Artist

Anthony
2D Artist

Chris
Founder

Dash
Level Designer / Texture Artist

Disco Stu
Web Designer

Gangsta Poodle
Level Designer

Kit Carson
Level Designer / Texture Artist

NilreMK
Modeler / Animator

Number17
Sound Engineer

Pyrofragger
Modeler / Animator

Remisser
Sound / Music Engineer

Rodney
Modeler / Animator

Yngwie
Level Designer / Texture Artist

Yrgol
Project Lead, Lead Programmer

::Additional Assistance::
Mooky, Perfect Chaos, Dakota, Bardock, DethAyngel, Ebola, Badhead, $onik, Gigatron, Timex & Nat.

About

WIP, not completed. Bid For Power source code replica. A legendary 90s era Quake 3 Arena mod.

Resources

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

Languages