in

dotNet Umbria

Il primo User Group in Umbria sul mondo .Net

NHooligans

Progetto NHooligans - Parte 1 - Concetti, entità e interfacce del sistema di simulazione

In considerazione della straordinaria risposta al mio post nella sezione "futuri appuntamenti" (intendo straordinariamente scarsa), provo ad addentrarmi un po' più nel concreto del sistema di simulazione che costituirà l'ambiente all'interno del quale interagiranno i vari agenti (denominati "hooligan") comandati dai programmi "contendenti".

Facendo riferimento alla terminologia utilizzata nel framework NSteer, intorno al quale verrà sviluppato il sistema di simulazione, si individuano i seguenti "attori", ciascuno con le proprie peculiarità (o, in altri termini, ciascuno caratterizzato dall'implementazione di una o più delle interfacce definite dal framework:

  • Un oggetto di tipo "agente" (Agent, in NSteer), descrive un'entità che vive all'interno del "mondo" (World, in NSteer). Un agente ha un "corpo" (Body, in NSteer), un sistema di "visione" (Vision, in NSteer) e un "comportamento" (Behavior, in NSteer).
  • Il "corpo" di un agente definisce le proprietà cinematiche dell'agente (posizione, velocità e accelerazione).
  • Un sistema di "visione" definisce la regione in cui un agente può "vedere" gli altri agenti o gli ostacoli presenti, tipicamente, nelle sue vicinanze.
  • Il "comportamento" di un agente determina, ad ogni passo della simulazione, la forza (in senso vettoriale) cui sarà sottoposto il suo "corpo".
  • Gli agenti sono confinati all'interno del "mondo".
  • Il "simulatore" (Simulator, in NSteer) determina, ad ogni passo della simulazione, la situazione cinematica (posizione, velocità e accelerazione) di tutti gli agenti presenti nel sistema.
  • Il sistema di simulazione implementato in NSteer definisce quattro servizi per gestire gli agenti, il mondo, gli ostacoli e la "prossimità" di un agente nei confronti degli altri rispettivamente mediante i servizi AgentService, WorldService, ObstacleService e NeighborhoodService.
  • Per quanto concerne la visualizzazione della simulazione NSteer definisce il concetto di Sprite, un oggetto 2D caratterizzato da attributi quali colori, visibilità, forma, ecc. e il concetto di "Scena" (Scene, in NSteer), che astrae gli aspetti legati al rendering della simulazione.

Prima che vi sloghiate la mandibola per gli sbadigli, vi incollo un'immagine relativa ad uno step della simulazione realizzata all'interno del demo che accompagna il framework NSteer.

NSteerDemo

Nello screenshot è possibile individuare una decina di agenti (i punti contornati dal cerchietto rosa, che rappresenta lo spazio occupato dall'agente) ciascuno dei quali ha un proprio "orientamento" ed un proprio "cono visivo" (rappresentato dai 3 segmenti terminati da pallini che escono dal centro dell'agente). I comportamenti di ciascun agente sono descritti dall'etichetta che compare accanto a ciascun cerchietto rosa. I comportamenti definiti all'interno del framework NSteer sono già parecchi, ma è possibile definirne di nuovi o scrivendoli da zero o utilizzando uno dei comportamenti "contenitore" già definiti in NSteer. I 3 cerchi viola rappresentano degli ostacoli circolari. Nell'immagine gli agenti al centro della finestra hanno attivato il comportamento "Seek" (ossia insegui) nei confronti del pallino verde in alto (comandato dal movimento del cursore del mouse nell'applicazione di esempio). Gli altri hanno attivato invece un comportamento composito caratterizzato dalla somma del comportamento "Confine" (ossia confina, argina) e del comportamento "Avoid" (ossia evita), rispettivamente per rimanere all'interno della regione permessa (rappresentata dal riquadro interno) e per evitare l'ostacolo che hanno accanto.

Anche se nello step di simulazione immortalato da questo screenshot non è evidente (perché in questo screenshot altri comportamenti avevano priorità), gli agenti tendono a rimanere uniti ma a non sovrapporsi grazie ad un altro comportamento: il FlockBehavior (dove flock significa "stormo").Questo comportamento ha una valenza "storica" particolare perché è proprio dalla scomposizione delle regole che guidano il comportamento di uno stormo di uccelli che Reynolds ha tratto lo spunto per il proprio lavoro. Per rendervi conto meglio di quello che Reynolds ha inventato (o forse dovrei dire "scoperto") vi consiglio di dare un'occhiata ai demo allegati, ed in particolare (premento Tab si passa da un demo al successivo) al demo "Boids".

