Interview de Kevin Klemmick / Lead Software Engineer de Falcon

Avatar de l’utilisateur

Topic author
Pilote Philanthrope
Pilote Philanthrope
Messages : 1892
Inscription : 20 février 2018

Interview de Kevin Klemmick / Lead Software Engineer de Falcon


Message par Flow » mer. janv. 30, 2019 7:23 pm

Elle se trouve de moins en moins sur le web, du coup je vais la sauvegarder sur ce forum.
Version FR traduite à l'arrache plus bas de le post
Interview with Kevin Klemmick ' Lead Software Engineer for Falcon 4.0
March 12th, 2011 Posted in Falcon . Interviews By Giorgio Bertolone Write comment

Falcon is, without any doubt, the most ambitious and realistic Air Combat Simulation ever created and, for this reason, many simmers all over the world still fly it regularly despite its aging graphics. Because of this success, I always hoped to have one day the opportunity to ask specific questions about its development.

I can't thank enough Kevin for agreeing to this interview and for answering in such a honest and professional way. This is a long interview that will reveal a lot of things that many simmers probably didn't know. I'm proud to make it available for everyone who, like me, considers Falcon as one the best simulators out there. There is a lot to read so sit comfortably and enjoy!

GENERAL NOTES FROM KEVIN: Keep in mind that all this happened about 15 years ago and my memory is definitely fuzzy. I pulled up what I could from there, but I will be the first to admit my memory isn't always accurate. I did no actual fact-checking on myselft, so take all this with a grain of salt.


Let's start from the beginning. What can you tell us about your background and how did you find yourself working for MicroProse?

I had been studying Aerospace Engineering at Cal Poly when an opportunity came up to take an Internship at MicroProse (which was still Spectrum HoloByte at the time). Back in the 80s I had written several multiplayer games for a gaming BBS I ran in high school, and I found the job opportunity through those contacts. Because of my background with both gaming and aerospace it seemed like a good fit.

Could you describe your roles and responsibilities during those years?

Initially I was hired as an intern and asked to design and develop a dynamic campaign. For better or worse there wasn't a lot of direction on what that would entail ' the directive was mostly to make something that would be a persistent world and generate dynamic missions instead of the pre-scripted model which was the norm. I'd written a few simple strategy games prior to this, so I approached it as designing and writing a strategy game. This was obviously a much bigger job than an intern could handle in a summer, so I eventually signed on full time. By the end of the project I'd ended up taking on much more, and was eventually lead programmer on the localization projects.

How many people were in the development team of Falcon 4.0?

I honestly couldn't give you an exact number. Probably 50 or so over the course of the project. The thing is, the entire team turned over twice due to people leaving, layoffs or terminations. For a brief period of time I was the only programmer on the team. So, depending on how you count it this number can vary widely. For most of the project we had about 6 engineers and maybe the same number of artists.

Working on a simulator like Falcon 4.0 must have been an incredibly exciting and stressful job. How was the general atmosphere in the team?

This was my first job in the industry so I didn't really have anything to compare it to. At the time it seemed like we were really excited to build something cool, but in retrospect I realize there was a lot of stress, conflict and tension in the team. I take responsibility for a portion of that too. We all had strong opinions about what we wanted to do and there wasn't a strong management presence until the end (when Gilman Louie came in and filled this role personally), so things definitely went off the rails regularly.

Falcon's real-time Dynamic Campaign is one of the most impressive engine ever created in a sim. Could you talk specifically about its design, challenges and implementation?

I was given a pretty blank check in designing the Dynamic Campaign, so I approached it as I would a strategy game. The idea being that this game would be running in the background whether or not the player flew any missions. In fact, it could be played as a strategy game from the tool I wrote to monitor it. The AI was broken into three tiers, a strategic level, operational level and tactical level. Yet another level of AI would operate in the Simulation itself to drive the vehicles or aircraft.

