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.
