Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Bohemia Interactive Studios' Operation Flashpoint
View All     RSS
January 18, 2021
arrowPress Releases
January 18, 2021
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Bohemia Interactive Studios' Operation Flashpoint

December 19, 2001 Article Start Previous Page 3 of 3

What Went Wrong

1.Development cycle much longer than expected. Ironic as it is, we have to start What Went Wrong exactly where we left off with What Went Right. Despite some of the usefulness the extra development time offered us, in the end th cycle was probably too long, and in optimal conditions would have been at least 20 percent shorter. It may have been possible to shorten the cycle, but we experienced various external events or internal missteps that prevented us from accomplishing that.

First of all, some technologies in the game were a bit outdated after more than four years. We didn't know at the outset that the game would be still in development after so long, and we hadn't left time at the end to rework parts of the engine. Some of the criticism of Operation Flashpoint addresses the amount of detail in the textures and some models — and we have to admit that these could have been better.

Furthermore, the excessively long development cycle led to burnout and heavy exhaustion, particularly for the people who had been working on the game since very beginning (the lead programmer, lead artist Jan Hovora, and the team leader). In some cases, we weren't able to sustain some of the features we'd implemented two or more years prior. They just disappeared somehow in the process of reworking parts of the code, and we didn't even notice. Newcomers to the development and testing process never knew such features had ever existed.

The main problem wasn't that the development cycle was too long per se, but that the development was so much longer than we'd expected. Next time, we will work much more diligently to better estimate our development time — and we will probably try to aim higher with the detail of our artwork, even if it seems insanely detailed for present and predicted hardware capabilities.

Bohemia Interactive's in-house motion capture facility has proven very beneficial in creation of lifelike human movement animations.

2.Documentation. Lack of documentation is a common affliction among game developers, but some aspects of this problem were so severe in our case that they are worth mentioning.
While we'd never believed too much in designing the game on paper, the real problem was that we never even had documentation of the things that we'd finished. This situation led to incredible problems in the final stages of development. Many tasks could only be done by one person on the whole team. In other cases, hours were spent trying to investigate how something had originally been meant to work. We recognized these problems and tried to improve them, but apart from a few instances, our effort wasn't really successful.

As the development team grew, the missing documentation was becoming a more serious problem. But the final project deadlines were getting closer as well, so it was nearly impossible to find the time to address the problem.

3. Quality assurance. We experienced various problems in communication and cooperation with our publisher. Generally, their focus and assistance in some areas of the production of the game (design suggestions, voice-overs, translation, scriptwriting) were really helpful. But in other areas, we experienced some events and circumstances that slowed down and complicated the game's development rather than moving things forward.

One of the most unsatisfactory areas was the way the QA procedures were managed and designed to work by the publisher. We never succeeded in achieving a common bug database, and the publisher enjoyed an illusory feeling that its QA database really covered the project. The truth was that such a database (even without any direct access for the development team) hardly said anything about the project's status because it covered just small fraction of all the problems we had tried to fix. Even when the publisher dedicated a pretty big testing team to the game, it sometimes seemed something of a waste of time for everyone involved in it.

In the end, we had to largely ignore the publisher's QA reports, because they contained too much useless information and very few real bugs. We tried to focus on very limited external testing managed directly in the very late stages of development to ameliorate this problem — but this approach could hardly replace real, full-time testing of the game.

We admit the situation was very difficult for the QA team as well — in no small part because of the lack of documentation on our side — but we still believe this process could have been handled much better. One of the mistakes we made was assuming that the publisher's QA would be sufficient, so we didn't build a strong testing team in-house. We definitely will find a solution for any future projects, because the way it was done for Operation Flashpoint wasn't satisfactory.

The Head of a tank crew in Oxygen. You can see face of Petr Pechar, one of the artists on Operation Flashpoint, under the helmet (left). A Soviet AKSU rifle shown in Bohemia Interactive's proprietary modeling tool, Oxygen, with direct real-time previewing using the game's engine (right).

4. Some content was not under our full control. One very concerning thing was that our final CD was still manipulated by the publisher. The publisher applied SafeDisc protection to the final code, which caused some unexpected compatibility problems that we weren't able to control. The mixing of various SafeDisc versions and a serious compatibility problem with Windows 2000 that was present in the first European batch of CDs could have been avoided.

In addition, we weren't able to finalize the English language in the game because we didn't have a native English writer on the team. We also didn't oversee the voice recording and voice actor selection, which led to some results that were unsatisfactory to us.

5. Multiplayer API. From the very beginning we were aware that our game had huge multiplayer potential, especially if it were implemented as a massively multiplayer online game. But we knew we would be unable to deliver such experience. Instead of aiming for such an unrealistically high goal, we decided to implement mission-based multiplayer that shared as much code as possible with single-player game. Even this effort proved to be extremely difficult. Operation Flashpoint was always developed primarily as single-player game with a strong story, but for a very long time we were thinking about multiplayer functionality, and we tried to design the game code in such a way that it would help us incorporate multiplayer later.

For implementation, we wanted to avoid low-level network coding and instead use a high-level API. As we were already using Direct3D for graphics and DirectSound for audio, and both suited our needs quite well, we decided to use DirectPlay as our network API. DirectPlay offered high-level handling of all network communication, including Voice Over Net capabilities. Unfortunately, our experience with this API was extremely bad. Often when trying to get some high-level functionality working, we realized it contained bugs that rendered it almost unusable.

We had to implement our custom code for things we thought DirectPlay would provide, but that was sometimes very hard, as we did not have the low-level control that we needed. We also encountered many performance problems, some very strange, such as significant (particularly server-side) slowdown even with no traffic over the network. This along with the lack of documentation and a lack of stability resulted in many problems that were hard to debug.

Another drawback that we didn't recognize beforehand is that DirectPlay is Windows-only, but many dedicated servers for games currently being played online run on Linux. Overall, selecting DirectPlay as our network API was one of the most unfortunate decisions in the whole game's development.

Future Dreaming

Most start-up game developers dream of developing a number-one title. We weren't any different. With Operation Flashpoint, this dream has come true for us. The game achieved the number-one position in sales charts of various countries and regions, including the U.S., Germany, the United Kingdom, Benelux, Scandinavia, and Australia. More than 500,000 copies sold worldwide in just three months, proving to us that our last four years of effort were worth something.

We always stayed focused on the game, and we didn't have too much regard for those who believe that the success of any game is mainly a question of marketing, securing a big license, or working on a sequel. We always believed that it's the game itself that makes the difference between success and failure.

The combination of infantry with full simulation of vehicles is a crucial part of the design of Operation Flashpoint.

We're still playing the game and we still like it. After such a long time, it's hard to believe that Operation Flashpoint remains the favorite choice of games for most of the development team. We're still working on new content for Flashpoint out of pure enthusiasm. In the end, we don't feel ourselves to be anything more than proud members of a big and healthy Flashpoint fan community that has arisen around the world.

We know that someday we will have to leave Flashpoint to its own destiny. But currently, we still feel too involved in the game. We are already looking forward to future projects, but it will take months for us to start one. We consider the success of Operation Flashpoint as the pole position for our next race. We plan to use all the experience and resources that we have gained during the last couple of years to push gaming even further in the future.

Operation Flashpoint

Game Data Publisher: Codemasters

Number of Full-Time Developers: 10

Number of Contractors: 3

Estimated Budget: $600,000

Length of Development: Over 4 years

Release Date: June 22 (worldwide except North America), August 29 (North America), 2001

Development Hardware (Average): Various PC systems from 266MHz Pentium IIs to 1GHz Pentium 4s and 1.2GHz Athlons with 20GB hard drives and Voodoo 2 or GeForce 2 graphics cards

Development Software: Windows 98/2000, Linux servers, Visual C++ 6, SourceSafe, Adobe Photoshop 5.0, 3DS Max, Microsoft Office, TextAloud (for voice prototyping)

Proprietary Software: Oxygen (3D low-polygon modeling and texturing tool), Visitor (landscape editor), and some other proprietary data conversion and packing tools

Notable Technologies: DirectX, Vorbis Ogg, Vicon 8 motion capture system

Project Size: 10,000+ files, 250,000 lines of C++ (some assembly), 5,000 textures, 800 3D models, 100,000 words (localized into six other languages), more than 60 single-player and multiplayer missions




Article Start Previous Page 3 of 3

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist
Insomniac Games
Insomniac Games — Burbank, California, United States

Sr. Environment Artist
Insomniac Games
Insomniac Games — Burbank, California, United States

Senior Designer
Insomniac Games
Insomniac Games — Burbank, California, United States

Sr. Character Artist (Outsourcing)

Loading Comments

loader image