Augmented Reality (AR) is a technology which blends virtual and real worlds. The technology has various potential application domains such as broadcasting, architecture, manufacturing, and entertainment. As the tempting developments in AR technology continues, the solutions for rapid creation of AR applications become crucial. This thesis presents an AR application development framework with scripting capability as a solution for rapid application development and rapid prototyping in AR. The proposed AR framework shares several components with game engines. Thus, the framework is designed as an extension of a game engine. The components of the framework are designed to be changable in a plug-in system. The proposed framework provides the developers with the ability of agile coding through the scripting language. Our solution embeds a dynamic scripting programming language (Python) in a strictly typed static programming language (C++) in order to achieve both agility and performance. The communication between the AR framework components and the scripting programming language is established through a messaging mechanism.

Pagrindinis projekto tikslas yra sukurti žaidimą Java kalba, naudojantis kliento-serverio architektūra. Analizė pristato skirtumus tarp dviejų žaidimo variklių. Vienas iš jų - komercinis Unity žaidimo variklis ir kitas JMonkeyEngine 3 (JME3), pastarasis buvo naudotas šiam projektui. Nepaisant fakto, kad Java kalba lėtesnė negu C++ arba C#, ji yra lanksti ir turi galimybę buti panaudota ant skirtingų platformų. Pagal oficialius duomenis JME3 yra panaudotas kuriant keletą komercinių žaidimų( pvz.: "Nord", "Grappling Hook" ). Taipogi JME3 turi savo SDK pastatyta ant "NetBeans", kuris ir buvo naudotas kuriant "Mech" žaidimą. Šis dokumentas pateikia informaciją kaip "Mech" žaidimas buvo kuriamas, kaip naudotis žaidimu ir kaip žaidimas buvo testuojamas. / Main Project objective is to make a game on Java language using a client-server architecture. Analysis presented differences between two game engines. One of them is commercial – Unity game engine and other is Java Monkey Engine 3 (JME3), which have been used for this Project. Despite the fact that Java language is slower than C++ or C#, it is flexible and have a possibility to be used on different platforms. According to official information JME3 is used for several commercial games ( in example: „Nord“, „Grappling Hook“ ). Moreover JME3 provides its own SDK based on „NetBeans“, which one have been used for developing „Mech“ game. This document provides information how „Mech“ game was developed, how to use game and how game was tested.

Technology such as television, computers, and video games are often in the line for reasons of why people lack physical activity and tend to gain weight and become obese. In the case of video games, with the advent of the so called “serious games initiative”, a new breed of video games have come into place. Such games are called “exergames” and they are intended to motivate the user to do physical activity. Although there is some evidence that some types of Exergames are more physically demanding than traditional sedentary games, there is also evidence that suggests that such games are not really providing the intensity of exert that is at the recommended levels for a daily exercise. Currently, most exergames have a passive approach. There is no real tracking of the players progress, there is no assessment of his/her level of exert, no contextual information, and there is no adaptability on the game itself to change the conditions of the game and prompt the desired physiological response on the player. In this thesis we present research work done towards the design and development of an architecture and related systems that support a shift in the exertion game paradigm. The contributions of this work are enablers in the design and development of exertion games with a strict serious game approach. Such games should have “exercising” as the primary goal, and a game engine that has been developed under this scheme should be aware of the exertion context of the player. The game should be aware of the level of exertion of the player and adapt the gaming context (in-game variables and exertion interface settings) so that the player can reach a predefined exertion rate as desired. To support such degree of adaptability in a multimedia, multimodal system, we have proposed a system architecture that lays down the general guidelines for the design and development of such systems.

This report will deal with the process of creating an example based procedural distribution tool. This is accomplished within the Frostbite game engine editor, FrostEd. By using actual placements of objects in the editor as in-data, the tool provides the artist with an unmatched visual feel for calibrating its properties and settings. Note that this is a unique technique and was invented during the creation of this tool. The tool is based on a machine learning approach. It creates a feature vector from the example placements for each type of object. These vectors are then used to create statistical models which in turn are used to generate new object placements. The process of determining the position and rotation when generating an object is divided into two parts. A new concept called Feature Function (FF) is utilized to provide each element in the population with a probability to obtain a certain position and rotation.

This report investigates if an HLA-plugin for the game engine Unity can be made and whether or not it would lead to any drawbacks in regard to data exchange and performance. An implementation of a plugin and performance tests on it proceeds to show that the possibilities of running HLA as a plugin in Unity shows a lot of promise for 3D-applications designed in Unity communicating over HLA.

