Topic: Un framework di sviluppo su pygame :|  (Letto 5397 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Amati

  • python unicellularis
  • *
  • moderatore
  • Post: 44
  • Punti reputazione: 0
    • Mostra profilo
Un framework di sviluppo su pygame :|
« il: Giugno 03, 2009, 11:56 »
Salve ho visto che ci sono alcune soluzioni (pygsear).
Pero' avevo in mente, o meglio sto gia facendo, una serie di librerie per velocizzare lo sviluppo. Volevo sapere se qualcuno si e' trovato difronte a problematiche dove ha dovuto "pastrugghiare" un mo di tempo.
O cmq soluzioni che nn sembrano pulite da poter migliorare.
Es io mi sono trovato molto spesso a sbattere la testa su come dispatchare gli eventi, creare una maniera pulita di passare la gestione degli eventi ai rispettivi oggetti su cui si interagisce e qualcosa l'ho inventata :D
molto + facile gestire ora gli eventi su gui e oggetti del gioco.
tra nn molto linko il git dove e' il progetto, cmq questo 3d era rivolto a chi avuto a che fare con pygame e avrebbe sempre voluto qualche funzione veloce che nn c'e' e sarebbe servita :|
quindi postate le vostre idee che se sono fiche le metto nel framework, un po come fa quello del perl che chiede agli utilizzatori le funzioni che vorrebbero :D

Offline Simosito

  • python sapiens sapiens
  • *
  • moderatore
  • Post: 2.072
  • Punti reputazione: 1
  • Vuoi la risposta rapida o quella veloce?
    • Mostra profilo
    • Simosito
Re: Un framework di sviluppo su pygame :|
« Risposta #1 il: Giugno 03, 2009, 12:30 »
Ottima idea!
Perché non marchi la discussione come importante per dare maggiore visibilità?

Offline Amati

  • python unicellularis
  • *
  • moderatore
  • Post: 44
  • Punti reputazione: 0
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #2 il: Giugno 03, 2009, 15:02 »
Visto che parlavo degli eventi io li ho pensati cosi...

Una classe singleton gestisce la scena, con una lista di oggetti da renderizzare (che estendono un mio oggetto disegnabile) e una coda di eventi strutturati.
Una parentesi sugli oggetti da disegnare: la classe singleton lancia una draw globale, cioe' ciclando su tutti gli oggetti chiama su ognuno di essi il metodo draw, quindi ogni oggetto gestisce il suo disegno, alla fine fa il refresh della scena (ovviamente estendendo un mio oggetto esisono dei flag che fanno capire se un oggetto puo' essere disegna, spostato, ecc).
Tornando agli eventi.... quando un evento viene sollevato se nn e' evento speciale (EXIT, QUIT) passa ad una funzione proxy_event del singleton.
Questa funzione ciclando sulla lista degli oggetti da renderizzare individua l'oggetto + esposto su cui e' avvenuto l'evento (es. click destro), quindi incoda un evento formattato del tipo [Oggetto, TipoEvento (MouseRightDown), posizione, ed eventuali kwagrs] nella coda degli eventi. Ovviamente anche altri eventi (scaturiti da altri processi, tutto avviene in twisted :|) posso essere incodati dall'esterno attraverso un apposito metodo.
Successivamente la coda viene eseguita, quindi x ogni evento viene chiamato il
gettattr(Oggetto, TipoEvento)(posizione, **kwargs).
In questa maniera basta implementare in un oggetto il metodo "MouseRightDown", "MouseLeftUp", "MouseMove", ecc e magicamente viene eseguita quella cosa quando si clicca sull'oggetto :|
Quindi la cosa diventa semplice, se cliccando su un oggetto deve comparirne un'altro basta che nel metodo MouseRightDown attraverso il singleton faccio
addEvent([<oggetto da comparire>, 'Show', posizione, <parametri opzionali>]),
sucessivamente implemento in quell'oggetto il metodo Show e tutto e' fatto :| nn so se sono stato kiaro :|
Ovviamente la cosa puo' essere estesa anche ad eventi non legati al mouse...

"Non so se mi sono spiegata, come disse al vela" (cit. :D)
« Ultima modifica: Giugno 03, 2009, 16:04 da Amati »

Offline Charles_Stain

  • python sapiens sapiens
  • *
  • moderatore
  • Post: 1.220
  • Punti reputazione: 0
    • Mostra profilo
    • My personal website
Re: Un framework di sviluppo su pygame :|
« Risposta #3 il: Giugno 04, 2009, 08:02 »
Una specie di pattern Observer se non ho capito male ;)

Offline Amati

  • python unicellularis
  • *
  • moderatore
  • Post: 44
  • Punti reputazione: 0
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #4 il: Giugno 04, 2009, 10:22 »
L'ho usato o visto solo una volta x un esame :P, era in java. Cmq si ora lo sto leggendo e sempra che il meccanismo sia grosso modo quello sisi.
Molto usato, leggo, in C#/MFC ecco xke' nn ci ho avuto molto a che fare :|. E anche usato molto dai javisti :P.
« Ultima modifica: Giugno 04, 2009, 10:24 da Amati »

