Things to do before starting to code
Rather than use a lot of superfluous words, let me cut straight to it, to have structured program, you need to have an outline of what you are intending to do, this gives a framework and helps solve issues which make programming easier, so let's start with sketching an outline.
Here's a sample from one really old book on Basic programming, where the example is provided on writing the steps for a simple Noughts and Crosses program. The program is build in phases and though this may produce more lines of code than normal, this will help debug and improve each of the modules easily.
Setup Initial Board Computer Move (A) Check if Middle Square Empty, If not move there (B) Check if there is a computer winning move, if so make it (C) check if human will win on next move, If so block (D) if no moves are made, check to see if a random move can be made, if so make it if not declare a draw Print Board Accept Player Move Print Board Check if player has won, if so Stop Goto Computer Move
You can see that the outline has provided quite a clear idea of how and what the game will do and all expected alternative actions to be taken (if any)
The second step in this process is to turn the sketched outline into a series of calls as follows
10 REM NOUGHTS AND CROSSES 20 GOSUB 9000: REM Initialise 30 GOSUB 1000: REM Computer Move 40 GOSUB 8000: REM Print Board 50 GOSUB 2000: REM Accept player Move 60 GOSUB 8000 REM Print Board 70 if human has not won AND computer has not won THEN GOTO 30 80 PRINT "Congratulations"
This is the ancient Basic code, this can be translated to modern day languages as functions, so each of the GOSUB routines can be translated to functions and so in Lua the same code would read as
--Noughts and Crosses initialise() repeat computerMove() printBoard() playerMove() printBoard() until (hasHumanWon == false and hasComputerWon == false) congratulate()
Again there are some differences between the languages and the way the programs worked in those days vs the technologies and the way the apps work today. There was no event based programming and everything was run from a central dispatch loop, which kind of controlled everything. In the modern applications, touches/player inputs are independent of the loop and can fire anytime.
The subroutines can be then further enhanced to work modular as
2000 REM Computer Move 2010 LET move = 0: REM if this is 1 then a valid move is found 2020 GOSUB 2200: REM check if middle square is empty 2030 IF move = 1 THEN RETURN 2040 GOSUB 2400: REM check if a possible move exists 2050 IF move=1 THEN RETURN 2060 GOSUB 2600: REM check if a possible Human win can be blocked 2070 IF move=1 THEN RETURN 2080 GOSUB 2800: REM check if any move at all can be made 2090 IF move=1 THEN RETURN 2100 REM a return with move=0 means no further moves are possible 2110 RETURN
So you see that it makes good sense to flesh out the structure and adding/changing anything is much easier than wading through spaghetti code.
I cite this example as I feel that the authors at the time did a very good job in explaining things, Universities and Schools are now run with teachers, that are not exactly qualified or educated in this discipline and the man's best friend, no not a dog, Google is not very helpful in teaching basics as today is the age of I want it all and I want it now.
I did not even touch upon the flowchart, which was what the era prior to this structured outline asked for. So if you can put together a visual plan on paper before coding starts, it is easier to work/manage it better.
Hope there was something that you could get out of it.