This paper describes our game engine written in C++, using the DirectX libraries for graphics, sound and input. Since the engine is written using DirectX, an introduction to this system is given. The report gives a description of the structure of the game and the game kernel. Following this is a description of the graphics engine and its core components. The main focus of the engine is on the physics and how it is used in the game to simulate reality. Input is discussed briefly, with examples to show how it relates to the physics engine. Implementation of audio in the game engine is not described, but a general description of how sound is used in games is given. A theory for the basics of how artificial intelligence can be used in the engine is presented. The system for the architecture of the levels is described as is its connection to the graphics engine. The last section of the report is an evaluation and suggestions for what to do in the future. A user manual for the level editor is included as an appendix.

This bachelor thesis describes the development of a MOD music player to run on GBA (Game Boy Advance) for Lypson Game Engine. GBA is a basic platform for embedded development, and the stereo system makes it possible to use the platform as a music player. The sound players of the GBA for Lypson Game Engine were designed to play wave files and the size of typical wave files is in the order of megabytes. MOD files are much smaller when compared with wave ones. Therefore, to avoid consuming the resources of the CPU and memory to process and store wave files, the use of MOD files represents a better alternative.The development took C++ as programming language and the development platform used was HAM. The first step was to obtain samples of music, and then control the hardware of GBA to play sound. After that, came the phase of combining it with Lipson Game Engine. These tasks enabled the acquisition of knowledge about the frame of MOD files; learning how to make the GBA play sound and mastering the operating instruction of GBA hardware by the process of development. In addition, it provided a chance to learn about embedded development, which represented a starting point to learn about embedded programming in general.As for the main result, it was achieved by the successful development of the MOD Player, which is now running on the Lypson Game Engine. As the MOD files are of small size, the music player is more efficient when compared with those previously used.

The thesis explains the development process of a production cell simulation in 3D implemented using Unity3D. The developed simulation communicates with existing control software and aims to test this control software in a 3D environment with physics simulation. The final result includes 3D models and also works as a visualization since it allows us to present the control system, and this visualization can be viewed using most web browsers. The thesis also includes a brief study and comparison between currently popular game engines to choose an appropriate option for this project.This is a project in collaboration with a local company (ARiSA) and has a high practical relevance.

Technology such as television, computers, and video games are often in the line for reasons of why people lack physical activity and tend to gain weight and become obese. In the case of video games, with the advent of the so called “serious games initiative”, a new breed of video games have come into place. Such games are called “exergames” and they are intended to motivate the user to do physical activity. Although there is some evidence that some types of Exergames are more physically demanding than traditional sedentary games, there is also evidence that suggests that such games are not really providing the intensity of exert that is at the recommended levels for a daily exercise. Currently, most exergames have a passive approach. There is no real tracking of the players progress, there is no assessment of his/her level of exert, no contextual information, and there is no adaptability on the game itself to change the conditions of the game and prompt the desired physiological response on the player. In this thesis we present research work done towards the design and development of an architecture and related systems that support a shift in the exertion game paradigm. The contributions of this work are enablers in the design and development of exertion games with a strict serious game approach. Such games should have “exercising” as the primary goal, and a game engine that has been developed under this scheme should be aware of the exertion context of the player. The game should be aware of the level of exertion of the player and adapt the gaming context (in-game variables and exertion interface settings) so that the player can reach a predefined exertion rate as desired. To support such degree of adaptability in a multimedia, multimodal system, we have proposed a system architecture that lays down the general guidelines for the design and development of such systems.

Context: Today there are a lot of different kinds of game engines to choose from, but is one of these engines more suitable for a developer with a beginners' experience in game development? Objective: This is something we explore in order to help teachers choose a suitable engine for teaching game development to beginners.In this study, two teams of two persons each compare two of these engines, Godot and Unity. Method: We conducted a study, consisting of six iterations, to observe the development of a prototype game using the two engines. We collected data during the development of the game using a think-aloud protocol and a questionnaire, and after the development using a questionnaire that included the SUS scale for assessing the overall usability of the game engines. Results: The Godot engine have been focused on completing their documentation and the documentation is somewhat directed to more experienced developers. In comparison the Unity engine got more solutions outside of the documentation and also got their own special guides towards beginners.Although Godot engine got a more simpler GUI which will be easier at first but as the tasks became more difficult this became more of a disadvantage and some solutions were not found easily among the documentation. In comparison the Unity engine got more menus and can seem a lot to a beginner but became to be more helpful the harder the tasks became and even though most solutions were not found among the documentation, there were enough information from other sources to solve all problems with an easy search.Neither of the engines provided with a lot of helpful information within the tool, although the Godot engine had some cases where the tool would let the developers know a certain component was needed. Conclusion: Our main conclusion is that Godot is a good entry point into game development but as the tasks gets more difficult students would need the teacher’s help in order to solve the tasks as easy as with Unity. In contrast, Unity starts more difficult but as tasks gets more difficult Unity have more solutions online, which makes it more suitable if students are to develop on their own.\\This study is rather small with only four participants and this limits the results, for future studies it would be best to have more participants. Keywords: Cognitive task analysis, game developer experience, Godot, Unity, game engine, usability