Bipolar: A Game of Electromagnetism
University of Arkansas – CSCE Department
Advanced Virtual Worlds – Spring 2013
Bipolar: A Game of Electromagnetism
Riley Turben, Armon Nayeraini
Abstract
Humans are born with intuitive senses of certain forces around them. Gravity is something that is understood as early as childhood, but other physical principles are never intuited in the course of our lives. Such aspects of physics may remain difficult to envision or understand, and as a result make our perception of the world more limited.
The aim of this project is to create a virtual environment where users can experiment to better understand the properties of electromagnetism. We will create a game in which players must utilize the properties of electrodynamics to solve puzzles while simultaneously providing a more thorough understanding of how electricity and magnetism manifest themselves.
1.0 Problem
By being born a human, we are equipped with a certain number of sensory organs. These senses determine how we interact with the world around us. The earliest scientific discoveries were largely based on our senses and what we could directly observe with them. It wasn’t until machines were invented to add to our sensory array that we were able to make great leaps in areas that we are not physically able to familiarize ourselves with.
Part of our limitations lie in the fact that we are not taught to cognitively grasp forces that we can’t perceive with our normal senses. If humans were born with magnetoception, the ability to sense magnetic fields, then it is possible that properties of magnetism such as Faraday’s law would have been discovered far before the time of Faraday. It is also possible that we are currently missing out on discovering other revolutionary insights into how our universe operates, simply because we do not have the sensory equipment or training to understand what we experience.
2.0 Objective
The objective of this project is to design and create a video game whose core mechanics revolve around the fundamental scientific concepts of electricity and magnetism to provide players with a better understanding of the electromagnetic force.
3.0 Background
3.1 EM Fields
As stated, humanity is incapable of sensing electromagnetic fields. This means that one cannot feel how an engine works or why a light bulb lights up. Despite these two example seeming to be completely different, they are both related. This is because of electromagnetic fields. Electricity and magnets are actually two sides of the same coin. Depending on the EM wave, magnetic properties are exhibited or, instead, electricity.
3.2 Puzzle Platformer
One of the most well developed genres in video games today, platformers are a simple backdrop for our game. It was chosen because it is known by almost anyone who has played a game, and is easily understandable for those who haven’t. The puzzle variation on top of this genre simply means that each level requires a puzzle to be solved before the player can move on to the next level.
4.0 Design
4.1 Design Goals
In order to have a successful project, two goals were set up. The first was to design a game that could give a basic understanding of electromagnetism to the user. The second was to set up a project architecture that allowed for clean development and easy content creation. To do this, we had set out a ten step plan to take our game build from version 0.0.0 to version 0.1.0, the first completed Alpha build. These steps started out from simple things such as setting up the class hierarchy for Alpha 0.0 to more complex tasks like adding electromagnetic physics in Alpha 0.8. The main goals for each Alpha are outlined in the table below.
Fig 4.1.1 Bipolar Alpha Build Timeline
Alpha Build Version / Main Build Goals0.1 / Working Game Architecture
0.2 / Save/Load System for Player and Game data
0.3 / Navigation of Game Menus
0.4 / Setting up Object Controllers
0.5 / Camera
Batch 1 of Game Objects
0.6 / Platforming Physics and Collision Handling
Batch 2 of Game Objects
0.7 / Batch 3 of Game Objects
0.8 / Electromagnetic Physics
0.9 / Object Textures and Background Parallaxing
1.0 / Levels 1 - 10
4.2 Gameplay Design
It was decided early on it was decided that the game would be a platformer. A platformer is a game where the player is required to traverse the game’s environment using whatever means necessary. These games often employ puzzles and obstacles to challenge the player’s wit and dexterity. As a way of both teaching and entertaining, we decided to use electricity and magnets to design puzzles. This way the player would be able to subconsciously learn the properties of electromagnetism without having us, the game developers, shove information down the player’s throat. Our game’s puzzles revolve around using exaggerated properties of electrified and magnetized objects. Each puzzle must be solved by getting an object to a goal. Less abstractly, in each level there is a ball. This ball is unaffected by gravity and does not respond to EM forces when first acquired in the level. Once the player throws it, however, it can become electrically charged by passing through sparks, or magnetically ionized by passing through a gaseous cloud. In either of these states, the ball responds to EM objects accordingly. The player must throw the ball so that it has one of the properties applied to it and reaches the corresponding fuse, which only accepts a ball if it has a property the fuse is seeking. Creating the puzzles that the player must solve is what most of the gameplay design of this game revolves around.
4.3 System Architecture
Before designing the actual game and gameplay, the overarching system for the project was first designed. The design approach taken was top-down. The first act was to come up with what components actually made up the system. Examples of this are the main menu, a settings menu, a world select, a level select, and a generic level. Afterwards, it was necessary to design how each component in the system would interact with each other. The main menu, for instance, must interact with settings. This is so that the player may change controls and other options before beginning play. Our game uses a simplified version of Model-View-Controller architecture. The model, or level, talks back and forth with the controller, or player. All data relevant to gameplay is held in the model, while the view is simply an output and the controller is an input. The two classes that make up the brunt of the Model are LevelController and EntityController. These control what objects go into each level and how the objects interact with one another, respectively. The rest of the model is divided up among the other game states, which consist of menus and loading screens. The Player object is the controller in our model, as it is the only thing within the level that responds directly to input. Finally, the camera object is our view. It talks back and forth with LevelController to figure out what part of the game world it should be rendering. A more detailed hierarchy of the game’s architecture is shown in the figure below.
Fig 4.3.1 Bipolar Game Architecture
4.4 Component Architecture
Upon completion of System Architecture, we moved to add detail. To do this, we moved down the component tier of the project. Here, we looked into what the component was responsible for. Using the main menu as an example again, its purpose is to allow the user to navigate between several other components. This meant it needed menu button to be used for user interface, as well as a menu object to hold these buttons. Thus, two of the needed modules to make up the main menu component were found. This procedure was repeated for every component, allowing for easy, yet precise detailing. In the game’s current iteration, we have about two dozen different components, from menu buttons to electrical machines. As development continues, some components can be streamlined together, such as all the different types of buttons. We also plan on adding more components, like solenoids for puzzles or splash screens at load time. The result of this streamlining and addition of content to our game means that the actual number of components is not expected to change much, but their functionality on the whole is expected to increase.
4.5 Module Architecture
When we finally began to develop individual modules, we found that what was needed of each module had already been outlined. The result was a streamlined process of filling out each module. The only notable part of the module design was that each module was totally confined to its component. In order to access non-localized data, the module was required to ask its parent component to retrieve the desired data. Each module runs in its own encapsulated hierarchy. This ensures that unrelated modules cannot exchange data without the help of one of the Controller classes. What this also means is that each module is extremely robust. For example, the Wire class module. It can take any game entity as an input, and any number of game entities as outputs. When the input entity is triggered, it can make a generic method call to each of the output entities that can result in different behavior. This means that we aren’t limited when designing control flow in the in-game puzzles, which adds a layer of flexibility to the project. Each module at the entity stage works in ignorance of any of the other modules: It is only through the Controller classes that they interface with one another.
4.6 Alpha Screenshots
Fig 4.9.1 The Player and the Ball
Fig 4.9.2 The Player Solves a Puzzle
Fig 4.9.3 Interactions with Electromagnetism
Fig 4.9.4 Toggling Objects with a Pad
Fig 4.9.5 Intermediary Puzzles: Machines
Fig 4.9.6 A Sample Game Level at Build Time
4.7 Risks
Risk / Risk ReductionExhibiting EM Physics / As the key purpose of this system, it is crucial to provide a means to learn about EM physics. To avoid overwhelming the user, the physics was abstracted in such a way that the principles are still seen, even if it is not a hundred percent accurate compared to reality.
Entertaining users / If the game failed to entertain, then the message of EM physics would be impossible to present. Thus there was a great focus of energy on designing innovative levels and easy to grasp controls to ensure that players are not frustrated or bored of gameplay.
Creating a concise design / Often, due to agile coding, games tend to get bogged down with bugs and other errors. To avoid this, intense documentation and strict coding guidelines were implemented to prevent code degradation.
4.8 Tasks - sentence on each task, tasks match schedule
1. Understand: To gather information on how electromagnetism was used in everyday life and how to replicate these applications in a virtual world.
2. Design: To use information gathered to create an appealing world that allowed for user to experience the power and application of electromagnetism
3. Implementation: Using base design, to code the virtual world and create the appropriate assists to help visualize this world
4. Test: Extensive testing of individual modules and system components to ensure no unwanted behavior is exhibited
5. Demonstrate: To provide the opportunity for individuals to experience the world created
6. Document: To record all changes and implementations to each successive build of the system
4.9 Schedule
Spring1. Understanding / Complete by Early February 2013
2. Design / Complete by End of February 2013
3. Implement / Complete by Mid April 2013
4. Test / Complete by End of April 2013
5. Demonstrate / Complete by End of April 2013
6. Document / Complete by End of April 2013
5.0 Key Personnel
Riley Turben – Turben is a junior Computer Science major in the Computer Science and Computer Engineering Department at the University of Arkansas. He has completed Programming Foundations I, Programming Foundations II, and Programming Paradigms. In addition, he also worked with Emberware Studios for two years as a game designer. In this project, he was responsible for creating the game engine, player platforming controls, and the EM physics.
Armon Nayeraini – Nayeraini is a junior Computer Science major in the Computer Science and Computer Engineering Department at the University of Arkansas. He has completed Programming Foundations I, Programming Foundations II, and Programming Paradigms. In addition, he also worked with Emberware Studios for two years as a software engineer. In this project, he was responsible for coding the camera, creating levels, and adding behavior to many key modules.
XXX