Grazie dei consigli, ho preso due manualetti per cominciare, uno per C# ed uno per VB6.

Permettimi di romperti per l'ultima volta le scatole ^^ Ho bisogno di capire come devo mutare il mio modo di pensare e soprattutto capire che c'è una soluzione anche se io al momento non riesco a trovarla.
Userò l'esempio del mio programma. Non so se tu conosci il Poker, spero di si, perchè qui l'esempio della difficoltà è molto calzante. Tieni conto che uso VB da pochi giorni e che passo direttamente dal Basic di 20 anni fa... allora:

Io (giocatore) Punto, ho il mio bel pulsante al cui click inizia il mio codice. Una volta puntato, i 3 giocatori gestiti dal PC, decidono se aprire, quindi devo inserire una routine che gestisca l'apertura di seguito a questa routine legata al pulsante "Punto".
Ora nessuno apre, la parola tocca a me che ho la possibilità di passare o aprire: Passo.
Il PC diventa mazziere e punta (questa routine di puntata è scritta quindi anche nel pulsante "Passo" e già era scritta nel pulsante "Punta"), i PC devono decidere se aprire o meno (quindi serve una routine di apertura legata al pulsante "Passo", ma una era già scritta nel pulsante "Punta").
Con l'aggiunta di altre complicazioni (rilancio, buio, controbuio), mi troverei a riscrivere continuamente routine simili e complicando sempre di più i vari pezzi di codice con sub-routine che dovrebbero regolare più eventi tra l'altro già regolati da altre routine.

La soluzione con il vecchio sistema era semplice: c'è un flusso di dati principale che si snoda tra le varie fasi del gioco, da qui si diramano le varie sub-routine che regolano gli eventi, per poi ritornare nel flusso principale che regola gli eventi principali.
Il diagramma di flusso posso progettarlo ad inizio progetto.

Ma con VB (che è l'unico per adesso che ho provato ad usare), che approccio dovrei avere con questi problemi? Come potrei farmi un progetto iniziale?