My take on a dynamic campaign

[Bluestream]

Hi everyone!

 

I want to share a little project I'm working on - a sort of dynamic campaign, at least it's a start I guess.

 

I'm creating this thread to share some of my ideas and explain what I'm currently doing. I think it will help keep myself motivated and hopefully I'll get some ideas from all of you as well.

 

Plans for the first release

 

My plan with this is to try and keep things simple to start with to have something release-ready as soon as possible, and then to keep improving it from there. That means that this will not even be close to as in-depth as the F4 campaign, or any other dynamic campaign that we imagine, anytime soon, if ever.

 

These are some things that I'm hoping will be in the first version:

 

• All living units are persistent between missions. (Does not yet include damage, loadout, ammo, wrecks, static objects)
  
• The campaign is run by an external application that will be running alongside DCS throughout the mission.
  
• I'm going for "bubble" around players approach, I believe this is the only way currently. What I mean by this is that enemies close to you will be spawned within the DCS world and the rest will be simulated by the external application.
  
• I'm focusing on A2G first, since I like to fly the A-10C.
  
• Capturing airfields will be the objective and is probably done by destroying most enemy forces in the area.
  
• Each coalition will have a set maximum amount of units the can be on the battlefield at once. Units spawn at a set position and will have to move from there, so no instant reinforcements.
  
• Each coalition has an AI that makes large-scale decisions. For now it will be able to send AI units to capture or defend airfields.
  
• Some kind of basic task/mission generation.
  

 

This may seem a bit lacking, but I think it's important to limit the scope to avoid ending up bored with slow progress. I would prefer being able to release something playable (even if it won't be fun at all) that can be improved, rather than trying to do too much at once and giving up.

 

Current status

 

Right now what I've got working is an external application that is able to communicate with DCS over TCP (during the mission) to track units, spawn/despawn units in the DCS world depending on player position and set basic tasks for units. I have also started developing a pretty simple AI that can make decisions on where to send units based on a few input parameters.

 

For the technically inclined, here's a short description of the three major parts in this project.

 

An external application

 

The external application is written in C# using .NET (because I know it well and therefor it allows faster development by far compared to Lua for me). When started it sets up a TCP socket that waits for DCS to connect to it. When a DCS client has connected it will request some static data from DCS. This includes airbase locations and trigger zone locations. It will also receive messages containing group data (positions, unit types, current tasks etc for all unit groups that are spawned in DCS). The applciation also tells DCS to spawn or despawn units depending on player position. All communication is done using JSON messages since there are good parsers available in both .NET and Lua. In theory this could be running on the same computer as DCS or another computer, it wouldn't matter, but for now I see no real reason to run it on another computer.

 

Lua script

 

The Lua script is run by the DCS mission and will handle all requests sent from the .NET application. It can currently, spawn/despawn groups, get group data, forward some events, get airbase/trigger zone data and send/receive messages to the external application over TCP using LuaSocket.

 

An HTML5 interface and REST API

 

This is basically just a WebGL application that currently draws a map with markers for airbases and markers for units. It can do this by using the REST API that is exposed by the .NET application. It currently does nothing that the built-in DCS map doesn't do better (except it shows units that aren't spawned in DCS, which may become handy for debugging in the future I guess). If I decide to continue down this road in the future this will be the campaign UI. Since it's web-based, this UI can be accessed from anywhere you wish.

 

This may seem like a weird thing to do, but I'm also using this project as a way to learn a couple of new things, web development is one of them.

 

Thanks for reading!

 

When I feel ready to, I'll put it up on github.

 

I appreciate any thoughts you may have on this, hopefully it seems interesting, and if not at least I think I got some clarity of my own thoughts by writing this.

[Rafal]

I don't know who you are, but i'll find you and hug you ;)

[ESAc_matador]

I don't know who you are, but i'll find you and hug you ;)

 

Looks great!

[Rangi]

Sounds promising, keep at it.

[mwd2]

How big is your bubble?

[Bluestream]

How big is your bubble?

 

