Wappo game on FBD or a moment of kindness
Welcome all.
This post will be about how to write the next simplest toy in the FBD programming language (of course, this implementation of the programming language deviates from the FBD standards, but most of the "special features" are not used, so the written program can be easily transferred to the classic FBD in any system), load the program into the controller and indulge in the memories of the beginning of the two thousandth.
Recently, a conversation started with one of our colleagues about the beginning of the two thousandth, and for some reason I remembered our first Siemens mobile phones and the Wappo game. As a result, the idea was born to write this toy by myself using the design tools of the Quint 7 software and hardware complex. Because great effort and a lot of time for this was not required, then here is the result:
Two halves of lunch breaks (together with drinking coffee) and a couple of hours in the evening for drawing pictures in MS Paint were spent on this whole thing.
In the game "Wappo" the size of the playing field is 6x6 cells. In the initial position on the field are:
In this case, the player in one move can move his character by one cell in any direction, provided that he has no wall in the way. The monster moves two squares per turn towards the player’s character. In this case, priority is given to horizontal movement. If the monster cannot move (there is a wall in his path), then he skips the move.
The game is considered a completed victory if the player managed to bring his character to the cage with the house, and defeat if the monster on its own stood on the same square where the player’s character is.
Let's start, as usual, with the technological program for the controller.
The entire program will consist of five large blocks:
Let us consider in more detail each of these blocks.
General view of game control algorithms:
Everything is simple here. For control two algorithms of "Rucselektor" are used. The first algorithm is used to start and stop the game, as well as to submit commands for the movement of the man. The selector works on the principle of "one of n". The duration of the output signal generation is 1 ms (i.e., one controller cycle). The first exit (the "start" button) cockes the trigger "There is a game." While the trigger is cocked, all other commands are processed. At the same time, the same output gives a command to the control blocks of moves to set the initial position of the level. The second output resets all the triggers in the game (including the main trigger “Game in progress”) and clears all memory elements.
The second “Hand Selector” algorithm is used to select a level. As you can see from the picture, three levels are currently implemented. Accordingly, if the number of levels increases, then at the same time it will be necessary to increase the algorithm modifier. At the output of the second selector there is a simple circuit that checks the selected value and if the player started the game without selecting a level (the output value is zero), forcibly assigns the first level.
Two more algorithms, “visibility” and “blocking,” are used to display / hide some graphic elements, as well as to set the block to give commands to the player. Why this lock is needed will be explained below.
General view of the macro "cell"
The processing of conditions itself is primitive. As you and I found out a little higher, each cell forms signs of the prohibition of movement in a certain direction, as well as signs of victory and defeat in the game. Further, all these signs are simply collected using a logical "OR" for use in the moves processing algorithm.
The player’s move processing block itself is very simple:
Two identical threads for processing vertical and horizontal movements.
Let's consider the first in more detail:
That's all the processing. Simple and clear.
Here it’s even easier than with the player’s move:
And there are not so many left, just a few algorithms.
- “Starting position” algorithm:
It sets the coordinates of the walls, the house and the initial position of the player’s character and the tomato. At the moment there are three such positions (three levels in total), but just adding a modifier to the algorithm and driving in new coordinates, you can increase the number of levels to three hundred without any alterations to the main program.
- distribution block of the current coordinate of the player’s character and tomato:
Here, too, everything is simple. The corresponding vector is transmitted to the current line number, then decomposed into bits and the resulting logical signals go to their “Cell” algorithms.
After all the blocks are ready, we can only compose them (i.e. nicely arrange them in the field) and the program is ready:
This graphic part took most of the time. It was necessary to search the Internet for pictures, paint them to fit your size. Some of the pictures could not be found right away, and it turned out that they were easier and faster to draw in Paint itself. But one way or another, the set of pictures was over and the rendering of the gameplay itself went on, which took about five minutes. We make one element (cell). Add animation of contents and walls to it. Copy 35 times and get the finished field. We outline around the brick wall, add a couple of inscriptions and buttons for control and you're done.
In this example, we made a classic game, but a quick search on YouTube showed that a lot of things were invented in the game. It is not difficult to do this on the basis of the above program, but I did not begin to do this in order not to clutter up the foundation.
Let's try to evaluate offhand what and how of the additional features you can implement:
The program is ready and works fine. The basis of the program allows you to expand it without drastic changes. At the same time, very little time was spent on “programming” itself. Moreover, programming in the FBD language (graphical programming language of the IEC 61131-3 standard) is simple, understandable and does not require deep knowledge. All that is needed is to master elementary logic and mathematics at the school level and to know how the simplest algorithms such as triggers and counters work.
That's all. I hope it was interesting.
This post will be about how to write the next simplest toy in the FBD programming language (of course, this implementation of the programming language deviates from the FBD standards, but most of the "special features" are not used, so the written program can be easily transferred to the classic FBD in any system), load the program into the controller and indulge in the memories of the beginning of the two thousandth.
Recently, a conversation started with one of our colleagues about the beginning of the two thousandth, and for some reason I remembered our first Siemens mobile phones and the Wappo game. As a result, the idea was born to write this toy by myself using the design tools of the Quint 7 software and hardware complex. Because great effort and a lot of time for this was not required, then here is the result:
Two halves of lunch breaks (together with drinking coffee) and a couple of hours in the evening for drawing pictures in MS Paint were spent on this whole thing.
Formulation of the problem
In the game "Wappo" the size of the playing field is 6x6 cells. In the initial position on the field are:
- House (or exit) - the goal of the game is to lead your character into this cell without getting caught by the enemy. In our version, this cell is indicated by a house with a lawn and a blue sky;
- A monster is an adversary who seeks to catch a player. In our version, it is a tomato;
- Player - the character of the player to be taken to the house. In our version, this is a cheesy little man;
- Walls - obstacles between cells that prohibit the passage of a player and a monster into an adjacent cell.
In this case, the player in one move can move his character by one cell in any direction, provided that he has no wall in the way. The monster moves two squares per turn towards the player’s character. In this case, priority is given to horizontal movement. If the monster cannot move (there is a wall in his path), then he skips the move.
The game is considered a completed victory if the player managed to bring his character to the cage with the house, and defeat if the monster on its own stood on the same square where the player’s character is.
Implementation
Let's start, as usual, with the technological program for the controller.
The entire program will consist of five large blocks:
- Control;
- Player turn processing;
- Tomato stroke processing;
- Field cell processing;
- Processing conditions;
Let us consider in more detail each of these blocks.
Control
General view of game control algorithms:
Everything is simple here. For control two algorithms of "Rucselektor" are used. The first algorithm is used to start and stop the game, as well as to submit commands for the movement of the man. The selector works on the principle of "one of n". The duration of the output signal generation is 1 ms (i.e., one controller cycle). The first exit (the "start" button) cockes the trigger "There is a game." While the trigger is cocked, all other commands are processed. At the same time, the same output gives a command to the control blocks of moves to set the initial position of the level. The second output resets all the triggers in the game (including the main trigger “Game in progress”) and clears all memory elements.
The second “Hand Selector” algorithm is used to select a level. As you can see from the picture, three levels are currently implemented. Accordingly, if the number of levels increases, then at the same time it will be necessary to increase the algorithm modifier. At the output of the second selector there is a simple circuit that checks the selected value and if the player started the game without selecting a level (the output value is zero), forcibly assigns the first level.
Two more algorithms, “visibility” and “blocking,” are used to display / hide some graphic elements, as well as to set the block to give commands to the player. Why this lock is needed will be explained below.
Field Cell Processing
General view of the macro "cell"
Macro Content and Short Description
The macro has 5 inputs and 7 outputs:
The macro has 5 inputs and 7 outputs:
Inputs
- Walls - five logical signs of the presence of a cell walls top / right / bottom / left, as well as a sign that this cell is a "house". These signs are static and are set once at the start of the level;
- Position is an unnecessary input. He left it just for clarity. The point is that each cell must check the possibility of movement to neighboring cells and issue appropriate locks (up_bans / right_bans / down_bans / left_bans). But motion blocking occurs not only when there is a wall between adjacent cells, but also when the cell is on the edge of the field. For example, from a cell with coordinates (1; 1) it is forbidden to move up and to the left (since there is no longer a playing field there). In the current version, to check this condition, the macro uses 4 comparison algorithms that compare the cell coordinate in a row and column with 1 and 6 and form the corresponding prohibitions. However, attentive readers will immediately say that it is possible to simplify the algorithm by removing these comparisons and assigning “virtual walls” to the extreme cells from the side of the field edge.
- The player’s move is a logical sign that the player’s move is currently taking place. On this basis, blockages are checked separately for the player and tomato;
- Cheese - a logical sign that the player’s character is in this cell;
- Tomato is a logical sign that an evil tomato is in this cell.
Outputs:
- Prohibition_U / R / B / L - prohibition of movement in the corresponding direction;
- The output is the main parameter of the cell. Used to display the state of the cell in the graphic part. 0 - the cell is empty, 1 - the player’s character in the cell, 2 - in the tomato cell, 3 - in the house cell. This output is formed sequentially by three selection algorithms (algorithms 5.6 and 7);
- Escaped - a logical sign that the player’s character got into the cage with the house and the level is passed;
- GameOver - a logical sign that the tomato caught up with the player’s character and the game is lost;
Condition processing
The processing of conditions itself is primitive. As you and I found out a little higher, each cell forms signs of the prohibition of movement in a certain direction, as well as signs of victory and defeat in the game. Further, all these signs are simply collected using a logical "OR" for use in the moves processing algorithm.
Condition processing
A few words about the rest of the algorithms (there should be no questions with the "OR" algorithms).
So, in addition to several “or” algorithms, several triggers and the “Delay” algorithm are used in the processing. The main trigger here is “Player Turn.” This trigger is cocked at the start of the game. After the player makes a successful move, this trigger is reset, and processing of the tomato move begins. In order for the actions of the tomato to be more or less clear, an algorithm of three consecutive delays of 200 ms was applied. As soon as the player makes a successful move, the “Player Turn” trigger is reset and at the same time the impulse along the opposite front arrives at a delay of 200 ms. After counting the time, the tomato takes the first of two steps and starts the next timeout again for 200 ms. Then the tomato takes its second step and starts the timeout again for 200 ms. After the third time delay, the “Player Turn” trigger is cocked and control is transferred to the player.
All of the above is done only so that the opponent’s moves are not instantaneous, but are displayed sequentially on the screen. This is much nicer and more convenient than seeing an instant change of position. For the duration of all these delays, a lock sign is set so that the player sees that the computer is “thinking” and does not press the control buttons once again. In logic, everything is fine and no extra commands will pass, but in a person this usually causes bewilderment: “How so? I press, but it doesn’t react! ” It is better to get rid of such situations.
A few words about the rest of the algorithms (there should be no questions with the "OR" algorithms).
So, in addition to several “or” algorithms, several triggers and the “Delay” algorithm are used in the processing. The main trigger here is “Player Turn.” This trigger is cocked at the start of the game. After the player makes a successful move, this trigger is reset, and processing of the tomato move begins. In order for the actions of the tomato to be more or less clear, an algorithm of three consecutive delays of 200 ms was applied. As soon as the player makes a successful move, the “Player Turn” trigger is reset and at the same time the impulse along the opposite front arrives at a delay of 200 ms. After counting the time, the tomato takes the first of two steps and starts the next timeout again for 200 ms. Then the tomato takes its second step and starts the timeout again for 200 ms. After the third time delay, the “Player Turn” trigger is cocked and control is transferred to the player.
All of the above is done only so that the opponent’s moves are not instantaneous, but are displayed sequentially on the screen. This is much nicer and more convenient than seeing an instant change of position. For the duration of all these delays, a lock sign is set so that the player sees that the computer is “thinking” and does not press the control buttons once again. In logic, everything is fine and no extra commands will pass, but in a person this usually causes bewilderment: “How so? I press, but it doesn’t react! ” It is better to get rid of such situations.
Player Turn Processing
The player’s move processing block itself is very simple:
Two identical threads for processing vertical and horizontal movements.
Let's consider the first in more detail:
- Algorithms "And" 69 and 70 check the assembly of conditions for moving up and down, respectively. If the first trigger “Game in progress” is cocked, the second trigger “Player move” is cocked, a command came from the third for moving up or the fifth for moving down the output of the control Selector and there is no blocking of movement in this direction, then
- On the “Choice” algorithms 71 and 72, depending on the triggered condition, either “+1” or “-1” is transmitted to the current coordinate;
- Using the “Choice” algorithm 73, it is verified that the signal to start the game has come to us and we need to set the starting position. Otherwise, the command generated earlier is transmitted;
- On the “Addition” algorithm, the new value is added to the value stored in the feedback and a new coordinate is obtained;
- Using the “selection” algorithm 75, it is checked that a reset signal has come to us (the second output of the control selector) and, if it arrives, the value stored in the feedback is reset;
- From the output of the “Addition” algorithm, the new coordinate of the player’s character goes to the “Distribution” block, through which it enters the corresponding cell;
- The "OR" 85 algorithm is needed to determine that we had a coup. Those. if all four conditions on one of the four “Is” have come together, then the player has made a successful move (successful not in the sense of “good”, but in the sense of “permitted by the rules”), and it’s time for us to discard the “Player Turn” trigger and pass the tomato move.
That's all the processing. Simple and clear.
Tomato Stroke Processing
Here it’s even easier than with the player’s move:
- The “OR" 89 algorithm (which by the way is not needed here and is left for illustration only) receives a pulse delayed for 200 ms from the opposite front to reset the "Player Turn" trigger (remember this thing in the condition processing block?). Next, the current coordinate of the tomato and the current coordinate of the player’s character are compared. Based on the comparison, the “+1” or “-1” command is formed for horizontal and vertical movement. Next, the conditions for the horizontal move are checked (“I” algorithms 93 and 94, here the check is similar to processing the player’s move, except that the “Player’s move” trigger must be reset) and the team is transferred to the “Addition” algorithm through a similar selection chain 101;
- If the conditions for the ability to move horizontally have not been fulfilled, then this inverse feature is fed to the algorithms “I” 106 and 107, where the remaining conditions for the possibility of vertical progress are checked;
- After the move is made, the timer counts down for another 200 ms (the “Delay” algorithm 90), after which all the logic is checked again for the second tomato step and the third timer (“Delay” algorithm 91) starts for 200 ms;
- Upon the triggering of the third timer, the “Player Turn” trigger is triggered;
- Another difference from the player’s move processing scheme is that Addition 98 and 111 are used to determine the direction of movement of the tomato (up-down or left-right). Because at the same time, both conditions in comparison cannot be fulfilled, we can simply add our teams (one of the terms will always be zero), getting the desired direction of movement at the output.
A few words about what remains behind the scenes
And there are not so many left, just a few algorithms.
- “Starting position” algorithm:
Kind of algorithm
It sets the coordinates of the walls, the house and the initial position of the player’s character and the tomato. At the moment there are three such positions (three levels in total), but just adding a modifier to the algorithm and driving in new coordinates, you can increase the number of levels to three hundred without any alterations to the main program.
- distribution block of the current coordinate of the player’s character and tomato:
Distribution of current coordinates
Here, too, everything is simple. The corresponding vector is transmitted to the current line number, then decomposed into bits and the resulting logical signals go to their “Cell” algorithms.
General view of the technical program
After all the blocks are ready, we can only compose them (i.e. nicely arrange them in the field) and the program is ready:
The final program. Drawing is very large
We fasten the graphic part
This graphic part took most of the time. It was necessary to search the Internet for pictures, paint them to fit your size. Some of the pictures could not be found right away, and it turned out that they were easier and faster to draw in Paint itself. But one way or another, the set of pictures was over and the rendering of the gameplay itself went on, which took about five minutes. We make one element (cell). Add animation of contents and walls to it. Copy 35 times and get the finished field. We outline around the brick wall, add a couple of inscriptions and buttons for control and you're done.
Original Figure (game not yet running):
It looks like a hash of elements where nothing is clear. But you need to take into account the fact that when the program is running, some of the elements will be hidden depending on the conditions, and in general the picture will be simple and clear.
It looks like a hash of elements where nothing is clear. But you need to take into account the fact that when the program is running, some of the elements will be hidden depending on the conditions, and in general the picture will be simple and clear.
Launched:
It can be seen here that after starting the mode of viewing data from the controller, some of the elements became invisible, thereby eliminating the hash that we had in the drawing mode.
It can be seen here that after starting the mode of viewing data from the controller, some of the elements became invisible, thereby eliminating the hash that we had in the drawing mode.
We play:
We lose:
And we win:
Unrealized
In this example, we made a classic game, but a quick search on YouTube showed that a lot of things were invented in the game. It is not difficult to do this on the basis of the above program, but I did not begin to do this in order not to clutter up the foundation.
Let's try to evaluate offhand what and how of the additional features you can implement:
- Game options (or levels) with two monsters. No problem. In the “Cell” macro, one more logical sign is added that “tomato 2” is in the cell. Two more coordinates of the “tomato 2” starting position are added to the starting position. The tomato stroke processing unit is copied and attached to these outputs. The coordinate distribution block is also copied and attached to the added input in the “Cell” macro. All. The approximate implementation time is ten minutes (to put everything neatly). The only question is: what to do if during the game both tomatoes occupy the same cell. And can they do it at all? But this is already a question regarding the rules of the game.
- Game options (or levels) with traps. No problem. After the player’s successful move, the “Player Turn” trigger is reset and processing of the tomato move starts on this reset. All that’s needed is to add a sign to the macro “Cell” that there is a trap in this cell. When it gets into it, a trigger to prohibit the course is cocked and a pulse counter is started to process the course of the tomato. While the trigger is cocked, this signal is not transmitted to the stroke processing unit (it is enough to add it along the “and” with the inverted trigger output). The prohibition trigger is reset when the counter reaches the specified number of moves by the counter of missed moves. The approximate implementation time is about ten minutes.
- Teleport Cell. In certain versions (or levels) of the game, there are two marked cells, when hit, the player’s character is teleported to the second cell. Again, this function is implemented without problems. We need one logical sign at the input of the "Cell" macro, that there is a "teleport" in this cell. In the player’s move processing block, another “Choice” algorithm is added, which, when hit on this teleport cell, substitutes the coordinates of the cell connected to it at the input of the “Addition” algorithm. Implementation time - about ten minutes.
- The number of levels. New levels are added elementary. The modifier on the "Selector" algorithm increases and the modifier of the "Start_position" algorithm increases accordingly. Next, the initial coordinates of the walls, the house, the tomato and the player are driven in and everything is ready. Implementation time - depends on the number of levels that need to be added. It took me just a few minutes to add two levels.
Brief Summary
The program is ready and works fine. The basis of the program allows you to expand it without drastic changes. At the same time, very little time was spent on “programming” itself. Moreover, programming in the FBD language (graphical programming language of the IEC 61131-3 standard) is simple, understandable and does not require deep knowledge. All that is needed is to master elementary logic and mathematics at the school level and to know how the simplest algorithms such as triggers and counters work.
That's all. I hope it was interesting.