Nel prossimo post inizieremo a dare un'occhiata a qualche snippet di codice, per poi fare chiarezza sui "lotti" di progetto disponibili per l'assegnazione a chi vorrà partecipare attivamente allo sviluppo di NHooligans.

Only published comments... Jun 11 2008, 07:53 AM by maiorfi
Filed under:

Comments

 

Andrea Cruciani said:

I'm in!

Non vedo l'ora di stracciare i tuoi flocks :D

June 11, 2008 3:53 PM

About maiorfi

Sopravvivo dal 1971. Pigio per la prima volta i tasti di gomma del Sinclair Spectrum nel 1982, grazie all'acquisto presso la famosa G.B.C. di Temperini in Via Pellas da parte di mio padre. Entro in possesso di un Commodore Amiga 1000 in una anno che ricordo a fatica tra il 1986 e il 1987. Inizia il quegli anni la sperimentazione della frustrazione per la difficoltà di utilizzo delle API C per lo sviluppo di applicazioni integrate nel sistema operativo "Workbench" (ispirato al sistema Macintosh), un po' dovuta anche agli unici 2 compilatori presenti sul mercato: Aztec e Lattice, amichevoli come il software per la perforazione delle schede. La frustrazione veniva lenita parzialmente solo dalle ore trascorse giocando a KickOff di Dino Dini. Finalmente nei primi anni 90 approdo al mondo dei PC, con un 386sx assemblato della Olidata. In quegli anni il Turbo Pascal prima e il Turbo C dopo riescono a far sembrare lo sviluppo un esperienza tutto sommato divertente. Nel 1993 installo per la prima volta una copia (ovviamente abusiva) di Windows 3.1, con la quale inizio a sperimentare, grazie anche alla strepitosa libreria OWL di Borland integrata in "Borland C++" (primo ambiente object-oriented degno di questo nome), lo sviluppo di applicazioni desktop (anche se a quei tempi l'espressione "desktop" era sconosciuta e superflua, visto che tutte le applicazioni windows avevano di fatto un'interfaccia utente). Negli anni a seguire il mio interesse si focalizza su Visual C++, MFC, COM, ATL e su tutto quanto oramai inizia ad orbitare intorno alla piattaforma di sviluppo Microsoft "unmanaged", tanto che nel 1996 impronto la mia tesi di laurea, svolta con e per la società Eles di Todi, interamente su COM/OLE/ActiveX, ed in particolare sulle architetture per l'integrazione binaria dei componenti software. Credo che la tesi abbia effettivamente totalizzato 2 lettori, me e il mio revisore compresi. Dopo la laurea ed un anno di militare speso smanettando in Clipper presso il Nucleo Elaborazione Dati del Distretto Militare di Perugia (allora gestito dal famoso Colonnello Ansalone e dal famigerato Maresciallo Venditto), vengo assunto dalla (oramai defunta) Sinfor s.r.l. come lead (and only) developer. Ricordo tanti piccoli progetti Visual C++/MFC e VB6, qualcuno fatto male e qualcuno fatto peggio, ma complessivamente utili al loro scopo: far sì che io riuscissi a millantare un'esperienza ed una capacità che non avevo, contribuendo a farmi guadagnare uno stipendio che non meritavo. Nel 1999 lascio la Sinfor (anticipando il termine dei 2 anni del contratto di formazione!) per fondare la Innovactive Engineering s.r.l. insieme ai miei 3 soci (a dire il vero uno dei 3 soci è cambiato qualche tempo dopo, ma a chi importa?). Stentiamo un po' ad affrontare il seppur ricchissimo ed apertissimo mercato umbro ma riusciamo alla fine a consegnare il nostro primo prodotto: un gestionale per l'amministrazione di una società che opera nel campo assicurativo/assistenziale. Non è un successo né in termini economici né in termini di soddisfazione professionale (ad eccezione di quanto concerne la realizzazione del più lento e inaffidabile ORMapper della storia) ma da qualcosa bisognava pure cominciare. Negli anni intorno al 2001-2002 ci spostiamo all'interno della sede di Carsoli del Sole24Ore, coinvolti in qualità di consulenti per lo sviluppo con ASP/COM+/VB6/VC++. E' il periodo delle "vacche grasse" (dovuto alla famosa bolla speculativa della new economy), purtroppo mai più ripresentatosi negli anni successivi. Rientrati stabilmente a Perugia, dal 2003 in poi iniziamo un'attività più propriamente "aziendale" e cresciamo fino a raggiungere quota 7, grazie alla acquisizione delle nostre tre colonne portanti: Fabrizio, Valerio e Gianluca.
dotNet Umbria 2007-2008
Powered by Community Server (Commercial Edition), by Telligent Systems