I'm not sure yet. I'm also thinking that maybe it doesn't need to be a bubble exactly. Spawning the 'x' closest units to the player could also work and may be better, if it doesn't cause too much trouble with the simulation. Ultimately it'll (size or spawn range) depend on number of AI. Lots of AI = needs shorter range, small amount of AI = range can increase.

[ESAc_matador]

Good luck! Very interesting concept!

[Kayos]

Cool, I wish you luck!

[FSFIan]

Hey Bluestream,

 

if you want an improved map for your web-based UI, take a look at this thing I made a while ago:

http://dcsmap.a10c.de

 

It's using the excellent OpenLayers JavaScript library, but since the map data uses the same tile format as major map services (e.g. Google and Bing), it should be usable with most libraries that are meant to display a map on a web page.

 

If I dig around a bit, I am sure I can find the code I used to export the data and make one for NTTR as well eventually.

 

I'd love to get in touch with you on TS or Skype some time (PM me if you are interested). Two years ago, I spent a lot of time exploring the feasibility of something that went in a similar direction (dynamic air-to-ground campaign). In fact, that is what got me into DCS scripting in the first place (one of the first things I built was DCS Witchcraft). Then I started building DCS-BIOS and that took up all of my DCS tinkering time.

 

A dynamic air-to-ground campaign is still something I desperately want to exist. While I can't commit a lot of time, I'll gladly contribute in whatever way I can.

[Bluestream]

Thanks to everyone for the encouragement.

 

Ian;2880272']Hey Bluestream,

 

if you want an improved map for your web-based UI, take a look at this thing I made a while ago:

http://dcsmap.a10c.de

 

It's using the excellent OpenLayers JavaScript library, but since the map data uses the same tile format as major map services (e.g. Google and Bing), it should be usable with most libraries that are meant to display a map on a web page.

 

If I dig around a bit, I am sure I can find the code I used to export the data and make one for NTTR as well eventually.

 

I'd love to get in touch with you on TS or Skype some time (PM me if you are interested). Two years ago, I spent a lot of time exploring the feasibility of something that went in a similar direction (dynamic air-to-ground campaign). In fact, that is what got me into DCS scripting in the first place (one of the first things I built was DCS Witchcraft). Then I started building DCS-BIOS and that took up all of my DCS tinkering time.

 

A dynamic air-to-ground campaign is still something I desperately want to exist. While I can't commit a lot of time, I'll gladly contribute in whatever way I can.

That map looks really interesting. Just out of interest, how did you get the data for it? If you've explored the possibility of an A2G campaign a bit before, maybe you're aware of some of the pitfalls along the way. I'll make sure to send you a PM.

 

On another note, I've been reading up on (the basics of) AI and common design patterns around that, and I'm implementing a variant of Goal Oriented Action Planning. It seems easy enough to understand and so far isn't too hard to implement.

 

I found a pretty good explanation of it here if anyone's interested: http://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793. The exact implementation I believe has a few problems, but it explains the method very well.

 

Currently I have a red and a blue side spawning units and fighting over a few objectives, marked as zones in the mission editor. The zones are captured when only one team is present within and ownership is tracked by the external application. Zone ownership is not visible in game yet, but they AI do respond to it, they won't send units to a zone they already control.

 

I'm struggling a lot with the pathfinding of the AI right now, they seem to get stuck all the time due to buildings and bridges etc. For example, I cannot get a group of 4 vehicles to move from Kobuleti to Batumi off road without getting stuck. Anyone else seen similar things? I'm not sure if going on road will solve anything since units will probably be spawned in pretty random locations if they have been simulated, so they have to be able to go off road without getting stuck sometimes. Going to have to think about this for a while.

 

Next up after that is simulating the same thing when units are not spawned in (if the player is too far away). Doesn't sound too hard but there are a few things I need to account for, like making sure they do not attempt to cross the ocean to get where they're going. I'll try to keep it as simple as possible though.

[FSFIan]

