Programmazione del gioco senza un ciclo principale

Question

Il mio professore ha dato alla mia classe un incarico oggi basato sulla programmazione orientata agli oggetti in Pygame. Fondamentalmente ha detto che il gioco che creeremo sarà privo di un ciclo di gioco principale. Mentre credo che sia possibile farlo (e this question ha dichiarato che è possibile) Non credo che ciò sia necessario per aderire al paradigma Object Oriented.

In un diagramma che il professore ha dato, ha mostrato l'inizializzazione del gioco e mentre gli oggetti venivano istanziati il ​​flusso di controllo del programma sarebbe stato distribuito tra gli oggetti.

Fondamentalmente credo che sarebbe possibile implementare un gioco in questo modo, ma non sarebbe un modo ideale né è richiesto per l'aderenza Object Oriented. qualche idea?

EDIT: Stiamo creando un clone di asteroidi, che a mio avviso complica ulteriormente le cose a causa del fatto che si tratta di un gioco d'azione in tempo reale.

Answer 1

I giochi a turni o qualsiasi evento guidato sono la strada da percorrere. In altre parole, prendi le app della GUI desktop. Faranno semplicemente segno di spunta (attendere) finché non viene attivato un evento. Lo stesso potrebbe essere fatto per un semplice gioco. Prendi Dama ad esempio. Fare il ciclo di ogni ciclo di gioco sarebbe eccessivo. Il 90% delle volte il gioco sarà statico. L'utilizzo di una qualche forma di eventi (il modello observer design sarebbe bello qui) fornirebbe una soluzione molto migliore. Stai usando Pygame, quindi potrebbe esserci un supporto per questo integrato, a causa del mio uso limitato non posso commentare completamente. Ad ogni modo, i principi generali sono gli stessi.

Tutto sommato è un bel po 'di spazzatura se me lo chiedi. Se vuoi insegnare la programmazione guidata dagli eventi, una semplice applicazione GUI sarebbe meglio. Anche il più semplice dei giochi è un loop di gioco di base, che può aderire ai principi OO.

Answer 2

Penso che possa qualificarsi come programmazione guidata dagli eventi? Quale può ancora essere orientato agli oggetti. Lo vedi in Flash molto.

C'è una differenza tra un ciclo principale in una classe principale. Puoi ancora fare in modo che una classe di gioco inizializzi tutti i tuoi oggetti e poi fare affidamento sugli input per spostare il gioco in avanti.

Difficile dire esattamente senza conoscere i parametri esatti del tuo incarico, il diavolo è nei dettagli.

Answer 3

Si potrebbe vedere come Python utilizza i segnali. Un esempio decente che ho trovato è: http://docs.python.org/library/signal.html

Answer 4

Hmm. Nel caso generale, penso che questa idea sia probabilmente hokum. SDL (su cui PyGame è implementato) fornisce informazioni al programma tramite una coda di eventi e il consumo di tale coda richiede una sorta di controllo ripetuto della coda per gli eventi, elaborazione e attesa dell'arrivo del prossimo evento.

Ci sono alcune eccezioni particolari a questo, però. È possibile eseguire il polling del mouse e della tastiera per il loro stato senza accedere alla coda eventi. Il problema è che richiede ancora qualcosa come un ciclo, in modo che accada più e più volte fino alla fine del gioco.

È possibile utilizzare pygame.time per attendere un timer invece di attendere sulla coda eventi e quindi passare il controllo agli oggetti di gioco che eseguono il polling del mouse e della tastiera come sopra, ma si sta ancora "eseguendo il ciclo", ma vincolati da un timer invece della coda degli eventi.

Invece di concentrarsi sull'eliminazione di un ciclo principale, che dire invece di pensare di usarlo in un modo orientato agli oggetti.

Ad esempio, è possibile richiedere un oggetto "root", che in realtà ha un proprio ciclo di eventi, ma invece di eseguire qualsiasi azione in base agli eventi in ingresso, chiama un gestore su diversi oggetti figlio. Ad esempio, quando l'oggetto radice riceve un evento pygame.event.MOUSEBUTTONDOWN, può cercare attraverso i suoi figli un attributo 'rect' e determinare se l'attributo event.pos si trova all'interno di tale rettangolo. se lo è, può chiamare un ipotetico metodo onClick su quell'oggetto figlio.