QuakeBot C/S Development News

To Do


[10/01] I put out an alpha version that should address some of the issues that UNIX has plus contains a partial fix for the NT console. Try it at your own risk. It will probably change a few times so I am not releasing it with a version number.

[8/27] Yes, I am still here. If I didn't answer your email, don't take it personally. I bought a house and moved and also spent some time in the Cayman Islands diving. I have been out of touch for a while.

A number of you have mailed in with fixes since I have been slack. This latest release should incorporate everything that I received over the last three months. If I left something out, mail me again. I also had a minor crash that nuked my mailbox, so some stuff might have been lost in the shuffle. Thanks to Simon Cross, Steven Duckworth and others for their contributions.

As for the future, nothing ambitious. I have more than I can handle outside of this project currently. I will continue to track down bugs as reported and post the relevant changes. If anyone is nice enough to make additions, I will be thrilled to include them. This is not to say that the project is stalled, I just cannot realistically place the same amount of time that I have previously into it for now. Hopefully in the coming months things will lighten up so that I can participate more.

Also, in the name of public service, Raven software has several job openings. You can read the text here....

[4/10] Taxes suck. I still have not tracked down the bug that is ignoring packets since I can't duplicate it on my system. I have a few other ideas on how to make it show itself, so all hope is not lost. However, I did find a bug that was preventing proper level change. It seems I had a changed slated that I forgot about. You might have noticed the CHANGE THIS message. That was it. Thanks to all those who mailed me about this. New release slated for after tax time, assuming I am not in prison. =)

[3/13] @#&$&%&. There is another bug, far larger, lurking in my code causing packets to be ignored. It probably won't affect you on Ethernet, but about anywhere else, it seems to crop up. It appears to be a timing problem due to my new event driven communications core. This is going to take some time and major recoding of the event handler so bear with me. Figure about a week or two.

I just added a link from my main page to the CIEC, Citizen's Internet Empowerment Coalition. These are the guys fighting the Communication (In)Decency Act. Only 6 days until the supreme court hears the case. Give 'em your support. To do my part at a good netizen, I added RSAC ratings to my pages. Internet Exploder is the only browser that supports this currently, and it puked. Ahhh, technology. If you use MSIE, give it a try and see if it works. Mail me with your results. This page it rated for language = 2, the rest are 0.

[3/9] Big honking fat juicy bug. I left some of my memory debug code in the DEM decode functions and the bot was running at a snails pace. It was dropping packets, delaying acknowledgments and generally very pissed. I didn't notice it because I am on Ethernet. Big thanks to those who mailed me about the problem. If this doesn't cure it, let me know.

I also cleaned up the proxy operation as it now understands server shutdown and instructs the proxy to die nicely. Minor changes in the AI to support John's work. No major IQ enhancement. Soon, tho.

For you UNIX types, I took the time to test compile under Solaris using g++. I made major changes changes in the conditionals. I had success minus one function I haven't nailed down, yet. You should have a much easier time. There is a makefile included that I used. It needs some dependency work but should compile fairly well. Please mail me with your successes/failures.

[2/28] I am calmer now. I would like to explain a few things to those that might be interested.

I am an avid Quake player and I would not do anything to hurt the game that I love. It is out of this admiration that I created QuakeBot C/S, my contribution to the net. Once this project reaches fruition, I feel that it is something that will be welcomed by a great majority of the Quake community. My response up to this point has been overwhelmingly positive. But recently I have received a lot of flack from people stating that my bot allows people to cheat and is ruining Quake. It is these issues I would like to address.

First, my bot does not support an enhanced proxy, it is totally autonomous. I specifically omitted features that would allow a player to take advantage of the bot's enhanced abilities. If you play against the bot, you play the against the bot, not a player who is cheating. I do not make any statements concerning the morality of cheating at Quake or software that allows this. It is just a choice that I have made.

I do not take this project lightly. Soon after the project had taken form, it became apparent to me that I was dealing with something that had potential for causeing a lot of problems. Additionally, I had been corresponding with another developer who expressed the same sentiment. He was taking steps to allow servers to ban his bot through the use of a banner message. In the interests of fair play, decorum and compatibility, I adopted his standard and allowed the capability for individual players to kick the bot. My bot has, from that day, had this fail-safe device built-in as have all the client bots that I have been exposed to.

Unfortunately, this caused some people with an iron will to defeat this feature. Once this was brought to my attention, I added additional features. These functions would prevent my bot from even logging on certain servers, thus (hopefully) preventing the type of situation that was causing so many problems. With this, I have taken reasonable and prudent steps to ensure that my creation will not cause more havoc than originally intended. If another situation occurs that I have not foreseen, then I will take the necessary steps to correct it. I have vested interest making sure that my bot doesn't run rampant on a server.

Due to the fact that I release source code, the question of security arises. My response is that the concept of security is a false one. Accept that everything is basically insecure. After 17 years in the industry, I know this to be true. For this reason, I believe my release of source code is a prudent one. The average programmer can defeat all of my features. But the slightly more advanced could defeat them in a more "secure" executable form.

My choice? Let as many people have access to the code as possible. The number of programmers that would gain from the code release would far outweigh the number of people that would use it for other purposes. Individuals with no programming experience will be thwarted by the features inherent in the executable, while others would not be stopped anyway. And the choice not to create the bot in the first place is ridiculous. Someone else would, and they may not have shown the forethought that I have.

At this point in my bot's development, I do not feel that it is a match for any but the lamest of players. This is as it should be. My intentions are to create the ultimate deathmatch opponent, not an insane killing machine. As time goes along, the bot will evolve and become a more refined player with selectable skill levels. I want a balanced opponent, one that can mimic a player and provide a challenge, not to slaughter everything possible. Cheating is easy, but it takes work to play the game.

[2/21] I HAVE HAD IT! I just received my second flame from someone with obviously more time on their hands than sense in their head. In an attempt to stop this stupidity, I would like to make an open statement to potential buttheads out there.

I accept that some people do not like bots. Some people do not like computers or TV's. This is life. If you feel that you need to be heard on this subject, feel free to mail me concerning your objections in a civil manner. I believe in fair time for all viewpoints. If you have a valid concern and it is something I agree with, then I will consider it. I am a very open person.

BUT, I will not be involved in another f*cking personal flame war just to further someone's therapy. There is a saying concerning aggravating snakes; The first person wakes it up, the second pisses it off, the third gets bit. Well, I am pissed off and ready to bite.

The next flame that I receive, I will post for the net community to see, complete with my response. You may have thought is was brilliant at the time, but things change when they're are brought under close scrutiny.

Jim Rorie

I apologize to those who have read this and are well meaning. This is something that really gets under my skin.

[2/21] V0.80 is out. Server proxy, teamplay, expanded command line options. Basically, the works. Notice that the command line works differently, similarly to Quake. Connect, name and color are supported from the command line in the Quake format. There is also a -noproxy option to disable the proxy.

The code is completely restructured. A slew of major bugs in the server were discovered and corrected. You really don't know what is going on until you try to pipe it to a display. This server object should be pretty tight.

There is some minor strangeness in nav object that translates to some jerkiness in on the proxy display. Werkin on it.

This should catch me up for the most part. I intend to take some time and work on the IBC language and other higher level aspects. I want to think things through a little more fully instead of rushing in like I have previously. I will also be fixing bugs as they arrive.

John is still working on the AI and .BSP stuff. This version does not include any of his code, yet. All suggestions for the AI should be addressed to him.

[1/31] V0.79 is out. It is an interim release. The bot is now event driven. I have a central event object that the AI, Server, Console, etc. register with and receive calls based on certain events. They also can communicate via messages. The key reason for the change was to support messaging. I realized recently that for my grand scheme to work, every object in the design would need to be able to talk to every other object. This was butt ugly using the previous code.

Things work very slick now, although they are a bit different. I documented the event object to explain its operation. The event registration process is a snap. Most of the previous functions stayed the same, I just linked to them using the new callbacks. Some of the top level server functions in main() did change, but they are replaced by two more robust functions that do the same thing, only better. The console has a new parser, complete with a help function. It is also is restructured to initiate connects similar to the Quake console.

The AI is different. It is in an object and its main loop is now an event handler that can be disabled via a message. This is quite different from the old method that allowed you to stay in the runtime thread continuously, but is necessary for proper event operation. Plus, that damn thread is gone. For those that think that this is a bad thing, let me point out that you can use a thread anyway and just have the AI event to pass you messages. No big deal, except for......


With this code, you should get an idea of what I am doing. It should also, give you a chance to transition to the new code structure as there are more drastic changes to come. First, the game data in the server will be moved external to an object container so that all the objects can access it more easily. Besides, this data needs a little better reorganization. I hope to have a set of functions that will allow a little easier access. Some of the calls in the AI were ridiculous, not to mention that the server object is getting too bloated.