The missions were generated as a byproduct of this AI, and in fact used real world planning techniques. For example, once a priority list of targets was determined, a package would be put together to time suppression of air defense, air superiority, refueling, AWACS, etc. All these missions would be timed out and planned much like a real world commander would, but were generated as a response to decisions made by the campaign's AI.

While my primary goal was to make something fun to play, we were very fortunate to get a lot of advice from military sources about how things work in the real world and I tried to match that as closely as possible while keeping the game play elements that I felt were important. However, all of this had to work within a very tiny slice of the CPU, which was a huge limitation given all the AI/planning work that was going on. That was probably the biggest challenge of this system.

How did you design and code the multiple scenarios? How did you manage to work on them without feeling overwhelmed by the immese scale of these virtual conflicts?

We talked a lot about what theatres we wanted to use. I did some research about what was at the time thought to be the most likely future conflict zones. In the end we went with Korea because of a number of factors. I pushed hard to focus on one theatre in depth rather than do multiple theatres poorly, so we decided to do multiple scenarios in a single theater instead. The scenarios were based somewhat on historical situations in the Korean War, but also what could be likely situations given deployments at the time. The biggest problem with the scenarios wasn't feeling overwhelmed by them, it was testing them enough to feel comfortable that completely non-scripted AI would be able to play through them realistically.

What were the biggest technical problems that you had to face and solve in the other areas engineered by you (AI, Multiplayer, Coms, etc)?

The biggest technical challenge for me was doing everything I wanted to with the Dynamic Campaign in the CPU slice we budgeted, which I believe was something like 5% of the CPU. To really get AI to work well you need to do a lot of pathfinding and data crunching, all of which is CPU intensive. So there was definitely a lot of compromise in AI quality because of this.

Coms was the other big challenge I was a part of. We developed a very low cost protocol and spent a lot of time on the whole 'player bubble' concept. This meaning mostly that events happening near the player were sent more often and with a higher level of detail than those far away. Outside of this bubble we updated very infrequently and with units in aggregate. For example, an entire battalion would pass a bitwise array of active vehicles, a formation and a location. All of which was just a few bytes of data.

Of course, there were plenty of other challenges as well, including simply organization of the various components. We had largely developed the various modules in isolation and when it came time to put them together this turned out to be the source of a lot of problems.

What part of your specific work on Falcon 4.0 are you most proud of and why?

Definitely the Dynamic Campaign. It's the first and last time I was able to design and code a part of a game pretty much on my own, which had been my experience doing games as a hobby up until then. In the rest of the gaming industry you really don't have very much input on the design of a game as a programmer. I was still pretty green at the time though and looking back I can see so much that could have been done better, but I am still quite proud of that.

Some parts of Falcon seem to have a modular design. Was this planned? Were you guys thinking ahead to future aircraft and terrain expansions?

Absolutely. In fact, we had different aircraft working in house very early on, but doing other aircraft to the level of detail we did for the F16 just wasn't possible given our resources. The Dynamic Campaign was initially designed to be able to be played as a separate game entirely, but in the end because very heavily intertwined with the rest of the game. Terrain sets and theatres were designed to be easily swapped out for future expansions (we had planned for an Iraq theatre). On the other hand, part of this modularization was due to different engineers working in isolation and became a problem later on. For example, three different modules ended up using 3 completely different coordinate systems, so communication between them required conversions.

It seems like the first release of Falcon 4.0 was rushed to the market in order to sell during the Christmas holidays. Was the code mature enough for this initial release?

I'd agree that the product was shipped in a pretty buggy state, but I couldn't honestly say the first release of Falcon 4.0 was rushed. It took about 5 years to build and the last 9 months we were working 12-16 hour days (They had a hotel booked across the street, so my wife ended up staying there so that we could even see each other). It was a huge challenge to just finishing the thing; this was an incredibly complex product that really wasn't planned out or managed well at all. Because of the complexity and lack of central design it became really difficult to find and fix the many, many bugs in the program. In the end we could have taken another year and still had open bugs, but at eventually you've got to get it out there. MicroProse was bleeding money at the time and Falcon already had the stigma of vaporware, so at some point we had to determine that it was good enough and then work hard on patching the problems.

