After a lot of refactoring, the first extra match state is working: Throw-ins.
Sunday, 21 February 2016
Saturday, 20 February 2016
Camera Height
In the sensi tradition, gameplay over graphics. The pulled out camera makes the sprites smaller, but easier to see team mates and build passing moves without having to look at a radar.
Doing Lines
Made the pitch markings a bit smoother. They are rendered on the fly to allow for custom size pitches.
Just for fun, a checked pitch texture:
Just for fun, a checked pitch texture:
Sunday, 7 February 2016
Back at It
So after a bit of a break for the xmas hols and an extra-busy month in work, development is back underway for Senseless! Yay!
To ease use back in, we're doing a bit of refactoring. Right now the player states are controlled in a top-down hierarchy, so the team state sends a message to the players to tell them what to do.
This is a bit (very) messy because it really makes the state machine too complicated to manage. Instead of each individual state strictly controlling it's behavior, it can be randomly "messaged" to change from outside. We don't like this.
Much better is a bottom-up mechanism. So the player "surveys" his environment and decides for himself what to do.
For example, in a throw-in match state, the team will not look up it's throw in taker and then send a message to that player to take the throw in. Instead, the player will recognize his team is in the throw-in state, and he will check to see if he is the designated throw in taker, then trigger the state change to take the throw-in. Much nicer me thinks.
Instead of continuously checking the match state, later we might want to turn this into an "observer" pattern. Normally I don't like to overload on patterns but here I think it makes a lot of sense. The player "observes" the state of the match. Seems pretty intuitive.
Just a reminder, the state of the game: (the flickering is only in the video cap. Honest!)
To ease use back in, we're doing a bit of refactoring. Right now the player states are controlled in a top-down hierarchy, so the team state sends a message to the players to tell them what to do.
This is a bit (very) messy because it really makes the state machine too complicated to manage. Instead of each individual state strictly controlling it's behavior, it can be randomly "messaged" to change from outside. We don't like this.
Much better is a bottom-up mechanism. So the player "surveys" his environment and decides for himself what to do.
For example, in a throw-in match state, the team will not look up it's throw in taker and then send a message to that player to take the throw in. Instead, the player will recognize his team is in the throw-in state, and he will check to see if he is the designated throw in taker, then trigger the state change to take the throw-in. Much nicer me thinks.
Instead of continuously checking the match state, later we might want to turn this into an "observer" pattern. Normally I don't like to overload on patterns but here I think it makes a lot of sense. The player "observes" the state of the match. Seems pretty intuitive.
Just a reminder, the state of the game: (the flickering is only in the video cap. Honest!)
Monday, 18 January 2016
Subscribe to:
Posts (Atom)