Offline Charles_Stain

  • python sapiens sapiens
  • *
  • moderatore
  • Post: 1.220
  • Punti reputazione: 0
    • Mostra profilo
    • My personal website
Re: Un framework di sviluppo su pygame :|
« Risposta #5 il: Giugno 04, 2009, 18:59 »
E' usato ovunque perchè è uno dei pattern GoF più importanti..
E' altresì noto col nome di Publisher-Subscriber per richiamare l'idea (secondo me geniale) di un publisher, un editore diciamo, che genera eventi, e dei subscriber, diciamo abbonati, che si abbonano all' editore.
Questa immagina evocativa fa capire il meccanismo.
Come si abbonano? Non si accoppiano direttamente col l'oggetto publisher ma con una interfaccia chiamata di solito PropertyListener.. ogni volta che un publisher genera un evento dice a tutti i suoi abbonati (che sono oggetti che implementano l'interfaccia propertyListener) di fare qualcosa.
E' il classico esempio di quanto tu hai un oggetto dello strato di logica applicativa che deve comunicare allo strato UI che qualcosa è cambiato (es. il totale di una vendita) e che deve refreshare, ad esempio , la GUI.
E' molto affascinante e potente, in Java si chiama Delegation Method qualcosa :D
Per ulteriori ragguagli c'è la bibbia dei GoF :D

Offline ~FullSyst3m~

  • python sapiens
  • *****
  • Post: 971
  • Punti reputazione: 0
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #6 il: Giugno 04, 2009, 20:03 »
E' usato ovunque perchè è uno dei pattern GoF più importanti..
E' altresì noto col nome di Publisher-Subscriber per richiamare l'idea (secondo me geniale) di un publisher, un editore diciamo, che genera eventi, e dei subscriber, diciamo abbonati, che si abbonano all' editore.
Questa immagina evocativa fa capire il meccanismo.
Come si abbonano? Non si accoppiano direttamente col l'oggetto publisher ma con una interfaccia chiamata di solito PropertyListener.. ogni volta che un publisher genera un evento dice a tutti i suoi abbonati (che sono oggetti che implementano l'interfaccia propertyListener) di fare qualcosa.
E' il classico esempio di quanto tu hai un oggetto dello strato di logica applicativa che deve comunicare allo strato UI che qualcosa è cambiato (es. il totale di una vendita) e che deve refreshare, ad esempio , la GUI.
E' molto affascinante e potente, in Java si chiama Delegation Method qualcosa :D
Per ulteriori ragguagli c'è la bibbia dei GoF :D

L'hai letto tutto il libro della GoF?

Offline Charles_Stain

  • python sapiens sapiens
  • *
  • moderatore
  • Post: 1.220
  • Punti reputazione: 0
    • Mostra profilo
    • My personal website
Re: Un framework di sviluppo su pygame :|
« Risposta #7 il: Giugno 05, 2009, 10:01 »
Magari, quel libro è oscuro se prima non ti leggi qualche testo introduttivo tipo il Larman.. tra l'altro nel Gof gli esempi sono in Smalltalk e C++, quindi un pelo meno comprensibili :P
Nel larman comunque ci sono dei GoF spiegati, tra cui Observer ;)

Offline Amati

  • python unicellularis
  • *
  • moderatore
  • Post: 44
  • Punti reputazione: 0
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #8 il: Giugno 05, 2009, 10:16 »
ma quel meccanismo che uso io rispetta il pattern o devo cambiare qualcosa :(? :D

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Un framework di sviluppo su pygame :|
« Risposta #9 il: Giugno 05, 2009, 15:54 »
ma quel meccanismo che uso io rispetta il pattern o devo cambiare qualcosa :(? :D

1. Non e' che i "pattern" si rispettano
2. Non cambiare codice se non "rispetta" un pattern. Un pattern e' una soluzione generalizzata ad un problema. Il problema e' non rispettare, eventualmente, qualche principio di OOP dove invece dovresti. Il pattern e' una soluzione. Se tu fornisci una soluzione meno generica ma corretta rispetto ai principi OOP hai solo un difetto comunicativo.

Nel senso che se usi "pattern x" dici: ho usato x e tutti capiscono. Se ti fai la tua soluzione, non ha un "fancy name". Ma se e' corretta, non stare a cambiarla, per ora.

Riguardo la letteratura dei Pattern, di recente mi sono trovato davvero bene con Head First Design Pattern. Lessi anni fa il Design Patterns: solutions..., ma ne rimasi profondamente insoddisfatto: un catalogo. Influente, ma sempre un catalogo.
Ebbi una parziale rivalutazione con il libro di Martin, Agile Development etc etc etc. Davvero un bel testo, spiega i pattern e riesce anche a contrapporli. Oltretutto e' abbastanza chiaro quali sono i pattern agili e quali quelli inchiodati. Mostra tutti i limiti logici di Singleton, etc etc etc.
Comunque la sua e' gia' una posizione 2. Usati, digeriti, criticati. Forse per imparare e' meglio HFDP, che invece si pone proprio l'obiettivo di insegnarli, mentre per Martin il focus e' sullo sviluppo agile.

Larman lo conosco attraverso il suo testo su UML e UP. Di fatto e' l'unico testo su UML (assieme a quello di Fowler) che non mi ha fatto rotolare per terra dalle risate, quindi suppongo che lo spirito critico di Larman sia sufficientemente sviluppato da offrire una buona trattazione anche dei design pattern. Che purtroppo altri libri prendono quanto scritto dalla GoF, ne fanno un testo sacro e ne offrono un'interpretazione. Che ovviamente e' molto poco utile. Daro' un occhio a questo libro: hai un puntatore?

Sebbene i pattern ormai mi escano un po' dalle orecchie. :P



Offline xFra32

  • python neanderthalensis
  • ****
  • Post: 481
  • Punti reputazione: 1
    • Mostra profilo
    • Utopico
Re: Un framework di sviluppo su pygame :|
« Risposta #10 il: Giugno 05, 2009, 19:14 »
Anche io ho fatto una cosa molto simile un po di tempo fa... Cosi puoi sviluppare applicazioni più velocemente ma poi e più complesso unire gli oggetti.

Io avevo fatto un mainloop che chiamava la funzione draw degli oggetti(e poi lo ho ottimizzato facendo il refresh solo degli oggetti che si ridisegnano). Poi avevo una funzione events che chiamava la funzione event di un oggetto inviando un oggetto-evento tipo mouseclick, mousescroll, keypress, mousein, mouseout, mousemove, analizzando la posizione degli oggetti.

molto simile. :) :) :)