You also worked as Lead Programmer for the post-release patch projects. What were your main priorities and which particular areas had to be fixed or improved?

I was actually a Lead Programmer on the localization projects, but I was involved in the patching process. The priorities there, to be perfectly honest, were to fix the problems that should have been fixed prior to shipping it. As I said, there were far more issues there than we had the resources to fix, but we tackled those that impacted the most users first and kept reducing the list. When I left I was still not happy with the stability of the game, which made it hard to leave it feeling unfinished, but I realized that to MicroProse this probably looked like a money pit.

Ironically, moving to SEGA was exactly the opposite environment. We were doing arcade games which had to run with absolutely zero crashes and which are burned write only on EPROM chips. It was a completely different challenge to develop software that worked out of the box and that was unpatchable.

The last official patch was 1.08. Was there any plan for future patches after that? If yes, what would they have addressed?

I had left for SEGA prior to then, so I don't know what the state of things were at that point.

Did the layoff of the entire development team come as a surprise or was it a predictable event after the acquisition of MicroProse by Hasbro?

Well, the development team had been hit with layoffs multiple times previously so the concept was pretty familiar by then. I saw the acquisition by Hasbro as a pretty negative thing, so left for SEGA prior to the layoffs. I don't think anyone was taken by surprise by that though.

Did you ever find out the cost of development of Falcon 4.0 (approximately) ?

I honestly don't know. I could make a guess given my industry knowledge but it would only be a guess. I suspect that in the end MicroProse did not make money on Falcon 4.0 however. This is not to say that flight simulators are entirely unprofitable, it's just that this one in particular had a much higher than average development cost.

You worked at MicroProse for a long time (almost five years). What are your best and worst memories?

I really liked the range of creative input I was allowed there. In retrospect maybe some of this wasn't so much allowed as assumed since I'd come from doing games as a hobby, but in any event it allowed me to go off and build something I thought was really cool. Unfortunately, it was exactly this approach that caused the development to take so long and coordination between engineers to be so difficult.

My worst memories are mostly of conflict between the team and the long hours. I was very young at the time (the youngest programmer on the staff) and was opinionated, overworked and had a fragile ego, so things got pretty tense at times.

Many recent simulators are released without even trying to code a Dynamic Campaign engine. Why do you think today's sim developers are so scared of what you guys were able to create more than a decade ago?

Well, it's just really hard to do. Looking back on it, I think the only reason we took on what we did is because we were too inexperienced to know better. Knowing what I do now, even given my experience on Falcon, the cost to develop such an engine would be substantial. Since flight sims don't bring in that kind of revenue companies look at it from a cost to benefit standpoint and Dynamic Campaigns score pretty low in that regard. There is also the argument that scripted missions are more interesting which has some merit. I think if I were to do it over I would do a mix of scripted/generated missions, so that the player still feels like they're involved in the world, but there is also some variety thrown in to keep things interesting.

In 2000 the source code of Falcon 4.0 leaked out and after that groups of volunteers were able to make fixes and enhancements that assured the longevity of this sim. Do you see the source code leak as a good or bad event?

Absolutely a good event. In fact I wish I'd known who did it so I could thank them. I honestly think this should be standard procedure for companies that decide not to continue to support a code base.

I know that after MicroProse you moved on to other opportunities and important roles. But if asked, would you still consider working on a modern combat simulation?

I'd been approached about that a while back and expressed interest, but the team was being put together in Colorado I believe and I'm pretty tied to the San Francisco Bay Area at this point. I'm not interested from a flight sim perspective (I actually don't play them), but I would be from a Dynamic Campaign perspective. I'm much more interested in the strategy/persistent world aspect of it all.

You currently work as Technical Director for Gravity Bear and you are developing very interesting applications. Could you talk about your work on current and future projects?

