[DISCUSSION] Code architecture

[dmitmel]

This is a thread for discussing general things about code architecture in Asciimon. Code architecture means usage of structs and traits, relationships between structs, patterns etc.

THIS IS A DISCUSSION, DO NOT CLOSE!!!

[dmitmel]

@Hopson97

So, the GameState trait has two methods: process_input and update. Both of them return ReturnResult. But: when we handle these results in the main loop, some things become uncertain:

1. Should we skip update if process_input returns something (i.e. any state except None)?
2. Should we run both functions first and then handle both results?
3. What should do on conflicts?

So what I suggest: since we rely on user input for updating the game state, let's just put input processing into update and remove process_input

[Hopson97]

These are good points, was something I was wondering about (sort of) myself), but you have outlined the issue well.

However, not sure if I like the idea of combining the update and input functions, as the two functions have are suppose to have different purposes and that. That being said, it does seem to look like it works fine, but I'll have to think about it.

I do like the use of slice pattern matching, I didn't know you could do that 😄

[Hopson97]

Also, not all input will be for updating the game. For example, when the player opens their bag, it will rather push a state to the game struct for the player too look on their bag. (This example would return a 'PushState(Box::new(BagMenuState::new()))' for the return result).

In this case, I guess skipping update when this happens is probably a good idea.

[dmitmel]

@Hopson97 No, the idea is that game can't do anything before the user inputs a command, so update won't be called without process_input, therefore they're tightly coupled. Also, look at the explore state handler: merging these two functions simplifies the code a lot.

And also, here's how I would do opening the bag:

impl ExploreState {
    // bla-bla-bla

    fn update(&mut self, input_args: &[&str]) -> ReturnResult {
        match input_args {
            ["bag"] => {
                PushState(Box::new(BagMenuState::new()))
            }

            // bla-bla-bla
        }
    }
}

impl BagMenuState {
    // bla-bla-bla

    fn update(&mut self, input_args: &[&str]) -> ReturnResult {
        match input_args {
            ["close"] => {
                PushState(Box::new(ExploreState::new()))
            }

            // bla-bla-bla
        }
    }
}

[Hopson97]

Good points.

This is the sort of thing that would be interesting a video :p

The only issue I have now is the function is called update() when it does more than just update, so we just need a better name I guess

[dmitmel]

@Hopson97 Well, well, well... Maybe, handle_command? Or handle_input? (Personally, I like the first one)

BTW, here's a PR with these changes.

[dmitmel]

@Hopson97 Just a small request (i don't want to open an issue): could you format the code with rustfmt, please?

[Hopson97]

Done

[dmitmel]

Thanks