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.
What Went Wrong
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.
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.
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
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.
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).
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
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.
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
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.
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.
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.
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.
Data Publisher: Codemasters
of Full-Time Developers: 10
of Contractors: 3
of Development: Over 4 years
Date: June 22 (worldwide except North America), August 29 (North
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)
Software: Oxygen (3D low-polygon modeling and texturing tool),
Visitor (landscape editor), and some other proprietary data conversion
and packing tools
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