-
-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enemy Commander pt1 #529
Comments
I find your idea already very interesting and I am curious how you will realize that. |
I think having a small player group on the enemy side in the same way that Antistasi does it could be interesting, but I'm not sure how many possibilities should be included. |
so i haven't played antistasi yet. but i think we're talking about the same possibilities in my idea, it's really just that you can interfere with the progress of the bluefor players or even push them back. |
If there must be players on the OPFOR team, then I believe they should only be able to spawn into the battle by taking control of an AI that's currently deployed in a sector or reinforcement wave. These players would have to be severely limited. OPFOR has a massive advantage already because of their huge numbers and constant stream of reinforcements on the later difficulties. The AI can sometimes be exceptionally proactive, taking several sectors at a time if unchallenged. Besides this, Arsenal should be an automatic no-go, and they should only be able to take vehicles by hijacking them from OPFOR AI in a sector. Such a system would be highly controversial. Fighting against swarms of enemies is something Liberation does better than any mission in Arma. To sacrifice that just so a few players could drive a tank out of the AO, wait for a battle to start, and then come up behind the players and blast them away, or hijack an artillery piece and simply turn them to meat paste, would be far from popular. We would need special blacklists just for what vehicles OPFOR players are allowed to commandeer. A whole new framework would have to be built on top of Liberation to make this work fairly. In the meantime, you could just install Achilles locally on a Zeus player, have him convert a few players to OPFOR, and drop them down in enemy sectors when it's time to defend them. And this might just work out better, for 60 seconds of Zeus work, than what might be 100 hours or more of work for the developers. |
Short Summary
As enemy I want to be capable of issuing strategical decisions and actions, so that I'm able to provide the players an immersive campaign.
Description
Many of these earlier written thoughts will be in our planning and considered individually:
#329 (comment)
Basically the enemy needs at first some values concerning his strength, aggressiveness/awareness.
First one is to determine how many soldiers/materiel he's able to throw against the players.
The second one would be how much he sees a threat in the players action, so it'll grow during the campaign.
The sector garrisons are currently provide a very basic "enemy" for the players as a local or tactical threat. For the strategical aspect the enemy should also, depending on the players progress in certain areas, try to reinforce these sectors with additional manpower for their garrison. This by moving vehicles/soldiers from one sector to another or by reinforcing them from his military bases (which could be considered as enemy forces spawn points). All of this maybe (if the AI would be really reliable enough concerning driving skills) as real driving convoys, so that players can have opportunities to intercept them, etc. It should provide many possibilities for a much deeper experience in the future.
Providing the above foundation would be the content of this pt1.
In the next part(s) there should be the functionality, that the enemy commander evaluate possibilities for sensible counter attacks to recapture sectors or destroy player FOBs to weaken their presence in areas of the map.
Also dynamic reactions/handling of events like activated/captured/deactivated sectors would be content of the next iteration of this module.
Sub-Tasks
The text was updated successfully, but these errors were encountered: