Frame World 2
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:
1. Playability
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:
- a setting that connects different problems and gives the player motivation to solve them
- a technical progression system that leads the player through the full game
- a sufficient set of game problems
- a didactically sound progression through the game that allows players to solve increasingly difficult and complex problems
2. Dynamic Gameplay
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.
3. Knowledge Based World Design
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...