Динамическая онлайн-кампания.

[Valery Blazhnov]

Valery Blazhnov

 

Вообщем я больше говорил про начальный этап и иерархиикак таковой пока не коснулся, но можно ли на начальном этапе смоделировать это как в "разорворксе" ?? Т.е. у нас вся иерархия пока сводится лишь к взводам отдельным юнитам. Скажем взвод танков -- 3 танка на карте светится одним ярлык (можно с маленькой циферкой, указывающей на количество).

 

Далее, если так глобально подумать, то нужна ли нам такая огромная иерархия(с множеством генералов, командуемыми ими дивизиями, полками и батальонами), если всё пока будет банально сводиться к передвижению юнитов, что вообщем без особого труда может осуществить один игрок. Этот вопрос возможно встанет ребром в сетевой игре, но на начальном этапе, ИМХО, это не так актуально.

 

ЗЫ Можно провести интересную параллель между реальным управлением армией и игрой в "стратегический симулятор" (можно я закопирайтю данный термин? :D ) --- в идеале реальное управление как раз стремится к такому вот централизованному управлению(аналог игрока, сидящего за компом и отслеживающего передвижение своих войск и изменения положения на электронной карте боевых действий), при этом каждый участник баталий будет видеть расположение своих воюющих объектов и разведанных объектов противника, тобишь это отметает необходимость многочисленных докладов по устаревшим радиостанциям вышестоящему командованию о продвижении или потере сил нижестоящими командирами взводов/батальонов/дивизий. Т.е. все сразу видно на одном экране. Имеет ли смысл симулировать те самые многочисленные иерархические ступени? Думаю что нет :)

На начальном этапе огромная иерархия, конечно, не нужна, она может быть совсем примитивной. Только вот, в реале она вовсе не стремится к малоэффективной централизации (не царское это дело - юниты двигать), а ищет разумный баланс между централизацией и децентрализацией, исходя из интересов иерархии в целом. Хорошо сбалансированная иерархия гораздо лучше развивается как в отдельных своих узлах, так и в общем, именно поэтому она более перспективна и для реализации симулятора, который намеревается более или менее реалистично моделировать аспекты управления войсками. Если мы с самого начала заложим продуктивную реалистичную концепцию в основу реализации, то нам будет гораздо легче в постепенном развитии данного направления. Если же мы сразу пойдем по пути привинчивания костылей, то уже через две-три итерации зайдем в тупик борьбы со сложностью развития и, в очередной раз, угробим все направление.

[Valery Blazhnov]

(1) One of the most serious issues is the development of the map objects. Lock On has an awkward map for a dynamic campaign - the best missions are in Georgia, but there is very little Georgian terrain and airbases - just Abkhazia. The detailed portion of the map is also a strange shape, not rectangular. Electricity generating stations and other industrial targets are present, but in many cases in Caucasian terrain, they don't correspond well to reality. Also, the addition or removal of map objects can change the numbering of existing objects, which makes old missions (and mission-generating software) need to be carefully updated. Can we ask about plans for the map and make suggestions - or, it's a developer's secret topic? I understand it's a very difficult and time-consuming part of the simulator, but also very important.

Согласен абсолютно. Для кампаний масштабы и инфраструктура театра военных действий имеют решающее значение. Мы намереваемся развивать и то, и другое. К сожалению, пока что это получается у нас очень медленно, но мы будем искать возможности для ускорения разработки в данном направлении.

(2) To allow the simulator to be run with command-line arguments, to suppress the Main Menu or other parts of the user interface. For example,

 

c:\lockon -m c:\missions\campaigns\mission1.cmp

 

starts Lock On, but skips the Main Menu and Briefing/Editor/Map screens to start the mission directly, as if the user pressed "Fly". or,

 

c:\lockon -bd c:\missions\campaigns\mission1.cmp c:\missions\campaigns\mission1.cmp

 

starts Lock On, but skips the Main Menu and file selection screens to jump directly to the briefing and editor/map view, as if the user chose to "open" the campaign mission "mission1.cmp". When the user exits the mission, the debriefing results are saved to the file "mission1.cmp", and Lock On exits.

 

(3) To allow .mis mission files to save the debriefing results, similar to .cmp campaign files

 

(4) To allow airbases to have nationality, even without assigned aircraft.

 

(5) Inclusion of additional computer-controlled units, which would be important in a real campaign:

- F-15E (USA)

- UH-1 helicopter (USA, Georgia, Turkey)

- S-75 SAMs (Georgia)

- T-72 tanks (Ukraine, Georgia)

- anti-tank ATGM ground soldiers

- "occupied building" units that shoot guns at ground soldiers, ATGMs at ground vehicles and RPGs at helicopters

- "Bora" missile boats (Russia)

- Hetman Sagadachniy (Ukraine)

- Matka missile boat (Georgia, Ukraine)

- EA-6B and Su-24MP ECM aircraft (USA, Russia, Ukraine)

- Be-12 (Russia, Ukraine)

- Harrier (UK, Spain)

- unmanned aerial vehicles (reconnaisance)

- radar decoys (similar to cruise missiles, they can also be launched from B-52 bombers)

 

(6) To allow cruise missiles (and radar decoys) to be given a flight path independently, so that it starts the mission already flying separate from any launching platform

 

(7) To allow cruise missiles and helicopters to be given "landing" waypoints on any terrain

 

(8.) to allow helicopter "landing/stopover" waypoints on terrain to be assigned a time duration, and to have additional flying waypoints afterwards. This can simulate missions where the user must escort the helicopter to deliver soldiers or supplies to a remote location, or to pick up ejected pilots.

 

(9) To allow such landings and takeoffs to be evaluated as part of the mission "success/failure" criteria

 

Hmm, enough for one message... :)

 

-SK

Мы подумаем. Я мог бы, со своей стороны, добавить еще несколько пунктов, однако будет лучше, если мы просто реализуем их в следующих версиях симулятора.

 

Возможно, что нам не следует в обсуждениях перспектив динамической кампании предполагать неизменным текущее понятие миссии, как файла, полностью определяющего всю обстановку. В конце-концов, реальная миссия - это всего лишь частный боевой приказ. Я предлагаю рассматривать динамическую кампанию, как единый процесс моделирования боевых действий в модельном времени, на который игроки могут повлиять выполнением различных персонажных ролей в рамках предоставленных симулятором должностных полномочий и способами, предусмотренными реализацией.

[Mayh3M]

2 SwingKid

Georgians have only a few of old T-72's... better replace T-72 with T-55A... anyway, I have an idea about tanks :roll:

 

2 Valery Blazhnov

Есть ещё небольшая идея упрощённого управления -- помните старую игрулю такую -- M1 Tank Platoon 2 ?? Там кстати очень неплохо реализовано тактическое управление даже на сегодняшний день, несмотря на то, что игра-то уже очень старая --- всё сделано чрезвычайно просто и в то же время функционально. Можно на начальном этапе сделать также (собственно может велосепид заново изобретать и не придётся) :roll:

[Valery Blazhnov]

2 SwingKid

Georgians have only a few of old T-72's... better replace T-72 with T-55A... anyway, I have an idea about tanks :roll:

 

2 Valery Blazhnov

Есть ещё небольшая идея упрощённого управления -- помните старую игрулю такую -- M1 Tank Platoon 2 ?? Там кстати очень неплохо реализовано тактическое управление даже на сегодняшний день, несмотря на то, что игра-то уже очень старая --- всё сделано чрезвычайно просто и в то же время функционально. Можно на начальном этапе сделать также (собственно может велосепид заново изобретать и не придётся) :roll:

Давайте дождемся какой-нибудь нашей реализации на данную тему, а потом уже будем сравнивать и оценивать более предметно. Возможных направлений начального развития очень много. Мне сейчас самому трудно предсказать, что получится на начальном этапе, поскольку это от многих объективных и субъективных факторов зависит. Одно можно сказать определенно: одной итерацией мы здесь не обойдемся, нас ожидает длительный процесс развития от версии к версии. Наверное, это само по себе и неплохо :)

[SwingKid]

Возможно, что нам не следует в обсуждениях перспектив динамической кампании предполагать неизменным текущее понятие миссии, как файла, полностью определяющего всю обстановку. В конце-концов, реальная миссия - это всего лишь частный боевой приказ. Я предлагаю рассматривать динамическую кампанию, как единый процесс моделирования боевых действий в модельном времени, на который игроки могут повлиять выполнением различных персонажных ролей в рамках предоставленных симулятором должностных полномочий и способами, предусмотренными реализацией.

 