I'm actually now working as a Technical Director for Electronic Arts, doing Sims projects (that 'The Sims', not flight sims). Gravity Bear is a small company we created to do Facebook games, and I worked there for about 2 years. The entire company consisted of only 6 people and for much of that time I was the only programmer. I've been involved in a couple other startup attempts, largely because I would love to work on games I would actually enjoy playing and so much of what the big companies are doing these days are just remakes of old concepts, but I also have a family to support, so the stability of a company like EA and solid titles like 'The Sims' is very attractive.

Version FR traduite automatiquement :
Entretien avec Kevin Klemmick ' Ingénieur logiciel en chef pour Falcon 4.0
12 mars 2011 Publié dans Falcon . Interviews Par Giorgio Bertolone Ecrire un commentaire[/b

Falcon est, sans aucun doute, la simulation de combat aérien la plus ambitieuse et la plus réaliste jamais créée et, pour cette raison, de nombreux simmers dans le monde entier continuent à voler régulièrement malgré ses graphiques vieillissants. En raison de ce succès, j'ai toujours espéré avoir un jour l'occasion de poser des questions précises sur son développement.

Je ne remercierai jamais assez Kevin d'avoir accepté cette entrevue et d'avoir répondu avec autant d'honnêteté et de professionnalisme. C'est une longue interview qui révélera beaucoup de choses que beaucoup de simmers ne savaient probablement pas. Je suis fier de le mettre à la disposition de tous ceux qui, comme moi, considèrent Falcon comme l'un des meilleurs simulateurs du marché. Il y a beaucoup de choses à lire, alors asseyez-vous confortablement et profitez-en !

NOTES GÉNÉRALES DE KEVIN : Gardez à l'esprit que tout cela s'est passé il y a environ 15 ans et que ma mémoire est définitivement floue. J'en ai tiré ce que j'ai pu, mais je serai le premier à admettre que ma mémoire n'est pas toujours exacte. Je n'ai pas vraiment vérifié les faits sur moi-même, alors prenez tout cela avec un grain de sel.


Commençons par le début. Que pouvez-vous nous dire sur votre parcours et comment vous êtes-vous retrouvé chez MicroProse ?

J'étudiais l'ingénierie aérospatiale à Cal Poly lorsqu'une opportunité s'est présentée de faire un stage chez MicroProse (qui était encore Spectrum HoloByte à l'époque). Dans les années 80, j'avais écrit plusieurs jeux multijoueurs pour un BBS de jeu que j'avais lancé au lycée, et j'ai trouvé un emploi grâce à ces contacts. En raison de mes antécédents dans les domaines du jeu et de l'aérospatiale, cela me semblait un bon choix.

Pouvez-vous décrire vos rôles et responsabilités au cours de ces années ?

J'ai d'abord été embauché comme stagiaire et on m'a demandé de concevoir et de développer une campagne dynamique. Pour le meilleur ou pour le pire, il n'y avait pas beaucoup d'orientation sur ce que cela impliquerait - la directive était surtout de faire quelque chose qui serait un monde persistant et de générer des missions dynamiques au lieu du modèle pré-établi qui était la norme. J'avais écrit quelques jeux de stratégie simples avant cela, alors je l'ai approché comme la conception et l'écriture d'un jeu de stratégie. C'était évidemment un travail beaucoup plus important qu'un stagiaire ne pouvait gérer en un été, alors j'ai fini par m'engager à temps plein. À la fin du projet, j'avais fini par en prendre beaucoup plus, et j'étais finalement programmeur en chef sur les projets de localisation.

Combien de personnes étaient dans l'équipe de développement de Falcon 4.0 ?

Honnêtement, je n'ai pas pu vous donner un chiffre exact. Probablement une cinquantaine au cours du projet. Le fait est que toute l'équipe s'est retournée deux fois en raison de départs, de mises à pied ou de cessations d'emploi. Pendant une courte période, j'ai été le seul programmeur de l'équipe. Donc, selon la façon dont vous le comptez, ce nombre peut varier considérablement. Pour la majeure partie du projet, nous avions environ 6 ingénieurs et peut-être le même nombre d'artistes.

Travailler sur un simulateur comme Falcon 4.0 a dû être un travail incroyablement excitant et stressant. Comment était l'ambiance générale dans l'équipe ?

C'était mon premier emploi dans l'industrie, donc je n'avais rien de comparable. À l'époque, nous avions l'air vraiment excités à l'idée de construire quelque chose de cool, mais avec le recul, je me rends compte qu'il y avait beaucoup de stress, de conflits et de tensions dans l'équipe. J'en assume aussi une partie. Nous avions tous des opinions bien arrêtées sur ce que nous voulions faire et il n'y avait pas une forte présence de la direction jusqu'à la fin (lorsque Gilman Louie est arrivé et a rempli ce rôle personnellement), alors les choses ont définitivement déraillé régulièrement.

La campagne dynamique en temps réel de Falcon est l'un des moteurs les plus impressionnants jamais créés dans une simulation. Pourriez-vous nous parler plus précisément de sa conception, de ses enjeux et de sa mise en œuvre ?

On m'a donné un joli chèque en blanc dans la conception de la Campagne Dynamique, alors je l'ai abordée comme un jeu de stratégie. L'idée étant que ce jeu serait exécuté dans l'arrière-plan si le joueur a volé ou non des missions. En fait, il pourrait être joué comme un jeu de stratégie à partir de l'outil que j'ai écrit pour le surveiller. L'IA a été divisée en trois niveaux, un niveau stratégique, un niveau opérationnel et un niveau tactique. Un autre niveau d'IA serait utilisé dans la simulation elle-même pour conduire les véhicules ou les aéronefs.

Les missions ont été générées en tant que sous-produit de cette IA et ont en fait utilisé des techniques de planification du monde réel. Par exemple, une fois qu'une liste de cibles prioritaires a été établie, un ensemble de mesures serait élaboré pour la suppression temporelle de la défense aérienne, la supériorité aérienne, le ravitaillement en carburant, les AWACS, etc. Toutes ces missions seraient planifiées à l'avance et planifiées comme le ferait un commandant du monde réel, mais elles ont été générées en réponse aux décisions prises par l'IA de la campagne.

Bien que mon but premier était de faire quelque chose d'amusant à jouer, nous avons eu beaucoup de chance d'obtenir beaucoup de conseils de sources militaires sur la façon dont les choses fonctionnent dans le monde réel et j'ai essayé d'être aussi proche que possible tout en conservant les éléments du jeu qui me semblaient importants. Cependant, tout cela devait fonctionner avec une toute petite partie du CPU, ce qui était une énorme limitation étant donné tout le travail d'IA/planification qui se déroulait. C'était probablement le plus grand défi de ce système.

Comment avez-vous conçu et codé les multiples scénarios ? Comment avez-vous réussi à les travailler sans vous sentir dépassé par l'immensité de ces conflits virtuels ?

Nous avons beaucoup parlé des théâtres que nous voulions utiliser. J'ai fait des recherches sur ce que l'on croyait à l'époque être les futures zones de conflit les plus probables. En fin de compte, nous avons choisi la Corée en raison d'un certain nombre de facteurs. J'ai insisté pour me concentrer sur un théâtre en profondeur plutôt que de faire plusieurs théâtres mal, alors nous avons décidé de faire plusieurs scénarios dans un seul théâtre à la place. Les scénarios s'appuyaient quelque peu sur des situations historiques de la guerre de Corée, mais aussi sur des situations probables compte tenu des déploiements de l'époque. Le plus gros problème avec les scénarios n'était pas de se sentir submergé par eux, c'était de les tester suffisamment pour se sentir à l'aise pour que l'IA complètement non scénarisée soit capable de jouer avec eux de façon réaliste.

Quels ont été les plus gros problèmes techniques que vous avez dû affronter et résoudre dans les autres domaines que vous avez conçus (AI, Multiplayer, Coms, etc.) ?

Le plus grand défi technique pour moi a été de faire tout ce que je voulais avec la Campagne Dynamique dans la partie CPU que nous avions budgétée, qui, je crois, représentait environ 5% du CPU. Pour que l'intelligence artificielle fonctionne vraiment bien, vous devez faire beaucoup de recherche de chemin et de recherche de données, ce qui exige beaucoup de CPU. Il y a donc eu beaucoup de compromis sur la qualité de l'IA à cause de cela.

Coms était l'autre grand défi auquel je participais. Nous avons développé un protocole très économique et avons consacré beaucoup de temps à l'ensemble du concept de " bulle de lecteur ". Cela signifie surtout que les événements qui se produisaient près du joueur étaient envoyés plus souvent et avec un niveau de détail plus élevé que ceux qui se produisaient loin de lui. En dehors de cette bulle, nous avons mis à jour très peu fréquemment et avec des unités dans l'ensemble. Par exemple, un bataillon entier passerait à côté d'un ensemble de véhicules actifs, d'une formation et d'un emplacement. Tout cela n'était que quelques octets de données.

Bien sûr, il y avait aussi beaucoup d'autres défis, y compris simplement l'organisation des différentes composantes. Nous avions en grande partie développé les différents modules de manière isolée et quand est venu le temps de les assembler, cela s'est avéré être la source de beaucoup de problèmes.

De quelle partie de votre travail spécifique sur Falcon 4.0 êtes-vous le plus fier et pourquoi ?

Définitivement la Campagne Dynamique. C'est la première et dernière fois que j'ai pu concevoir et coder une partie d'un jeu par moi-même, ce qui avait été mon expérience en tant que passe-temps jusque-là. Dans le reste de l'industrie du jeu, vous n'avez pas vraiment beaucoup d'influence sur la conception d'un jeu en tant que programmeur. J'étais encore assez vert à l'époque et en y repensant, je peux voir tant de choses qui auraient pu être mieux faites, mais j'en suis quand même très fier.

Certaines parties du Falcon semblent avoir une conception modulaire. Est-ce que c'était prévu ? Pensez-vous aux futurs agrandissements d'avions et de terrains ?

Tout à fait d'accord. En fait, nous avons eu différents avions qui travaillaient à l'interne très tôt, mais faire d'autres avions avec le même niveau de détail que nous l'avons fait pour le F16 n'était tout simplement pas possible étant donné nos ressources. La Dynamic Campaign a d'abord été conçue pour pouvoir être jouée comme un jeu à part entière, mais en fin de compte parce qu'elle est très fortement imbriquée avec le reste du jeu. Les décors de terrain et les théâtres ont été conçus pour pouvoir être facilement échangés contre des extensions futures (nous avions prévu un théâtre en Irak). D'autre part, une partie de cette modularisation est due à l'isolement des différents ingénieurs et est devenue un problème par la suite. Par exemple, trois modules différents ont fini par utiliser trois systèmes de coordonnées complètement différents, de sorte que la communication entre eux nécessitait des conversions.

Il semble que la première version de Falcon 4.0 ait été lancée d'urgence sur le marché pour être vendue pendant les vacances de Noël. Le code était-il assez mature pour cette première version ?

Je suis d'accord que le produit a été livré dans un état assez bogué, mais je ne peux honnêtement pas dire que la première version de Falcon 4.0 a été précipitée. Il a fallu environ 5 ans pour construire et les 9 derniers mois, nous travaillions 12-16 heures par jour (ils avaient réservé un hôtel de l'autre côté de la rue, donc ma femme a fini par y rester pour que nous puissions même nous voir). C'était un énorme défi d'achever ce projet ; c'était un produit incroyablement complexe qui n'avait pas été bien planifié ou géré du tout. En raison de la complexité et du manque de conception centrale, il est devenu très difficile de trouver et de corriger les très nombreux bogues du programme. En fin de compte, nous aurions pu prendre un an de plus et avoir encore des bugs ouverts, mais au bout du compte, il faut les faire sortir. MicroProse saignait de l'argent à l'époque et Falcon avait déjà le stigmate du vaporware, alors à un moment donné, nous avons dû déterminer qu'il était assez bon et ensuite travailler dur pour résoudre les problèmes.

Vous avez également travaillé en tant que programmeur en chef pour les projets de patchs après leur sortie. Quelles étaient vos principales priorités et quels domaines particuliers devaient être fixés ou améliorés ?

J'étais en fait programmeur en chef sur les projets de localisation, mais j'étais impliqué dans le processus de correction. Pour être tout à fait honnête, les priorités consistaient à régler les problèmes qui auraient dû être réglés avant de l'expédier. Comme je l'ai dit, il y avait beaucoup plus de problèmes que nous n'avions les ressources nécessaires pour les régler, mais nous nous sommes attaqués d'abord à ceux qui touchaient le plus d'utilisateurs et avons continué à réduire la liste. Quand je suis parti, je n'étais toujours pas satisfait de la stabilité du jeu, ce qui rendait difficile de le laisser inachevé, mais j'ai réalisé que pour MicroProse cela ressemblait probablement à une fosse à argent.

Ironiquement, le passage à SEGA était exactement le contraire. Nous faisions des jeux d'arcade qui devaient fonctionner sans aucun plantage et qui sont brûlés n'écrivent que sur des puces EPROM. C'était un défi complètement différent que de développer un logiciel qui fonctionnait hors de l'ordinaire et qui était imparable.

Le dernier patch officiel était 1.08. Y avait-il un plan pour de futurs correctifs après cela ? Dans l'affirmative, qu'auraient-ils abordé ?

J'étais parti pour SEGA avant cela, donc je ne sais pas où en étaient les choses à ce moment-là.

Le licenciement de toute l'équipe de développement a-t-il été une surprise ou était-ce un événement prévisible après l'acquisition de MicroProse par Hasbro ?

Eh bien, l'équipe de développement avait déjà été mise à pied plusieurs fois auparavant, de sorte que le concept était déjà assez familier à ce moment-là. J'ai vu l'acquisition par Hasbro comme une chose plutôt négative, alors j'ai quitté pour SEGA avant les mises à pied. Je ne pense pas que cela ait surpris qui que ce soit.

Avez-vous déjà découvert le coût de développement de Falcon 4.0 (environ) ?

Honnêtement, je ne sais pas. Je pourrais faire une supposition étant donné ma connaissance de l'industrie, mais ce ne serait qu'une supposition. Je soupçonne qu'à la fin MicroProse n'a pas fait d'argent sur Falcon 4.0 cependant. Cela ne veut pas dire que les simulateurs de vol ne sont pas entièrement non rentables, c'est juste que celui-ci en particulier avait un coût de développement beaucoup plus élevé que la moyenne.

Vous avez travaillé chez MicroProse pendant longtemps (près de cinq ans). Quels sont vos meilleurs et vos pires souvenirs ?

J'ai beaucoup aimé l'éventail de suggestions créatives qui m'ont été permises là-bas. Rétrospectivement, peut-être qu'une partie de tout cela n'était pas tant permise que supposée puisque je venais de faire des jeux comme passe-temps, mais en tout cas cela m'a permis d'aller construire quelque chose que je pensais être vraiment cool. Malheureusement, c'est précisément cette approche qui a rendu le développement si long et la coordination entre ingénieurs si difficile.

Mes pires souvenirs sont surtout des conflits entre l'équipe et les longues heures de travail. J'étais très jeune à l'époque (le plus jeune programmeur de l'équipe) et j'avais des opinions, je travaillais trop et j'avais un ego fragile, alors les choses devenaient parfois tendues.

