Skip to content
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

Swoosh2 Rewrite ActionLists #26

Open
TheMaverickProgrammer opened this issue Jul 18, 2024 · 0 comments
Open

Swoosh2 Rewrite ActionLists #26

TheMaverickProgrammer opened this issue Jul 18, 2024 · 0 comments

Comments

@TheMaverickProgrammer
Copy link
Owner

TheMaverickProgrammer commented Jul 18, 2024

In original Swoosh, the Actions for an ActionList required the user to allocate on the heap while the ActionList deleted memory for the user. This is not intuitive. Generally the expectations are that, if a user allocates memory, then they must also delete their own memory too. Therefore a clearer API would use smart pointers and constructs to do this behind-the-scenes as Swoosh's mission statement is to let the user be free of any memory management and one of the reasons why segue effects are wrapped in meta template syntax.

Similarly, ActionList type and constructor arguments can be bound, but not allocated on the heap until needed. This is not a complete example, but for illustrative purposes describes what I mean:

auto checkHealth = [this]() {
    return creatureHealth > 0;
};

sw::ActionListBuilder builder = { 
   sw::Concurrent<AttackAction>(3.0, &decalSpr),
   sw::Blocking<WaitForInput>(Input::Key_Enter),
   // args: query func, list if true, list if false
   // both lists are intentionally std::nullopt for this example
   sw::Conditional(checkCreatureHealth, std::nullopt, std::nullopt),
   ...
... };

while(actionList.empty() == false) {
    sw::ActionRef currAction = actionList.top();
    currAction.tick();
    
    //Later, a conditional execution path changes the next actions
   if(currAction.is<sw::Conditional>()) {
    sw::ConditionalRef branch= currAction.as<sw::Conditional>();
    if(condition.isTrue()) {
       actionList.clear();
       // Do something else
    } else {
        actionList.insert(actionList.begin(), builder.buildList());
    }
}

The idea is that all memory management is safe and hidden away from the user. They should receive primitive-like handles which wrap the complex logic. Only when a direct call to buildList() should any of the "registered" action metadata allocate memory for those Actions.

It's debatable whether or not the ActionList itself needs to be a UDT type at all as it can be represented by std::stack or some other satisfactory data structure. Mutation of the list could occur in the underlining class of the sw::ActionRef itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant