Autocombat == Geoscape Test Tool

[stjones]

I am new to this project, but it seems that one thing you desperately need is an AutoCombat program that can be used as a replacement for the Battlescape program. Not only does this give the end user an additional way to play Xenocide, but it also provides a way quickly generate combat results that can be used as a test tool for the Geoscape program.

 

I recently implemented AutoCombat in XcomUtil and am willing to port it to Xenocide. It should be easy to produce an initial version that randomly presents one of several pre-generated results, such as All Aliens Killed, All Soldiers Killed, or Successful/Unsuccesful Mission with Random Number of Casualties. Eventually the AutoCombat program could grow into anything, even a way for user-programmed AIs to compete against the aliens or each other. Any comments or suggestions?

[red knight]

It is a very good idea cause it can gives us the posibility to implement and test both battlescape and geoscape without having the other finished and tested... And as you state it can eventually become a feature of Xenocide.

 

Greetings

Red Knight

[[[Micah]]]

I agree emphatically. Implementing the autocombat will allow us the focus on, test, and complete the geoscape (to perfection before we have to finish the battlescape. Basically a restate of what Scott said, but I just wanted to say I agree.

[[mindstormmaster]]

I also agree that it is something that should be done as it will allow for testing to proceed (i think that's the third time now). It's also a good idea for the final release as it will allow users such as myself to play without having to play out every battle. I think some other turn based games have this as an option (Star Wars Rebellion for example). The best option would be for the computer to play against itself (AI vs. AI) and then determine the result. This would probably be something to implement after the AI is finished.

Ok, that's my two cents

[stjones]

I don't know how to access the header files or design documents, if any, that describe the interface between Geoscape and Battlescape. Could someone tell me how to get this information or who I should work with?

 

With that information, the minimal version of AutoCombat should be possible to produce in a matter of days. The one that tries to actually simulate combat, like the one in XcomUtil, could take as much as a few weeks. It all depends on how firm the interface is.

[red knight]

The Geoscape is a techdemo... so that i hadnt addressed that, the source will be release in a little time after i finish collision detection for the game engine it will be imported into the Sourceforge CVS...

 

Greetings

Red Knight

[Guest stewart]

This /may/ be an appropriate place to put this, if not sorry. I had an idea over the weekend. For the "debug" target (not the release target) why don't we build-in a two player mode for battlescape which can be played without a network layer (like an old fashioned game). Game play would proceed more-or-less like playing two-player with XcomUtil. The point of this is that Battlescape could be tested before we have a network layer or an AI.

[red knight]

If we are thinking on the line of multiplayer battlescape, i wouldnt dare to make that without the Network layer ready and tested... Besides we should concentrate on one topic at a time, to avoid breaking the product down....

 

Greetings

Red Knight

[mamutas]

For testing purposes, I think it would be very useful to have 2 players play mode. One turn you play for aliens, another for XCom. Even better, if there would be an ability to choose who is playing who. For example, you can choose, that CPU will play both XCom and aliens - great AI testing tool.

[Guest stewart]

That's what I meant. As a means for testing battlescape itself not the network layer. Or else we need either the network layer or AI functioning first before we can test battlescape.

 

Plus this is for the debug target only, not for release. This is similar to a technique discribed in "Writing Solid Code" in this case for the debug version of MS Excel certain functions were written with two different algorhythms which were both activated on use for testing purposes.

 

I'm not saying the final game should have this, just the debug version for, debugging.

 

BTW I'm moving this thread from Geoscape to the General Programming discussion forum.

[red knight]

Of course a two players in the same machine is needed for debugging, but the idea is not to write two versions of the code for single and multiplayer... you will need the network layer (even if what is required is a direct memory copy on the same machine) call it a network simulation if you want, but all comunication goes from the Client (UI) in commands send to the data engine (the server) via the network API... A local machine UI will be like connecting both players via a Client to the network layer and issue commands on the data engine (where the game state is stored)....

 

If you start to issue commands directly to the data engine, then you will have 2 redundat codes (that do the same thing) one for multiplayer and one for single player (What we want to avoid on the first place)....

 

Grettings

Red Knight

[Guest stewart]

My gut feeling is it will only be a few lines of code, especially early on when all we'll have is single player.

[red knight]

My gut feeling is it will only be a few lines of code, especially early on when all we'll have is single player.

It maybe be few lines of code, but it is pretty common that that kind of code in himself become standard if you allow it to grow... Bypassing a complete communication mechanism is not good (even if it is for a good cause)... If i have to vote, i say no... lets concentrate on the network API, zwn told me he will post an API (header) draft in 7 to 10 days... more than enough for others interested to do the same...

 

Greetings

Red Knight

[Guest stewart]

If the relevant code exists only in the debug target (ie #ifdef DEBUG) then when we compile the Release version it won't show up, not even passwords can activate it. Remember this is to be a debug tool really not an actual feature of the final game. Do we really need to wait for the network layer or AI first?

[red knight]

If the relevant code exists only in the debug target (ie #ifdef DEBUG) then when we compile the Release version it won't show up, not even passwords can activate it.  Remember this is to be a debug tool really not an actual feature of the final game.  Do we really need to wait for the network layer or AI first?

Not AI just Network Layer API... The shortcut when in single machine play will be there...

 

And polute the code with those annoying #define _DEBUG (i had to use them sometimes but i wouldnt do that for a complete subsytem hack) .... I really dont like those, they make readability goes to 0... Remember that the Network layer is the communication nexus between the "Data Engine" or simulation and the UIs (Battlescape and Geoscape)....

 

Greetings

Red Knight

[tamat]

Well, we can start aporting posible algorythms to resolve the battle winner, casualtyes, points, etc.

 

Easy:

 

Every team have a puntuation, team with higher wins. The difference determine how many team members survive.

The team puntuation is calculed adding the puntuation of every soldier.

The puntuation of a soldier is calculed with his skills and his weapons.

Dies soldiers with less puntuation untill all diferente points between teams are depleted.

Some modificators can add or substract points like ship injuried, time taken to arrive to battle point, number of hostages, veteran soldiers...

 

 

Medium:

 

Make the same soldier ranking than before. Now every soldier are assigned to an enemy and makes a random action:

- attack: make a shot with primary weapon, enemy health are reduced in a porcentage calculed taking account skills of both members, shot can fail and exist the probabily of impact on a team member.

- move: change the enemy assigned to that player, increase the posibility of being hit but reduce the posibily of a success hit.

- defense: soldier searchs cover on the scenario, reduce the probabily of being hited.

- heal: heal a injuried soldier, increase the health of a soldier.

- take item: soldier take a random item of the corpses.

- abandon: soldier left the battle.

 

The probability of every action are calculed taking into account the strategy given by the player from geoscape, like - offensive strategy, exporation strategy, etc

 

When no soldier rest alive or all alive soldiers abandon the battle, then finishes.

 

 

Hard:

 

Playing IA vs IA...

[stjones]

Here is a description of the AutoCombat algorithm that is already working in XcomUtil. As soon as we have a solid definition of the interface between Geoscape and Battlescape, I can port this to Xenocide. It may not be perfect, but the algorithm already exists and has had a fair amount of testing. It is also driven by a configuration file that can be easily modified if you want to vary the difficulty.

 

AutoCombat Algorithm:

 

The basic success percentage for each soldier with a loaded weapon is 5% for each rank above rookie or seaman. Thus, each soldier contributes from 0% to 25% to your total chance of success in combat.

 

High reactions and firing accuracy add even more when the damage of your weapons is greater than the average health of the aliens. Similarly, soldiers with Psi/MC skill greater than the Psi/MC Strength of the aliens add to your chance of success. Aliens and other factors, like darkness, reduce your chances of success. To reduce the penalty for darkness, soldiers who carry flares in darkness get a bonus.

 

All of these factors and the amount they effect your chances of success are specified using StatStrings in the AutoCombat section of XCOMUTIL.CFG. The default abort threshold is also defined there.

 

If the final success percentage is less than the abort threshold, there will be no combat. If the percentage is 100 or greater you win. Otherwise, your success is randomly determined.

 

If you lose, the number of aliens killed is based on the amount by which you missed your success percentage. If you win, all aliens are killed or stunned. The soldier credited with the kill is selected randomly. If that soldier is using a small launcher loaded with a stun bomb, the alien is always stunned. Otherwise, the chances are only 1 in 32 that the alien will be stunned. You earn 20 points for each alien you kill and 10 points or each corpse you recover. All alien ammo clips are captured as full clips. Human ammo clips are emptied according to how much they are used, just as in normal combat.

 

The algorithm to determine who gets wounded is as follows. Each alien can wound one human. The probability of each alien actually hitting a human is the difference between the total success percentage and the success roll, a number between 1 and 100. If the difference is more than 90, the maximum chance that the alien misses the soldier is 90%. If the difference is more than 200, the maximum chance is 95%. Thus, the more overwhelming your force, the fewer soldiers will be killed or wounded.

 

The probability that any given soldier will be wounded is based on the order defined by the SortStats in XCOMUTIL.CFG. The last soldier in the craft, has one chance of being selected. The next to the last soldier has 2 chances, the one before that has 3 chances, and so on. The Nth soldier from the back, the first one off the craft, has N chances to be selected. That is, if you have 4 soldiers in the craft, their chances of being the one wounded are 10%, 20%, 30%, and 40%, respectively. The last soldier on a full Skyranger has less than a 1% chance of being selected.

 

By default, soldiers with high Psi/MC skill or very high firing accuracy are moved to the back of the craft to protect them. Thus, it is highly unlikely that they will be wounded if there are many soldiers in the battle. However, any soldier can be killed, regardless of where he or she is placed in the craft.

 

Tanks are always considered to be the first units into combat and the first units wounded or killed. Each tank receives the wounds that would have gone to the four soldiers it replaces, but tank armor greatly reduces the amount of damage taken. Compared to soldiers, tanks do not significantly improve the chances of success. However, if they are not destroyed in combat, they are immediately repaired when you return to your base.

 

The damage inflicted by each wound is the average weapon damage of the aliens. The damage reduces armor first. When it is gone, it reduces health, until the human is dead. If a dead human is selected for wounding, another is selected in its place. If a live human has not been found after three tries, the potential wound is ignored.

 

During AutoCombat, the XCOMUTIL.LOG file records a summary of the battle, along with all Hits (armor damaged, but no wounds), Wounds, and Kills. It also reports Healed when a Medi-Kit is successfully used after a soldier is wounded. The victory points lost because a soldier is killed in combat is 20 plus 10 for each rank above rookie/seaman.

[Guest stewart]

If the relevant code exists only in the debug target (ie #ifdef DEBUG) then when we compile the Release version it won't show up, not even passwords can activate it.  Remember this is to be a debug tool really not an actual feature of the final game.  Do we really need to wait for the network layer or AI first?

Not AI just Network Layer API... The shortcut when in single machine play will be there...

 

And polute the code with those annoying #define _DEBUG (i had to use them sometimes but i wouldnt do that for a complete subsytem hack) .... I really dont like those, they make readability goes to 0... Remember that the Network layer is the communication nexus between the "Data Engine" or simulation and the UIs (Battlescape and Geoscape)....

 

Greetings

Red Knight

Not using #ifdef for purely easthetic reasons, if you'll pardon the pun, is unreasonable. Sometimes they ARE nessessary, this is just such a case. Now, of course, I've seen code with them everywhere and it is uglier, but in that case it was code supporting hacks, dating back a decade, because of the declared need to rush to market.

 

This would be a useful thing to have and in this case would not be EVERYWHERE. Throwing away something useful because it's a little icky.

 

Besides if we CAN'T EVER use them then we can't make use of the benefits of the multi-targeted approach to software developement. I think it would be a mistake to do so.

[mamutas]

In my opinion #ifdef's are only siutable to separate OS-specific code. And for _DEBUG for temporary println's. I would vote against of their usage for simulating network functionality though.

[Guest stewart]

I guess people have misunderstood. I'm not suggesting simulating networking, just that for battlescape we have a built in tool to run all sides on one computer for debugging.

[red knight]

There are nicer ways to do multiplatform development without resorting to compiler directives.... About using them, well as i had said i use them for examples to call the assertions, warnings, and fails... and i guess i will add a new one to just information like

info ("The texture " + manipulator->getName () + " had been loaded");

and if in release that compiles to a null statement

;

but that is not really using compiler directives because they are isolated in only one place, not all around the code...

 

Greetings

Red Knight

[[[Micah]]]

I guess people have misunderstood.  I'm not suggesting simulating networking, just that for battlescape we have a built in tool to run all sides on one computer for debugging.

That was what Scott was planning after we get the battlescape underway, I believe.

[Guest stewart]

Maybe I misunderstood. I thought scotts idea was more-or-less push a button the groundbattle results are computed; done. What I'm talking about is for playtesting battlescape (not geoscape).

[stjones]

Maybe I misunderstood.  I thought scotts idea was more-or-less push a button the groundbattle results are computed; done.  What I'm talking about is for playtesting battlescape (not geoscape).

In case there is any confusion, AutoCombat can be a COMPLETE replacement for the Battlescape that can be used to test Geoscape. However, it can also be a way to finish an existing battle. It would all depend on whether it runs between Geoscape and Geoscape OR Battlescape and Geoscape, respectively.

 

There would also be a good reason to produce a Battlescape AI to be used for testing Battlescape. However, that would be a completely different kind of program. As I envision it, and implemented it in XcomUtil, AutoCombat just randomly determines the outcome of battle and updates the files. It does NOT attempt to actually fight the battle or issue any of the commands that Battlescape would handle.

[Guest stewart]

Scott any thoughts of having an autocombat option to "autoplay" both sides, so we could load a battle and watch it (I realize this requires an AI first)?

[TheAssassin]

I like the idea of an autoplay. I do also like the idea of eventually making it multiplayer. I have always wanted to make some AI.

[Maverick]

It is possible for the AI to play for both sides of the game in a battlescape and I don't see why you couldn't watch. It also should not be something that would be difficult to do. This does require that the AI and the battlescape be completed however.

 

Scott's system means that there is no Battlescape, like it never existed to begin with. All his system needs is the method (may be a bad word to describe it, but it's all I've got) through which the geoscape will send data to the battlescape. (for example: In UFO defense when geoscape closed and called battlescape it saved all data into the MISSDAT folder; battlescape would initialize and then load from MISSDAT, on closing it would save back to MISSDAT; Geoscape then loads from MISSDAT. What we need in order to use his system is to know what we would be putting "in" to the MISSDAT folder)

 

If we know what data will be sent to the battlescape we can use his system to playtest the Geoscape, effectively allowing us to have a fully functional Geoscape to bug track in while the Battlescape and AI are worked on completely separately.

 

As an aside, we don't need a working battlescape to develop the AI for it. What we do need is an XML listing of all the factors involved in a battlescape. The things that the AI can incorporate. Then it is a matter of letting the AI include different things in the process. We only need to let the AI have enough information to obtain the required result. Just because it has access to information doesn't mean that it is required to use it.

 

Anyway, his suggestion was that we could use his autoplay system to substitute for a lack of battlescape system. If it still doesn't make sense, using his system you would essentially be able to play an entire game without ever controlling a soldier. (In other words, when the geoscape is finished, we add this in and people can play in this and play full functional games using the geoscape only while we develop the battlescape)

 

-Mav

[red knight]

We will use send in whatever format your apps will need... I think the best way is to send objects directly (marshalled into a stream) to the other cause we are thinking on the multiplayer lines too. Geoscape and Battlescape are just two separated GUIs, of course they have different purposes... but the data they manipulate is the same... our idea was to have a different (say process, probably a thread in a local machine) that runs the server (even in single player mode) where all the data relationships and stuff is concentrated and the server gives the users (Geoscape and Battlescape) all they need to know to handle the game...

 

For example: the server logic will prevent unlawful event like a flying guy without a flying suit... cause the move command sent by an rogue (or cheated) battlescape will be discarded because it is not right with the logic. The only way to have a cheated multiplayer game is to have a hacked server (who would play with it?)....

 

The idea of modelling the data is what has been uploaded to the CVS long ago (that was just the data definitions in C++ style of the entities that you would encounter in a game, like IWeapons (for weapons, with attributes such damage, type, etc) or IWearable (things that you can let a Soldier or Alien to wear (put in the backpack, etc) to avoid bugs like letting you get carry elerium, elerium wont inherit from wearable... For instance Elerium should be onle IStorable and a Laser Rifle would be IStorable, IWeapon and IWearable....

 

I would like to chat (sadly I cannot phone him from here) with Scott about it cause he knows the original pretty well so he is the right person to define the kind of "Entity Database" we need... If this way can help you to get the AI and Scott's autocombat feature running with Xenocide I will port it to the new format as soon as posible and upload it again to the CVS. Cause I had taken it away because it wasnt compliant with the new source schema.... If not we will have to find another way.

 

Greetings

Red Knight

Edited June 4, 2003 by red knight

[mamutas]

I was thinking about our implementation more in terms of Model-View-Controller pattern. It is somehow similar to Red Knight's client-server architecture. And maybe it is even the same thing... So, let me explain.

 

There is an object which holds current state of the game including all Geoscape info as well as Battlescape (if the battle is currently on). During save/load operation whole this object is getting serialized/deserialized to the file system. For the network play, each machine will have a copy of such object and if one of the object has changed small packet of changes is sent to the opponents machine (or something like that, but probably we would need to add some conflicts checking mechanizm too). This object is the Model.

 

On top of that Model we would put other objects the whole responsibility would be to extract necessary data from the Model and put new info in that. Those would be Controllers and there would be one for each View: the Geoscape, the Basescape, the Battlescape. The point is that each Controller does not care about all data in the Model, but only about a subset of the data specific for the View. For example, Battlescape Controller extracts all the data about units on the battlefield, but it does not care about crafts or base facilities.

 

Then when during the game control is passed from Geoscape to Battlescape, the GeoController updates the Model and then BattleController reads the data and passes it to Battlescape view. When the battle is finished the process goes opposite way.

 

Applying Scott's idea here, we can have multiple implementations of Battlescapes, as long as they are all able to communicate with BattleController: it could the original battlescape, or auto-combat or even pencil and paper battlefield (or you can play chesses, if you want: white-XCom, black-Aliens )

 

Well, I got the feeling that we are all talking about the same thing. Do you think so?