Decide how the micromanagement will be integrated with OLCBP and what are its main components

Make Case Visualizer use Enums[*] for engine IDs instead of using the ID Lookup table, and make such table generate only Game dependent IDs

Currently there is a bug in the planner that it fail to execute parallel plans

Train Army (ArmySize)

Number of attacking units <= ArmySize

Small Army [1, 66]

Medium Army [67, 132]

Large Army [133, 200]

Need to get MaxPopulation from the game

Update the setup wiki
Make it super easy for new devs to start development

Attack Goals

Deploy Army (ArmySize)
Enemy in line of sight

Check this comment

• Develop gather resource action
• Develop a resource manager using FSM or whatever possible and use the gather action to issue gather commands
• Develop the required communication between the OLCBP and the resource manager

Use Qt treeview widget to visualize the current plan expansion and execution

IStrategizer solution and IStrategizerClient should be modified in their settings, to look at the new places of the Serialization libs

Win Game
All enemy entities are destroyed

The success conditions of this goal is that the entity is available for training/building from tech tree

Consider Workers, build areas, production resources (minerals, etc..) as sharable and each action should get the onwership of each resource during usage

1. Support full screen and auto-fit layout
2. Support zooming and/or scrolling in plan graph view
3. Drop-down boxes of choosing enum values should be related

• Decide the generic gamestate by refactoring and abstracting the old gamestate
• Implement gamestate retrieval in starcraft game model

The case revision algorithm is very simple and trivial, that can't handle issues like this:

Consider the matched cases CaseA, CaseB, CaseC appears in the same sequence in the Case base where CaseA is the first case.
The following is the cases performance (Success/Trial)
CaseA (1/1), CaseB(1/2), CaseC(1/3)

The cases above are equal in case-relevance, and the retriever will judge which one to return based on their performance.
Consider the retriever first return CaseA, and CaseA fail.
Reviser will update its performance to be CaseA (1/2) which is equal to CaseB (1/2)
When we try to get another case to match our goal, the retriever will find that the best case to retrieve is the case with performance (1/2), since CaseA and CaseB are equal in the performance and differ in the the order in the case-base list
The retriever will get CaseA as it is the first to appear in the case-base

This behavior is buggy, somehow we should try CaseB and not to try CaseA again, at-least for this game.

Now we just get the distance for the first base found in the game. We need to handle case that there are many bases

Satisfy Require Resource (ResourceTypeID, Amount)

Resource Available
Amount: {Set of all required amounts by units, researches}

CellFeature::Null().To(_planstepParams);

Destroy Entity (EntityClassID)
Entity destroyed

VM need:

• Qt installed with VS integration.
• VS 2008
• Visual assist
• Git and TortoiseGit
• StarCraft 1.16.1 with Chaoslauncher

This action will be given an entity class id (not entity id) to move for a location

• Update(*) methods currently accept unsigned p_cycles which is the number of frames elapsed since the game started, which is not accurate and can't be used for time based components like Actions
• Using game frames is inaccurate and will make the engine behavior differ based on the machine speed that the engine is running on
• Actions need the elapsed milliseconds to be able to measure execution time and assess of Actions success/failure

1. Implement "Save", "Save As" and "Auto Save" options similar to those in MS Word
2. Remove the unnecessary tabs

Logging should be available to all engine objects .. and it should be directed to the console and a log file at the same time

Provide overload for each condition checking

SuccessConditionSatisifed(const RtsGame* pGame);

..
etc..

This method should replace all these methods

AdaptWorkerForBuild
AdaptBuildingForTraining
AdaptAttacker
AdaptTargetEntity
AdaptEntityToMove

The method signatures will be like this

TID GetEntityObjectId(entityClassId, rankedStates)
TID GetEntityObjectId(entityClassId) // i don't care about the state just get the first unlocked entity

For the states, the class should provide default rankedStates so users can use them directly without defining new states:

pAdapter->GetEntityObjectId(_attackerId, AdapterEx::AttackerStates)

The success conditions is that the research is available to be done

15 case or more with all required actions to play a complete game

Scenario:
CaseA with the following plan build steps: Build B1, Build B3, Build B3
CaseB with the following plan build steps: Build B1, Build B4, Build B6
Where B1, B2, B3, etc.. is a building type.

• CaseA is retrieved and its plan starts expansion and execution.
• Build(B1) succeed
• Build(B3) fail
• CaseA goal fail due to Build(B3) failure
• CaseB is retrieved and its plan starts expansion and execution
• Build(B1) succeed
• Build(B4) succeed
• Build(B6) succced

Output::
The engine has
2 buildings of type B1
1 building of type B3
1 building of type B4

Problem:
The engine shouldn't have built another B1 since B1 already exist and was built, it should have deduced this and mark B1 as succeeded without executing it and proceed to Build B3

Solution:
The planner should deduce the post-conditions of a give plan, and on replacing a current plan with another, actions should be evaluated for know which post condition are satisfied so as not to re execute that action that satisfy this post-condition again.

Example:
Post conditions of CaseA are: having 1 B1 and 2 B3
Post conditions of CaseB are: having 1 B1, 1 B4 and 1 B6

On applying CaseB plan after failure of CaseA, we will find that they intersect in 1 B1 which is satisfied, so we continue expansion and execution to satisfy B4 and B6 steps.

Including making TechTree cloneable and can run offline