Offline Amati

  • python unicellularis
  • *
  • moderatore
  • Post: 44
  • Punti reputazione: 0
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #11 il: Giugno 07, 2009, 11:17 »
si se vuoi fare qualcosa di grosso invece di rifarti tutto sempre, qualcosa del genere serve :D
e quella maniera e' la migliore, infatti siamo minimo in 2 che l'hanno implementata :|

Offline nkint

  • python neanderthalensis
  • ****
  • Post: 368
  • Punti reputazione: 1
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #12 il: Agosto 31, 2010, 14:03 »
come è andata a finire questa discussione? ci sono stati avanzamenti?

ho trovato questo:
http://gameprogrammingpatterns.com/

in particolare per le esperienze che ho avuto in un framework di sviluppo __per videogames__
ho utilizzato un sacco di volte
l'object pool e il double buffering. non so se possono essere considerati pattern veri e propri
o semplicemente tecniche..

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Un framework di sviluppo su pygame :|
« Risposta #13 il: Agosto 31, 2010, 23:21 »
sarei piu' sul "tecniche standard"

Offline ubuntu_of_fortune

  • python sapiens
  • *
  • moderatore
  • Post: 745
  • Punti reputazione: 3
    • Mostra profilo
Re: Un framework di sviluppo su pygame :|
« Risposta #14 il: Settembre 01, 2010, 10:03 »
sarei piu' sul "tecniche standard"
Sono d'accordo con il riko (naturalmente).

Premessa:
Da quello che si trova in rete la tecnica di *object pooling* sembra di carattere e di uso piu` generale mentre il *double buffering* sembra specifica per il game programming.
Questa dicotomia, imho, lascia il tempo che trova in quanto spesso capita che le soluzioni applicate in un contesto possono rivelarsi utili in un altro (anzi quando questo accade trovo che la cosa sia molto stimolante!).

Anyway, sarei portato anche io a definirle "tecniche standard" piu`che pattern per due semplici ragioni:

1) In generale si tende a confondere il concetto di pattern con una ottima soluzione progettuale per un determinato problema.
Una tecnica/soluzione, per assumere i connotati di un pattern, deve essere sufficientemente generale (nel senso che puo` essere all'occorrenza customizzata per un determinato contesto) e allo stesso tempo avere una propria identita`.
Inoltre, un vantaggio/conseguenza dei pattern, e` la diretta associazione che c'e` tra Nome-Problema Risolto.
Con un il nome di un pattern si identifica immediatamente una soluzione. Inflazionare troppo il concetto di pattern indebolisce questa correlazione mnemonica.

2) Dire "tecnica standard" significa connotare una soluzione in modo maggiore che non Pattern. Un pattern, come dicevo, puo` e deve essere customizzato a seconda delle occorrenze.
Una tecnica standard, invece, e` SEMPRE utilizzata as-is per un determinato problema e sempre per quello stesso problema,divenendo, cosi`, uno Standard!

Mi rendo conto, pero`, che quest'ultima motivazione e` puramente filosofica ed eccessivamente zelante nell'attribuzione di semantica alla coppia di termini "tecnica standard".

(Quando scrivo queste frasi penso sempre che avrei dovuto fare il venditore porta-a-porta!! :D  :angel: :party:)

[EDIT]
A proposito di semantica e significato dei termini segnalo questo interessante articolo di M Fawler http://martinfowler.com/bliki/TypeInstanceHomonym.html
da leggere in un momento di pausa ;)
Cheers
[/EDIT]
« Ultima modifica: Settembre 01, 2010, 11:27 da ubuntu_of_fortune »