Bid For Power (BFP) Recreation Project source code

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

Table of contents

1. History
2. About the repository
3. How to build

3.1. Introduction
3.2. Windows

3.2.1. Building QVM (using .bat)
3.2.2. Building QVM (mingw)
3.2.3. MSYS2 (mingw) (Building dynamic libraries (.dll))
3.2.4. Cygwin (mingw) (Building dynamic libraries (.dll))
3.2.5. MSVC (.dll))

3.3. Linux

3.3.1. Building QVM (make)
3.3.2. Building QVM (using .bat)
3.3.3. Building shared libraries (.so)

3.4. Optional

4. Notes
5. Legal
6. Credits

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.

About the repository

This is the complete recreation of the mod's original logic structure, now available as a structured and standardized game SDK that allows for easier modification and extension of the mod.

It contains the recreated and improved version of the code, incorporating known bug fixes, performance optimizations and new features. The goal was to preserve the essence of the original Bid For Power while addressing its technical limitations and adding improvements based on analysis of expected behavior.

As for documents, you can see all that in this repository: https://github.com/LegendaryGuard/BFP-docs

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)
• there's code about real impact crack mark, when projectiles/ki attacks impact something solid on ground, walls or slopes
• projectile with missile attack type using beam trail applies where the beam muzzle was started
• particle aura is implemented, "powerups/particleaura" shader can be used
• sprite aura looks implemented, "powerups/spriteeaura" shader can be used
• 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_oldRocketTrail 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 has a fitting muzzle flash
  • 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
• CREDITS menu can play music (on original BFP, no), by default, plays music/fla22k_02 file, feel free to change the music name or the file itself without changing the filename

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...
• ...

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 bfpr.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.

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

  make -f MakefileQVM

  3. Once compiled successfully, look for bfpr.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

  4. Install make:

  pacman -S make

  5. 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"

  6. 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.

  2. 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

  3. 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.

  2. 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.

  3. 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

  3. Once compiled successfully, look for bfpr.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.

  2. Keep in mind, you must be in the repository directory to execute the script:

  wine cmd /c build.bat

  3. Once compiled successfully, look for bfpr.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

  2. 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

  3. 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:

  • MSYS2 (mingw) (Building dynamic libraries (.dll))
  • Cygwin (mingw) (Building dynamic libraries (.dll))
  • Building shared libraries (.so)

  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
• bg_weaponconfig.c
• cg_aura.c
• cg_cvar.h
• cg_skinconfig.c
• cg_trails.c
• g_cvar.h
• ui_bfpoptions.c
• ui_cvar.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.

Warning

Any derivative works must be licensed under the same terms, guaranteeing its recipients access to the corresponding source code. If you distribute this mod or modified versions of it, you are required to provide the complete source code to those who receive it, under the same terms of this license.

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 Recreation Project

LegendGuard
Maintainer

Special Thanks
Quake3World
ZEQ2

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.