De nombreux simulateurs récents sont sortis sans même essayer de coder un moteur Dynamic Campaign. Pourquoi pensez-vous que les développeurs de sims d'aujourd'hui ont si peur de ce que vous avez pu créer il y a plus de dix ans ?

C'est juste très difficile à faire. En y repensant, je pense que la seule raison pour laquelle nous avons pris ce que nous avons fait, c'est parce que nous étions trop inexpérimentés pour en savoir plus. Sachant ce que je fais maintenant, même avec mon expérience sur Falcon, le coût de développement d'un tel moteur serait substantiel. Comme les simulateurs de vol n'apportent pas ce genre de revenus, les entreprises ne voient pas les choses d'un point de vue coût-bénéfice et Dynamic Campaigns obtient des résultats plutôt faibles à cet égard. Il y a aussi l'argument selon lequel les missions écrites sont plus intéressantes, ce qui a un certain mérite. Je pense que si je devais recommencer, je ferais un mélange de missions scénarisées/générées, pour que le joueur se sente toujours comme s'il était impliqué dans le monde, mais il y a aussi de la variété pour garder les choses intéressantes.

En 2000, le code source de Falcon 4.0 a fait l'objet d'une fuite et après cela, des groupes de volontaires ont pu apporter des corrections et des améliorations qui ont assuré la longévité de cette sim. Voyez-vous la fuite du code source comme un bon ou un mauvais événement ?