It's not necessary to invent the mechanics of a "theater" wargame from nothing - there exists a long tradition of 100 years of this genre, which we can study. Such games are generally divided into three categories - "tactical", "operational", and "strategic".

 

The "strategic" wargame emphasizes logistics more than any other element, and usually requires a very large map with entire opponent countries. If we will now consider the flight simulator as a form of real-time "tactical" wargame, then maybe we should look now instead, to expand in the direction of the median "operational" level.

 

Examples of such games that currently exist at this level include "The Operational Art of War". They are not played in real-time, but are rather "turn-based" - the game is played on a board map divided into hexagons, the opponents take turns moving and using units, and there are established rules for line-of-sight aiming and shooting at opponents, and often a simple model of logistics. Such games evolved after many years and we should not try to dramatically change the formula, at the same time as we try to make the dramatic step of integrating operational-level warfare into a flight simulator.

 

If this is really a serious goal (and I should say that I don't agree, that flight simulator potential has itself yet been exhausted ;) ), then I can only imagine it like so: to combine the turn-based operational warfare with the real-time flight simulator. The operational decisions are made between the missions. The user then plays both roles - operational commander before and after the mission, and pilot during the mission.

 

To create a game that will function dynamically or in the single-player mode, there are now required two levels of artifical intelligence (AI) - unit AI during the mission, and operational AI between missions. The operational AI model should be based on the existing AI models of operational wargames - how to advance forces, where to put headquarters and artillery, etc. We are now developing practically two games, for the price of one. It's really a serious idea?

 

If yes, then the most significant challenges that I see:

 

(1) To create a map that is divisible into hexagons for the operational AI to understand between missions, yet still retains "photo-realism" for the flight simulator,

 

(2) To somehow balance the game model, so that the flying tactical missions of each opposing side occur together simultaneously (so that there is interesting air combat instead of flying in empty air), with a good balance between the operational and tactical phases of the game, and

 

(3) To create an entirely new AI for the operational decision-making, probably based on such war-games that already exist.

 

What do you think, it makes sense? For some time, I have been struggling to understand how to envision such a colossal challenge as you describe..

 

-SK

[OTV_Ashot]

На мой вгляд так же можно исходить из существующего разделения на командующих и исполняющих. Таким образом, исполняющему пилоту (оператору ДРЛО) для своей же эффективности в миссии нет необходимости знать все детали стратегического планирования. С другой стороны командующий не может в полной мере ориентироваться в масштабе отдельных миссий. Поэтому мне кажется нужно разделить эти две роли по идеологии клиент-сервер. Т.е. сервер выполяет стратегической управление, будь-то по-ходовое исполнение или в реальном времени (по сути отдельная игра, со своим планированием ресурсов и пр.), в каком-то смысле "сервер" может быть игрой сам с себе. Однако, он может, также в кач-ве ресурса использовать реальных (не ИИ) исполнителей (онлайн), поручая таким образом, задачу в человеческие руки (со всеми результатами и последствиями). Для этого, тот же сервер может иметь ряды "служащих", рекрутов и пр., с соотв. раногм и квалификацией. Можно для простоты вести "очередь" исполнителей. Исполнитель, получив приказ, сгружает конкретную миссию, с указанным временем ее начала. Далее как в обычном случае успех/провал, зачет/незачет. Таким образом каждый несет ответственность в _своем деле. Для поддержки осведомленности состава можно вести службу фронтовых новостей с этого сервера :).

 

В этом случае стратегия становится отдельным модулем, и вопрос разделяется на отработку интерфейса между существующим ЛО и стратег-сервером, и собственно реализацию последнего. Загрузка распределяется равномерно по требованиям, учитывая, что тактические миссии требуют большего быстродействия в силу своей динамики.

 

В каком-то смысле эта концепция созвучна с SwingKid's генератором миссий. В то же время серверную часть можно строить на базе известных стратег-моделей.

 

Опять таки эта идея основывается на том, что есть желающие играть в стратегию при этом приглашать других на "самую интересную" :) роль. Но главное, решается вопрос организации, личного предназначения и ответственности, ведь далеко не каждый [мечтающий] _решится быть генералом.

[SwingKid]