The map data was exported by calling land.getSurfaceType() for every single pixel in every single tile. Took about a week of running the export script whenever I was not otherwise using my desktop PC to get all of the zoom levels finished.

 

Buildings were located with world.searchObjects(). I exported a list of all their anti-collision bounding boxes to a JSON file, then used some kind of GIS software (can't recall the name right now) to convert the vector data to bitmap tiles, as drawing a few thousand rectangles at once from vector data is too much for a browser to handle.

[Pikey]

Pathfinding and spawning objects can be fraught. Its going to be a challenge spawning a lot of things in and out with a bubble approach but its where this will lead.

 

Have a look at Daws for saving objects. That saves all the units to a new mission file. Your engine needs to consider persistence and rebooting and saving the state.

 

I was going to do a campaign based on grids and areas. Those are fairly easy to do in scripting and i already had and engine that could track ownership of an area to an offline file. Its a simpler variant of blue flag where key areas are captured and spawn in or out defenses and boot up the map on load to show ownership.

 

However that might have been the pretty part and not wanting to be negative but the key to a good campaign is not just that front face but a decent logistics system and i couldnt get that nailed. Warehouses in game dont really lend themselves to a logistic sysyem that deals with units. We need that because DCS hates more than a certain amount of units in play. Its going to be less than the 200 mark and not too many moving. So logistics and delivery and capture of warehouses and virtualising that seems to be the way to make a persistent campaign have some legs on it. You dont want it to be just fly bomb tanks and rtb else its boring. You need to have strategic elements like deep strike and interdiction to to stop the other side building an advantage.

 

Wish you luck. Ive known lots of people with the same ambition. You should talk to them as there are some fundamental limitation of the game engine that can derail these beautiful dreams and hard work.

[chromium]

I'm also working on a ground dynamic campaign, and I'm writing now the decision making process for the units movement. As I wanted it to work completely inside the SSE, I won't have a proper graphic overlay for showing terrain ownership (I can see it in testing by dumping tables). It's structured like DCS like... functions & tables. Due to the fact that I won't make a load for the computer running the mission each function works as a state machine evaluating 1 entry table at each time: you can define how much entry/seconds you want to evaluate, and this way works pretty well in keeping the system not that busy. I suggest you to move in the same direction for inner sim calculation (if there are).

 

The Idea is to automatically save & re-load the mission every "n" hours (3, 6 or 12 at the moment) using DAWS Save Mission module.

 

This system is very simplified and it will lack of a real strategic component, only ORBAT & SITREP for each territory is evaluated classifing ground groups for type (ATGM, APC, SAM, AAA, MBT, IFV, REC and so on) and tasking them accordigly to SITREP, Coalition situation and territories. The module will work as a state machine itself following this loop:

 

GlobalState events (v = completed, c = working):
0 - initialization (launched only once, build territory table) - v
A - group update status (ORBAT) - v
B - intel update status - v
C - territory update status - v
D - coalition SITREP - v
E - coalition OPORD -> c
F - read & command POD execution every Globaltimer cycle (or skip)
G - check mission completion for each ground group and replan if necessary
H - Coalition update status
I - air ORBAT update
J - air ATO request & planning ("human" air squadron recieve request but not planning).
K - Autosave process - v

 

If you want I can send you the actual code by PM, else you can wait the first release and then grab what you need, if you need. I'm trying to keep as many things as possibile inside functions to make easier the readability or copy&paste for others.

Edited August 22, 2016 by chromium

[Stonehouse]

Don't discount the idea of using the road network. For those that remember it Lowengrin's DCG used a system where the road system was defined by the path of waypoints a vehicle would take to go from one strategic location to the next. A similar thing could probably be done with a collection of late activation units that never spawn to give you a "good" path that avoids issues from one location to the next. Groups could inherit these template paths.

 

Similar things were done with the rail network and sea routes.

 

FYI see http://members.shaw.ca/lowengrin/ and http://forum.jg1.org/forum/8-lowengrins-dynamic-campaign-generators-dcg-for-il-2-cfs2/ and in particular some (slightly out dated but good enough to give you the idea) info about how it worked from the campaign designers viewpoint http://forum.jg1.org/topic/3793-dcg-download-site/#entry20855

 

I'm not saying duplicate it verbatim but some of the ideas do transfer I think once translated to a DCS World equivalent concept. Many a fantastic co-op/PvP/mixed campaign was flown using this system. I can remember building a fictional invasion of Darwin by the Japanese based around the premise that the IJN had caught the USN carriers at Pearl and then won Midway causing the US fleet to pull back for home defence which was quite popular at the time.

 

The strength of the lua scripting engine within DCS probably means something much better could be built.

[chromium]

Stonehouse is right, using road you can also make difference between those moving situation:

 

-Good weather road speed

-Good weather night road speed

-Good weather offroad speed

-Rain weather road speed

-Rain weather offroad speed

-Stormy/Snowy weather road speed

-Stormy/Snowy weather offroad speed

(those are the ones I want to use)

 

also I would suggest to take into account land surface type (http://wiki.hoggit.us/view/DCS_func_getSurfaceType). I'm not, cause I'm not that good at programming and I need to keep everything simple... but as this aspect will be improved once normandy map will be out, It could be a good idea to evaluate it since know if you can.

 

If you need, unit.getDesc() is a very powerful function that provide a lot of info about the unit, and one interesting is "rivercrossing" variable. Grimes also provide the community with a fantastic objects database witch can show you many variable whitout having to lose time exporting each time what you want to investigate: http://forums.eagle.ru/showpost.php?p=2785140&postcount=1

 

PS: I'm extremely looking forward to the Goal Oriented Action Planning framework idea :)

Edited August 22, 2016 by chromium
changed to "I want to use" cause that part isn't in place and I don't know if I can achieve that

[Pikey]

Good to see some experienced heads bringing information together. If anyone wants the code snippet for creating areas that are capturable and assigning them, then writign out the file, I have a demo to share to insipre, reject or motivate, whichever takes your fancy. It's literally very short code made by a friend when I begged him, in exchange for beer :)

 

Now if only we can get Ian, Xcom, chromium, mbot, ciribob (and OIP and anyone else) together for a dynamic campaign team I believe we would get a really nice product.

Edited August 22, 2016 by Pikey

[chromium]

Now if only we can get Ian, Xcom, chromium, mbot, ciribob (and OIP and anyone else) together for a dynamic campaign team I believe we would get a really nice product.

 

Sadly I can't cause my ideas needs to be focused on my wing needs, and I'm really bad at coordination. Anyway I wrote here cause I would like to support any effort in the DC developement of anyone, cause I don't mind who will achieve it first or better, I simply think that our community can deliver something great and maybe let ED integrate it in the main sim.

Also, consider that I'm not a programmer and really not good at it.. every thousand of lines written by me is probably not much more than 200 or 300 written by a professional programmer.

 

And now I'm going to be quiet, not want to spam more Bluestream thread.

[Fri13]

I wrote once about the dynamic campaign AI (actually multiple AI that each would take care of different things, each AI running as separate by the information they actually itself can get). And I didn't even come to think that the AI could really well be a external program instead DCS itself!

 

Is your campaign AI then limited only for the airports/airfields?

That as sounds fairly limited and sorry to say, boring, as in war there are so many other important areas as well like good areas for AA or harbors or other traffic routes.

 

The external program thing likely can override so many limitations that there is in the DCS for everything. So if Eagle Dynamics has good API/ABI for the external program to connect and start doing own commands for ground troops, it might offer very powerful ways to do things.

[ESAc_matador]

I wrote once about the dynamic campaign AI (actually multiple AI that each would take care of different things, each AI running as separate by the information they actually itself can get). And I didn't even come to think that the AI could really well be a external program instead DCS itself!

 

Is your campaign AI then limited only for the airports/airfields?

That as sounds fairly limited and sorry to say, boring, as in war there are so many other important areas as well like good areas for AA or harbors or other traffic routes.

 

The external program thing likely can override so many limitations that there is in the DCS for everything. So if Eagle Dynamics has good API/ABI for the external program to connect and start doing own commands for ground troops, it might offer very powerful ways to do things.

 

I did some functions to make the IA smarter, based on trigger zones. You put certain areas distributed like a piramid with the lines, 1 then 2-3 and then 4-5-6, where 4,-5-6 is the base of the pyrramid and the first line.or tree. Once a group in 4-5-6 is being attacked, they move inside the area they already are. If the group is damaged badly, it retires to second line 2-3 , and another goes forward to replace. The problem is that, it seems, that many groups moving creates a big stutter in dCS. There is a limit in movements.

 

I remember, someone made a script to organize movements, tô not overload the DCS but... i dont know wher it is.

 

It is just an idea.

Edited August 22, 2016 by ESAc_matador

[Bluestream]

Wow, thanks again for all the feedback. I realise that some of the things I blurt out may be hard to follow since this is kind of a brain dump at the moment, I apologise for that. Anyway, I'm going to try to quickly respond to the points you've all given since I really appreciate it.

 

Ian;2880937']The map data was exported by calling land.getSurfaceType() for every single pixel in every single tile. Took about a week of running the export script whenever I was not otherwise using my desktop PC to get all of the zoom levels finished.

 

Buildings were located with world.searchObjects(). I exported a list of all their anti-collision bounding boxes to a JSON file, then used some kind of GIS software (can't recall the name right now) to convert the vector data to bitmap tiles, as drawing a few thousand rectangles at once from vector data is too much for a browser to handle.

 

It's cool, I like it!

 

Pathfinding and spawning objects can be fraught. Its going to be a challenge spawning a lot of things in and out with a bubble approach but its where this will lead.

 

Have a look at Daws for saving objects. That saves all the units to a new mission file. Your engine needs to consider persistence and rebooting and saving the state.

 

I also feel the pathfinding will be a problem and I'm having trouble seeing any easy solutions at the moment. I believe I may need to use exported map data (like [FSF]Ian's idea above) if I want to get it working perfectly.

 

Persistence on the other hand is already pretty much a solved problem in the campaign, it's actually not dependent on mission files at all. I can just kill the DCS process at any time and start it back up and it'll load up as it was (perhaps with a small rollback of a few seconds or so). I'm not currently saving everything either, actually it's just living unit groups for now, but I believe that the concept is working well and adding to it will hopefully not cause too much headache. Oh, and for now the player group is not saved by the campaign either, so player state will not save.

 

If anyone wants more details on this I'd be happy to explain it in more depth.

 

I'm also working on a ground dynamic campaign, and I'm writing now the decision making process for the units movement. As I wanted it to work completely inside the SSE, I won't have a proper graphic overlay for showing terrain ownership (I can see it in testing by dumping tables). It's structured like DCS like... functions & tables. Due to the fact that I won't make a load for the computer running the mission each function works as a state machine evaluating 1 entry table at each time: you can define how much entry/seconds you want to evaluate, and this way works pretty well in keeping the system not that busy. I suggest you to move in the same direction for inner sim calculation (if there are).

 

The Idea is to automatically save & re-load the mission every "n" hours (3, 6 or 12 at the moment) using DAWS Save Mission module.

 

This system is very simplified and it will lack of a real strategic component, only ORBAT & SITREP for each territory is evaluated classifing ground groups for type (ATGM, APC, SAM, AAA, MBT, IFV, REC and so on) and tasking them accordigly to SITREP, Coalition situation and territories. The module will work as a state machine itself following this loop:

 

GlobalState events (v = completed, c = working):
0 - initialization (launched only once, build territory table) - v
A - group update status (ORBAT) - v
B - intel update status - v
C - territory update status - v
D - coalition SITREP - v
E - coalition OPORD -> c
F - read & command POD execution every Globaltimer cycle (or skip)
G - check mission completion for each ground group and replan if necessary
H - Coalition update status
I - air ORBAT update
J - air ATO request & planning ("human" air squadron recieve request but not planning).
K - Autosave process - v

 

If you want I can send you the actual code by PM, else you can wait the first release and then grab what you need, if you need. I'm trying to keep as many things as possibile inside functions to make easier the readability or copy&paste for others.

 

I'm really happy to see more people working on campaigns, I also feel this is something DCS really needs! I'm currently avoiding in-sim calculations as much as I can but throttling any calculations that I need to do sounds like a good idea - that may be relevant for exporting group data to the .NET app in the long run.

 

Also thanks for the offer, I'll keep it in mind.

 

The same goes the other way around for anyone, if you believe you could use the source for any particular part of my mission before I'm releasing it, just ask and I'll see if I can give you something (if it's working well enough).

 

Don't discount the idea of using the road network. For those that remember it Lowengrin's DCG used a system where the road system was defined by the path of waypoints a vehicle would take to go from one strategic location to the next. A similar thing could probably be done with a collection of late activation units that never spawn to give you a "good" path that avoids issues from one location to the next. Groups could inherit these template paths.

 

Similar things were done with the rail network and sea routes.

 

FYI see http://members.shaw.ca/lowengrin/ and http://forum.jg1.org/forum/8-lowengrins-dynamic-campaign-generators-dcg-for-il-2-cfs2/ and in particular some (slightly out dated but good enough to give you the idea) info about how it worked from the campaign designers viewpoint http://forum.jg1.org/topic/3793-dcg-download-site/#entry20855

 

I'm not saying duplicate it verbatim but some of the ideas do transfer I think once translated to a DCS World equivalent concept. Many a fantastic co-op/PvP/mixed campaign was flown using this system. I can remember building a fictional invasion of Darwin by the Japanese based around the premise that the IJN had caught the USN carriers at Pearl and then won Midway causing the US fleet to pull back for home defence which was quite popular at the time.

 

The strength of the lua scripting engine within DCS probably means something much better could be built.

 

Yes, this is a really good idea, expecially about using units that doesn't spawn to get routes, that's something I'll really look into for the simulation side of it as well. I guess just placing units with waypoints that cover all the roads would be a nice and quick way of exporting the road data! I could then have a few set entry/exit points (on roads) to strategic locations and as long as the units do not get stuck while moving to/from the 'entry points'/'exit points' to the locations it should be fine, it wouldn't be perfect and I believe it would still fail sometimes, but it would be good enough for now.

 

I wrote once about the dynamic campaign AI (actually multiple AI that each would take care of different things, each AI running as separate by the information they actually itself can get). And I didn't even come to think that the AI could really well be a external program instead DCS itself!

 

Is your campaign AI then limited only for the airports/airfields?

That as sounds fairly limited and sorry to say, boring, as in war there are so many other important areas as well like good areas for AA or harbors or other traffic routes.

 

The external program thing likely can override so many limitations that there is in the DCS for everything. So if Eagle Dynamics has good API/ABI for the external program to connect and start doing own commands for ground troops, it might offer very powerful ways to do things.

 

It's actually not limited to airports/airfields, but it currently is limited to capturable zones, that is no buildings to bomb or anything like that. The reason I mention airfields is that the AI usually behaves reasonably well there. The objectives can currently be any zone marked in the default DCS mission editor. When starting the campaign for the first time, this information will be fetched from DCS once and used by the .NET application.

 

I agree I think it will override a few limitations, but it also creates a few problems, I have to develop the API between Lua and .NET for example. The overall greatest positive about it for me is that I can use an environment I'm comfortable with that comes with a good debugger. I have no doubt that someone who knows Lua well would not be hindered by working only with Lua, in-sim.

[MikeMikeJuliet]

Good luck with the project.

 

Considering the performance of DCS with multiple units in the game, I feel an external campaign engine is a very welcome idea. The less DCS needs to pull horsepower to calculate things that don't directly affect the player, the better... meaning logistics, units out of sensor range, campaign AI... I wonder if this could be driving a miltiplayer campaign in addition to SP.