Before you write to me with suggestions for the next version of Bolo, please read these frequently asked questions files, and read the "Bolo.futureplans" file to see if your suggestion is already on the list.
This file deals with frequently asked questions about playing a game of Bolo and other general questions.
"Why are there so many FAQs for Bolo?"
I guess there are a lot of people using Bolo a lot of different ways.
"Bolo.GeneralFAQ" contains general questions about playing games of Bolo.
"Bolo.NetworkingFAQ" contains networking questions.
"Bolo.Maps&BrainsFAQ" contains some hints and advice for people creating maps and for people writing Brains.
"rec.games.bolo FAQ" (Parts 1 and 2) contains questions compiled from the Internet News Group. I did not write it, but I include it here because it has some useful information, and provides an alternative perspective on the game.
"If I pay the shareware fee, what do I get?"
You get exactly what you get when you buy a game in a shop, namely, the game. Just like in shops, you can take the game without paying for it if you want, but the people who run shops are reputed to react rather badly if they see you doing this :-)
"Why doesn't Bolo have a pause mode, like for when I have to answer the telephone?" There are other human beings out there on the net playing at the same time. What happens to them? I know they make time stand still all the time on Star Trek, but I haven't figured out how to do it yet. If you have to leave your computer, put it onto autopilot. Select some defensive settings, and it will stay where it is and try to take care of itself until you return.
"Bolo is almost unplayable on my slow Mac Plus."
The Macintosh Sound Manager does a lot of work to make those sound effects on older Macs which lack fancy sound hardware. On A Classic 8MHz 68000 Mac, half the CPU time can be spent doing sound, so you can double the performance of Bolo by turning sound off. Alternatively, upgrade to Sound Manager 3.0 (included in System 7.5) which is a lot more efficient.
"Why does Bolo make strange squawking sounds occasionally?"
Bolo is a heavily network oriented program. In a ten player game 90% of what Bolo is doing is determined by the packets sent by the other 9 players, and only 10% by what keys you are pressing on the keyboard. Network protocols differ from normal algorithmic programs, in the sense that instead of the program telling the computer what to do and when to do it, it is the other way around. The computer tells the program what to do and when to do it, in the form of an "interrupt" every time a network packet arrives. This is how Bolo works. There are only two components of the Macintosh System software that don't work when called from interrupt routines, the Memory Manager, which is sort of understandable, and the Sound Manager, which isn't. I have talked to Jim Reekes about this in person several times and he is adamant that he sees no reason for the Sound Manager to work from interrupts at all, and he most definitely has no plans to ever support it. Jim Reekes has done a pretty excellent job on Sound Manager 3.0 in all other respects, so Apple is not likely to replace him. It seems that Bolo is stuck with the strange squawking sounds, at least until there's a major change in the System Software.
"Why doesn't Bolo accept that if we put sound on 0, we want no sound?"
It's nothing to do with me. Bolo just makes Apple Sound Manager calls. Why doesn't the Apple Sound Manager accept that if we put sound on 0, we want 0 sound? I don't know. That's why Bolo has a menu option to turn sound off, which is probably better -- just because you want no sound from Bolo doesn't *necessarily* mean that you don't want any other sound from your computer, so I offer the added flexibility of an application-specific switch for Bolo.
"I turn on 'Background Sound' but there is no music."
Background sound does not mean music, it means Bolo continues to make sounds when you put it in the background to work with some other application. RTBH! (Read the Balloon Help.)
"How do I play Bolo on my own against computer controlled enemies?"
Bolo is not designed to work this way, but you can make it work. You need to run several copies of Bolo, and have them controlled by "Brains" for you to play against. They can run on different Macs, or all on the same Mac, if it is fast enough (ie not a Mac Plus or SE). In either case, you need to have AppleTalk enabled (in the Chooser) for the different copies of Bolo to communicate with each other, even if they are colocated on the same Mac. Make a folder called "Opponents" and put a copy of Bolo and the "Brains" folder into it. Since Brains don't need to have digitised sound effects, you don't need to copy the "Bolo Sounds" file, and you can reduce Bolo's memory allocation to 800K in its "Get Info" box. Now, duplicate the Bolo application file a few times, and call them "Bolo 1", "Bolo 2", "Bolo 3", etc. Run each copy of the program in turn, joining them into the same AppleTalk game, and switching them all to Brain control. Now go back to your original copy of Bolo and join into the game.
"Why doesn't the auto-slowdown option with with cyborg Brains?"
Cyborg Brains do their own keyboard processing, and ignore all the settings in Bolo's key setup dialog. I'm planning to add facilities to Bolo to allow cyborgs to be better integrated, but for now that's just the way it is.
"What is the Frame Rate menu for?"
If you are running some other program(s) in the background while you play Bolo, setting Bolo to a lower frame rate will allow the background program(s) more CPU time. One example might be when you are running other copies of Bolo in the background, as described above. If you set your frame rate to 60 frames per second then the Brains won't get enough time to think, and they will not be very challenging opponents.
"What's the point of the joystick option?"
For playing Bolo with the standard overhead view it's not very helpful, but imagine if there were a 3D 'Doom-style' version of Bolo... :-)
"Why is there so little penalty for dying, and why do you have unlimited lives?"
I don't want Bolo to be boring for beginners. Remember when you played "Monopoly"? The first player to get knocked out of the game spends an awfully long time sitting around, bored, waiting for the other players to finish the game. I don't want Bolo to be like that. Everyone should be able to have fun playing, good or bad. Whether or not you win is another question...
"So why should I care about getting killed?"
You may be able to do a suicide attack on a pillbox and then pick it up with your next tank when you are playing on your own, but in a crowded game the pillbox will be gone by the time you get back to it.
"Alliances don't work."
They do. RTFM. Here is how:
"Why don't pillboxes shoot each other?"
Can you imagine how dull that would be? Two hostile pillboxes would simply fire at each other at maximum rate and wipe each other out in under a second. All the skill, strategy and tactics would disappear from the game, and the sole decider of who won any confrontation would be whoever had the most pillboxes.
"Why don't pillboxes shoot at enemy men?"
Pillboxes don't shoot men because they shoot far too well. If they shot at your man, he would be dead, every time.
"So how am I supposed to stop enemy men putting down hostile pillboxes in the middle of my base?"
Little Green Men aren't very bright. They tend to run in straight lines. Design the entrance to your fortress so that a man can't find his way inside.
"Why can't I steer the man with the keyboard, to guide him around obstacles?"
Because you would then be able to send the man into places which he couldn't reach before. That would invalidate the defense described above, which would mean that there would have to be some other way to prevent hostile men from getting inside a fortress. End result: I do loads of work, the Bolo program gets bigger, you have to learn lots of new keys to operate the new features in the game, and your man still cannot get inside a well defended fortress. What is the benefit?
"Why did the hostile pillbox I just repaired attack me?"
Because it is hostile. Capture it by picking it up with your tank before you repair it. The only time you might want to repair a hostile pillbox is if it fighting one of your enemies, and you want to give it some help, but that won't make it loyal to you.
"When ever I die and get a new tank, I get a 'random' amount of ammo. Why?"
It is not random. The ammo you get is determined by the game type selected by the person who started the game.
"Why does my tank, when it blows up, sometimes make a huge explosion and sometimes just a tiny one?"
Come on, guess! What do you think influences the size of the explosion? The amount of explosive material you are carrying perhaps?
"I found a bug. The screen faded out even though I hadn't been killed."
If you are viewing from a pillbox when it is destroyed, then you lose the picture like when your tank is destroyed. Switch to another pillbox, or return to tank view.
"When I shoot and kill an enemy refuelling base, it doesn't change colour."
That is correct. You can wipe out its defenses by shooting it (and its status indicator on the right of the screen changes to a cross to indicate that it is dead) but it won't change ownership until you drive over it.
"OK. I drove over the base to capture it, but the status indicator still says it's dead."
That is correct. The refuelling base status will not change from "dead" to "operative" until the base has regained enough strength to defend itself.
"Who gets to see mines I lay?"
"I hate mines. After a hard fight to capture a pillbox, I lose it seconds later by hitting one of the mines that people scatter randomly across the map."
If you are low on armour, and carrying something valuable, BE CAREFUL. Your tank can detect invisible mines up to one map square in front of it, so watch carefully, and drive slowly enough that when you see a mine you can stop before you hit it.
"Why don't you generate a new random map for each new game?"
There are several hundred maps available from various Bolo enthusiasts, so you have a wide choice. Peter Lewis has also written a pretty good random map generator which outputs a different random Bolo map file each time you run it, but I still prefer the maps made with human creativity to random ones. If you think you can write a better algorithm to generate plausible looking interesting maps, then why not write it? You know what the different terrain types are, you know the map file format, and I've even provided sample C to read and write the files, so the framework is all there for you.
"Why don't you produce a map editor so that I can create my own maps?"
I was going to, but several other people got impatient and wrote their own. Check out anonymous ftp on Sumex-aim.Stanford.EDU (in "info-mac/game/bolo").
"Some of the map editors allow you to set the ownership number of bases, but when Bolo saves a map itself, ownership is ignored and all of the bases revert to neutral."
Setting the ownership number for a base falls in the "cute but useless" category. You can make novelty maps where everyone starts with one base and one pillbox, but when you join the game there is no guarantee that you will get the same player number as before, so it is all a bit pointless. 'BGAM' game files will be the solution to this problem.
"Why can't I plant trees?"
Ecology, my friend. If you totally defoliate an area, then it takes 50 years to replant and cultivate a forest again, by which time you probably won't still be playing Bolo (or at least not on your current Macintosh, anyway). If you want to maintain a forest, don't totally destroy it. Farm just a few squares, or farm narrow strips through the forest, leaving the trees on either side to help the farmed area to grow back.
"Why don't you allow the tank turret to rotate relative to the tank body?"
Many people request this, so that "when driving by a pillbox, you could drive on road and blow it away by shooting to the side." This is precisely the point. To maintain the balance of the game I would then have to make pillboxes more powerful to compensate for your enhanced abilities. The difficulty of shooting a pillbox, or an enemy tank, would be exactly the same, except that you'd have to do more finger ballet on the keyboard to achieve the same results. This would just make the game even harder on novice players (as if it wasn't hard enough already).
"Why can't the tank reverse?"
Same reason as above. It adds more buttons and adds complication to the game without making it any better. As it is now, if you cleverly catch someone carelessly hanging around on a narrow bridge or beside a lake, you can shoot them and knock them into the water, where they will be almost helpless for you to easily finish off. If they had reverse they could quickly reverse out of the water and escape. In this game, if you are stupid, you pay the penalty. There are no second chances, no smart bombs, and no hyperspace. Watch your back.
"Why can't I shoot things on land when I am on a boat?"
Boats are for transport, not for fighting. You can however shoot bridges away, and repeated shelling will disintegrate river banks.
"Why can't I drop floating 'sea mines' in the water?"
Boats are for transport, not for fighting. Travelling by boat makes you immune from minefields, but leaves you vulnerable to being sunk by a single shot. Boats are best used for 'peacetime' transportation. In the heat of battle, they are a liability.
"Why don't you implement line-of-sight-only vision?"
Bolo is a multi-player game. What makes it interesting is the encounters with other players. As it is you can spend far too long searching for the other players in the game, especially when they are hiding in forest, so making it even harder to find other players would not be an improvement.
"Why don't you assign a different colour to every team, instead of just red/green?"
My goal is to have games of a thousand players across the Internet. I'd probably need to have about two hundred different colours, and with alliances changing all the time, I don't see how I can make a thousand computers agree on what colour every player is at every moment in time.
"Why don't you add xyz feature?"
One of the main goals in writing Bolo was to try to give it one of the properties that Chess, Othello, and other good board games have -- the "a moment to learn and a lifetime to master" characteristic that gives them lasting interest. The aim is that there are a few simple 'actions' that you can perform in the game, but that they are flexible enough to let you carry out your complex strategies. That's why there is only one kind of tank, one kind of armour, and one kind of bullet. For me to add another major feature, it must add at least as much interest to the game as any of the features that are already there.
"Why don't you add some feature [that Bolo already has]?"
This is one of the most annoying kinds of question. Here's common one: "I
hate having to click the close box to put away the message window, why
a. Make some key, like say "Escape", dismiss the window?JUST TRY IT BEFORE YOU WASTE MY TIME WITH E-MAIL. THEY *ALL* WORK ALREADY.
b. Use the standard Macintosh convention of Command-W to close the window?
c. Use Command-M to hide the window, since Command-M is what you do to show it?
d. Just let the user click anywhere in the game window to bring it to the front?
"Why doesn't Bolo have a 'panic' button to hide all the windows?"
Duh! (See above) It does. Command-H hides all the windows. Besides, System 7 has its own built-in 'panic' command -- option click in any other application's window (or on the desktop) to instantly switch to that application and hide all the windows of the current one.
"I really like Bolo except for the fact that I need to have friends to play it with. Why don't you make a single player version?"
If you want to try writing your own Artificial Intelligence routines to drive enemy tanks, sample source code is provided. If it turns out to be popular, we could have a new kind of Bolo Turing Test, where you have to play against various opponents and decide whether they are human or not. (Anyone remember the old 'Core War' tournaments? It would be fun to see Bolo become the battle ground for similar programming competitions).
"I am going to write a totally awesome network game for the Mac. Please tell me how to do it." (Yes, I really do get this question quite frequently.)
There is no magic spell; no secret to tell. I use simple point-to-point AppleTalk DDP packets. Bolo does not use broadcast DDP packets like most games, because that doesn't work across multiple networks. Bolo does not use ATP, or ADSP, because these offer extra features and reliability that Bolo doesn't need. So-called "reliable" protocols don't work by having a magic genie, they work by sending extra packets and waiting for acknowledgements. The increased reliability is always a trade-off against extra delay and lower throughput. I can write code to deal with unreliability. I have not yet managed to write a time-travel routine to deal with packets being delivered late because a "reliable" protocol delayed them. Bolo uses NBP to locate other players, but that is of course only at startup time, not during the game itself. The game communication works by having all the machines forward packets from one to the next in turn so that they form a logical ring with packets going all the way round hop-by-hop until they get back to the start. Bolo works equally well with UDP/IP and could work with any other datagram protocol. Point-to-point datagrams are not the best way to do everything, but until there is better support for multicast, there is no good solution to this problem. If you want more information, the Cambridge University Computer Science Library has my undergraduate degree project report "An Experiment in Real Time Networking" which describes everything in great detail. The Microsoft Word file is also available by ftp from Bolo.Stanford.EDU. Hayden Books are also publishing a book this summer called "Tricks of the Mac Game Programming Gurus" which should be very helpful.
"Can I have source code?"
Sorry, I'm not giving out Bolo source code yet, and perhaps not ever if I decide to sell it commercially. Besides, until I work out the security issues, it would make it too easy for people to compile rogue versions of Bolo with indestructible tanks and unlimited firepower. Is that what you want to meet coming out of the forest on a dark night? If you want sample code showing how to use ATP, NBP, etc. check out Sumex-Aim or the mirrors. You can also get an excellent collection of sample code on the Apprentice CD from Celestin (Telephone USA [+1] 206 385 3767, or e-mail email@example.com).
"What is the "BBC ROM file" 'ROMd' resource? Did you secretly implement a 6502/BBC Micro Emulator just to play this game ;-)"
No, Bolo was originally written for the BBC micro, and then ported to the Mac. The BBC Micro only had a 2MHz 6502 processor and 32K RAM. 20K of that was screen memory, and the operating system consumed another 4K itself, so that only left 8K for Bolo. Even written entirely in 6502 assembly code, Bolo turned out to be just a little too ambitious to fit into 8K, so I had to find some way to get more memory. What I did was to replace the BBC Micro's BASIC ROM chip with a 16K EPROM of my own into which I had programmed all of the graphics character data. Bolo on the Mac still uses exactly the same graphics character data as the original BBC Micro game, which is why the EPROM data is included as a resource. Some day I might decide to improve the graphics on the Mac, but it there are many other higher priorities.
"I think Bolo is great, but I'd like to redo the graphics for it."
You may think that you can just draw new pictures in MacPaint and I all have to do is paste them into Bolo to make it work, but it would take a lot of programming effort, and my priority is networking, not graphics. Many many people have offered to do this, but so far only map editor authors are in any position to claim they have also written the code to display graphics on the screen. It's not easy, especially when you need it to be fast enough for real-time interactive use.
"My company wants to sell Bolo commercially. How about it?"
Commercialization would kill Bolo. We are at the dawn of an era. In ten years time computers, displays and networks will have evolved to the point where multi-user interactive virtual reality simulations will reach a quality which is unimaginable today. I hope that in retrospect Bolo will be regarded as as an ambitious first attempt at such a networked multi-user synthetic world, as useful research which taught valuable lessons. An attempt to bleed money out of it at this early stage would destroy it. Bolo will be freely distributed for the Macintosh because the Mac has ubiquitous networking. However, the big markets will always be in the Nintendo/Sega/IBM PC class machines, so if there is to be any commercialization, that is where it will be. In the near future, I think we can expect to see these class of machines evolve to the point where networking becomes a standard built-in feature. The Macintosh will make Bolo famous, and if you want to buy the source code to port it to one of these other machines, then give me a call in a couple of years' time, and we can talk about it.
"What about all these other versions of Bolo from other people I hear about?"
A number of other people have worked on implementating Bolo for DOS and for Windows. The reason that I have not offered my assistance is that I don't have the time to give a lot of help, and a lot of help is what would be required to make sure that the networking code operated properly. The networking code in Bolo is very complicated -- it is about half of the entire program. If I were to publish the network communication protocol then my worry is that the other implementations would work just well enough to connect to a game most of the time, but not well enough to keep the game going without destroying it. The other factor is that I am still changing the Bolo communication protocol, so anything I published would be out of date with the next release. When the protocol is stable and finalized, then I might think about interfacing with other compatible implementations.
"Why is it called Bolo?"
Bolo is the Hindi word for communication. Bolo is about computers communicating on the network, and more importantly about humans communicating with each other, as they argue, negotiate, form alliances, agree stategies,. etc.
"What's this thing in the About Box about Developer Conferences?"
It was a request to Apple to send me a free pass to their World Wide Developer Conference, which is held every May. Being a Mac programmer can be pretty disheartening, especially when you see the size of the PC market and the amount of money that games like Doom can make. Going to the Developer Conference two years ago and seeing the neat new things that Apple was working on really renewed my enthusiasm for programming on the Mac. Apple's evangelists have a number of complimentary WWDC passes for developers they want to encourage, and I'd hoped that this year they would decide that Bolo deserved encouragement. Well, they didn't. That's not to say that there aren't great people at Apple. First place for outstanding efforts in support of Bolo goes to Brent Pease of ATG Graphics, with Craig Fryar, Bill Gibson, Dennis Hescox and Brian Wilson as runners up, and numerous other strong strong contenders. (To be fair, all but one of those people have since left Apple.)
"When are you going to update Bolo to use Open Transport?"
OpenTpt (pronounced "open teapot", I think) is not released yet. I'm not a registered Apple developer, and I didn't get to go to the Developer Conference. I don't get any special treatment from Apple, so until the OpenTpt developer kit is made public there's not much I can do. OpenTpt offers one significant new feature -- multicast -- but before I can take advantage of that I will have to rewrite all the Bolo networking code to use the new OpenTpt programming interfaces, which will be a lot of work.
"When will Bolo work with ARA?"
Unlike SLIP or PPP, ARA changes the network addresses inside the packets. It does this for ATP, ADSP, NBP, and other protocols that it knows about, but not for the Bolo protocol. I'm hoping that OpenTpt will provide an easy way for me to make Bolo work with ARA.
"When are you going to write a native PowerPC version of Bolo?"
Not soon. Bolo is about 85% interrupt routine and about 15% forground code to draw the graphics. Since the System software doesn't yet support native interrupt routines (only emulated ones!) it's not just a case of "recompile it with CodeWarrior" as many people quite naturally assume. If Bolo seems slow or jerky on your PowerMac check what frame-rate you have Bolo set to, and make sure you're not running too many other programs in the background. I've played Bolo on a basic PowerMac 6100/60, and it seemed fine to me.
"Why did it take you so long to bring out version 0.99.5 of Bolo?"
A variety of reasons. Bolo 0.99.2 was a big mess internally, and it needed a lot of tidying up before I could make any more progress on it. I also had lots of other demands on my time, and Mac programming has just got a lot harder than it used to be. Back in 1984 people expected a Mac program to have windows, a menu bar and cut-and-paste. By the time System 6 came out, programs were expected to support colour, multiple monitors, MultiFinder, and the Sound Manager, all of which, I'm pleased to say, Bolo does. Since System 7, the programming burden has gone way up. To write a respectable program on the Mac these days a programmer has to know about and support most of: Balloon Help, Apple Events, Movable Modal Dialogs, Program Linking (PPC Toolbox), Publish and Subscribe, DeferUserFn for Virtual Memory Compatibility, QuickTime, WorldScript, Drag-and-drop, PowerTalk Mail, AppleScript, ColorSync, Drag Manager, Thread Manager, Macintosh Easy Open, Apple Guide and GuickDraw GX. People send me mail all the time asking when Bolo is going to be PowerMac native. Pretty soon there's going to be QuickDraw 3D, OpenTpt, Copeland, and who knows what else to support too. I don't think I can keep up.
"Hey, I love Bolo, but when are you going to write it for the IBM PC?"
As soon as I finish my PhD.
"I thought you said "never" in the 0.99.2 ReadMe file?"
That was written in 1993. Things change. Back then DOS and Windows were a mess, PCs didn't come with networking built-in, sound was an option, and there were a dozen different kinds of graphics cards to support. Now it's 1995. Networking and high quality sound is becoming standard on PCs. Windows 95 promises a single uniform TCP/IP programming interface, a single uniform graphics programming interface, and a cleaner programming environment in general. With a little encouragement and support from Apple I might have stayed with the Mac, but it's time I stopped deluding myself. Apple isn't a charity, and Apple is not going to support me just because I support the Mac. Business is business, and the bottom line is what counts.