mirror of
https://github.com/vcmi/vcmi.git
synced 2024-12-04 09:42:40 +02:00
Address code review, fix few more issues with formatting
This commit is contained in:
parent
74a4a10f48
commit
36fe8462c5
@ -11,14 +11,14 @@ We have 3 battle AIs so far:
|
||||
* StupidAI - for neutrals, should be simple so that experienced players can abuse it
|
||||
* Empty AI - should do nothing at all. If needed another battle AI can be introduced.
|
||||
|
||||
Each battle AI consist of a few classes, but the main class, kind of entry point usually has the same name as the package itself. In BattleAI it is the BattleAI class. It implements some battle specific interface, do not remember. Main method there is activeStack(battle::Unit*stack). It is invoked by the system when it's time to move your stack. The thing you use to interact with the game and receive the gamestate is usually referenced in the code as cb. CPlayerSpecificCallback it should be. It has a lot of methods and can do anything. For instance it has battleGetUnitsIf(), which returns all units on the battlefield matching some lambda condition.
|
||||
Each side in a battle is represented by an CArmedInstance object. CHeroInstance and CGDwelling, CGMonster and more are subclasses of CArmedInstance. CArmedInstance contains a set of stacks. When the battle starts, these stacks are converted to battle stacks. Usually Battle AIs reference them using the interface battle::Unit*.
|
||||
Each battle AI consist of a few classes, but the main class, kind of entry point usually has the same name as the package itself. In BattleAI it is the BattleAI class. It implements some battle specific interface, do not remember. Main method there is `activeStack(battle::Unit * stack)`. It is invoked by the system when it's time to move your stack. The thing you use to interact with the game and receive the gamestate is usually referenced in the code as `cb`. `CPlayerSpecificCallback` it should be. It has a lot of methods and can do anything. For instance it has battleGetUnitsIf(), which returns all units on the battlefield matching some lambda condition.
|
||||
Each side in a battle is represented by an `CArmedInstance` object. `CHeroInstance` and `CGDwelling`, `CGMonster` and more are subclasses of `CArmedInstance`. `CArmedInstance` contains a set of stacks. When the battle starts, these stacks are converted to battle stacks. Usually Battle AIs reference them using the interface `battle::Unit *`.
|
||||
Units have bonuses. Nearly everything aspect of a unit is configured in the form of bonuses. Attack, defense, health, retaliation, shooter or not, initial count of shots and so on.
|
||||
When you call unit->getAttack() it summarizes all these bonuses and returns the resulting value.
|
||||
When you call `unit->getAttack()` it summarizes all these bonuses and returns the resulting value.
|
||||
|
||||
One important class is HypotheticBattle. It is used to evaluate the effects of an action without changing the actual gamestate. It is a wrapper around CPlayerSpecificCallback or another HypotheticBattle so it can provide you data, Internally it has a set of modified unit states and intercepts some calls to underlying callback and returns these internal states instead. These states in turn are wrappers around original units and contain modified bonuses (CStackWithBonuses). So if you need to emulate an attack you can call hypotheticbattle.getforupdate() and it will return the CStackWithBonuses which you can safely change.
|
||||
One important class is `HypotheticBattle`. It is used to evaluate the effects of an action without changing the actual gamestate. It is a wrapper around `CPlayerSpecificCallback` or another `HypotheticBattle` so it can provide you data, Internally it has a set of modified unit states and intercepts some calls to underlying callback and returns these internal states instead. These states in turn are wrappers around original units and contain modified bonuses (`CStackWithBonuses`). So if you need to emulate an attack you can call `hypotheticbattle.getforupdate()` and it will return the `CStackWithBonuses` which you can safely change.
|
||||
|
||||
## BattleAI
|
||||
## BattleAI
|
||||
|
||||
BattleAI's most important classes are the following:
|
||||
|
||||
@ -47,9 +47,9 @@ Nullkiller engine - place where actual AI logic is organized. It contains a main
|
||||
|
||||
* reset AI state, it avoids keeping some memory about the game in general to reduce amount of things serialized into savefile state. The only serialized things are in nullkiller->memory. This helps reducing save incompatibility. It should be mostly enough for AI to analyze data avaialble in CCallback
|
||||
* main loop, loop iteration is called a pass
|
||||
**update AI state, some state is lazy and updates once per day to avoid performance hit, some state is recalculated each loop iteration. At this stage analysers and pathfidner work
|
||||
** gathering goals, prioritizing and decomposing them
|
||||
** execute selected best goals
|
||||
* update AI state, some state is lazy and updates once per day to avoid performance hit, some state is recalculated each loop iteration. At this stage analysers and pathfidner work
|
||||
* gathering goals, prioritizing and decomposing them
|
||||
* execute selected best goals
|
||||
|
||||
Analyzer - a module gathering data from CCallback *. Its goal to make some statistics and avoid making any significant decissions.
|
||||
|
||||
|
@ -68,7 +68,9 @@ Be aware that building Vcpkg might take a lot of time depend on your CPU model a
|
||||
|
||||
From command line use:
|
||||
|
||||
`git clone https://github.com/microsoft/vcpkg.git %VCMI_DIR%/vcpkg`
|
||||
```sh
|
||||
git clone https://github.com/microsoft/vcpkg.git %VCMI_DIR%/vcpkg
|
||||
```
|
||||
|
||||
#### Build vcpkg and dependencies
|
||||
|
||||
|
@ -6,8 +6,7 @@
|
||||
2. Xcode: <https://developer.apple.com/xcode/>
|
||||
3. CMake 3.21+: `brew install --cask cmake` or get from <https://cmake.org/download/>
|
||||
4. Optional:
|
||||
|
||||
- CCache to speed up recompilation: `brew install ccache`
|
||||
- CCache to speed up recompilation: `brew install ccache`
|
||||
|
||||
## Obtaining source code
|
||||
|
||||
|
@ -91,7 +91,7 @@ Open `VCMI.xcodeproj` from the build directory, select `vcmiclient` scheme and h
|
||||
|
||||
## Packaging project into DMG file
|
||||
|
||||
After building, run `cpack` from the build directory. If using Xcode generator, also pass `-C`<configuration name> with the same configuration that you used to build the project.
|
||||
After building, run `cpack` from the build directory. If using Xcode generator, also pass `-C <configuration name>` with the same configuration that you used to build the project.
|
||||
|
||||
If you use Conan, it's expected that you use **conan-generated** directory at step 4 of [Conan package manager](Conan.md).
|
||||
|
||||
|
@ -21,4 +21,4 @@ The build dir should be set to something like /trunk/build for the debug build a
|
||||
There is a problem with QtCreator when debugging both vcmiclient and vcmiserver. If you debug the vcmiclient, start a game, attach the vcmiserver process to the gdb debugger(Debug \> Start Debugging \> Attach to Running External Application...) then breakpoints which are set for vcmiserver will be ignored. This looks like a bug, in any case it's not intuitively. Two workarounds are available luckily:
|
||||
|
||||
1. Run vcmiclient (no debug mode), then attach server process to the debugger
|
||||
2. Open two instances of QtCreator and debug vcmiserver and vcmiclient separately(it works!)
|
||||
2. Open two instances of QtCreator and debug vcmiserver and vcmiclient separately (it works!)
|
||||
|
@ -68,7 +68,7 @@ The following code shows how the logging system can be configured:
|
||||
|
||||
If `configureDefault` or `configure` won't be called, then logs aren't written either to the console or to the file. The default logging setups a system like this:
|
||||
|
||||
**Console**
|
||||
#### Console
|
||||
|
||||
Format: %m
|
||||
Threshold: info
|
||||
@ -76,11 +76,11 @@ coloredOutputEnabled: true
|
||||
|
||||
colorMapping: trace -\> gray, debug -\> white, info -\> green, warn -\> yellow, error -\> red
|
||||
|
||||
**File**
|
||||
#### File
|
||||
|
||||
Format: %d %l %n \[%t\] - %m
|
||||
|
||||
**Loggers**
|
||||
#### Loggers
|
||||
|
||||
global -\> info
|
||||
|
||||
|
@ -27,8 +27,8 @@ So far we using following services:
|
||||
- One administrative email used for other services registration.
|
||||
- "noreply" email used for outgoing mail on Wiki and Bug Tracker.
|
||||
- "forum" email used for outgoing mail on Forums. Since we authenticate everyone through forum it's should be separate email.
|
||||
- Administrator access: Tow, SXX.
|
||||
- [Google Play Console](https://play.google.com/apps/publish/) account.
|
||||
- Administrator access: Tow, SXX.
|
||||
- [Google Play Console](https://play.google.com/apps/publish/) account.
|
||||
- Hold ownership over VCMI Android App.
|
||||
- Owner: SXX
|
||||
- Administrator access: Warmonger, AVS, Ivan.
|
||||
|
@ -59,7 +59,7 @@ Should be done 1 day before release. At this point beta branch is in full freeze
|
||||
- Merge `beta` into `master`. This will trigger CI pipeline that will generate release packages
|
||||
- Create draft release page, specify `1.x.y` as tag for `master` after publishing
|
||||
- Check that artifacts for all platforms have been built by CI on `master` branch
|
||||
- Download and rename all build artifacts to use form "VCMI-1.X.Y-Platform.xxx"
|
||||
- Download and rename all build artifacts to use form `VCMI-1.X.Y-Platform.xxx`
|
||||
- Attach build artifacts for all platforms to release page
|
||||
- Manually extract Windows installer, remove `$PLUGINSDIR` directory which contains installer files and repackage data as .zip archive
|
||||
- Attach produced zip archive to release page as an alternative Windows installer
|
||||
|
@ -12,9 +12,7 @@ Check the files in *config/heroes/* for additional usage examples.
|
||||
|
||||
- Type: Complex
|
||||
- Parameters: valPer20, stepSize=1
|
||||
- Effect: Updates val to
|
||||
|
||||
`ceil(valPer20 * floor(heroLevel / stepSize) / 20)`
|
||||
- Effect: Updates val to `ceil(valPer20 * floor(heroLevel / stepSize) / 20)`
|
||||
|
||||
Example: The following updater will cause a bonus to grow by 6 for every
|
||||
40 levels. At first level, rounding will cause the bonus to be 0.
|
||||
@ -46,13 +44,9 @@ Remarks:
|
||||
## TIMES_HERO_LEVEL
|
||||
|
||||
- Type: Simple
|
||||
- Effect: Updates val to
|
||||
- Effect: Updates val to `val * heroLevel`
|
||||
|
||||
`val * heroLevel`
|
||||
|
||||
Usage:
|
||||
|
||||
`"updater" : "TIMES_HERO_LEVEL"`
|
||||
Usage: `"updater" : "TIMES_HERO_LEVEL"`
|
||||
|
||||
Remark: This updater is redundant, in the sense that GROWS_WITH_LEVEL
|
||||
can also express the desired scaling by setting valPer20 to 20\*val. It
|
||||
@ -61,9 +55,7 @@ has been added for convenience.
|
||||
## TIMES_STACK_LEVEL
|
||||
|
||||
- Type: Simple
|
||||
- Effect: Updates val to
|
||||
|
||||
`val * stackLevel`
|
||||
- Effect: Updates val to `val * stackLevel`
|
||||
|
||||
Usage:
|
||||
|
||||
@ -74,13 +66,9 @@ Remark: The stack level for war machines is 0.
|
||||
## ARMY_MOVEMENT
|
||||
|
||||
- Type: Complex
|
||||
- Parameters: basePerSpeed, dividePerSpeed, additionalMultiplier,
|
||||
maxValue
|
||||
- Effect: Updates val to val+= max((floor(basePerSpeed /
|
||||
dividePerSpeed)\* additionalMultiplier), maxValue)
|
||||
- Remark: this updater is designed for MOVEMENT bonus to match H3 army
|
||||
movement rules (in the example - actual movement updater, which
|
||||
produces values same as in default movement.txt).
|
||||
- Parameters: basePerSpeed, dividePerSpeed, additionalMultiplier, maxValue
|
||||
- Effect: Updates val to `val+= max((floor(basePerSpeed / dividePerSpeed) * additionalMultiplier), maxValue)`
|
||||
- Remark: this updater is designed for MOVEMENT bonus to match H3 army movement rules (in the example - actual movement updater, which produces values same as in default movement.txt).
|
||||
- Example:
|
||||
|
||||
``` jsonc
|
||||
|
@ -3,13 +3,18 @@
|
||||
Total value of Bonus is calculated using the following:
|
||||
|
||||
- For each bonus source type we calculate new source value (for all bonus value types except PERCENT_TO_SOURCE and PERCENT_TO_TARGET_TYPE) using the following:
|
||||
`newVal = (val * (100 + PERCENT_TO_SOURCE) / 100))`
|
||||
|
||||
```
|
||||
newVal = (val * (100 + PERCENT_TO_SOURCE) / 100))
|
||||
```
|
||||
|
||||
- PERCENT_TO_TARGET_TYPE applies as PERCENT_TO_SOURCE to targetSourceType of bonus.
|
||||
|
||||
- All bonus value types summarized and then used as subject of the following formula:
|
||||
|
||||
`clamp(((BASE_NUMBER * (100 + PERCENT_TO_BASE) / 100) + ADDITIVE_VALUE) * (100 + PERCENT_TO_ALL) / 100), INDEPENDENT_MAX, INDEPENDENT_MIN)`
|
||||
```
|
||||
clamp(((BASE_NUMBER * (100 + PERCENT_TO_BASE) / 100) + ADDITIVE_VALUE) * (100 + PERCENT_TO_ALL) / 100), INDEPENDENT_MAX, INDEPENDENT_MIN)
|
||||
```
|
||||
|
||||
Semantics of INDEPENDENT_MAX and INDEPENDENT_MIN are wrapped, and first means than bonus total value will be at least INDEPENDENT_MAX, and second means than bonus value will be at most INDEPENDENT_MIN.
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
## Introduction
|
||||
|
||||
Starting from version 1.3, VCMI supports its own campaign format.
|
||||
Campaigns have `*.vcmp file` format and it consists from campaign json and set of scenarios (can be both `*.vmap` and `*.h3m`)
|
||||
Campaigns have `*.vcmp` file format and it consists from campaign json and set of scenarios (can be both `*.vmap` and `*.h3m`)
|
||||
|
||||
To start making campaign, create file named `header.json`. See also [Packing campaign](#packing-campaign)
|
||||
|
||||
|
@ -172,7 +172,7 @@ You can modify general properties of the map
|
||||
|
||||
## Player settings
|
||||
|
||||
Open **Map** menu on the top and select **Player settings"
|
||||
Open **Map** menu on the top and select **Player settings**
|
||||
|
||||
<img width="141" src="https://user-images.githubusercontent.com/9308612/188781357-4a6091cf-f175-4649-a000-620f306d2c46.png">
|
||||
|
||||
|
@ -208,8 +208,10 @@ Link to our mod will looks like that: <https://github.com/vcmi-mods/adventure-ai
|
||||
|
||||
For sanity reasons mod identifier must only contain lower-case English characters, numbers and hyphens.
|
||||
|
||||
`my-mod-name`
|
||||
`2000-new-maps`
|
||||
```
|
||||
my-mod-name
|
||||
2000-new-maps
|
||||
```
|
||||
|
||||
Sub-mods can be named as you like, but we strongly encourage everyone to use proper identifiers for them as well.
|
||||
|
||||
|
@ -53,7 +53,9 @@ The easiest way to install the ipa on your device is to do one of the following:
|
||||
|
||||
Alternatively, to install the signed ipa on your device, you can use Xcode or Apple Configurator (available on the Mac App Store for free). The latter also allows installing ipa from the command line, here's an example that assumes you have only 1 device connected to your Mac and the signed ipa is on your desktop:
|
||||
|
||||
`/Applications/Apple\ Configurator.app/Contents/MacOS/cfgutil install-app ~/Desktop/vcmi.ipa`
|
||||
```
|
||||
/Applications/Apple\ Configurator.app/Contents/MacOS/cfgutil install-app ~/Desktop/vcmi.ipa
|
||||
```
|
||||
|
||||
## Alternative Step 2: Installing Heroes III data files
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user