Part I

Sometime after Glenn "Sleepdoc" Kletzky took on his huge Falcon 4 Mission Builder and Force on Force writing projects for COMBATSIM.COM™, Microprose contacted him for his help in continuing to test and debug Falcon 4. They recognized what was obvious: here was a scientific mind who was capable of organizing a large amount of potentially confusing information and breaking it down logically so that others could understand it.

Glenn graduated Tulane engineering Magna cum Laude as a Biomedical engineer and did his thesis work in programming of robotic AI and specifically robotic image recognition systems. He later graduated from from Tulane medical school, completed an Anethesiology residency at the unversity of Miami and is now in private practice in Denver colorado.

It's no mystery that training in the sciences makes for an excellent game tester. The ability to observe, then record in a standardized format the particular details of a game anomaly so that the occurrence can be repeated is the quickest way to debug a game in operation.

At the time, Glenn was the commanding officer of the 303rd VFS Sidewinders, a virtual squadron located in Denver, Colorado. At the request of Microprose, Glenn began to assemble a team from regulars on the kali server and and people he met there and made them the basis of a new test team which has been labeled "I-beta," for Internet beta.

The I-beta Team

As we all know, these high sounding acronyms disguise to our wives and girl friends the real reason for the existence of a squadron, which is to get together with a bunch of guys, fly all night long, and generally raise Hell in the virtual battlefields.

In fact, Glenn is probably the best outside resource on the Microprose Falcon 4 task force. Glenn has built an effective testing force, trained and grew them into F4 Hunter-Killers with a single mission in mind: make the multiplayer code of Falcon4 robust and effective.

The label "I-beta," however, may lead you to think that his group is focussed only on Internet play via Kali. While it's true that this is the only way that the majority of Falcon4 pilots will experience the multiplayer aspects, I-beta has much broader implications. Every bug that is killed the I-beta will also be killed for the LAN players. And naturally, it is not only multiplayer bugs that have been found and killed.

One particular example is the delay bug that occured every time a human player jumped into the action in Falcon 4.0. As the code exists, jumping into a flight in progress often leaves one disconnected from his flight, with the other elements up to ten miles away. I-beta was directly responsible for killing this and other prominent bugs that will make life for ALL F4 pilots simpler and more successful. (For the exacting details on this particular bug as well as the "COTT" bug, click HERE.)

The I-Beta Guide

Recently Glenn filled me in on some of the organizational details of I-beta. The documents and testing procedures Glenn designed are quite extensive, and we'll share only a fraction of the information here.

Of particular interest to some would be a portion of the Guide that Glenn penned early on. All that follows from here on was penned by Glenn Kletzky.

The Internet-Function Multiplayer Beta Testers Guide

Mission Statement:

The mission of the Internet-Function Multiplayer " Beta Test Team (For both Charter Members and Apprentices) is to guide the programmers of Falcon 4.0 multiplayer toward an orderly repair of bugs that affect the internet function of this simulation. Although many bugs also exist which are not specific to multiplayer games, we do not report on those bugs. We are a focused group whose only purpose it is to see multiplayer internet become a stable platform for play.

Beta testing is a labor of love. We do it because we want to help ourselves and the other players of this simulation to get the game they always hoped for.

The team is to be assembled of level-headed guys and ladies who are not interested in emotional outbursts, flame wars or other products of internet immaturity. The idea is to put together a crack team of orderly testers who stick to a rigid format of bug hunting and reporting as set forth by these documents.

All testers understand that burnout is possible, and that they may leave the team at any time without hard feelings towards or from the other members. We are here to have fun, despite the rigid reporting rules you are about to review in this document. If at any time, any member feels that they are no longer enjoying the process, then our only request is that they gracefully bow out. There will be no hard feelings from us. They may return to the team at any time.

The priorities of bug reporting for the Falcon 4.0 I-Beta team.

After much discussion, the priorities of this team have been determined. They are to locate bugs in the following sections of the game. These priorities represent that which this team and Microprose believe need to be fixed first in order to make this a viable internet multiplayer product. These priorities for internet game repair are listed in the order of importance. We will hunt for bugs and make suggestions for repair based on this order of priorities.

Priority ONE:

To Get 2 player DF and TE and CPN working solidly on the internet.

• 1. Connections across the internet must be stable.
• 2. Multiplayer game settings must work properly.
• 3. Dynamic re-entry (called XYZ-HAS re-entry)in DF and CPN must work properly.
• 4. The infamous "ghost plane bug" must be eliminated
• 5. Pilot assignments to new plane icons in the ready room must work correctly
• 6. The "queueing bugs" associated with delayed chat and delayed pilot assignments must be fixed.
• 7. AI Brains must be passed properly back to planes who had their human inhabitants leave.
• 8. The "AI Brain Transfer of Ownership" feature must work properly between the M-host and all of his M-Guests (no matter how many M-Guests there are)
• 9. Comms chatting and comms channel selections must work and connect you to the correct people.
• 10. Clock sync must work.
• 11. Regenerations in DF must work.
• 12. Memory leaks must be eliminated.
• 13. Progressive frame rate deteriorations must be eliminated (Probably a side effect of progressive memory leaking or comms settings not functioning properly).
• 14. ROE screens must consistantly appear at the start to all game types (DF, TE & CMPN), whether or not the players are already in compliance.
• 15. ROE screens must remember prior settings after returning from windows or new reboot.

Priority 2:

Then get 3 player working; then get 4 player working. Then consider looking at server software development, but until the above priorities are working, there really isn't any point in server software.

Defining the seven (7) Internet game types that we are going to test and designating their proper abbreviations:

• 1. DogFight - Furball………… DF-F
• 2. DogFight - Team furball……….. DF-TF
• 3. DogFight - Match play.. DF-MP
• 4. Tactical Engagement - Force vs. AI (p-p)……... TE-FvAI
• 5. Tactical Engagement - Force vs. Force (p-p)…….. TE-FvF-Pre
• 6. Tactical Engagement - F vs. F (chess like)……. TE-FvF-chess
• 7. Campaign ……. CMPN

Part II - By Glenn Kletzky

1. DF-Furball (DF-F)

This is dogfight furball. As you know, the dogfight module of F4 has 3 variants and this is the first one. They need little explanation, so I will just list the other 2 variants without further elaboration. It is actually TE type games that need elaboration.

2. DF-Team Furball (DF-TF)

3. DF-Match Play (DF-MP)

4. TE-Force vs. AI (pre-programmed) (TE-FvAI)

In Tactical engagement custom missions, the most common type is this type (remember...we are talking about 2 player or more internet games...not playing single player). This is the basic pre-scripted, co-op multiplayer format where 2 or more guys on the same team play a pre-programmed mission where all the flights (both friendly and enemy) were already designed by the designer before the mission started.

You can change waypoint locations and loadouts once you enter one of these missions, but adding new flights once in the game or issuing new orders to ground troops is not in the scope of this "type" of mission (hence the term "pre-programmed"). It is called "Force vs. AI (pre-programmed)" Also, all humans are on the same team. No humans play for the DPRK.

5. TE - Force vs. Force (pre-programmed) (TE-FvF-Pre)

In FvF(pre-programmed) missions, all flights are already written in by the guy who designed the mission before the game starts, and no new missions are created (or ground troop movements issued) once the game begins (hence the term "pre-programmed"). The difference, however, is that at least one human is playing for the US side and atleast one human is playing for the enemy side. It is a competition between humans.

The "Victory conditions" were set forth by the designer in advance (as they always are) and the players simply fly the missions that they were given and attempt to complete the victory conditions as set forth. In this case, you are competing against the enemy which is accompanied or lead by atleast one human.

Once again, if the flight you are in gets shot down, then you may NOT make new flights on the fly. You may enter other planes already in the original mission, but you may not make new flights with remaining resources, and you may not issue new ground troop movements when you are back at the ready-room, between flights. If all your pre-programmed missions are gone, then your game is over.

6. TE - Force vs. Force (chess like). (TE-FvF-Chess)

Unlike in a game of chess, the prior TE game types defined did not permit moves and countermoves. You were not allowed to create new flights "on the fly" once the game was started. When you were dropped back to the "ready-room" you could only re-enter the game if pre-existing planes and flights remained. You also could not issue new ground troop movements.

In chess, as in this type of play, you may do all these things and more. These "chess like" games usually start with a set of resources on the map (like peices on the chess board). These resources would be things like Squadrons of pilots and aircraft placed at certain bases. Ground troops such as tanks and mobile SAM battalions sitting at predetermined starting points.

Each player has limited resources (as an a example, lets say each player has 3 squadrons of f-16s and other type aircraft based at certain airbases and each player has a bunch of mobile entities like SAMs and tanks). When the players first connect to play, all they have are their resources and their victory conditions. No flights or packages have been constructed and no ground troop orders have been issued.

Let's say the victory condition is to "OCCUPY" the city of Seoul with at least 4 tank divisions. As soon as the game starts, you start frantically making flights and packages and issuing ground troops orders to move. Once you feel you have made a good first move, you let the AI take over and you enter the game to fly as one of many airplanes in the sky. Once you die, (or you decide you need to get back to the interface and check on the status of your troops) you end the mission, and return to the "ready-room".

Once back at the interface, you check on the troops and the results of all the flights that have gone out, you re-assess, you re-issue new ground troop movements, you create new flights and packages, and then when you are satisfied, you fly again. All the while, your friend on the enemy side is doing the same thing. Ultimately, after many returns to the interface and many new flight creations and ground troop re-orderings, either someone occupies Seoul or the game is a stalemate. Just like chess.

To me, this is the ultimate form of play in TE, and may even prove to be more exciting than a campaign in multiplayer, due to the strategic level of control that the player has.

Part III - By Glenn Kletzky

What a Bug reporting FORMAT and Bug reporting TEMPLATE Is

As you recall from the prior part of this document, we have defined seven types of internet game play types. For each of these game play types (DF-F , DF-TF, etc) we will have a bug reporting FORMAT to match. Each of these FORMAT documents are to be printed out and kept handy during bug report writing.

The FORMAT document for each game type will show the tester every category he is to report on, and all the possible things he can enter for each category. He may sometimes think of other things that need to be options for the format documents, and he may submit his additions at any time to me (Sleepdoc) for approval. If they are valid, they will be added to all the groups FORMAT documents.

The tester will also receive a TEMPLATE document for each game type. The Bug reporting FORMAT document and it's related bug reporting TEMPLATE document constitute the "matched pair" of documents for each game type (DF-F , DF-TF, etc).

The TEMPLATE document is to be opened by each tester in his or her word processor and read fully. Then the TEMPLATE is to be customized (edited) to be an "empty shell" with each category listed and the individual testers COMPLETE system specs added to the end. Then, when it is time to report bugs, the player opens the appropriate TEMPLATE (there will be one for each game type).

A Partial Listing of the I-Beta Team

Glenn "Sleepdoc" Kletzky
Andre "ILL_DRE" Jennings
Cam "Raptor" Kristensen
Chris "Hawk" Schroeder
Dave "Madcow(App)Dewdog" Wagner
David "Crankshaft" Hiebert
Jeff "Jet-thro" Thomas
John "NavlAV8er" Simon
Nester "RED-10" Colon
Robert "Navy1" Stanley
Ken "Sidekick" Crawford
Börje "Speed" Johansson
David "Ham" Hamilton
Joe "Surfdog" Abramo
Cameron "VLAD(App)Sleepdoc" Paine
Charles "Dirtdobber" Weems

Craig "NightLight(App)SideKi...
Dale "FlightDoc" Varner
David "Crankshaft" Hiebert
Joe "Surfdog" Abramo
John "Avenger" Grey
John "Makani(App)Surfdog" Sa...
John "NavlAV8er" Simon

Leigh "Anytime(App)Ham" Wooley
Len "Archer(App)Hawk" Collins
Leo "Central(App)Hawk" Park
Mike "Cannon(App)SideKick" K...
Nester "RED-10" Colon
Richard "DedMan(App)DewDog" ...
Rick "Harpy(App)SideKick" Co...
Rick "Iceman(App)DirtDobber"...
Speed
Steve "Wizard(App)DirtDobber...
Tennie "Spaceman(App)NavLAv8...
Todd "GreatWhite(App)DirtDob...
Victor "Duke" Zaveduk

