copyright |
This code, and the accompaning documentation, is copyright © 1997 Mike Warren. You may not redistribute this code, in any form, without the written permission of the author (even if it has been modified, repackaged or is being released along with other, original, code) You are also not allowed to release any project based on this code without first notifing me (Mike Warren).Also note that you need my (Mike Warren) written consent to use this code in any comercial project.
disclaimer |
This code is provided "as is", without any guaruntees as to results. Any harm that results from this code can in no way be blamed on the author, Mike Warren.
introduction |
This source code is intended to provide an easy and quick start into AI development for a client-side quake-bot.By handling all client-server communication, tracking all entities, providing support for mikeBot Language, making entity-type determination easy, seperating fire and navigation facings and providing a skeleton AI class-system, this C++ code makes entry into the bot-development process relativly pain-free.
There are a few things to note, however: this code is copyright © 1997 Mike Warren and cannot be used for comercial purposes without his written consent. You must also notify Mike before publically releasing any program written using all or part of this code.
The documentation you are reading is intended to be up-to-date and accurate; if you find any errors or have any questions, you can contact Mike at:
mbwarren@acs.ucalgary.ca
mike@planetquake.com
getting started |
Most of your code should be added to mbfire and mbnav. Fire and Nav can be implemented completely seperatly, with facing disparities handled by the movement-sending functions of mbot.By changing qcs::mbf_facing and qcs::mbn_facing, your bot's fire-facing and navigation-facing are changed, respectivly. qcs::mbn_velocity specifies target speed in the directeion qcs:mbn_facing. Use the functions mbfire::fire() and mbnav::jump() to perform those actions. Note that mbfire::update() and mbnav::upate() are called on each timestamp (default 0.100 of a second) and that mbfire is updated before mbnav.
Also, the array qentity qcs::entities[ 450 ] will be very useful; it tracks all the entities in the level (see the description of qentity in the other section) You can also use functions like mbotbase::isHealth(), mbotbase::isProjectile(), etc. to determine which type of entity each one is (i.e. to determine if entitiy 45 is visible and a projectile, try this:)
void mbfire::update() { . . . if( isVisible( 45 ) && isProjectile( 45 ) ) doStuffQuickBecauseEntity45IsAVisibleProjectile(); . . . }The descriptions of the respective classes are available in their own sections.
the client-server protocol |
There are a few important points about Quake's client-server protocol.
- More players
- It allows many more people to play over the same bandwidth than with a peer-to-peer protocol like Doom had because, as more people connect, only the server and client communicate. In a peer-to-peer system, each "client" (player) must send its updates to every other player.)
- Crappy modem play (as implemented)
- The way Quake currently implements modem play, one player has both a server and client on their computer (unavoidable). However, the quake engine doesn't account for the fact that the other player has lag, so one player has no lag while the other has (potentially) considerable lag. (This could be fixed by inducing comprobable lag into the player with the client on his computer)
- Client-side bots
- mikeBot would have far more difficult to implement using a peer-to-peer protocol like Doom's, for a number of reasons. The following points about Quake's protocol make client-side bots easier (and less cheat-prone than Server-side ones):
- Only visible entities have updates sent.
- The server tracks game state. In Doom, each client had to determine what the other players were doing based on keypresses; most of a Doom engine would have to have been created to make a Doom-bot.
- Facing and movement can be seperated by fiddling with the strafe velocities in the client-to-server updates.