Absolument un bon événement. En fait, j'aurais aimé savoir qui l'a fait pour pouvoir les remercier. Je pense honnêtement que cela devrait être la procédure standard pour les entreprises qui décident de ne pas continuer à soutenir un code de base.

Je sais qu'après MicroProse, vous êtes passé à d'autres opportunités et à d'autres rôles importants. Mais si on vous le demandait, envisageriez-vous toujours de travailler sur une simulation de combat moderne ?

On m'en avait parlé il y a quelque temps et j'avais manifesté de l'intérêt, mais l'équipe était en train d'être formée au Colorado, je crois, et je suis assez liée à la région de la baie de San Francisco à ce stade-ci. Je ne suis pas intéressé du point de vue d'une simulation de vol (en fait, je ne les joue pas), mais je le serais du point de vue de Dynamic Campaign. Je suis beaucoup plus intéressé par l'aspect stratégie/monde persistant de tout cela.

Vous travaillez actuellement comme directeur technique pour Gravity Bear et vous développez des applications très intéressantes. Pouvez-vous nous parler de votre travail sur les projets en cours et à venir ?

Je travaille actuellement en tant que directeur technique pour Electronic Arts, sur des projets Sims (les Sims, pas des sims de vol). Gravity Bear est une petite entreprise que nous avons créée pour faire des jeux Facebook, et j'y ai travaillé pendant environ 2 ans. Toute l'entreprise ne comptait que 6 personnes et pendant une grande partie de cette période, j'étais le seul programmeur. J'ai participé à quelques autres tentatives de démarrage, en grande partie parce que j'adorerais travailler sur des jeux auxquels j'aurais vraiment plaisir à jouer et qu'une grande partie de ce que font les grandes compagnies ces jours-ci ne sont que des remakes de vieux concepts, mais j'ai aussi une famille à soutenir, donc la stabilité d'une compagnie comme EA et des titres solides comme'The Sims' est très attractive.

Cougar FFW04
Chef de patrouille
Chef de patrouille
Messages : 4934
Inscription : 20 janvier 2002

Re: Interview de Kevin Klemmick / Lead Software Engineer de Falcon


Message par Cougar FFW04 » jeu. janv. 31, 2019 2:31 pm

Très intéressant
La grande époque pour un grand simu.

Avatar de l’utilisateur

Pilote Philanthrope
Pilote Philanthrope
Messages : 2706
Inscription : 13 août 2008

Re: Interview de Kevin Klemmick / Lead Software Engineer de Falcon


Message par BadJack » mer. mai 15, 2019 7:09 am

Un petit déterrage pour dire qu’effectivement, ça mérite d'être archivé ici !

Merci Flow :notworthy


CARTE MERE ASUS Z97-DELUXE - 16 Go - Core i5 4690 K - CG ASUS GTX 980 TI + GTX 660 TI- COUGAR FSSB1 - TRACK IR 4 -WINDOWS SEVEN 64 et ...un Pit de placard couloir.

Revenir à « Falcon 4.0 BMS »