diff --git a/content/ss20/bachelor/b1-hexarcade/_index.md b/content/ss20/bachelor/b1-hexarcade/_index.md index fe5a79c..10dacbc 100644 --- a/content/ss20/bachelor/b1-hexarcade/_index.md +++ b/content/ss20/bachelor/b1-hexarcade/_index.md @@ -14,12 +14,12 @@ team = ["Adil Altuner", "Daphna Beljavskij", "Diro Baloska", "Florian Murzov-Pir supervisor = "Prof. Dr. Tobias Lenz" +++ -Heutzutage prasseln auf den Menschen eine Vielzahl an verschiedensten Eindrücken ein. Eine Push Benachrichtigung hier, eine Mail dort, noch schnell auf die Nachricht antworten und dabei den Kaffee nicht verschütten, um dann frisch geduscht ins Zoom-Meeting zu kommen. Die konstante Überflutung unserer Reize und die wenige Zeit, die uns pro Tag zur Verfügung stehen sorgen dafür, dass es uns immer schwerer fällt, Dingen und Aufgaben unsere ungeteilte Aufmerksamkeit schenken zu können. +Heutzutage prasseln auf den Menschen eine Vielzahl an verschiedensten Eindrücken ein. Eine Push Benachrichtigung hier, eine Mail dort, noch schnell auf die Nachricht antworten und dabei den Kaffee nicht verschütten, um dann frisch geduscht ins Zoom-Meeting zu kommen. Die konstante Überflutung unserer Reize und die wenige Zeit, die uns pro Tag zur Verfügung steht, sorgen dafür, dass es uns immer schwerer fällt, Dingen und Aufgaben unsere ungeteilte Aufmerksamkeit schenken zu können. {{
}} Der Grundgedanke dieses Projektes ist es, diesem Umstand entgegenzuwirken und mithilfe einer Anwendung die Konzentrationsfähigkeit, aber auch die Motorik, spielerisch zu verbessern. -Deshalb war es unser Ziel, ein Spiel zu entwickeln, das jederzeit und in kurzen Sessions gespielt und so diese Fähigkeiten Schritt für Schritt wieder trainiert werden können. Das Endprodukt was dabei entstanden ist, heißt *HexArcade*. +Deshalb war es unser Ziel, ein Spiel zu entwickeln, das jederzeit und in kurzen Sessions gespielt und so diese Fähigkeiten Schritt für Schritt wieder trainiert werden können. Das Endprodukt, das dabei entstanden ist, heißt *HexArcade*. {{
}} {{
}} diff --git a/content/ss20/bachelor/b1-hexarcade/about-us/index.md b/content/ss20/bachelor/b1-hexarcade/about-us/index.md index 57d6d73..d07a412 100644 --- a/content/ss20/bachelor/b1-hexarcade/about-us/index.md +++ b/content/ss20/bachelor/b1-hexarcade/about-us/index.md @@ -6,7 +6,7 @@ weight = 1 {{project image}} {{
}} -Vor dem Projekt kannten wir uns noch nicht bzw. nur von Sehen her. Aufgrund der besonderen Schwierigkeiten dieses Semesters, konnten wir uns auch nicht persönlich treffen und uns so kennenlernen. Zusätzlich hatte die Hälfte von uns noch nie mit Unity, der Entwicklungsumgebung, mit der wir unser Spiel erstellen wollten, gearbeitet. Doch rückblickend müssen wir sagen, dass die Zusammenarbeit im Projekt trotz alledem sehr harmonisch und produktiv verlief. +Vor dem Projekt kannten wir uns noch nicht bzw. nur vom Sehen her. Aufgrund der besonderen Schwierigkeiten dieses Semesters, konnten wir uns auch nicht persönlich treffen und uns so kennenlernen. Zusätzlich hatte die Hälfte von uns noch nie mit Unity, der Entwicklungsumgebung, mit der wir unser Spiel erstellen wollten, gearbeitet. Doch rückblickend müssen wir sagen, dass die Zusammenarbeit im Projekt trotz alledem sehr harmonisch und produktiv verlief. {{
}} {{
}} diff --git a/content/ss20/bachelor/b1-hexarcade/future-prospects.md b/content/ss20/bachelor/b1-hexarcade/future-prospects.md index 1728728..af36252 100644 --- a/content/ss20/bachelor/b1-hexarcade/future-prospects.md +++ b/content/ss20/bachelor/b1-hexarcade/future-prospects.md @@ -5,11 +5,11 @@ weight = 4 Einer der wesentlichen Gründe, warum wir uns schnell auf unser Spielekonzept einigen konnten, war, dass es sehr gut skalierbar ist. Während der Entwicklungsphase sind uns viele weitere Ideen und Elemente eingefallen, mit denen unser Konzept erweitert werden könnte. -So haben wir uns sehr viel mehr Distraktoren ausgedacht, als im fertigen Spiel enthalten sind zusätzlich hatten wir mit anderen Level-Konzepten und Spielmodi experimentiert. +So haben wir uns sehr viel mehr Distraktoren ausgedacht, als im fertigen Spiel enthalten sind, zusätzlich hatten wir mit anderen Level-Konzepten und Spielmodi experimentiert. Da wäre zum einen ein ***Free Play-Modus***. Statt von uns erstellten Leveln, werden hier endlos Level mit einem zufälligen Pfad generiert. -Darüber hinaus gab es die Idee, den Level-Editor, den wir für uns in der Unity GUI verwirklicht haben, im Spiel zur Verfügung zu stellensodass unsere Nutzer_innen eigene Level erstellen und teilen könnten – eine Art *HexArcade Maker*. Für einige Zeit hatten wir auch überlegt, einen Mehrspielermodus zu implementieren, da wir fanden, dass dieser dem Spiel so einen größeren Mehrwert geben könnte. Da das ursprüngliche Spielkonzept jedoch für Einzelspieler ausgelegt war, haben wir uns zunächst darauf konzentriert, diesen so gut wie möglich auszuarbeiten. Wir wollten aber trotzdem zumindest eine - wenn auch einfache - Form des Mehrspielermodus in Form einer Highscore-Liste zur Verfügung stellen. +Darüber hinaus gab es die Idee, den Level-Editor, den wir für uns in der Unity GUI verwirklicht haben, im Spiel zur Verfügung zu stellen, sodass unsere Nutzer_innen eigene Level erstellen und teilen könnten – eine Art *HexArcade Maker*. Für einige Zeit hatten wir auch überlegt, einen Mehrspielermodus zu implementieren, da wir fanden, dass dieser dem Spiel so einen größeren Mehrwert geben könnte. Da das ursprüngliche Spielkonzept jedoch für Einzelspieler ausgelegt war, haben wir uns zunächst darauf konzentriert, dieses so gut wie möglich auszuarbeiten. Wir wollten aber trotzdem zumindest eine - wenn auch einfache - Form des Mehrspielermodus in Form einer Highscore-Liste zur Verfügung stellen. Beim Programmieren war es uns wichtig, unseren Code hinsichtlich eines echten Mehrspielermodus erweiterbar zu machen. Allerdings hätte die Implementierung eines asynchronen oder Echtzeit-Multiplayers, den Rahmen des Projekts gesprengt. diff --git a/content/ss20/bachelor/b1-hexarcade/idea-finding.md b/content/ss20/bachelor/b1-hexarcade/idea-finding.md index f36bab8..cc847da 100644 --- a/content/ss20/bachelor/b1-hexarcade/idea-finding.md +++ b/content/ss20/bachelor/b1-hexarcade/idea-finding.md @@ -3,17 +3,17 @@ title = "Ideenfindung" weight = 2 +++ -Zu Beginn des Projektes, hatten wir noch keine klare Idee von dem Thema ***Motorik und Konzentration*** und wie wir ein dazu passendes Spiel bauen könnten. Deshalb lag unser Fokus am Anfang stark auf der Recherche zu diesem Thema, bevor wir begonnen haben Spieleideen zu sammeln. +Zu Beginn des Projekts hatten wir noch keine klare Idee von dem Thema ***Motorik und Konzentration*** und wie wir ein dazu passendes Spiel bauen könnten. Deshalb lag unser Fokus am Anfang stark auf der Recherche zu diesem Thema, bevor wir begonnen haben Spielideen zu sammeln. {{
}} -Wir hatten uns bereits früh darauf geeinigt, dass das Spiel auf Smartphones ausgerichtet sein soll. Aus diesem Grund haben wir uns explizit angesehen, was es bereits für Spiele auf diesen Geräten gibt, die in unsere Thematik passen könnten. Dabei haben wir uns mit verschiedenen Spieleelementen und -prinzipien beschäftigt und unsere Favoriten zusammengetragen. Hier ist eine Auswahl davon: +Wir hatten uns bereits früh darauf geeinigt, dass das Spiel auf Smartphones ausgerichtet sein soll. Aus diesem Grund haben wir uns explizit angesehen, was es bereits für Spiele auf diesen Geräten gibt, die in unsere Thematik passen könnten. Dabei haben wir uns mit verschiedenen Spielelementen und -prinzipien beschäftigt und unsere Favoriten zusammengetragen. Hier ist eine Auswahl davon: * Ein Puzzle Game, wie [*Cut the Rope*](https://de.wikipedia.org/wiki/Cut_the_Rope), [*Where’s my Water*](https://en.wikipedia.org/wiki/Where%27s_My_Water%3Fkirby) oder [*Kirby: Canvas Curve*](https://en.wikipedia.org/wiki/Kirby:_Canvas_Curse). Diese Spiele funktionieren prinzipiell so, dass die Spielfigur oder das Spielfeld mithilfe von Touchscreen-Eingaben gesteuert bzw. manipuliert werden, um die Level erfolgreich abzuschließen. * Die Nutzung des Accelerometers ([Beschleunigungssensor](https://de.wikipedia.org/wiki/Beschleunigungssensor)), der in jedem modernen Smartphone vorhanden ist, um z.B. eine Spielfigur durch Neigen des Gerätes zu steuern oder Aktionen, wie ein kurzes Schütteln, zu registrieren. * Das Einbinden des Gyroskopsensors ([Kreiselinstrument](https://de.wikipedia.org/wiki/Kreiselinstrument#Technische_Anwendungen)), für physikbasierte Herausforderungen und Puzzles. * Das Anzeigen von verschiedenen Mustern auf dem Bildschirm, die der Spieler nachzeichnen soll. -* Ein Geschicklichkeitsspiel wie [*InkBall*](hhttps://de.wikipedia.org/wiki/InkBall). Hier rollt eine Kugel über ein 2D-Spielfeld und soll in farblich gekennzeichnete Löcher gelenkt werden. Die Farbe der Kugel verändert sich jedes Mal, wenn sie an einem der andersfarbigen Ränder abprallt. Der Ball wird gesteuert, indem der Spieler selbst, Wände auf dem Spielfeld einzeichnet. +* Ein Geschicklichkeitsspiel wie [*InkBall*](https://de.wikipedia.org/wiki/InkBall). Hier rollt eine Kugel über ein 2D-Spielfeld und soll in farblich gekennzeichnete Löcher gelenkt werden. Die Farbe der Kugel verändert sich jedes Mal, wenn sie an einem der andersfarbigen Ränder abprallt. Der Ball wird gesteuert, indem der Spieler selbst Wände auf dem Spielfeld einzeichnet. * Ein Endless-Runner wie [*Temple-Run*](https://de.wikipedia.org/wiki/Temple_Run), jedoch langsamer und mit einem festem Levelaufbau. {{
}} diff --git a/content/ss20/bachelor/b1-hexarcade/platform-and-design.md b/content/ss20/bachelor/b1-hexarcade/platform-and-design.md index a169dd3..6bf9fbf 100644 --- a/content/ss20/bachelor/b1-hexarcade/platform-and-design.md +++ b/content/ss20/bachelor/b1-hexarcade/platform-and-design.md @@ -4,17 +4,17 @@ weight = 3 +++ {{
}} -Schon zu Beginn des Projekts hatten wir uns geeinigt, dass unser Spiel für Smartphones ausgelegt sein soll. Der hauptsächliche Grund war, dass wir der Meinung sind, dass wir dadurch sowohl unsere Zielgruppe der jungen Erwachsenen noch besser erreichen können als auch, dass ein Spiel, das Konzentration und Motorik trainieren soll, nicht über mehrere Stunden am Stück unterhalten muss. Wir wollten den Fokus eher auch kurze Aufgaben legen, sodass das Spiel gut zwischendurch, z.B. beim Pendeln, spielbar ist. +Schon zu Beginn des Projekts hatten wir uns geeinigt, dass unser Spiel für Smartphones ausgelegt sein soll. Der hauptsächliche Grund war, dass wir der Meinung sind, dass wir dadurch sowohl unsere Zielgruppe der jungen Erwachsenen noch besser erreichen können als auch, dass ein Spiel, das Konzentration und Motorik trainieren soll, nicht über mehrere Stunden am Stück unterhalten muss. Wir wollten den Fokus eher auf kurze Aufgaben legen, sodass das Spiel gut zwischendurch, z.B. beim Pendeln, spielbar ist. {{
}} {{
}} -Da wir alle im Team noch keine großen Erfahrungen mit der Entwicklung von Apps oder Spielen hatten, wollte wir gerne eine Entwicklungsumgebung nutzen, die uns den Einstieg in die Spieleprogrammierung erleichtert. +Da wir alle im Team noch keine großen Erfahrungen mit der Entwicklung von Apps oder Spielen hatten, wollten wir gerne eine Entwicklungsumgebung nutzen, die uns den Einstieg in die Spielprogrammierung erleichtert. -Einige unserer Teammitglieder hatten bereits Erfahrungen mit Unity gesammelt und haben vor allem betont, dass mit Unity der Export für das Android-Betriebssystem im Gegensatz zu anderen Engines, problemlos verläuft. Unsere Wahl gestaltete sich deshalb sehr einfach. +Einige unserer Teammitglieder hatten bereits Erfahrungen mit Unity gesammelt und haben vor allem betont, dass mit Unity der Export für das Android-Betriebssystem, im Gegensatz zu anderen Engines, problemlos verläuft. Unsere Wahl gestaltete sich deshalb sehr einfach. Denn Unity ist eine vollwertige Spiel-Engine, die bereits viele Features mit sich bringt. Als Einsteiger muss man sich nicht damit beschäftigen, Shader zu programmieren oder ein robustes Physiksystem zu bauen. Das heißt nicht, dass uns alles abgenommen wurde. Das Grundgerüst mussten wir natürlich selbst erstellen und eigene Algorithmen entwickeln, um unser Spiel erst lauffähig zu machen. Unity war uns eine große Hilfe, das Projekt innerhalb dieses Semesters zu realisieren. {{
}} {{
}} -Wir haben uns als Zielgruppe junge Erwachsene gesetzt, weil es kaum Konzentrations- und Motorikspiele gibt, die unsere Generation ansprechen sollen. Da wir aus eigener Erfahrung wussten, dass gerade Mobile-Games oft alleine wegen ihres visuellen Designs heruntergeladen werden, dachten wir, dass, wenn wir schon ein sehr buntes Spiel haben, das Fünkchen 80er Nostalgie, dem Spiel nicht nur ein zusammenhängendes und stilisiertes aussehen geben könnte, sondern auch wegen dem aktuellen Nostalgie-Trend gerade unsere Zielgruppe ansprechen würde. Damit heben wir uns auch stark von anderen Konzentrationsspielen ab und setzen ein klares Statement, dass unser Spiel auch Spaß machen soll. +Wir haben uns als Zielgruppe junge Erwachsene gesetzt, weil es kaum Konzentrations- und Motorikspiele gibt, die unsere Generation ansprechen sollen. Da wir aus eigener Erfahrung wussten, dass gerade Mobile-Games oft alleine wegen ihres visuellen Designs heruntergeladen werden, dachten wir, dass, wenn wir schon ein sehr buntes Spiel haben, das Fünkchen 80er Nostalgie, dem Spiel nicht nur ein zusammenhängendes und stilisiertes aussehen geben könnte, sondern auch wegen des aktuellen Nostalgie-Trends gerade unsere Zielgruppe ansprechen würde. Damit heben wir uns auch stark von anderen Konzentrationsspielen ab und setzen ein klares Statement, dass unser Spiel auch Spaß machen soll. {{
}} diff --git a/content/ss21/bachelor/b1-strollr-project/features.md b/content/ss21/bachelor/b1-strollr-project/features.md index d80efc1..57086c8 100644 --- a/content/ss21/bachelor/b1-strollr-project/features.md +++ b/content/ss21/bachelor/b1-strollr-project/features.md @@ -16,14 +16,14 @@ Next up is our **Photo Editor**. During your time strolling around, you might wa With the help of our powerful photo editor you are able to make every picture you've taken shine. You can adjust **contrast, brightness, crop or use filters**! ## Questionnaire -Strollr is **aimed** especially at **kids at school age**, to deliver an **additional form** of interaction for them **to engage with the environment**. -That is why we have implemented the **questionnaire feature**! Here children are able to **note what they know** **about** a certain **plant or animal**, +Strollr is **aimed** especially at **kids of school age**, to deliver an **additional form** of interaction for them **to engage with the environment**. +That is why we have implemented the **questionnaire feature**! Here, children are able to **note what they know** **about** a certain **plant or animal**, thus there is the option to **take notes** and **write down questions that** they can **discuss with teachers or parents** later on. ## Herbarium -The **Gallery** is the next big feature of Strollr. Here you are able to **revisit** your **pictures** and remember the **tracks** you were on! Below the photo, you can see crucial information to your subject! -So every **information you provide**, is **saved** and there for you to **edit afterwards**! +The **Gallery** is the next big feature of Strollr. Here, you are able to **revisit** your **pictures** and remember the **tracks** you were on! Below the photo, you can see crucial information to your subject! +So every piece of **information you provide** is **saved** and there for you to **edit afterward**! ## Statistics -We also provide information on your current **statistics** like **walked kilometers** and **time spent** for strolling around. +We also provide information on your current **statistics**, like **walked kilometers** and **time spent** for strolling around. {{
}} \ No newline at end of file diff --git a/content/ss21/bachelor/b1-strollr-project/future.md b/content/ss21/bachelor/b1-strollr-project/future.md index fc0aee0..0713bae 100644 --- a/content/ss21/bachelor/b1-strollr-project/future.md +++ b/content/ss21/bachelor/b1-strollr-project/future.md @@ -17,7 +17,7 @@ plug-ins for **social media** platforms like WhatsApp, Instagram or Facebook. This platform could include a shared map where pins indicate the starting point of shared strolls. On click, you could be forwarded to the overview of the stroll, where the tracked walk and information about the stroll are displayed. Maybe you just want to **go through the pictures the other user made throughout their stroll** (of course you can like and comment) or even solve some riddles yourself. -Since Strollr’s original idea is to capture the stroll via pictures and learn something new about the environment, the option to **help others to find out what plant, tree or animal they managed to find** along the way is vital. +Since Strollr’s original idea is to capture the stroll via pictures and learn something new about the environment, the option to **help others find out what plant, tree or animal they managed to find** along the way is vital. Therefore, the sharing user could send out a request in a provided category and other users could share their guesses. _So get inspired and start your own stroll._ diff --git a/content/ss21/bachelor/b1-strollr-project/process.md b/content/ss21/bachelor/b1-strollr-project/process.md index f1262bb..380246f 100644 --- a/content/ss21/bachelor/b1-strollr-project/process.md +++ b/content/ss21/bachelor/b1-strollr-project/process.md @@ -5,8 +5,8 @@ weight = 2 {{
}} -The **idea** for our app **originated** out of a **conversation** with a **local gardening project**. It is an approach to a rather recent question: _How do you make spending time in nature more appealing to children and adolescents who grew up on smartphones and other mobile devices?_ \ -Our supervisor, **Prof. Dr. Lenz** approached us with his initial idea for a **mobile application** which already laid out most of the **core features** that the final version of Strollr incorporates, like the ability to take photos and **visualize walks** with a map. +The **idea** for our app **originated** from a **conversation** with a **local gardening project**. It is an approach to a rather recent question: _How do you make spending time in nature more appealing to children and adolescents who grew up on smartphones and other mobile devices?_ \ +Our supervisor, **Prof. Dr. Lenz**, approached us with his initial idea for a **mobile application** which already laid out most of the **core features** that the final version of Strollr incorporates, like the ability to take photos and **visualize walks** with a map. During a brainstorm session, we collected our own input and came up with a **design concept**. \ With that in mind, our first **mockups** were created. {{
}} @@ -20,7 +20,7 @@ After agreeing on **Flutter** as our **development framework**, we briefly **fam Going into the development period, we separated the group into **three teams**, concerned with the general **UI**, **map visualization** and **database design**. This way, we could focus on different tasks while maintaining communication within the group and making use of agile techniques like **pair programming** and **code review**. Maintaining our source code with Git allowed us to simultaneously implement different features on their respective branches and avoid conflicts when integrating them. \ -We manifested a **biweekly rhythm for the big team meetings** with our supervisor in which we reviewed our recent progress, **collected feedback** and **set goals** for the **following two-week period**. +We manifested a **biweekly rhythm for the big team meetings** with our supervisor, in which we reviewed our recent progress, **collected feedback** and **set goals** for the **following two-week period**. Additional weekly calls with the core team helped us to stay current on each other's progress and resolve potential issues.\ Throughout the development phase, we **continuously updated our Backlog** of ideas, **collectively taking** on the **role** of a **product owner**. Making use of project management tools, we constructed user stories and arranged them in a Story Map, thereby identifying and refining **the most important features**. diff --git a/content/ss21/bachelor/b1-strollr-project/tech-stack.md b/content/ss21/bachelor/b1-strollr-project/tech-stack.md index 9cc34f6..8ab422c 100644 --- a/content/ss21/bachelor/b1-strollr-project/tech-stack.md +++ b/content/ss21/bachelor/b1-strollr-project/tech-stack.md @@ -6,7 +6,7 @@ weight = 3 {{
}} #### Miro -We used our Miro board primarily for **planning** our weekly meetings ahead of time and as sort of a blank space for **brainstorming** and working on our **project management** assignments. The wide variety of tools and plugins was of great benefit to us. +We used our Miro board primarily for **planning** our weekly meetings ahead of time and as a sort of blank space for **brainstorming** and working on our **project management** assignments. The wide variety of tools and plugins was of great benefit to us. #### Trello Trello was used to keep track of our **Backlog** and document the **progression** of all our tasks. The **kanban style layout** and handy functions like requirements and deadlines made it the perfect choice for the job. @@ -20,7 +20,7 @@ During our time developing Strollr, Discord was the **main hub** for all our con #### Flutter™️ During the early planning stages, we decided that our application should be able to run on both Android and iOS. As a result of that, we narrowed down our framework options to **React Native** and **Flutter**. Having **little to no experience with app development** at that time and relying mainly on our own research and experiences from previous IMI projects, we decided that **Flutter** should be the framework of our choice. -Flutter is provided by Google and based on Dart, a programming language similar to JavaScript. Its biggest advantage is the ability to deploy projects on both **Android and iOS** with **very little adjustments**. Additionally, it is **well documented** and beginner-friendly. +Flutter is provided by Google and based on Dart, a programming language similar to JavaScript. Its biggest advantage is the ability to deploy projects on both **Android and iOS** with **very little adjustment**. Additionally, it is **well documented** and beginner-friendly. #### Android Studio, IntelliJ or Visual Code? Instead of specifying one, we used a **variety** of different **IDEs**, all of them offering integration for the Flutter SDK. This way, everyone could choose according to their own preferences and feel comfortable while coding, which was important to us. @@ -29,13 +29,13 @@ Instead of specifying one, we used a **variety** of different **IDEs**, all of t For the **tracking capabilities** of our App, we are using the **Google Maps API** for Flutter. It is provided via the **Google Cloud Services** and free to use within a certain request limit. But for our use case, that was **plenty enough**! #### GitHub -The **version control** system of our choice is **Git** with **GitHub** as the hosting platform. Easy to use, hard to master, but definitely a +The **version control** system of our choice is **Git**, with **GitHub** as the hosting platform. Easy to use, hard to master, but definitely a **good training exercise** for later jobs. We struggled with occasional **merge errors** and some other **branching issues**, but managed to overcome them by means of research and team spirit. #### SQLite -Since our app runs locally we chose SQLite as relational database to persist and query the data. SQLite is an **open source database** that -does **not require a server** and provides faster inserts, updates, and queries compared to other **local persistence solutions** (like local file or key-value store). -With the help of the **sqflite plugin**, flutter can easily make use of the database. +Since our app runs locally we chose SQLite as a relational database to persist and query the data. SQLite is an **open source database** that +does **not require a server** and provides faster inserts, updates, and queries compared to other **local persistence solutions** (like a local file or key-value store). +With the help of the **sqflite plugin**, Flutter can easily make use of the database. {{tech stack part 2}} diff --git a/content/ss21/master/m1-gezumi/_index.md b/content/ss21/master/m1-gezumi/_index.md index 4e25a98..5c72802 100644 --- a/content/ss21/master/m1-gezumi/_index.md +++ b/content/ss21/master/m1-gezumi/_index.md @@ -14,11 +14,11 @@ supervisor = "Prof. Dr. Tobias Lenz" {{}} {{
}} -**Ge**ometrie **Zu**m **Mi**tnehmen (GeZuMi) was created with the objective of testing the **boundaries and possibilites of Bluetooth** technologies in mind. The ideal outcome of the project was to be a fully functional application that would allow an **unspecified number of players (n)** to play a game that would display a **geometric shape with n sides and corners** that the users would then **reproduce in real life**. Everyone involved in the project was aware from the beginning that the objective might not be obtainable due to technical constraints. +**Ge**ometrie **Zu**m **Mi**tnehmen (GeZuMi) was created with the objective of testing the **boundaries and possibilities of Bluetooth** technologies in mind. The ideal outcome of the project was to be a fully functional application that would allow an **unspecified number of players (n)** to play a game that would display a **geometric shape with n sides and corners** that the users would then **reproduce in real life**. Everyone involved in the project was aware from the beginning that the objective might not be obtainable due to technical constraints. {{
}} {{
}} -The team was made up of five people with diverse development backgrounds. Before the start of the project, only two of the five had actively worked on an Android App and Bluetooth development. To improve efficiency and speed, we split into two main focal points: One was setting up and ensuring a stable Bluetooth connection whereas the other dealt more heavily with the mathematical aspects of the project. +The team was made up of five people with diverse development backgrounds. Before the start of the project, only two of the five had actively worked on an Android App and Bluetooth development. To improve efficiency and speed, we split into two main focal points: One was setting up and ensuring a stable Bluetooth connection, whereas the other dealt more heavily with the mathematical aspects of the project. {{
}} {{}} diff --git a/content/ss21/master/m1-gezumi/features.md b/content/ss21/master/m1-gezumi/features.md index 6189c33..72cd838 100644 --- a/content/ss21/master/m1-gezumi/features.md +++ b/content/ss21/master/m1-gezumi/features.md @@ -11,7 +11,7 @@ To help players understand which of the **'player-dots'** they represent on the #### Join-Requests -After choosing a player name and clicking 'Join Game' on the start screen, users can **scan for existing games and request to join** one. After having been approved, the player will be see the game screen as soon as the host starts the game. +After choosing a player name and clicking 'Join Game' on the start screen, users can **scan for existing games and request to join** one. After having been approved, the player will see the game screen as soon as the host starts the game. {{
}} {{client user flow}} @@ -47,7 +47,7 @@ The first step is the **distance calculation** between the different players. Th {{
}} -After the distances between all players are known, the player positions can be calculated. Only **relative positions** can be calculated from the distances. This means that the resulting triangle can be transformed by translation, rotation or reflection and would still match all the distances (**congruence**). +After the distances between all players are known, the player positions can be calculated. Only **relative positions** can be calculated from the distances. This means that the resulting triangle can be transformed by translation, rotation or reflection and still match all the distances (**congruence**). {{Step 1 distances to positions}} @@ -64,21 +64,21 @@ Player A is positioned at the origin of the coordinate system. Player B is posit {{Step 3 distances to positions}} -Finally, the alpha angle can be calculated using the law of cosines. This in turn can be used to determine the x and y position of player C. +Finally, the alpha angle can be calculated using the law of cosines. This, in turn, can be used to determine the x and y position of player C. {{
}} {{
}} -As the calculated player positions are **relative**, they need to be aligned to the target shape. As soon as the players' positions and the positions of the target shape have the same distances between them, the shapes have to lie perfectly **on top of each other**. This is done in three steps: +As the calculated player positions are **relative**, they need to be aligned to the target shape. As soon as the players' positions and the positions of the target shape have the same distance between them, the shapes have to lie perfectly **on top of each other**. This is done in three steps: {{Step 1 Shape Alignment}} -At first the position of player A is always **translated** to the 'first' point of the target shape (Step 1). +At first, the position of player A is always **translated** to the 'first' point of the target shape (Step 1). {{Step 2 and 3 Shape Alignment}} -In Step 2 the player shape is **rotated** so that the corresponding sides of the target and the player shape are parallel. +In Step 2, the player shape is **rotated** so that the corresponding sides of the target and the player shape are parallel. Finally, both shapes are **centered** independently on the game screen. {{
}} @@ -86,7 +86,7 @@ Finally, both shapes are **centered** independently on the game screen. {{
}} **Bluetooth Low Energy (BLE)** is the foundation of GeZuMi. Throughout the app, the connection relies on a **broadcasting approach** that avoids having to pair all devices with each other, which would make the connection unstable, and a **client-server-communication** between clients and the host of the game. -Clients that have joined a game make themselves noticeable to other players via broadcasting and communicate with the host which provides updates of the game state. The **Bluetooth packages** that are broadcast by every player contain a game-specific identifier and some game data to be processed by all other players. Using the **8-byte-game-identifier** games running simultaneously at the same place can be differentiated. Through slight variations of the ID, devices can determine wether another device is a host or a client which is necessary for a consistent join process. Other **game data** included in these packages are a **custom device identifier** which is unique per device, a device name, the game name, and the device-specific transmission power value, for example. Due to the very limited size of the broadcast packages (around 20-25 bytes available for custom data), they could only contain the most important bits of information, and some **filtering mechanisms** had to be built in order to maximize the packages' utility. +Clients that have joined a game make themselves noticeable to other players via broadcasting and communicate with the host, which provides updates on the game state. The **Bluetooth packages** that are broadcast by every player contain a game-specific identifier and some game data to be processed by all other players. Using the **8-byte-game-identifier** games running simultaneously at the same place can be differentiated. Through slight variations of the ID, devices can determine whether another device is a host or a client, which is necessary for a consistent join process. Other **game data** included in these packages are a **custom device identifier**, which is unique per device, a device name, the game name, and the device-specific transmission power value, for example. Due to the very limited size of the broadcast packages (around 20-25 bytes available for custom data), they could only contain the most important bits of information, and some **filtering mechanisms** had to be built in order to maximize the packages' utility. The broadcast packages can be received by other devices scanning the environment. This enables them to measure and calculate the distance to other players. Using direct client-server-connection, every client sends the measured and processed data to the **host device** which **collects, joins and corrects all the data**. The host is responsible for **computing a valid game state** (i.e. the positions of all players) and providing consistent game data to the clients. Clients and server communicate via the **ATT (Attribute Protocol)** data protocol. The host runs a **game service** that contains **characteristics**. The service as well as its characteristics are addressed using predefined 128-bit-UUIDs. The characteristics can be used by the clients for reading or writing data. The host is able to **notify** clients that have subscribed to a certain characteristic. The data is written in a serialized manner because of the limited number of bytes that can be transferred via a characteristic. diff --git a/content/ss21/master/m1-gezumi/future.md b/content/ss21/master/m1-gezumi/future.md index 283ee83..ebc959b 100644 --- a/content/ss21/master/m1-gezumi/future.md +++ b/content/ss21/master/m1-gezumi/future.md @@ -17,6 +17,6 @@ Ideally, with an improvement in distance and position calculation, **more than t #### Gamification In the future, more gamification features will be included in the game. To incentivize more games, overall **highscore lists** are planned. This would allow players to compare their own group with the skills and speed of others and, hopefully, increase the team's motivation. -Different types of **levels or game modes** are also in planning. One version would be to have a **predefined game time**, of 60 seconds for example, with the objective of matching **as many target shapes as possible**. Another alternative is the '**blind mode**'. In this game mode, only one player would see the target shape. They then need to quickly and clearly direct their teammates to their target positions. +Different types of **levels or game modes** are also in planning. One version would be to have a **predefined game time**, for example of 60 seconds, with the objective of matching **as many target shapes as possible**. Another alternative is the '**blind mode**'. In this game mode, only one player would see the target shape. They then need to quickly and clearly direct their teammates to their target positions. {{
}} diff --git a/content/ss21/master/m1-gezumi/process.md b/content/ss21/master/m1-gezumi/process.md index 3cb9228..d35aaba 100644 --- a/content/ss21/master/m1-gezumi/process.md +++ b/content/ss21/master/m1-gezumi/process.md @@ -4,8 +4,8 @@ weight = 2 +++ {{
}} -At the beginning, all ideas were collected on a Miroboard from which the following mock-ups were then developed (see image below). Players would land on a **starting screen** where they could select whether they wanted to start a new game or join an existing one. **Two variants for the game-setup screen** were mocked (screen 2 and 3). One would allow the host to **manually select the players** for a game, while the other alternative would **randomly create teams** based on all available, current app users. **Additional settings**, such as team size and the game's duration, were considered as well. -Not shown in the image are the potential features that were discussed in the beginning of the ideation phase, such as a 'calibration round' to potentially reduce the learning curve as well as a scoring system that would allow different teams to compete against each other. +At the beginning, all ideas were collected on a Miro board, from which the following mock-ups were then developed (see image below). Players would land on a **starting screen** where they could select whether they wanted to start a new game or join an existing one. **Two variants for the game-setup screen** were mocked (screens 2 and 3). One would allow the host to **manually select the players** for a game, while the other alternative would **randomly create teams** based on all available current app users. **Additional settings**, such as team size and the game's duration, were considered as well. +Not shown in the image are the potential features that were discussed in the beginning of the ideation phase, such as a 'calibration round' to potentially reduce the learning curve, as well as a scoring system that would allow different teams to compete against each other. {{First Mockups of the App}} @@ -13,7 +13,7 @@ After the initial mockups, some very basic designs were created. These designs d {{First App Design}} -Different possibilities on how to visualize the game were tried out. In the mock-up, the plan was to color individual player positions as soon as they matched the target. During the implementation, it became clear that this was not technically possible with the chosen concept of position determination. Coloring the line between the players green as soon as they are correct was also considered (see image above). In the end, the decision was made to display the **target shape in the background**: +Different possibilities for how to visualize the game were tried out. In the mock-up, the plan was to color individual player positions as soon as they matched the target. During the implementation, it became clear that this was not technically possible with the chosen concept of position determination. Coloring the line between the players green as soon as they are correct was also considered (see image above). In the end, the decision was made to display the **target shape in the background**: {{Different game mode}} @@ -28,11 +28,11 @@ The final implemented design can be seen below. {{
}} {{
}} -The development process was split into **one-week sprints**, with a self-contained feature release and briefing with the project supervisor every other week. In weekly sprint meetings all team members were brought up to date and new goals were set for the upcoming sprint. +The development process was split into **one-week sprints**, with a self-contained feature release and a briefing with the project supervisor every other week. In weekly sprint meetings, all team members were brought up to date and new goals were set for the upcoming sprint. For **pair programming**, brainstorming or researching the team met in smaller sub-groups based on who was working on the respective task. To improve collaboration as a team and reflect on conflicts and impediments, a **retrospective** was organized whenever the need arose. -Due to the social distancing regulations, the process was fully organized through digital meetings. Toward the end of the project's time-frame, in-person meetings became possible again and were used to focus on specific challenges and to prepare the show-time. +Due to the social distancing regulations, the process was fully organized through digital meetings. Toward the end of the project's timeframe, in-person meetings became possible again and were used to focus on specific challenges and to prepare the show-time. With Github Project each sprint iteration was organized (see image below). {{
}} @@ -70,9 +70,9 @@ Another problem was that devices have **different transmission powers**. Dependi
-**Position updates come suddenly** and not at regular intervals. That makes the game seem random and unpredictable at times. To prevent this we **interpolate** the position change and animate it over two seconds. +**Position updates come suddenly** and not at regular intervals. That makes the game seem random and unpredictable at times. To prevent this, we **interpolate** the position change and animate it over two seconds. -If a new position arrives in the meantime, the current animation is interrupted and the next position change is animated. Below you can see the position changes before and after filtering and interpolation. +If a new position arrives in the meantime, the current animation is interrupted and the next position change is animated. Below, you can see the position changes before and after filtering and interpolation. {{
}} @@ -83,10 +83,10 @@ If a new position arrives in the meantime, the current animation is interrupted {{
}} -One challenge was the **small community of BLE developers** as it made finding support quite difficult. Google provides good documentation, however the tutorial was not very thorough and the search for material took a significant amount of time. +One challenge was the **small community of BLE developers**, as it made finding support quite difficult. Google provides good documentation, however the tutorial was not very thorough and the search for material took a significant amount of time. -Another difficulty was how to gracefully handle the **Android lifecycle** in our App. A lot happens behind the scenes when an app is opened, paused or stopped. As the goal was to build a **consistent application** a solution for managing the connections and Bluetooth activity on Android events was indispensable. Should a client be disconnected from the game if they pause the app? When should the Bluetooth scanner be turned off to save power? Can the host reconnect to a game session? +Another difficulty was how to gracefully handle the **Android lifecycle** in our App. A lot happens behind the scenes when an app is opened, paused or stopped. As the goal was to build a **consistent application**, a solution for managing the connections and Bluetooth activity on Android events was indispensable. Should a client be disconnected from the game if they pause the app? When should the Bluetooth scanner be turned off to save power? Can the host reconnect to a game session? -Dealing with the limited size of Bluetooth packages was another big part of the Bluetooth implementation. To make the most of the limited package size, some filtering and **masking** for the environment scan had to be implemented. The built-in filter functionality for BLE scans caused some problems and did not work as intended which took us quite a bit to realize. Since we needed some extra filtering mechanisms anyway, we implemented our own masks for BLE scans. +Dealing with the limited size of Bluetooth packages was another big part of the Bluetooth implementation. To make the most of the limited package size, some filtering and **masking** for the environment scan had to be implemented. The built-in filter functionality for BLE scans caused some problems and did not work as intended, which took us quite a bit to realize. Since we needed some extra filtering mechanisms anyway, we implemented our own masks for BLE scans. {{
}} diff --git a/content/ss21/master/m1-gezumi/tech-stack.md b/content/ss21/master/m1-gezumi/tech-stack.md index ecdfe2e..0144d1a 100644 --- a/content/ss21/master/m1-gezumi/tech-stack.md +++ b/content/ss21/master/m1-gezumi/tech-stack.md @@ -27,7 +27,7 @@ Common with all modern technologies and tech stacks, using a newer approach inhe #### GitHub GitHub was used to **host** the code as well as for the **project management**. -Using Github Actions a **CI/CD pipeline** was implemented. +Using Github Actions, a **CI/CD pipeline** was implemented. It ensures a high code quality and builds an apk which is then released on Github. {{CI Pipeline}} diff --git a/content/ss22/master/m1-could-it-be-more-unreal/_features.md b/content/ss22/master/m1-could-it-be-more-unreal/_features.md index dde768b..d8048e2 100644 --- a/content/ss22/master/m1-could-it-be-more-unreal/_features.md +++ b/content/ss22/master/m1-could-it-be-more-unreal/_features.md @@ -56,7 +56,7 @@ Lumen is Unreal Engine 5's fully dynamic global illumination and reflections sys {{}} {{
}} -Nanite is a new virtualized geometry system of Unreal Engine 5 which uses a new internal mesh format and rendering technology to render pixel scale detail and high object counts. It intelligently shows only human-perceivable details. +Nanite is a new virtualized geometry system of Unreal Engine 5, which uses a new internal mesh format and rendering technology to render pixel scale detail and high object counts. It intelligently shows only human-perceivable details. {{}} {{
}} diff --git a/content/ss22/master/m1-could-it-be-more-unreal/_index.md b/content/ss22/master/m1-could-it-be-more-unreal/_index.md index a1ce7ca..e229045 100644 --- a/content/ss22/master/m1-could-it-be-more-unreal/_index.md +++ b/content/ss22/master/m1-could-it-be-more-unreal/_index.md @@ -13,8 +13,8 @@ supervisor = "Prof. Dr. Tobias Lenz" {{
}} -On April 5, 2022, Unreal Engine 5 was officially released. This was a perfect timing for us as a team! The new version of the engine offers many new features, which we wanted to take a closer look on. We dealt with the Nanite Virtualized Geometry System, the MetaHuman Creator, Niagara Fluid Simulation and many more Features. +On April 5, 2022, Unreal Engine 5 was officially released. This was a perfect timing for us as a team! The new version of the engine offers many new features, which we wanted to take a closer look at. We dealt with the Nanite Virtualized Geometry System, the MetaHuman Creator, Niagara Fluid Simulation and many more features. -The result of our project is a playable showcase demo which supports many of the new features. We built a living world with wandering animals, flying insects, dense woods, a dark cave, medieval buildings and different small riddles to make the playable showcase demo as an experience. We also included an online multiplayer with Steam to experience the world not alone, but together! +The result of our project is a playable showcase demo, which supports many of the new features. We built a living world with wandering animals, flying insects, dense woods, a dark cave, medieval buildings and different small riddles to make the playable showcase demo an experience. We also included an online multiplayer with Steam to experience the world not alone but together! {{
}} \ No newline at end of file diff --git a/content/ss22/master/m1-could-it-be-more-unreal/_process.md b/content/ss22/master/m1-could-it-be-more-unreal/_process.md index a2bbae9..4984d7f 100644 --- a/content/ss22/master/m1-could-it-be-more-unreal/_process.md +++ b/content/ss22/master/m1-could-it-be-more-unreal/_process.md @@ -20,10 +20,10 @@ One of our focus was to create some various assets ourselves using the software The photorealistic nature of the showcase demo, coupled with Nanite allowed high-poly meshes to be created and used directly in Unreal Engine. This workflow was used for example for the wall and gate at the beginning of the demo. A simple low-poly model was created, subdivided and the resulting geometry was displaced via heightmaps that came coupled with the PBR-textures that were then applied to the resulting geometry. To reduce file size, the geometry was then decimated, which is a process somewhat akin to lossy compression, where low-detail vertices get removed from the mesh. {{}} {{}} -The cave was a special case, as modeling such an organic shape would have been difficult. As a base, a low-poly mesh was constructed, containing the openings at both ends as well as the chambers and pathways. The pillars in the main chamber were separate meshes combined with the cave via a boolean operation. With the complete base the remaining detail, roundings and protrusions were sculpted in. For texturing triplanar mapping was used, as UV-mapping such a complex object without obvious texture stretching or texture boundaries would have proven an exercise in futility. Furthermore, painting a custom texture, while possible, would have produced an enormous texture, which was not the case with the simple tiling texture used and projected along world space coordinates. +The cave was a special case, as modeling such an organic shape would have been difficult. As a base, a low-poly mesh was constructed, containing the openings at both ends as well as the chambers and pathways. The pillars in the main chamber were separate meshes combined with the cave via a boolean operation. With the complete base the remaining detail, roundings and protrusions were sculpted in. For texturing, triplanar mapping was used, as UV-mapping such a complex object without obvious texture stretching or texture boundaries would have proven an exercise in futility. Furthermore, painting a custom texture, while possible, would have produced an enormous texture, which was not the case with the simple tiling texture used and projected along world space coordinates. {{}} {{}} -Finally, simple modeling was also used, as the walkway found in the cave was essentially a lot of cuboids fitted together in a convincing manner. Of course to resemble real wooden construction the perfectly straight and right angle boxes were subdivided and distorted and had their edges beveled so as to look more convincingly wooden and hand-made. +Finally, simple modeling was also used, as the walkway found in the cave was essentially a lot of cuboids fitted together in a convincing manner. Of course, to resemble real wooden construction, the perfectly straight and right angle boxes were subdivided and distorted and had their edges beveled so as to look more convincingly wooden and hand-made. {{}} {{}} For even better texturing, vertex colors were used on many custom objects to vary their appearance in different parts of the model. One example is how the material of the cave is glossier where water would run into the pond. Another is the material for the mirrors blending between very corroded bronze, mildly corroded bronze and shiny bronze as well as varying the roughness of the shiny part, all using vertex colors to blend the various textures. @@ -32,7 +32,7 @@ For even better texturing, vertex colors were used on many custom objects to var {{}} {{
}} -First experiments using around 50 pictures shot with the subjects standing and using a wide-angle lens from close up produced barely if at all usable results. Missing features, artifacts and a generally low-resolution scan of the subjects made post-processing extremely difficult. Our teammate Hendrik then delivered a good scan of himself, which allowed us to pinpoint the differences and come up with a theory as to how to get Meshroom to produce better scans. He used a crop-sensor DSLR with a 50mm lens, giving him a narrow field of view. Coupled with the distance the camera was moved between pictures, this gave Meshroom very little information to also reconstruct the background, Information which was plentiful in the wide-angle shots used previously. In the second round of scans, more pictures were taken per person - around 150 - and make-up markers were added on the face to aid the algorithm in creating an accurate point cloud. Additionally, the background was manually masked out in all pictures preventing any reconstruction of anything but the subject. This produced good to excellent results, which were easily post processed via sculpting in Blender. For texturing again triplanar mapping was used with vertex colors determining parts of increased roughness, such as the hair, bears (if present) and eyes as that makes these parts visually distinct. +First experiments using around 50 pictures shot with the subjects standing and using a wide-angle lens from close up produced barely if at all usable results. Missing features, artifacts and a generally low-resolution scan of the subjects made post-processing extremely difficult. Our teammate Hendrik then delivered a good scan of himself, which allowed us to pinpoint the differences and come up with a theory as to how to get Meshroom to produce better scans. He used a crop-sensor DSLR with a 50mm lens, giving him a narrow field of view. Coupled with the distance the camera was moved between pictures, this gave Meshroom very little information to also reconstruct the background, Information which was plentiful in the wide-angle shots used previously. In the second round of scans, more pictures were taken per person - around 150 - and make-up markers were added on the face to aid the algorithm in creating an accurate point cloud. Additionally, the background was manually masked out in all picture, preventing any reconstruction of anything but the subject. This produced good to excellent results, which were easily post processed via sculpting in Blender. For texturing again triplanar mapping was used with vertex colors determining parts of increased roughness, such as the hair, bears (if present) and eyes as that makes these parts visually distinct. {{}} {{
}} @@ -50,12 +50,12 @@ In addition to blackboards, we also used Unreal's AI Perception, which can simul {{}} {{
}} -For our character models we used Epic Games' MetaHuman-Creator, which is a toolset within the Unreal eco system for achieving lifelike human characters. Our animations are retargeted to fit our MetaHumans. +For our character models, we used Epic Games' MetaHuman-Creator, which is a toolset within the Unreal eco system for achieving lifelike human characters. Our animations are retargeted to fit our MetaHumans. {{}} {{
}} {{
}} -With Unreal Engine 5 the developer gets a new workflow which greatly speeds up the retargeting process for any humanoid character. Futhermore there is a new IK Rig System, which lets one alter IK Goals during Runtime. +With Unreal Engine 5 the developer gets a new workflow, which greatly speeds up the retargeting process for any humanoid character. Furthermore, there is a new IK Rig System, which lets one alter IK Goals during Runtime. {{}} {{
}} diff --git a/content/ss22/master/m1-could-it-be-more-unreal/_tech_stack.md b/content/ss22/master/m1-could-it-be-more-unreal/_tech_stack.md index 635e7d1..1aa9368 100644 --- a/content/ss22/master/m1-could-it-be-more-unreal/_tech_stack.md +++ b/content/ss22/master/m1-could-it-be-more-unreal/_tech_stack.md @@ -9,7 +9,7 @@ weight = 3 * Unreal Engine 5
Unreal Engine 5 was our main tool.
We built our project and put all small parts together as one. * Steam
-We were able to play Could it be more Unreal? with Steam multiplayer using the Advanced Steam Sessions plugin. +We were able to play "Could it be more Unreal?" with Steam multiplayer using the Advanced Steam Sessions plugin. * MetaHuman
MetaHuman is a framework that enables anyone to create highly realistic human characters. {{}} diff --git a/content/ss23/bachelor/b2-i-cant-c-sharp/features.md b/content/ss23/bachelor/b2-i-cant-c-sharp/features.md index 67c71dd..129d6ca 100644 --- a/content/ss23/bachelor/b2-i-cant-c-sharp/features.md +++ b/content/ss23/bachelor/b2-i-cant-c-sharp/features.md @@ -9,7 +9,7 @@ weight = 1 The game is divided into two segments. A single player mode where each of our simple games can be played separately from others. -In the endless mode you can play until you run out of hearts. In this mode two randomly selected games of matching genres are displayed in parallel, on the right and left side respectively, and can be played simultaneously. +In the endless mode, you can play until you run out of hearts. In this mode, two randomly selected games of matching genres are displayed in parallel, on the right and left side respectively, and can be played simultaneously. {{}} {{}} @@ -22,7 +22,7 @@ During our research and preparation for the project, we discovered four types of + Cognition, tests your ability to deduce information; + Rhythm, tests your feel for the beat. -By being virtually from different genres and requiring different kinds of attention, played in parallel they do require a certain amount of skills and a lots of concentration. With each additional game added to the roster, the chances for unexpected combinations and thus new challenge-ground for the mind arises. +By being virtually from different genres and requiring different kinds of attention, played in parallel they do require a certain amount of skills and a lot of concentration. With each additional game added to the roster, the chances for unexpected combinations and thus new challenge-ground for the mind arises. {{}} @@ -36,9 +36,9 @@ There are the classic modes easy, medium and hard, but also a new one we named v * **Scores and Times** -What great game can do without high-scores, collecting points and a pressuring timer? Exactely! That´s why we have them, too. +What great game can do without high-scores, collecting points and a pressuring timer? Exactly! That´s why we have them, too. But we used them for "scientific reasons". ;)
-The points incentivise you to to stay engaged in playful testing of your concentration, while the high-scores indirectly show your progression and betterment of concentration, by constantly reaching higher values. The timer is a dreading sight at the beginning, but a great measuring Tools for your brain's endurance in the end. +The points incentivise you to stay engaged in playful testing of your concentration, while the high-scores indirectly show your progression and betterment of concentration, by constantly reaching higher values. The timer is a dreadful sight at the beginning, but a great measuring tool for your brain's endurance in the end. {{}} {{}} \ No newline at end of file diff --git a/content/ss23/bachelor/b2-i-cant-c-sharp/process.md b/content/ss23/bachelor/b2-i-cant-c-sharp/process.md index 3900bb4..a24fa52 100644 --- a/content/ss23/bachelor/b2-i-cant-c-sharp/process.md +++ b/content/ss23/bachelor/b2-i-cant-c-sharp/process.md @@ -14,5 +14,5 @@ In order to create a balanced gaming experience, we adapted the mini-games to th After collecting the game ideas and dividing the mini-games into four categories, we started developing the games. Since some already had experience with Unity, the first prototypes were built to illustrate. The group members with less experience first familiarized themselves with the development environment and initially built small test objects. -After we all got used to it, the games were implemented one after the other and simultaneously with everyone participating. A framework was created to structure the project. We also used this framework to regulate basic functions such as starting and pausing the entire game. +After we all got used to it, the games were implemented one after the other and simultaneously, with everyone participating. A framework was created to structure the project. We also used this framework to regulate basic functions such as starting and pausing the entire game. {{}} \ No newline at end of file diff --git a/content/ss23/bachelor/b2-i-cant-c-sharp/techstack.md b/content/ss23/bachelor/b2-i-cant-c-sharp/techstack.md index 6a012a2..78472ad 100644 --- a/content/ss23/bachelor/b2-i-cant-c-sharp/techstack.md +++ b/content/ss23/bachelor/b2-i-cant-c-sharp/techstack.md @@ -17,8 +17,8 @@ In the future, we have some exciting plans in store! Our commitment to continuou - **More Games:** The more the better! A various collection enhances the overall experience. - **Multiplayer Support:** Where you can engage in thrilling gameplay with and against other players. -- **Mechanic Modifiers:** For the motivated who are not fully occupied, there are some special events that make your gameplay spicy (e.g. mirrored controlls, enhanced button sequence, upside down visuals). +- **Mechanic Modifiers:** For the motivated who are not fully occupied, there are some special events that make your gameplay spicy (e.g. mirrored controls, enhanced button sequence, upside down visuals). - **Accessibility Options:** Appeal to everybody! Regardless of their abilities or preferences. -- **Especially important:** The innovative smart fridge version! Improve your skills even when cooking. +- **Especially important:** The innovative smart fridge version! Improve your skills, even when cooking. {{}} \ No newline at end of file diff --git a/content/ws20/bachelor/b1-kiss/_index.md b/content/ws20/bachelor/b1-kiss/_index.md index 16a9b07..0db6a88 100644 --- a/content/ws20/bachelor/b1-kiss/_index.md +++ b/content/ws20/bachelor/b1-kiss/_index.md @@ -17,18 +17,18 @@ supervisor = "Prof. Dr. Tobias Lenz" {{}} -KISS is intended for people who want to be more **concious** about their cosmetic products. KISS keeps track of your allergies and **warns** you whenever you scan a product with an allergic ingredient in it. KISS runs on both **IOS** and **Android** and **doens't require an internet connection** after the initial download. +KISS is intended for people who want to be more **conscious** about their cosmetic products. KISS keeps track of your allergies and **warns** you whenever you scan a product with an allergic ingredient in it. KISS runs on both **IOS** and **Android** and **doesn't require an internet connection** after the initial download. {{Mockup}} {{
}} For most people, the chemical ingredients on the back of cosmetic products are meaningless. -Very few people understand what a "Prunus Amygdalus Dulcis Oil" is. This is where our app comes into place. We wanted to **help people understand** what it **means** and what it **does**. The **work** that the user has to put in to get the information needed, should be **as little as possible**. It also **shouldn't be dependant** on factors like a **good internet connection** or products with **barcodes**. +Very few people understand what a "Prunus Amygdalus Dulcis Oil" is. This is where our app comes into place. We wanted to **help people understand** what it **means** and what it **does**. The **work** that the user has to put in to get the information needed, should be **as little as possible**. It also **shouldn't be dependent** on factors like a **good internet connection** or products with **barcodes**. {{
}} {{
}} - **Communication is key.** Everyone was working towards the same goal and we all agreed on the importance of communication in that process. - Everyone of us found something that they were passionate about, which made our development process both **fun and motivating.** -- Henry, Jonathan and Anton were at first responsible for the backend while Kieu, Kenneth and Niklas were implementing the text recognition and UI but we switched around later on. +- Henry, Jonathan and Anton were at first responsible for the backend while Kieu, Kenneth and Niklas were implementing the text recognition and UI, but we switched around later on. {{
}} {{}} diff --git a/content/ws20/bachelor/b1-kiss/features.md b/content/ws20/bachelor/b1-kiss/features.md index 38e6dc7..d21248f 100644 --- a/content/ws20/bachelor/b1-kiss/features.md +++ b/content/ws20/bachelor/b1-kiss/features.md @@ -6,7 +6,7 @@ weight = 1 {{Mockup}} {{
}} #### Offline Data -Our app is completely offline compatible +Our app is completely offline compatible. We have **over 30.000 ingredients** stored in our data set. It was important for us to guarantee that the user is always able to use the app. Therefore we didn't want to rely on an internet connection. diff --git a/content/ws20/bachelor/b1-kiss/future.md b/content/ws20/bachelor/b1-kiss/future.md index 8f51531..26a6fd0 100644 --- a/content/ws20/bachelor/b1-kiss/future.md +++ b/content/ws20/bachelor/b1-kiss/future.md @@ -15,7 +15,7 @@ The European Commission has other datasets that are related to the CosIng datase There are a couple of common allergies like peanuts and shellfish out there. Our idea is to have **groups** for these allergies. Once a user selects one of the products, we **mark all the related allergies** to that product. It should make the **initial setup** of our app a little **easier**. #### Advanced camera -While our camera does what it is supposed to do, it is still pretty bare bones. **Post-processing for our images** is the keyword here. Little things like **adjusting the brightness** so the text recognition has an easier time recognising the text. We also want to give the user options like **turning on the flashlight** etc. +While our camera does what it is supposed to do, it is still pretty bare bones. **Post-processing for our images** is the keyword here. Little things like **adjusting the brightness**, so the text recognition has an easier time recognising the text. We also want to give the user options like **turning on the flashlight** etc. #### Barcode scanning There are a couple of apps out there that can scan the barcode of cosmetic products. While scanning the text is generally a better idea because not all products have barcodes on them, scanning the barcode still has a **couple of perks**, so **providing both options** is something we will look into as an upcoming feature. diff --git a/content/ws20/bachelor/b1-kiss/process.md b/content/ws20/bachelor/b1-kiss/process.md index 4b0f2cd..25d35d7 100644 --- a/content/ws20/bachelor/b1-kiss/process.md +++ b/content/ws20/bachelor/b1-kiss/process.md @@ -14,10 +14,12 @@ The other group was **responsible for the frontend** and how we **integrate the We were **always staying in contact** and **communicating with each other regularly**. We **stayed** in these **subgroups** up until our **prototype was done**. {{
}} + {{
}} We knew a couple of things before thinking of our design. Our app would have three pages: A **search, camera and history screen**. We also liked the idea of **valuing a clean and simple design over a complex one** because it fits our app the best. {{
}} {{Mockups}} + {{
}} For our **prototype**, we wanted to make sure that our **basic structure** and **feature set** is **present**. Our **UI** wasn't the **main focus at that point**. After having our prototype, we also set out to **improve our UI** by making it **look more like our Mockup**. {{
}} @@ -30,7 +32,7 @@ This process took some time because we came up with great ideas but filtering th The **Miro board helped us** a lot in the process of visualising and managing our ideas. We also used it as a Task/Kanban board. We **never ran out of ideas**, therefore our idea collection and **prioritisation changed weekly**. -Staying in touch with our **supervisor helped us** a good deal with our decision making over which features to implement. +Staying in touch with our **supervisor helped us** a good deal with our decision-making over which features to implement. Keeping a **constant communication flow allowed** us to be **very flexible**. This phase lasted until the end of our development. {{}} @@ -42,14 +44,14 @@ Our backend group struggled with retrieving data at first. Since our **data came from the European Commission**, who was **fond of helping people** who were going to use the data, we knew that we wanted to **get in touch** with them to see if they had an **API endpoint** or something else to help us in any way. It turns out they had one, but it was **poorly documented**. We **didn't know** how to **access the data** we wanted. -After a lot of **confusion** and a couple of **mails exchanging**, we found out that the endpoint **didn't even provide a way to access the data** but only to return a file containing the data. +After a lot of **confusion** and a couple of **mails exchanging**, we found out that the endpoint **didn't even provide a way to access the data**, but only to return a file containing the data. So it was a **dead-end** and cost us at least 1 1/2 weeks. #### Group responsible for our text recognition At around the same time, the other group struggled with their own problems. -One of their tasks was to **cut unnecessary words from our recognized text**, so we didn't have to search for them in our database hence improving our performance. -Their **idea** was to use **RegEx** but **no one** in our group **has used** RegEx before. +One of their tasks was to **cut unnecessary words from our recognized text**, so we didn't have to search for them in our database, hence improving our performance. +Their **idea** was to use **RegEx**, but **no one** in our group **has used** RegEx before. It was quite a **drag** for them to get into RegEx, especially because we had so many **little details to consider**. This was an **ongoing process** up until the end because there was always **something to improve on**. {{}} diff --git a/content/ws20/bachelor/b1-kiss/tech-stack.md b/content/ws20/bachelor/b1-kiss/tech-stack.md index dcb58d6..a99ed53 100644 --- a/content/ws20/bachelor/b1-kiss/tech-stack.md +++ b/content/ws20/bachelor/b1-kiss/tech-stack.md @@ -20,7 +20,7 @@ The **mobile SDK Firebase ML Kit** provides **machine learning functionalities** #### Android Studio and IntelliJ Installing Flutter, setting up the IDE and the necessary emulators was **trickier than expected**: -**Each team member** had to **fight** with some **issues** to get the tools running before we could start with the actual development. In the end, **half of our group** used **Android Studio** and the **others** went with **IntelliJ** but there aren't any differences in functionality. +**Each team member** had to **fight** with some **issues** to get the tools running before we could start with the actual development. In the end, **half of our group** used **Android Studio** and the **others** went with **IntelliJ**, but there aren't any differences in functionality. {{}} diff --git a/content/ws20/master/m1-augmented-boardgame-experience/_index.md b/content/ws20/master/m1-augmented-boardgame-experience/_index.md index 1fc45dd..cf8773e 100644 --- a/content/ws20/master/m1-augmented-boardgame-experience/_index.md +++ b/content/ws20/master/m1-augmented-boardgame-experience/_index.md @@ -8,7 +8,6 @@ card_description = "Is it possible to enhance board games with modern technology # These properties may be removed if you don't need them source_link = "https://linktr.ee/themole" -demo_link = "http://themole.ml" # website_link = "http://themole.ml" team = ["Bruno Schilling", "Christopher Adams", "Johannes Wanner", "Keoma Trippner", "Kevin Wrede", "Lena Serdarusic", "Shari-Lynn Eichberger"] @@ -19,11 +18,11 @@ supervisor = "Prof. Dr. Tobias Lenz" {{
}} -In our project we investigated the possibility of improving a traditional board game with modern technology. Due to the lockdowns during the corona situation, we developed a particular interest in the idea of a **digital board game**. It offers the possibility to have **common game nights** with friends **despite social distancing**. The board game can be shared via a desktop screen for all players to see. And players can join the game using their smartphones. The advantage of this variant is that, for example, it is easier to **conduct secret agreements or information** during the game using the smartphone. This guarantees that no unauthorized person will find out about it. Furthermore, less physical material is needed and it is very easy to switch between languages. Moreover the integration of a **"smart" opponent** is possible with the help of a digital board game. In addition, the atmosphere of the game can be supported with **suitable music**. Since most game lovers enjoy the luck required when **rolling the dice**, we wanted to preserve this aspect. Above all, it was important to us not to leave out the **social aspect** of a game night, despite the use of a smartphone. That's why we placed a lot of emphasis on ensuring that **communication** remains important in our game concept. +In our projec, we investigated the possibility of improving a traditional board game with modern technology. Due to the lockdowns during the corona situation, we developed a particular interest in the idea of a **digital board game**. It offers the possibility of having **common game nights** with friends **despite social distancing**. The board game can be shared via a desktop screen for all players to see. And players can join the game using their smartphones. The advantage of this variant is that, for example, it is easier to **conduct secret agreements or information** during the game using the smartphone. This guarantees that no unauthorized person will find out about it. Furthermore, less physical material is needed and it is very easy to switch between languages. Moreover, the integration of a **"smart" opponent** is possible with the help of a digital board game. In addition, the atmosphere of the game can be supported with **suitable music**. Since most game lovers enjoy the luck required when **rolling the dice**, we wanted to preserve this aspect. Above all, it was important to us not to leave out the **social aspect** of a game night, despite the use of a smartphone. That's why we placed a lot of emphasis on ensuring that **communication** remains important in our game concept. {{
}} {{
}} -In the game "The Mole" players take on the role of **Scotland Yard detectives**. Sherlock Holmes asks them to help him solve a **mysterious murder case**. While the players search for evidence to **find the murderer**, they are in the greatest **danger**, because the murderer is now targeting them. The goal of the game is to arrive at Scotland Yard before the murderer catches up with them. Also, you must find at least four solid pieces of evidence by then to finally arrest the murderer. The players can't win without colluding with each other, but beware! **Among them is a mole, a traitor who is in cahoots with the murderer.** +In the game "The Mole" players take on the role of **Scotland Yard detectives**. Sherlock Holmes asks them to help him solve a **mysterious murder case**. While the players search for evidence to **find the murderer**, they are in the greatest **danger** because the murderer is now targeting them. The goal of the game is to arrive at Scotland Yard before the murderer catches up with them. Also, you must find at least four solid pieces of evidence by then to finally arrest the murderer. The players can't win without colluding with each other, but beware! **Among them is a mole, a traitor who is in cahoots with the murderer.** {{
}} {{
}} @@ -54,7 +53,7 @@ All used icons are from **Font Awesome**. https://fontawesome.com/ The used logos of heroku, Nuxt.js and PostgreSQL are from the related **companies' websites**. -https://brand.heroku.com/ | https://nuxtjs.org/design | https://wiki.postgresql.org/wiki/Logo +https://nuxtjs.org/design | https://wiki.postgresql.org/wiki/Logo The used logos of django, JavaScript and Python are from **gilbarbara's Github repository**. https://github.com/gilbarbara/logos diff --git a/content/ws20/master/m1-augmented-boardgame-experience/features.md b/content/ws20/master/m1-augmented-boardgame-experience/features.md index afbaca6..be87a0e 100644 --- a/content/ws20/master/m1-augmented-boardgame-experience/features.md +++ b/content/ws20/master/m1-augmented-boardgame-experience/features.md @@ -29,7 +29,7 @@ To create the game, two steps are required. 1. **Host:** Open the browser on your computer, laptop or SmartTV and visit http://themole.ml. Click on "Create game" to start a new game session. Now you can see the game lobby and the players that have joined. Once all players are present, click on "Start game". -2. **Players:** If the game lobby is open on your computer, laptop or SmartTV, players can enter. To do this, scan the QR code or visit http://scotlandyard.ml. +2. **Players:** If the game lobby is open on your computer, laptop or SmartTV, players can enter. To do this, scan the QR code. {{
}} {{create and join game screens}} @@ -50,7 +50,7 @@ At the start of the game, players are randomly assigned different clues. There a {{
}} Once the game is started, a map and other game-related information appear on your computer, laptop or SmartTV. There are **four map sections in total, each with around 20 fields**. The fields are connected to each other and show the path you have to complete. When you reach the end of a map, you'll automatically move on to the next section, provided it's not the last one. -On the board game map there are **three types of fields**: "normal fields" (white), "occasion fields" (grey) which can trigger an event on your smartphone and "minigame fields" (blue) which offer you a shortcut, if you manage to win the minigame. On an **"occasion field"**, the player must choose one from two occasions. There are five occasions in total, three of which are positive and two negative. The **"minigame field"** is always located at a shortcut. Crossing a minigame field, the detective team will always be stopped to play a minigame (so far: a pantomime game) and if the word is guessed correctly by the whole team, the team is allowed to take the shortcut. On a **"normal field"** nothing happens. +On the board game map there are **three types of fields**: "normal fields" (white), "occasion fields" (grey) which can trigger an event on your smartphone and "minigame fields" (blue), which offer you a shortcut if you manage to win the minigame. On an **"occasion field"**, the player must choose one of two occasions. There are five occasions in total, three of which are positive and two negative. The **"minigame field"** is always located at a shortcut. Crossing a minigame field, the detective team will always be stopped to play a minigame (so far: a pantomime game) and if the word is guessed correctly by the whole team, the team is allowed to take the shortcut. On a **"normal field"** nothing happens. {{
}} {{The Map}} @@ -81,7 +81,7 @@ Players take their turn one after the other. The following options are available **View role:** Here you can see your role. If you are the mole, then keep it secret and do not stand out. -Click the button **"Show Clues"** to see all your clues. For each evidence category there are three correct clues that you have to find. If you have found all the clues of a category, you can verify them under "Send in Evidence". +Click the button **"Show Clues"** to see all your clues. For each evidence category, there are three correct clues that you have to find. If you have found all the clues in a category, you can verify them under "Send in Evidence". {{}} {{Waiting options}} @@ -89,15 +89,15 @@ Click the button **"Show Clues"** to see all your clues. For each evidence categ **When it is your turn**, you will see a selection menu. Here you can choose between four options. -**1. Roll the dice:** To advance on the map you can roll the dice and confirm the corresponding steps. For this you need a dice and a dicing disc. The game tells you how to roll the dice. If nothing special is shown to you, you roll the dice **normally** and enter the rolled number in the smartphone. If you see **hinder/easy** dice instead, you have to read exactly what to do. In both variants you have to use the dicing disc and try to hit the center. Then enter the area you landed in on your smartphone. +**1. Roll the dice:** To advance on the map, you can roll the dice and confirm the corresponding steps. For this you need a dice and a dicing disc. The game tells you how to roll the dice. If nothing special is shown to you, you roll the dice **normally** and enter the rolled number in the smartphone. If you see **hinder/easy** dice instead, you have to read exactly what to do. In both variants, you have to use the dicing disc and try to hit the center. Then enter the area you landed in on your smartphone. {{Dice Variants}} **2. Search for clues:** One way to get clues is to look for clues on your turn. Here you roll the dice and if you roll a four, five or six, you will find a clue. If successful, confirm this on your smartphone. -**3. Share clue:** Here you can share clues with other players to verify evidence faster. But be careful, don't always give your clues to the same person, because it could be the mole using them to work against the team. +**3. Share clues:** Here, you can share clues with other players to verify evidence faster. But be careful, don't always give your clues to the same person, because it could be the mole using them to work against the team. -**4. Verify proof:** If you have found all three clues of a category, you can secure a piece of evidence here. Remember, by the end of the game your team must have verified four pieces. +**4. Verify proof:** If you have found all three clues in a category, you can secure a piece of evidence here. Remember, by the end of the game your team must have verified four pieces. If you have new messages or other important information, you will be notified by a popup window on your smartphone. @@ -106,5 +106,5 @@ If you have new messages or other important information, you will be notified by {{
}} -A further **possibility of digital technology** in a board game we wanted to experiment with, is **the use of adaptive music**. It can be used to set the **atmosphere**, add to the **excitment of events** in the game, and with that create a more **immersive experience**. In The Mole, the background music we produced reacts to the progress and events of the game. The **closer the team is to getting caught**, the **more intense** the music gets, blending between **different layers of tracks**. Changes, events and sound effects are **synhronized to the music**. +A further **possibility of digital technology** in a board game we wanted to experiment with, is **the use of adaptive music**. It can be used to set the **atmosphere**, add to the **excitement of events** in the game, and with that create a more **immersive experience**. In The Mole, the background music we produced reacts to the progress and events of the game. The **closer the team is to getting caught**, the **more intense** the music gets, blending between **different layers of tracks**. Changes, events and sound effects are **synchronized to the music**. {{
}} \ No newline at end of file diff --git a/content/ws20/master/m1-augmented-boardgame-experience/future.md b/content/ws20/master/m1-augmented-boardgame-experience/future.md index 5cf09e1..917627b 100644 --- a/content/ws20/master/m1-augmented-boardgame-experience/future.md +++ b/content/ws20/master/m1-augmented-boardgame-experience/future.md @@ -6,14 +6,14 @@ weight = 4 {{
}} Due to the time constraints of this project, our first and foremost goal was to create a working prototype to present at the end of the semester. -One of the most important next steps, now that we achieved that goal, is to make sure the **Web Content Accessibility Guidelines** are followed. While some features of the game offer great opportunities, e.g. the logged history of each game for which we could add an **voice over** for the visually impared, for others we will need the option to disable them if needed. One example for this is the pantomime minigame. All this should then be tested by experienced experts in accessibility testing. +One of the most important next steps, now that we achieved that goal, is to make sure the **Web Content Accessibility Guidelines** are followed. While some features of the game offer great opportunities, e.g. the logged history of each game, for which we could add a **voice over** for the visually impaired, for others we will need the option to disable them if needed. One example for this is the pantomime minigame. All this should then be tested by experienced experts in accessibility testing. {{
}} {{
}} **Lock Picking** -In the concept phase of our project we developed more ideas for minigames than those which made it to the final game. One of our favorite ideas was a **team agility game** using the phones’ gyroscopes. All players have to work together – everyone on their own device – to pick a lock. The players need to rotate their device, each controlling the position of one of the pins of a lock. The player that triggered the minigame then needs to rotate his/her device to slide a pick through the lock to open it - another way for the mole to hinder the team. +In the concept phase of our project, we developed more ideas for minigames than those which made it to the final game. One of our favorite ideas was a **team agility game** using the phones’ gyroscopes. All players have to work together – everyone on their own device – to pick a lock. The players need to rotate their device, each controlling the position of one of the pins of a lock. The player that triggered the minigame then needs to rotate his/her device to slide a pick through the lock to open it - another way for the mole to hinder the team. **Would You Rather** @@ -23,21 +23,21 @@ Another minigame idea we would want to implement in the future is a **game of tr {{
}} -From the start of the project we tried to think about achieving a balanced game experience. Since players play not only against the **'AI' enemy** chasing them but also **against one of their own** and both parties have additional different objectives to achieve, the chances to win depend on a lot of factors. +From the start of the project, we tried to think about achieving a balanced game experience. Since players play not only against the **'AI' enemy** chasing them but also **against one of their own** and both parties have additional different objectives to achieve, the chances to win depend on a lot of factors. -Although we played many test games, we will need to playtest the game a lot more ourselves and – even more importantly – with actual end users. To figure out a good **balance between the dice rolling, finding and verifying clues**,the **overall chances for events to happen** and the **two parties to win**, a lot more work needs to be put into adjusting the different settings and probabilities. A part of this will be adapting the **games difficulty based on the number of players**. +Although we played many test games, we will need to playtest the game a lot more ourselves and – even more importantly – with actual end users. To figure out a good **balance between the dice rolling, finding and verifying clues**, the **overall chances for events to happen** and the **two parties to win**, a lot more work needs to be put into adjusting the different settings and probabilities. A part of this will be adapting the **game's difficulty based on the number of players**. {{
}} {{
}} Since our **enemy 'AI' is controlled by a program**, it doesn't have the same constraints as regular analog board games. They mostly have to rely either on generators of randomness in the real world like dice or cards, time intervals, or events in the game itself to control the 'AI' playing against the players. -In the future we want to look into creating a **more intelligent enemy** that e.g. adapts the difficulty based on the level and on the current state of the game. This way a gaming experience could be achieved which would never be too easy or too hard, **adapting to the age, skill level and luck of the players** in the current round, while still keeping enough of an element of chance and challenge to keep the game interesting. +In the future, we want to look into creating a **more intelligent enemy** that e.g. adapts the difficulty based on the level and on the current state of the game. This way, a gaming experience could be achieved that would never be too easy or too hard, **adapting to the age, skill level and luck of the players** in the current round while still keeping enough of an element of chance and challenge to keep the game interesting. {{
}} {{
}} Composing and producing enough music to underscore the whole game without getting repetitive and boring was not possible in the time frame of this project. -In the future this feature could be greatly improved with **more content and more professionally produced adaptive music and sound effects** to create a **more exciting and immersive experience**. Additionally, the technological possibilities of this feature are not yet fully exhausted: Real-time filters and other audio-effects could provide even more opportunities to make the musical backdrop more varied and exciting. +In the future, this feature could be greatly improved with **more content and more professionally produced adaptive music and sound effects** to create a **more exciting and immersive experience**. Additionally, the technological possibilities of this feature are not yet fully exhausted: Real-time filters and other audio-effects could provide even more opportunities to make the musical backdrop more varied and exciting. {{
}} \ No newline at end of file diff --git a/content/ws20/master/m1-augmented-boardgame-experience/process.md b/content/ws20/master/m1-augmented-boardgame-experience/process.md index c774a99..e4fa644 100644 --- a/content/ws20/master/m1-augmented-boardgame-experience/process.md +++ b/content/ws20/master/m1-augmented-boardgame-experience/process.md @@ -6,16 +6,16 @@ weight = 2 {{
}} Our approach towards developing The Mole can be explained with the help of Schell’s Elemental Tetrad [1]. This is a framework for game designers to support them in creating a certain desired gaming experience while keeping the purpose and the dependencies between **the four pillars mechanics, aesthetics, story and technology** of a game in mind. -To predefine the gaming experience, we followed the given project guideline to create a board game augmented by digital elements. We further extended this vision to an **exciting game for groups** that would be fun to **play remotely as well as in person**. The game should thrill players by the **central mechanism of unknown roles** which they would have to identify and defend over the period of the game. +To predefine the gaming experience, we followed the given project guidelines to create a board game augmented by digital elements. We further extended this vision to an **exciting game for groups** that would be fun to **play remotely as well as in person**. The game should thrill players with the **central mechanism of unknown roles**, which they would have to identify and defend over the period of the game. -We started to work out the game idea based on further game principles which we knew from other games and enjoyed, and then came up with a few first graphical drafts. Thus, our **process started with a focus on the game mechanics, slightly tending to the aesthetics**. +We started to work out the game idea based on further game principles that we knew from other games and enjoyed, and then came up with a few first graphical drafts. Thus, our **process started with a focus on the game mechanics, slightly tending to the aesthetics**. Moreover, Bartle’s player taxonomy [2] can help describing our target group: The Mole players range between the **“socializers”**, those who mostly enjoy roleplay and interacting with fellow players, and the **“killers”**, those who enjoy damaging opponents and prefer competing with actual fellow players over artificial instances. {{
}} {{
}} -For brainstorming and elaboration we used a Miro board to share our ideas in the team. +For brainstorming and elaboration, we used a Miro board to share our ideas in the team. The first thing we did was to **collect all the games that we knew and that we could imagine in augmented form**. For each game, we wrote down ideas on how we could digitally enrich the respective game or the underlying game mechanics. Then we presented the games and the corresponding ideas in the team. Afterwards we sorted out the games in which we saw little potential. The list of games we finally used for **inspiration** contained for example **“Safehouse”, “Werewolf”, “Clue” and “Among us”**. Even the movie “The Fugitive” made it to our inspiration board, as we wanted to achieve a similar exciting atmosphere on the run. {{
}} @@ -23,7 +23,7 @@ The first thing we did was to **collect all the games that we knew and that we c {{Game Idea}} -After we decided on the general direction of the game and the main mechanics, we tried to clarify and unite all ideas in a **flow chart**. This process helped not only everyone to get a clearer imagination, but also to create one shared vision in the team. Further it provided a **structure that we could use as a base for implementation**. +After we decided on the general direction of the game and the main mechanics, we tried to clarify and unite all ideas in a **flow chart**. This process helped not only everyone to get a clearer imagination, but also to create one shared vision in the team. Further, it provided a **structure that we could use as a base for implementation**. {{Activity Diagram}} @@ -45,23 +45,23 @@ After the gameplay was determined, the other screens were designed and discussed {{
}} **Identifying the technology** -In the development process it was now necessary to agree on a technology to be used. +In the development process, it was now necessary to agree on a technology to be used. - **Frontend:** On the frontend side, we were able to agree on **web technologies** first, because our **expertise** was the best here and we are therefore not dependent on a specific platform. In addition, Vue.js offered a web framework that is easy to learn. The framework Nuxt.Js offers us the possibility of modular, high-performance development. So we wouldn’t have to reinvent the wheel in order to, for example, achieve PWA advantages. -- **Backend:** In the backend we agreed on **python** after a productive discussion. We had **considerable experience** with the programming language and a required framework. Afterwards we agreed to match the **communication technology the frontend could use**, which was SocketIO. At this point it was very helpful that SocketIO had a Python API. On the data side we used SQlite in the beginning until we integrated the demands of a live website. This led us to the PostgreSQL Database. +- **Backend:** In the backend, we agreed on **python** after a productive discussion. We had **considerable experience** with the programming language and a required framework. Afterwards we agreed to match the **communication technology the frontend could use**, which was SocketIO. At this point, it was very helpful that SocketIO had a Python API. On the data side, we used SQlite in the beginning until we integrated the demands of a live website. This led us to the PostgreSQL Database. **Iterative development** -In our development, we relied on an **agile approach** in order to **have playable results quickly** and to be **able to react quickly to adjustments**. We had weekly meetings where we defined goals for the next sprint and continuously developed on a playable prototype. To organize these goals we used the **Kanban board** available in GitLab to distribute tasks and visualize the workflow. Functionalities were developed in separate branches. Backend and frontend were developed in two separate GitLab projects. +In our development, we relied on an **agile approach** in order to **have playable results quickly** and to be **able to react quickly to adjustments**. We had weekly meetings where we defined goals for the next sprint and continuously developed on a playable prototype. To organize these goals, we used the **Kanban board** available in GitLab to distribute tasks and visualize the workflow. Functionalities were developed in separate branches. Backend and frontend were developed in two separate GitLab projects. -- **Frontend:** In frontend development we **first developed the views** and **then added their functionalities**. In order to avoid redundancies, similar functionalities were outsourced to components. The project was implemented in two languages from the start (German and English). This could easily be implemented using an i18n plugin. -- **Backend:** In the beginning the backend needed a way to test our application as soon as possible. The frontend team was in the design phase so we had no client to test. So we implemented a **skeleton test client** with which we could **test our communications**. This client helped the fronted as well as they had a basis to see how we established communication. +- **Frontend:** In frontend development, we **first developed the views** and **then added their functionalities**. In order to avoid redundancies, similar functionalities were outsourced to components. The project was implemented in two languages from the start (German and English). This could easily be implemented using an i18n plugin. +- **Backend:** In the beginning, the backend needed a way to test our application as soon as possible. The frontend team was in the design phase, so we had no client to test. So we implemented a **skeleton test client** with which we could **test our communications**. This client helped the fronted as well, as they had a basis to see how we established communication. **Almost Continuous Deployment** -Both our Codebases were deployed to the Heroku platform which meant that we had **live access to the development versions all the time**. We also had the option to roll back changes to a working version if anything crashed. We didn’t have continuous deployment since this feature is only supported by the GitHub installations by default. +Both our Codebases were deployed to the Heroku platform, which meant that we had **live access to the development versions all the time**. We also had the option to roll back changes to a working version if anything crashed. We didn’t have continuous deployment since this feature is only supported by the GitHub installations by default. **Accompanying gameplay tests** diff --git a/content/ws20/master/m1-augmented-boardgame-experience/tech-stack.md b/content/ws20/master/m1-augmented-boardgame-experience/tech-stack.md index c2b774e..bc45eef 100644 --- a/content/ws20/master/m1-augmented-boardgame-experience/tech-stack.md +++ b/content/ws20/master/m1-augmented-boardgame-experience/tech-stack.md @@ -4,7 +4,7 @@ weight = 3 +++ {{
}} -In the following, all important technologies used in our project are indicated. For each technology, the logo, name and general function are presented. This should help you to better understand the graphic of the software architecture in the next paragraph. +In the following, all important technologies used in our project are indicated. For each technology, the logo, name and general function are presented. This should help you better understand the graphic of the software architecture in the next paragraph. {{
}} {{Technologies}} @@ -13,13 +13,13 @@ In the following, all important technologies used in our project are indicated. {{
}} The following graphic describes the software architecture of the game "The Mole". -There are two basic elements in the architecture, a backend server and a frontend server. Both our servers are deployed on the cloud application platform **heroku**. Furthermore all instances communicate using **Socket.IO**. SocketIO is a library for real-time web applications that enables bidirectional real-time communication between web clients and servers. +There are two basic elements in the architecture, a backend server and a frontend server. Both our servers are deployed on the cloud application platform **heroku**. Furthermore, all instances communicate using **Socket.IO**. SocketIO is a library for real-time web applications that enables bidirectional real-time communication between web clients and servers. -In the backend we used Python as a programming language with the **django** web framework. Our data is stored in the object-relational database system **PostgreSQL**. This is supported by Django as well as by Heroku. +In the backend, we used Python as a programming language with the **django** web framework. Our data is stored in the object-relational database system **PostgreSQL**. This is supported by Django as well as by Heroku. -In the frontend we used **Vue.js**, a JavaScript frontend framework for declarative rendering and component composition. Furthermore we extended Vue.js with **Nuxt.js**, a JavaScript frontend framework with functionalities like routing, state management, universal rendering and more. To quickly build responsive designs, we used the CSS-Framework **tailwind.css**. +In the frontend we used **Vue.js**, a JavaScript frontend framework for declarative rendering and component composition. Furthermore, we extended Vue.js with **Nuxt.js**, a JavaScript frontend framework with functionalities like routing, state management, universal rendering and more. To quickly build responsive designs, we used the CSS-Framework **tailwind.css**. -Clients can open the game as a **progressive web app**. This means that the game is available as a responsive website, but can additionally be used like an app. When the player connects to the frontend they basically create their own client. That helps us with communication. +Clients can open the game as a **progressive web app**. This means that the game is available as a responsive website but can additionally be used like an app. When the player connects to the frontend, they basically create their own client. That helps us with communication. {{
}} {{Architecture}} \ No newline at end of file diff --git a/content/ws22/bachelor/b2-mobile-companion-app/process.md b/content/ws22/bachelor/b2-mobile-companion-app/process.md index d065268..8316c4e 100644 --- a/content/ws22/bachelor/b2-mobile-companion-app/process.md +++ b/content/ws22/bachelor/b2-mobile-companion-app/process.md @@ -11,5 +11,5 @@ We had ideas like: Scotland Yard as a board game, children's games like hide and After some further discussions on the how's and what's of the game, we started debating which tools to use for the game. Since two of us had already worked with unity, and we were keen on creating a mobile cross-platform application, we settled on unity. So we started researching how we could use Unity to create a network to control the data within the app. There were multiple options like Photon or Mirror (third-party solutions), though Unity's Netcode seemed the best solution for us. -Once a simple network functionality had been established, we split up and started working on the game logic, UI / Design and further network specif tasks. +Once a simple network functionality had been established, we split up and started working on the game logic, UI / Design and further network specific tasks. {{
}} diff --git a/content/ws22/bachelor/b2-mobile-companion-app/techstack.md b/content/ws22/bachelor/b2-mobile-companion-app/techstack.md index d2a537e..389e285 100644 --- a/content/ws22/bachelor/b2-mobile-companion-app/techstack.md +++ b/content/ws22/bachelor/b2-mobile-companion-app/techstack.md @@ -49,7 +49,7 @@ default portrait https://www.pngitem.com/download/ixJxJh_default-profile-picture discord logo https://assets-global.website-files.com/6257adef93867e50d84d30e2/636e0b5061df29d55a92d945_full_logo_blurple_RGB.svg -miro logo https://brandfetch.com/miro.com/brand/id1rEl70oX +miro logo https://brandfetch.com/miro.com unity logo https://upload.wikimedia.org/wikipedia/commons/8/8a/Official_unity_logo.png?20150903192614 diff --git a/content/ws22/master/m2-mmo-HungryGames/_index.md b/content/ws22/master/m2-mmo-HungryGames/_index.md index 0319e92..b774995 100644 --- a/content/ws22/master/m2-mmo-HungryGames/_index.md +++ b/content/ws22/master/m2-mmo-HungryGames/_index.md @@ -7,7 +7,6 @@ card_image = "Logo_Water_1000px.png" card_description = "“Hungry Games” is a Massively Multiplayer Online Game that offers the possibility to experience a Deathmatch-game adventure with up to 32 other players, thanks to a Scalable Generic Network Component. This massively multiplayer online game has a high speed and quickly develops a great feeling of chaos." -source_link = "https://github.com/m2-retro-mmo/Tierfresser" team = ["David Holz", "Hendrik Kiewitt", "Max Linke", "Rika Petersen"] supervisor = "Prof. Dr. Tobias Lenz" +++ @@ -43,10 +42,10 @@ In Hungry Games, the player takes on the role of an animal fighting for survival The MMO can be played with up to 32 players. The mirror networking library for Unity was used here. -The lobby is a waiting area for players to collect before starting a round, as late joining is deliberately prevented to give everyone a fair shot at winning. Players can ready up in the lobby leading to a countdown to start the round when everybody is ready. +The lobby is a waiting area for players to collect before starting a round, as late joining is deliberately prevented to give everyone a fair shot at winning. Players can ready up in the lobby, leading to a countdown to start the round when everybody is ready. -All maps are tile based and procedurally generated, with care taken to ensure that they are actually playable. In a first version Wave Function Collapse was used to generate the map based on a small input image. This approach worked but turned out to be not fast enough for the size of the map that was needed. For runtime reasons, a classical noise approach was adopted in the subsequent process. So in the End Perlin Noise was used to generate the base map, which was refined by detecting unreachable island regions and flood filling them with background tiles so as to remove them. In the game, upon starting a new round, the server picks a seed to generate the next map, which is then sent to all the clients who generate the same map locally. +All maps are tile based and procedurally generated, with care taken to ensure that they are actually playable. In a first version, Wave Function Collapse was used to generate the map based on a small input image. This approach worked but turned out to be not fast enough for the size of the map that was needed. For runtime reasons, a classical noise approach was adopted in the subsequent process. So in the End Perlin Noise was used to generate the base map, which was refined by detecting unreachable island regions and flood filling them with background tiles so as to remove them. In the game, upon starting a new round, the server picks a seed to generate the next map, which is then sent to all the clients who generate the same map locally. {{Mockup}} @@ -62,9 +61,9 @@ Various pick-ups and power-ups help players to survive and gain an upper hand in {{Mockup}} -If a lobby is not completely filled by human players, the remaining slots are filled by AI opponents. Their behavior has slight variations to break the monotony which would arise otherwise. Care was taken to not make the bots overpowering in their ability while still presenting a fun challenge. +If a lobby is not completely filled by human players, the remaining slots are filled by AI opponents. Their behavior has slight variations to break the monotony which would arise otherwise. Care was taken to not make the bots overpowering in their ability, while still presenting a fun challenge. -At the beginning, the player lands in the main menu from which they can start the game. In the lobby, they can give themselves a nickname and see which other players are joining the session. As soon as the game starts, the player has the opportunity to choose a game character from a menu. At the end of a game round, a scoreboard appears, providing a list of the game results. +At the beginning, the player lands in the main menu, from which they can start the game. In the lobby, they can give themselves a nickname and see which other players are joining the session. As soon as the game starts, the player has the opportunity to choose a game character from a menu. At the end of a game round, a scoreboard appears, providing a list of the game results. The player HUD consists of various elements. On the one hand, there is a health indicator, which shows the current health status of the player. There is also another variable that is important for the course of the game, namely the player's saturation, which is also visualized via a HUD element. In the upper left corner of the screen, there is a timer that shows the player the remaining playing time. At the bottom of the screen in the middle, the player can see how many Ability Points they still have. diff --git a/content/ws22/master/m2-mmo-bubble-bobble/_index.md b/content/ws22/master/m2-mmo-bubble-bobble/_index.md index a6eb92f..d61b926 100644 --- a/content/ws22/master/m2-mmo-bubble-bobble/_index.md +++ b/content/ws22/master/m2-mmo-bubble-bobble/_index.md @@ -13,7 +13,7 @@ supervisor = "Prof. Dr. Tobias Lenz" +++ {{
}} -Fast-pasted massively multiplayer online games have received a lot of recognition in recent years and have proven to be a successful and popular gaming concept, not least thanks to Fall Guys. +Fast-pasted massively multiplayer online games have received a lot of recognition in recent years and have proven to be a successful and popular gaming concept, not the least thanks to Fall Guys. Considering this development, our goal was to create a fun multiplayer gaming experience that would easily be accessible to a large online community. We chose an existing classic, [**Bubble Bobble**](https://de.wikipedia.org/wiki/Bubble_Bobble), and modernized it with a multiplayer component: @@ -77,12 +77,12 @@ We chose the Unity Game Engine as our main development tool, since it is one of A key element of our project was a joint network component with the [**Hungry Games**](https://showtime.f4.htw-berlin.de/ws22/master/m2-mmo-hungrygames/) project. For network communication, we looked at two network libraries: [**Mirror**](https://mirror-networking.com/) and [**Photon**](https://www.photonengine.com/#). After evaluating the two libraries, we decided to use [**Mirror**](https://mirror-networking.com/), an open-source networking library for Unity, that best met our requirements. -All custom assets for our game including the player, cave and bubble assets were created using Adobe Photoshop in combination with a graphics tablet. Animations were then implemented frame-based with the help of Unity's built-in Animation package. +All custom assets for our game, including the player, cave and bubble assets, were created using Adobe Photoshop in combination with a graphics tablet. Animations were then implemented frame-based with the help of Unity's built-in Animation package. {{Bubble Bobble Techstack}} {{
}} {{
}} -Potential enhancements of **Bubble Bobble reloaded** include additional features such as power-ups, more detailled animations and souds. +Potential enhancements of **Bubble Bobble reloaded** include additional features such as power-ups, more detailed animations and sounds. To ensure a reliable gaming experience as the number of players grows, the game could also be extended by a stable, scalable, and large cloud infrastructure. This would enable the creation of user accounts, allowing players to save their ingame data and progress in a database. A cloud infrastructure would also allow for better scalability, as well as the ability to handle even larger amounts of players.