Попробовал считать карту, чтобы найти как минимальной трудности доработать и создать хорошую основу для кампании.

 

 

The "active portion" of the map is centered on Abkhazia. Two conflicts can be modelled: (a) the historical Abkhazia conflict of 1994, or (b) a conflict in the near future.

 

The conflict is "officially" between Georgian federal forces and Abkhaz separatists. The separatists receive support from Russia, and Georgian forces receive support from USA, but since these countries are not "officially" at war, their long-range SAMs and interceptors are not based inside Abkhazia - only ground forces. So, each mission would have small numbers of aircraft, and most missions would start from bases in friendly, well-protected "safe areas" outside Abkhazia.

 

It is a "low-intensity" conflict, and the ground armies advance very slowly through the villages of Abkhazia. Players may be assigned to conduct attacks against targets outside Abkhazia, but the front line of ground forces would always stay inside Abkhazia from the beginning to the end. Georgian forces have no plan to invade Russia, and separatist forces are not interested to invade Georgia.

 

The role of the map outside of Abkhazia is to provide logistical support for ground forces inside Abkhazia. So, attacking railways stations and bridges in Russian or Georgian territory can have an effect on the war.

 

There should be "rules of engagement" to control the intensity of the conflict. At the beginning - only military targets inside Abkhazia are attacked. If there is "collateral damage" against civilian targets, then attacks on bridges, airports and railway stations begin. At a higher level, strategic attacks against the oil industry at Novorossiysk and Batumi may occur far away from Abkhazia.

 

As minimum, the map should be expanded to include the red zone. This relatively small area would provide three of the five largest cities in Georgia, several important Georgian airbases, the oil industry at Batumi, and the Georgian navy port at Poti. The existing brown zone should also be edited for correct placement of electricity stations and oil industry targets, and to provide necessary road connections into and out of Abkhazia through the Caucasus mountains.

 

If time remains after completing the red zone, the violet zone should be included to provide a Turkish NATO airport (Trabzon), and to provide a southern "limit" to the map for Russian aircraft. It's a significant area, but with little content.

 

If time remains, the green zone should then be considered, to make the map rectangular and provide a northern "limit" for US and Georgian aircraft. The extra cities and bases would compensate the Russian player for the problem that most Russian airbases (yellow and green dots) are distant from Abkhazia. It also provides room around Abkhazia for placing defensive long-range SAMs, without making the air over Abkhazia itself unsafe for CAS aircraft.

 

As the normal map is expanded, the data about cities, roads, and strategic objects should be added to an independent database that is developed in parallel, and used by an automatic mission generator. Ground forces can be moved by the user from one discrete strategic location in the database to another between missions, without the need to place objects on the map. Larger cities can "hold" more ground forces than smaller villages. The locations of hills and mountains can be stored in the database as good locations for SAMs or artillery.

 

I think, my previous suggestion to use a "hexagonally-divided" map was inappropriate for a flight simulator... so, I search for a way to use the existing map.

 

-SK

[Dmut]

...

The conflict is "officially" between Georgian federal forces and Abkhaz separatists. The separatists receive support from Russia, and Georgian forces receive support from USA, but since these countries are not "officially" at war, their long-range SAMs and interceptors are not based inside Abkhazia - only ground forces. So, each mission would have small numbers of aircraft, and most missions would start from bases in friendly, well-protected "safe areas" outside Abkhazia.

...

Good background story, quite realistic btw. Looking forward for your next releases.

[SwingKid]

Thanks!

 

The idea is for the campaign "database map", which is used for the movement of ground units, to be separated from the "editor map", which is shown above, and is used for aircraft.

 

The "database map" could be made much smaller. It would consist of points, and connections between the points. For faster development, it can be made from a small section of the editor map:

 

 

The points can be population centers, airports, or other strategic locations. Each point in the database has attributes which indicate which side controls it, how many soldiers are there, how many soldiers can be supported, if there are civilians, how many vehicles, how much fuel and ammunition, and if there is electricity and heat.

 

Each connection between points also has attributes. It may be a large road, small road, pedestrian trail, railroad, a route for transport aircraft or helicopters to land or drop supplies, a port or oil terminal for ships, a suitable beach for amphibious assaults, a river for small boats, a pipeline for oil or gas, an electrical connection, or any combination of these.

 

Depending on the capabilities of the connection, it may be possible for the "commander" to move soldiers, weapons, electricity, fuel, and ammunition to different friendly connected points on the map between missions. Some connections (e.g. roads) may be used to invade enemy points, others (e.g. helicopter routes) may be used only to provide supply resources to friendly points. Destruction of bridges can temporarily break road and railroad connections.

 

Developing the campaign "database map" according to a separate model from the "editor map" helps to provide additional freedom - new points and connections can be added or removed according to available project time, without making complex changes to the editor map. It is even possible to make a separate "Crimean" campaign using the same system and the same editor map, by simply changing the database of points and connections.

 

-SK

[Dmut]

hmm, this looks like a interesting and quite a serious project.

 

It could be difficult to develop an AI that can do resources management with all these kind of resources and routes, but at fisrt stage you can implement a man-to-man gameplay - two players will handle their resource management, secretly from each other, then both side will get a mission to fly, and then programm will calculate a new resources map, accoding to players resourse management actions and mission results. This gonna be a fun!

 

So, let's do some classification:

we have a resources heaps: like cities, military bases, airfields.

we have a resources types: population, military vehicles, airplanes, gas&oil.

we have a routes, which connect resources heaps: roads, railroad, rivers, pipelines, air-route (transport planes or copters).

 

Objects like bridges comes along, since their destruction eliminate not resources heap but route.

 

Routes like rivers and some air-routes, seems to me, should be counted as undestructable.

 

Destruction or taking over an airfield will create both a resouces loss and route (air-route) loss.

 

Player's turn will consist of 3 phases: he will manage resources, he will choose a mission to fly, and, finally, mission itself.

 

Looks great!

 

And you dis right, when decided to separate resources map from current LO map - it's will simplify migration from LO to next ED's project.

 

I'm very interested in your project, SK. I wish to take part in it.

 

Regards , Dmut.

[Mayh3M]

This is going to turn to the real war simulation! :D And you know guys -- I really like it! :D

 

Resource and command AI-management could surely overload the CPU's -- the progress of science seems to be far behind from PC-Games developers requests :D

 

By the way -- what's about air-(big planes, like IL-76MD) and sea-cargo transportation? Could it be also some routes for them? And I also thinking about some kind of "main base", where are the all resources should appear in worst quantity, than we should have on conquered territories :roll: (let's think, that it is the outland investment from allies). Those I think seems to be enough for start...

[SwingKid]

It could be difficult to develop an AI that can do resources management with all these kind of resources and routes, but at fisrt stage you can implement a man-to-man gameplay - two players will handle their resource management, secretly from each other, then both side will get a mission to fly, and then programm will calculate a new resources map, accoding to players resourse management actions and mission results.

 

I prefer to develop features in parallel. To develop a complex two-player campaign system, without designing AI for a computer-controlled player from the very beginning - it creates a situation similar to Lock On development, with excellent flight model and avionics, but no dynamic campaign. Attempts to later add something completely new, to an already complex project, are very difficult and often fail. Fundamental mechanisms should be present at the very beginning, and later only details added.

 

In my opinion, it's possible to start with a simple model, and then grow. For example: only "road" connections, and only "soldier" resources. Then, to teach the AI how to move soldiers between points by using the roads. Then, to add railroads, and ammunition resources, and teach the AI how to use those, and so forth. If only the "roads and soldiers" level of complexity is finished within the time before release - already, it's better than nothing. But to say "I will do this now, and that later" - it creates danger that "this" will never be finished, and "that" will never be started.

 

So, let's do some classification:

we have a resources heaps: like cities, military bases, airfields.

we have a resources types: population, military vehicles, airplanes, gas&oil.

we have a routes, which connect resources heaps: roads, railroad, rivers, pipelines, air-route (transport planes or copters).

 

For an Abkhazia campaign, I would add some strategic "heap" objects:

- Inguri dam electricity station at Jvari

- Coal mines at Tkvarcheli (contains ammunition)

- Artillery position on Mount Zegan, north of Sukhumi

- Russian "seismological laboratory"

 

For "resources", I would start with soldiers and ammunition, instead of vehicles and oil. Abkhazia and Georgia have some vehicles, but the real fighting involves more soldiers and buildings.

 

