COMBATSIM.COM: The Ultimate Combat Simulation and Strategy Gamers' Resource.
 

 
Falcon 4.0 I Beta Team
by Leonard "Viking1" Hjalmarson
 

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.

Click to continue

 

F4

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 Two further defines these game types and Part Three defines some of the bug reporting routines developed by I-beta and lists the team members. Sleepdoc welcomes your emails on this and other subjects.

 

Copyright © 1997 - 2000 COMBATSIM.COM, INC. All Rights Reserved.

Last Updated April 27th, 1999

© 2014 COMBATSIM.COM - All Rights Reserved