What Went Right
1.The
team. Probably the most positive thing we encountered during development
of this game was the people working on it. Almost all of the people who
joined the team really helped to improve the game and remained fully dedicated
to it from the first day until the final moments. While we were understaffed
almost all the time, we are happy to say that while the team was growing
steadily, it was very stable — almost all the people who participated
in the development of Operation Flashpoint are still working at
our studios now that the game is finished. Another advantage was that
the team was very cooperative. Some roles on the team were not demarcated
very strictly. Still, between the programmers, designers, and artists,
everyone could comment on any part of the game, and everyone's opinions
were taken seriously.
While this
often made communication more difficult, it definitely helped the design
and development process and enriched the game in many areas. One of the
most powerful tools we used for internal communication was our intranet
news server, which proved to be an invaluable tool during the whole design
process. The game was mostly designed on the fly, and the newsgroups made
the design process not only convenient, but really quite enjoyable.
2.The
community. Operation Flashpoint's public following is incredible.
We ourselves are surprised by the number of people creating fan sites,
developing new content for the game, or just keeping in touch with the
community by reading news and forums. Currently there are hundreds of
different sites dedicated to Flashpoint, and dozens of them are of a truly
professional quality with news updated almost hourly.
Another
great thing about the community is that some of the people have been following
this game for years already, and they still carry a great deal of enthusiasm
for it. Some of the first great fan sites started out more than two years
before the game was released, and we managed to keep people's excitement
going with regular updates about the improvements we were making to the
game throughout its development. We take it as a good sign that most of
the sites are still online and updated regularly. About halfway through
development, we invited some people from the community to participate
in the design of the game directly, via external forums and newsgroups.
Their skills in both military and gaming areas were invaluable, and we
constantly used their feedback to improve the game.
Since the
release of the public demo version (around three months prior to the release
of the final game), the community following has become much bigger. The
only downside to the increase in the community base is that the community
has become much less focused and less mature, as the average age of those
visiting the web sites has descended notably.
But the community still looks really vital and the most-visited fan site
has counted millions of page views already. Recently, fans have been creating
many custom-made tools and enhancements to the game in addition to the
various web sites and services.
3.Open
architecture. Since we know that plenty of players enjoy not just
playing games but also providing their own content for them, we wanted
to enable this extensibility as much as possible. Therefore, the game
included exactly the same mission editor that we had used to design our
missions. In addition, much of the game's functionality is data-driven
instead of being hard-coded. This includes not only the mission files
and world maps but also the capabilities and properties of units. The
units are stored in a very powerful hierarchical configuration tree with
inheritance capability, yet they are relatively easy to edit. By using
these configuration files, it is possible to add completely new units
and worlds to the game or add modified versions of existing ones, which
is what many players are doing to create their own content, thus lengthening
the product's lifespan. We wanted to use configuration files to shorten
coding time as well, because we figured that the fine-tuning of most values
could be done by designers or testers instead of programmers. But this
didn't work as we expected, mostly because only the programmers really
knew meaning of the values.
Our scripting
language also featured highly in the game's development and extensibility.
We started to build the mission editor as a visual tool, but we soon recognized
its limitations in certain areas. Seeing this, we added an expression
evaluator for trigger activation, which was surprisingly powerful, and
a full scripting language soon followed. When the game was released, we
knew immediately that scripting was a really good choice, as many user-made
mission used scripts to implement specific new functionality. Looking
back, we can say scripting proved to be much more powerful than we expected.
We only wish we had added it sooner in the development cycle, so that
some of the functionality that we hard-coded into the game could have
been scripted instead, including some AI behavior.
At a later
stage of development (after the European release, in fact), we extended
the game's ability to support add-on content. Single files stored in specific
folders could add, for instance, new models, units, or islands. Besides
some official add-ons that we have introduced since the game's release,
there is already a massive number of user-made add-ons, all available
for free on the Internet.
4. Creative
freedom. From the very beginning of the project, we tried to create
the game that we really wanted to play. We didn't look too much toward
other games for inspiration, and we virtually ignored games that might
be considered our competition. We also gave little regard to whether the
market would like the game or not. Our relationships with publishers were
never too strong (actually, we changed publishers several times), and
all important decisions were made by the core development team, keeping
us relatively independent throughout the game's development. In fact,
changing publishers so many times wasn't strictly a negative thing. Even
though it led to some financial uncertainties, the creative freedom we
enjoyed instead of some more money was more than worth it.
The result
of this creative freedom is a game that is really distinct. Our design-on-the-fly
approach (or "design by playing," as we prefer to think of it)
made the game very enjoyable and a different experience from any other.
Most design decisions were first discussed (mostly in newsgroups as mentioned
earlier) and then tried out in the game. No matter how nice a design idea
might have seemed at first, only the elements that worked well in the
game ended up being included.
5. Long
development cycle. The unusually long time that Flashpoint was in
development was very beneficial. In terms of gameplay, the game is very
mature, which would not have been possible in a shorter development cycle,
especially because this was our first major game. Two or three years into
development, the game started to be really enjoyable. In fact, it was
polished enough then to suit our original plans for the release version.
But due to various things (mainly on the publishing side), the game wasn't
released at that point, which gave us more time to polish and improve
it. We were able to incorporate various features that we originally hadn't
planned to develop, either because they were too difficult or required
excessive CPU or memory resources.
We were
also able to incorporate feedback from various external testers —
our friends as well as colleagues at well-known gaming companies who evaluated
the game throughout its development. We refocused and redesigned the game
a couple of times, always opting to keep everything that worked well and
change the things we felt could work better.