In the FrameIT project (#1 and https://uframeit.github.io), we use the Unity game engine in combination with MMT to have access to mathematical knowledge management techniques and interact with the knowledge in the game world.
To deploy FrameIT games in schools, it is very important to also support Android. Accordingly, this topic involves adapting current games and features and design new interactions and possibly new games/levels that have synergies with touchscreens.
In the FrameIT project (#1 and https://uframeit.github.io), we use the Unity game engine in combination with MMT to have access to mathematical knowledge management techniques and interact with the knowledge in the game world. In the initial prototype game Frame World, the player is tasked to measure the height of a tree with the help of trigonometry.
After a series of projects that have improved game Frame World or explored game variants, we now want to focus our work towards a true successor game Frame World 2. Aside from incorporating the lessons learned and technical advancements so far, we define three main pillars that we want to implement for the new game:
While the original game is very much playable, it only consists of a single game level. By now, there have been extensions to that, but to count as a meaningful serious game, more structure is required. In particular, we have the following requirements:
One main advantage of video games is that it is possible to visualize and simulate processes that are problematic in the real world because they are, e.g., expensive or dangerous. In the original game this concept is only partly implemented in the sense that abstract mathematical concepts are brought into practical applications. We want to extend this to dynamic processes that involve movement of objects and matter.
On the technical level, this allows us to implement a bigger range of problems in the UFrameIt framework, but more importantly, this is supposed to improve the learning experience as the consequences of the player's actions can be visualized interactively. This would lead to more immersive gameplay and a greater sense of achievement when the problem is solved.
There have been first steps to this in the form of the LoViWo project, where the movement of cogwheels is modeled knowledge based. While this project is isolated from the overall UFrameIt framework so far, it is also based on MMT and should be integrable without greater adaptions. Furthermore, the principles of solving equations to calculate the movement should be adaptable to other dynamic problems. Examples that might fit well to the themes of serious games are simple fluid simulations or trajectory calculations.
An example with less movement but also dynamic interactions could be electrical circuits.
A common issue in the development of video games is the interaction between different game entities or events. As different parts of the game are developed individually, adding such interactions may be difficult and introduce overhead.
Imagine a merchant that sells items to the player. Depending on the progress and events in the game the available stock may change. In these cases, there needs to be a custom script that updates the stock list accordingly. This is no issue in theory, but in practice these kinds of interactions occur repeatedly throughout games, which makes it very difficult to keep an overview of all dependencies in complex games.
A special case of this are quests and missions. Particularly open world games can easily come with hundreds of them. As simple tasks like collecting a certain amount of items or defeating a monster quickly become repetitive, significant effort is required for the creation of engaging side quests.
If we now look at this from a knowledge based perspective, we can model all kinds of interactions in the same way, just the level of abstraction changes. In UFrameIt, we call elements of information Facts. For example, each point the player measures for the determination of the tree height is registered as such a fact. But in the same way, we can also model events that determine the offerings of the merchant as facts. Finally, we interpret the requirements for fulfilling a quest as facts as well. The advantage for the game developer is that with our framework, the different interactions no longer have to be implemented individually but simply stated declaratively for the respective game entities.
In practice, a quest of obtaining a potato could be implemented as follows: a potato is a buyable game entity that is produced by farms in potato land. For merchants to offer potatoes, there needs to be a route between potato land and the current town. Since the old river bridge has collapsed, there no longer is a such a route. Trees are objects that can be chopped down and can be traversed when chopped. Five trees of height greater than the width of the river can form a river bridge. An axe is sharp enough to chop five trees and the player could only acquire one axe. The height of trees can be measured with the correct use of trigonometry.
While this also would be a quest of obtaining an item, the different dependencies are not hardcoded into the quest anymore. More exciting quests can be implemented now by only extending the knowledge entities accordingly (possibly also with scripted events, cutscenes etc.). Last, interactions with the whole game world can be added easily. An NPC could consider the player as man of culture for traveling with a potato and choose to aid the player - thus changing the course of the game forever...
In the FrameIT project, we use the Unity game engine in combination with MMT to have access to mathematical knowledge management techniques and interact with the knowledge in the game world. We visualize problems or puzzles in the form of interactive scrolls, where players can input their gathered knowledge to obtain more information and, eventually, solve the problem.
While currently the scroll is visualized as a combination of problem description and a list of input fields, we would prefer a more organic layout and typesetting where you can fill in the blankets directly in the description text.
The biggest technical issue is the rendering of HTML5 and MathML content outside of web browsers, while at the same time allowing interactions between individual elements of the scroll and their counterparts in the game. Searching for solutions and possibly comparing different ones will be part of this topic.
For more information, please take a look at the project issue and #1.
In the FrameIT project (#1 and https://uframeit.github.io), we use the Unity game engine in combination with MMT to have access to mathematical knowledge management techniques and interact with the knowledge in the game world.
With the growing number and complexity of interaction tools, it would be helpful to have some kind of tutorial or instructions for players. The task here will be to investigate and implement different ways of providing this.
In the FrameIT project, we use the Unity game engine in combination with MMT to have access to mathematical knowledge management techniques and interact with the knowledge in the game world. We visualize problems or puzzles in the form of interactive scrolls, where players can input their gathered knowledge to obtain more information and, eventually, solve the problem.
We want to have the conditions to solve the game level within MMT! [WIP, description needs update] das Konzept von Levels in MMT irgendwie repräsentieren (ähnlich wie wir Scrolls in MMT auch in einer strukturierten Art und Weise repräsentieren) in Metainformationen sowas repräsentieren wie "the level is solved iff dist(C, A) evaluates to a numeric value" Insb. könnte mensch sich überlegen, dass es durchaus Levelziele geben wird, die nur Unity überprüfen kann, die MMT-extern sein müssen. Die könnte mensch trotzdem in MMT repräsentieren a la "level is solved iff [some condition mmt can check internally] and [some condition Unity needs to check]" Geht in Richtung "flexiformale Repräsentation von Levelzielen in MMT"
For more information, please take a look at the project issue and #1.