I decided that the next addition is a Server Proxy. To really be able to debug the navigation, you need to see what is going on. It needs to be done and dammit, I am doing it. I know that this will be a welcome addition. This release has enough of the proxy function to reject a request, although some of the responses are total BS.

[1/27] A little warning to those of you using my core. I am doing a fairly large change to the structure of the communications layer. I am implementing a type of cooperative multi-tasking through the use of an event object. This will allow me to remove the runtime threads and call the AI, communication and other objects on a regular basis. It will clean things up as well as let me do other functions, like the IBC server, which are not currently possible in the current code. Also, extensions to the core could be more easily provided by the user through inheritance, making your lives easier.

These changes should result in the code being more generic, thus giving better support of UNIX. The current code contains threads, which translate to lightweight processes on some UNIX flavors, but not all. Some people attempted to port it, but as time went along, the code became more system specific. I hope to remedy this with these changes.

I hope to change the top level functions very little. Unfortunately, I have sort of programmed myself into a box, making some changes necessary. The result should be a cleaner, more unified interface to the comm layer. If you are worried as to how this might affect you, just hang out and lemme flesh it out a little further. After it begins to come together, I will be able to make some specs.

John is working on the navigation and AI, so that area should progress shortly.

[1/24] NEW RELEASE!! Fixed entity bugs. Cleaned some stuff up. The 'No Bots' message is history. Too many people were running the .exe without taking that part out, so I changed it. Read the .txt file for details.

Don't expect a lot. You are seeing a nasty navigation object in this version. I felt like the number of other changes that had been made merited a release. It will be a while before navigation works worth a damn, but it does move around a bit.

BTW, if anyone knows a lot about lighting in Truspace 2, drop me a line. My QuakeBot C/S logo is looking a little irregular. :)

[1/21] I have installed a new LAN to try to model the QuakeWorld crap. Jeez, NT server is a slut. There are a backlog of bug fixes that I need to make. I am working on them!

I got the most interesting mail the other day. Check it out and see if you got's what they need.

We are Raven Software, the creators of such products as Shadowcaster, Cyclones, Necrodome, Heretic and Hexen. We are currently working with a variety of publishers to bring top quality games to MS-DOS, Windows 95, and Sony Playstation platforms.

We seek a special breed of programmer to work on high profile computer games. This individual is enthusiastic, creative, and is proficient in C programming. He or she enjoys using their code to push the hardware (PC preferred) to the limit, and treats programming as an art form, solving problems with algorithms of elegance and originality.

This person must be willing to be part of a team, and be prepared to contribute to overall game concepts and design decisions.

Applications Programmer with QuakeC experience

--Reports directly to the Lead Programmer of the Hexen 2, as well as to the Applications Programming Manager.



--Perform coding tasks as detailed by a schedule and series of milestones, initially in QuakeC (the external script code created for id Software's game Quake), and afterwards in C, on Raven Software's Hexen 2 project.

--Assist in the determination of the schedules and milestones that define a project.

--Assist in the code design of the various modules required for a project.

--This position may be available as an internship or contract, lasting through the duration of the Hexen 2 project, which would be early summer.


Qualifications (fulfill as many as possible):

--More than two years experience programming in C or C++.

--Experience in coding in QuakeC and working with id Software's Quake to add entirely new elements to the game.

--Involvement in one or more large projects, working with others and preferably involving the sharing of code.

--Ability to work under direction of a Lead Programmer, yet able to take the initiative and find solutions without assistance.

--Ability to learn on the go.

--Innovative, creative coder able to push the Quake game system to the limit.

Raven is a stable, well-established, and well-respected game developer with more than six years in the industry. We work in a fun, relaxed environment, offer full health benefits and a retirement package, and we'll kick your butt in Doom, Quake or foosball, your choice! :-)

These positions are full-time, and would involve living and working in Madison, Wisconsin. Applicant's current location is not a major concern. If possible, please provide a demo of your work and sample code.

If you think you're ready for Raven Software, contact:

Michael Crowns
Director of Project Development
Three Point Place, Suite One
Madison, WI 53719
Phone: (608) 833-5791 ext. 231
Fax: (608) 833-7178

Older QuakeBot C/S News

Return to The QuakeBot Page