A simple "roads and soldiers" network allows us to consider towns as "containers" for hidden soldiers, without making it necessary to create 3D models for the soldiers themselves. Destruction of the correct map object buildings results in the reduction of enemy soldiers. Untargetted buildings may contain civilian population, friendly soldiers, or nothing. A large city can "contain" more soldiers than a small village, and therefore have a natural higher value to the campaign.

 

Player's turn will consist of 3 phases: he will manage resources, he will choose a mission to fly, and, finally, mission itself.

 

This is a good consideration. How should the user interface be, for moving resources from one point to another? Clicking on points on the map? Using menus? Pressing keys or typing commands? We should propose the most efficient way for the user to accomplish these tasks.

 

I'm very interested in your project, SK. I wish to take part in it.

 

Thanks, but it's not really my project. Rather, I try to imagine and understand some concepts that Valery proposes. Probably he has himself many ideas, but he is very busy with v1.1.

 

It's a good design for the ground war, but to make it work with a flight simulator would require more Georgian territory and airbases. So, my own "SkyWars" project uses a different strategy - not points and connections, but rather zones and boundaries. And, it uses the whole Lock On map. This discussion is something different. I try to help ED create a good new design, which allows them to immediately begin expansion of the existing map, without fear of necessarily replacing all work in the near future. As Valery agreed, the whole campaign design rests solidly on one question: What will we do with the map? Expand the existing one, or replace it with something new? The map is in many ways the first and biggest part of the project, and I have no ability to change it myself.

 

Resource and command AI-management could surely overload the CPU's -- the progress of science seems to be far behind from PC-Games developers requests

 

Well, if we start with a simple "soldiers and roads" system, we can add features slowly and observe what the AI can manage, and what not. Since such ground-war decision-making would occur between missions, it doesn't need high speed performance.

 

By the way -- what's about air-(big planes, like IL-76MD) and sea-cargo transportation?

 

Air transport may be more interesting to include as something that occurs during the mission, instead of between missions. What do you think?

 

And I also thinking about some kind of "main base", where are the all resources should appear in worst quantity, than we should have on conquered territories (let's think, that it is the outland investment from allies).

 

It's why I included Adler, Zugdidi, Jvari and Teberda towns outside of Abkhazia on the map. Maybe air transport into the combat zone (e.g. to Sukhumi) should occur during the mission, but air transport to the "main base" (e.g. to Adler) should occur between missions?

 

Also, I would like for there to be some organization for the ground units, with mobile headquarters at one or more points. The user can decide where to move the headquarters. Putting the headquarters near friendly soldiers should provide a combat advantage, and destruction of the friendly headquarters should cause the soldiers to fight less efficiently. The mobile headquarters can act as a distribution hub for resources - for example, ammunition must reach the mobile headquarters first (e.g. by railroad), before it can be distributed to fighting units (e.g. by road). Losing the headquarters causes ammunition to be distributed randomly and inefficiently. This can provide some dynamic modelling of logistics.

 

Those I think seems to be enough for start...

 

From my experience with SkyWars, I would consider some other basic user interface questions...

 

- How many points or resource "heaps" should there be for each side? It's related to the question:

- How many missions should be necessary as minimum, to finish a campaign?

- Should the user command only the logistics, with ground units automatically invading and retreating according to their strength? Or the user should be able to initiate ground assaults on command, independent of unit strength?

 

Thanks for your interest!

 

-SK

[SwingKid]

Для сравнении, здесь шот похожего ДК Фалкона 3,0 в Кореи, работает на компьютере 486 - технология 1991 года:

 

 

-SK

[Mayh3M]

Well, if we start with a simple "soldiers and roads" system, we can add features slowly and observe what the AI can manage, and what not. Since such ground-war decision-making would occur between missions, it doesn't need high speed performance.

Agree!

 

Air transport may be more interesting to include as something that occurs during the mission, instead of between missions. What do you think?

I'm still positioning to make the whole campaign as one big continuious mission. So the air transport and supply support could be AI-generated(for example, AI spots the far-out base's resoureces and ammo low and send there the air cargo plane which drop down with parashute some ammo) and, as the best way, could be optional, when player want to give the orders to suppluy units by himself... This kind of mission processing should be much easier(as I think) to simulate, than divide everything to X-number of missions and between these missions generating the results... :roll: