report.tex

\documentclass[a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[italian]{babel}
\usepackage[T1]{fontenc}
\usepackage{amsmath,amssymb,amsthm}
\usepackage{enumerate}

\usepackage{epigraph}
\renewcommand{\epigraphrule}{0pt}
\renewcommand{\textflush}{flushepinormal}
\setlength{\epigraphwidth}{0.3\textwidth}
\renewenvironment{flushepinormal}{}{\vspace*{-\baselineskip}}

\title{Overengineered \\
\large Relazione del progetto per l'insegnamento di Programmazione}
\author{
  M. Girolimetto,
  A. Scrob,
  L. Tagliavini,
  S. Volpe
}

\date{
	Universit\`a di Bologna \\
  \today
}

\begin{document}

\maketitle
\thispagestyle{empty}

\epigraph{Il tempo che vi divertite a sprecare non è tempo sprecato.}
{\textit{Bertrand Russell}}

\section{Funzionalit\`a}

\emph{Overengineered} \`e un videogioco di piattaforme a scorrimento laterale
con mappa illimitata implementato in \verb!C++!. L'esecuzione avviene
all'interno di un terminale: l'interfaccia \`e perci\`o realizzata tramite una
grafica ASCII. La mappa \`e generata in modo incrementale tramite l'unione di
frammenti presviluppati. La possibilit\`a di scegliere tra pi\`u personaggi,
unita alla variet\`a di nemici e oggetti, rende il sistema di combattimento una
sintesi fra scontri corpo a corpo e a distanza. Ciascun evento degno di nota
viene inoltre descritto al giocatore in forma didascalica in tempo reale.

\section{Spartizione dei ruoli}

Il lavoro \`e stato diviso tra i membri del gruppo sia sul piano della
programmazione che su quello delle figure di contorno richieste per la creazione
di un videogioco.

\subsection{Programmazione}

Il programma, scritto usando \verb!C++11! come norma tenica, si articola in
pi\`u moduli, che sono rappresentati nel codice con lo strumento linguistico
dello spazio dei nomi (\emph{namespace}). \`E stato designato un responsabile
diverso per ciascuno di questi moduli.
\begin{itemize}
  \item \verb!Data! (S. Volpe): descrive la base di dati del gioco e gli enti in
    essa contenuti, come \verb!Scenery!, \verb!Hero!, \verb!Skill!. La lettura
    di tali informazioni avviene da disco.
  \item \verb!Engine! (L. Tagliavini): fornisce il nucleo \emph{software} per
    l'uso di grafica in tempo reale e audio. Offre strutture per il
    \emph{rendering}, la creazione di interfacce utente e la riproduzione della
    colonna sonora.
  \item \verb!World! (M. Girolimetto): genera una mappa di gioco dinamicamente
    espandibile, popolandola con entit\`a di vario genere. Il livello di
    difficolt\`a aumenta in relazione alle dimensioni della mappa.
  \item \verb!Game! (A. Scrob): combina le funzionalit\`a degli altri moduli in
    un unico \emph{game loop}. Implementa la logica di gioco, incluso il sistema
    di combattimento, e la navigazione tra menu diversi.
\end{itemize}

\noindent
Le specifiche del progetto prevedono serie limitazioni sull'uso della
\emph{Standard Template Library}. I contenitori come \verb!vector!, \verb!list!
e \verb!map! e \verb!string!, per esempio, sono vietati. Per far fronte a tali
richieste, \`e stato necessario includere un ulteriore modulo, denominato
\verb!Nostd!. Esso emula alcuni strumenti della libreria standard, integrandoli
secondo le necessit\`a del progetto. \verb!Nostd! \`e stato realizzato
congiuntamente dall'intera squadra: a ciascun membro del gruppo \`e stata
affidata una parte delle intestazioni. In cima ad ogni \emph{file} \`e
comunque presente il nominativo del programmatore che ne \'e esso responsabile.

\subsection{Miscellanea}

La cartella \verb!assets! raccoglie le risorse (file di estensioni \verb!.txt! e
\verb!.csv!) caricate dalla base di dati. Esse sono classificabili in quattro
categorie.

\begin{itemize}
  \item Progettazione (S. Volpe): creazione dei frammenti della mappa e delle
    statistiche di gioco.
  \item Grafica (L. Tagliavini): scelta di caratteri e colori per la
    rappresentazione di paesaggi, entit\`a e ritratti.
  \item Audio (M. Girolimetto): composizione della colonna sonora riprodotta
    nelle varie fasi del gioco.
  \item Testi (A. Scrob): nomi delle entit\`a e descrizioni dei personaggi
    giocabili.
\end{itemize}

\section{Scelte implementative}

Nella stesura del codice sorgente, sono stati usati come punti di riferimento i
"paradigmi"\footnote{\label{note1} \guillemotleft [...] la parola "paradigma" mi
mette a disagio in quanto pretenziosa e (secondo la definizione originale di
Kuhn) con implicite pretese di esclusivit\`a\guillemotright (B. Stroustrup,
\emph{C++. Linguaggio, libreria standard, principi di programmazione}, 4. ed.,
trad. it. di Giulia Maselli e Paolo Postinghel, Pearson Italia, Milano 2015,
p. 11).} di programmazione procedurale, orientato agli oggetti e generico. Il
linguaggio scelto ci ha permesso di coniugare l'uso di potenti strumenti
linguistici e concettuali per l'astrazione con accorgimenti di basso livello per
ottenere prestazioni relativamente soddisfacenti.

\subsection{Nostd}

\verb!Nostd! (re)implementa liste, vettori, stringhe, matrici e mappe, ovvero i
contenitori utili al resto del progetto. Fedelt\`a alla \emph{STL}, semplicit\`a
e pragmatismo ne hanno guidato la progettazione. Proprio come la libreria a cui
si ispira, \verb!Nostd! fornisce appositi tipi di iteratori; questo porta a
diversi vantaggi, fra cui la possibilit\`a di usare sia l'istruzione
\emph{range-for} che \verb!<algorithm>!. Per parametrizzare rispetto ad uno o
pi\`u tipi di dato i costrutti definiti, si \`e fatto talvolta uso di
programmazione generica e metaprogrammazione, raggiungendo cos\`i il punto pi\`u
alto delle capacit\`a espressive del linguaggio. Infine, \verb!<allocator.hpp>!,
\verb!<concepts.hpp>! e \verb!<pair.hpp>! hanno funto da intestazioni
ausiliarie.

\subsection{Data}

Come prescritto da Bjarne Stroustrup (\guillemotleft A meno che esista una buona
ragione per non farlo, usate \verb!vector! \guillemotright \footnote{
\label{note2} B. Stroustrup, \emph{C++. Linguaggio, libreria standard, principi
di programmazione}, 4. ed., trad. it. di Giulia Maselli e Paolo Postinghel,
Pearson Italia, Milano 2015, p. 810.}), la quasi totalità delle informazioni
della base di dati viene memorizzata in vettori del tipo appropriato. Fa
eccezione \verb!Result!, le cui istanze sono memorizzate in una lista per
privilegiare inserimenti interni durante l'iterazione su esse. Molte delle
classi coinvolte, inoltre, appartengono ad un'unica gerarchia circoscritta dal
sottospazio dei nomi \verb!Data::Pawns!. In essa, un uso ragionato di metodi e
basi virtuali ha fatto convivere esempi di \emph{dispatch} statico e dinamico.
L'interazione con il disco, invece, \`e regolata da sovraccaricamenti degli
operatori di slittamento a sinistra (\verb!<<!) e a destra (\verb!>>!) specifici
per ciascun tipo di ente trattato dalla base di dati.

\subsection{Engine}

Tutte le schermate ad eccezione della scena di gioco sono composte da una serie
di elementi visuali contenuti in \verb!Engine::UI!. Essi vengono inseriti in una
struttura arborescente che ricorda quella di un \emph{Document Object Model}:
questo permette, oltre al riutilizzo del codice, una più netta separazione tra
contenuto e logica dei men\`u. La schermata di gioco scorre la lista di
frammenti del mondo vicini al giocatore per mostrarli a schermo sovrapponendovi
entit\`a e proiettili.

\subsection{World}

Sia la mappa di gioco che l'insieme degli agenti che la popolano sono conservati
in apposite liste. Le operazioni di accodamento ed eliminazione da effettuare
con il progredire del gioco risultano cos\`i semplificate, ma lo stesso non vale
per la ricerca di eventuali enti in una data posizione del mondo. Per agevolare
quest'ultimo compito, ciascun frammento di mappa offre matrici di puntatori
a eventuali elementi delle suddette liste. Le coordinate di ciascun agente sono
quindi rappresentabili da un iteratore facente riferimento alla matrice
appropriata e dagli indici della riga e della colonna relative. Per assicurare
un livello di difficolt\`a sempre crescente man mano che la partita prosegue,
viene applicata una distribuzione di Poisson a un generatore di interi
pseudoaleatori. Cos\`i facendo, le probabilità di uscita di ciascun nemico,
oggetto o mappa sono deterministicamente regolate in base alla lunghezza della
mappa esplorata fino all'istante corrente.

\subsection{Game}

In fase di inizializzazione, \verb!Game! richiede la costruzione di una nuova
base di dati specificando i percorsi da cui recuperare le risorse necessarie.
In seguito, affinch\'e il modulo possa gestire il \emph{game loop}, ad ogni
aggiornamento dello stato della partita la lista degli agenti viene scorsa per
intero una ed una sola volta. Tale processo prevede spostamenti sulla mappa,
controlli di collisioni, modifiche alle statistice e distruzioni; ogni
avvenimento rilevante per il flusso del gioco innesca la composizione dinamica
di un messaggio di commento da mostrare a schermo. Per gestire questo intricato
meccanismo vengono istanziati appositi gestori innestati: ciascuno di essi \`e
caratterizzato da una distinta area di competenza.

\subsection{Unit testing}

La natura interconnessa dei moduli del progetto ha da subito messo in luce il
bisogno di poter verificare il funzionamento del codice per garantirne
l'affidabilit\`a sul lungo periodo. A tal fine si fa uso della funzione
ausiliaria \verb!Nostd::test! e del comando \verb!make test! per compilare ed
eseguire tutti i file per il \emph{testing} d'unit\`a.

\end{document}