XYZ HASA Fixes

XYZ-HASA fixes

This was a big one, and took longer than any other bug to characterize and track down. The Charter members of the I-Beta team really showed their stuff when they tracked this bad boy down and helped Mr. Heydon focus on killing it. It deserves a full definition, not only for historical purposes, but also in case it ever rears its ugly little head again.

The XYZ part of XYZ-HASA refers to the xyz position in space. In other words, if Cowboy 12 is an AI controlled aircraft flying right off your wingtip in formation, and you choose to dynamically re-enter it (that means enter it in mid-flight), then when you do dynamically re-enter that aircraft, the human should be put right in that craft at its current location right off your buddy's wingtip. Right?

Well.. unfortunately, since the original release, that was not what happened. As soon as the human was applied dynamically to that AI craft, that AI aircraft would literally warp anywhere from 4 to a million miles away. We started inventing terms like "warp -4" (back 4 miles) and "warp one million" (god knows where that one went .. hehehe). We even had a weird one we once called "warp RTB" (RTB = Return to Base).

That was a real weird one, because no matter where the aircraft was at the time you entered it, it would always warp straight back to the base it took off from and be placed on the ground in the grass field near the base of origin, with its wheels down !!! No kidding. We called it "Warp RTB" (RTB=Return to Base). So clearly, For this revolutionary new feature in Falcon 4.0 to be worth a damn (dynamic re-entry has never been done in a complex flight sim before.. not even SU-27 1.5), this feature needed a lot of work.

The HASA part of this term stands for "Heading/Altitude/Speed and Attitude." After all, even if the programmers got the XYZ position correct, what if the aircraft was suddenly turned around 180 degrees from its original direction (heading), pointing straight down at the ground (attitude), was in a stall at 80 knots (speed), and was suddenly only 500 feet off the ground (altitude , which is actually part of xyz, but you get the point here.) So it wasn't enough that we fixed XYZ. We needed to fix XYZ-HASA.

This bug took many failed attempts to fix, and is still not perfect yet, but has come 95% of the way there since this version. It works very well almost all the time now. Here is an inside explanation of what is happening, how it works, and what the remaining little problems are.

  When the Gilman pie (those 5 pictures we see during the loading of the game) is at the transition from Gilman Pie Slice 2 to Pie Slice 3, that is the point at which a player inside the simulation will see your name label applied to the aircraft you are entering. It is the time that you are actually placed in the aircraft. It used to be the time that the wild "Warps" occurred as well.

The problem is that even though you are now "applied" to the aircraft, you still have many seconds of load time remaining, and therefore cannot see the world around you and fly the aircraft. SNAFU you say? Well, not really. The solution is that at the moment you are applied at Gilman 2/3, the "Combat autopilot" is also activated. And at the very instant that you actually enter the airplane, a final XYZ-HASA packet is re-checked, the "Combat autopilot" subroutine is disengaged and whamo! You are in the hot seat. Sometimes it helps to understand the inner workings, don't you think?

And please don't be confused by this explanation. The user does not have to have "combat autopilot" selected in his setup for the program to use combat autopilot in this load "Dynamic Re-entry" situation/Gilman pie sequence. So just leave your autopilot settings anywhere you like it.

COTT

The document that defined this bug and its fixes was ten full pages in length. Here is the initial definition....

A set of bugs which have come to be cumulatively known as the "CHAOS ON THE TAXI-WAY" bugs (COTT) have been identified and characterized. All of them will be given names here at the beginning of this write up, and then defined through out the content of this write up.

The COTT bugs are a result of the following individual bugs.

1. The "Slider-Collider" bug (AKA the "Explosion on Entry" bug)

2. The "Variable destructibility of aircraft on the Taxi-way" feature

3. The "Over-Zealous 1-1 Aircraft AI brain" bug

4. The "Chain-Link, Who Follows Who on the Taxi-way" bug.