Bipolar: A Game of Electromagnetism

fiftysixpowersElectronics - Devices

Oct 18, 2013 (3 years and 5 months ago)



University of Arkansas

CSCE Department

Virtual Worlds



Bipolar: A Game of Electromagnetism

Riley Turben
Armon Nayeraini


Humans are born with intuitive senses of certain forces around them. Gravity is something that is
derstood 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 t
his 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 p
roviding a more
thorough understanding of how electricity and magnetism manifest themselves.


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 e
arliest 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,
ly because we do not have the sensory equipment or training to understand what we


The objective of this project is to design and create a video game whose core mechanics revolve
around the fundamental scientific concepts of elect
ricity and magnetism

to provide players with
a better understanding of the electromagnetic force

Bipolar: A Game of Electromagnetism



EM Fields

As stated, humanity is

of sensing electromagnetic fields. This means that one cannot
el 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.

and magnets are actually two sides of the same coin. Depending on the EM wave, magnetic
erties are exhibited or, instead, electricity.

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
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


Design Goals

In order to have a successf
ul project, two goals were set up. The first was to design a game that
could give a basic understanding

of electromagnetism to the u
ser. The second was to set up a

project architecture that allowed for clean development and easy content creation.

To do thi
s, 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 Goals


Working Game Architecture


Save/Load System for Player and Game data


Navigation of Game Menus


Setting up Object Controllers



Batch 1 of Game Objects


Platforming Physics and Collision Handling

Batch 2 of Game Objects


Batch 3 of Game Objects


Electromagnetic Physics


Object Textures and
Background Parallaxing


Levels 1


Bipolar: A Game of Electromagnetism


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
ry. These games often employ puzzles and obstacles to challenge

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 lea
rn the properties of
electromagnetism without having us, the game developers, shove information down the player’s

Our game’s puzzles revolve around using exaggerated properties of electrified and
magnetized objects. Each puzzle must be solved by ge
tting 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 pass
ing 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 corres
ponding 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.




Before designing the actual game an
d 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 sele
ct, 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 ot
her options before
beginning play.
Our game uses a simplified version of Model
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 sim
ply 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 ou
r 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.

Bipolar: A Game of Electromagnetism


Fig 4.3.1 Bipolar Game Architecture


onent 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 purpos
e 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 fou
nd. 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
s 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
Bipolar: A Game of Electromagnetism


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


Module Architecture

When we finally began to develop individual modules
, we found that what was needed of each
module had alread
y 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 i
ts 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 ex
tremely 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
the Controller classes that they interface with one another.


Alpha Screenshots

Fig 4.9.1 The Player and the Ball

Bipolar: A Game of Electromagnetism


Fig 4.9.2 The Player Solves a Puzzle

Fig 4.9.3 Interactions with Electromagnetism

Bipolar: A Game of Electromagnetism


Fig 4.
9.4 Toggling Objects with a Pad

4.9.5 Intermediary Puzzles: Machines

Bipolar: A Game of Electromagnetism


Fig 4.9.6 A Sample Game Level

at Build Time




Risk Reduction

Exhibiting EM Physics

As the key purpose of this system, it is crucial to provide a
means to learn about EM physics. To avoid overwhelmin
g 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 impossib
le 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
with bugs and other errors. To avoid this, intense
documentation and strict coding guidelines were implemented
to prevent code degradation.

Bipolar: A Game of Electromagnetism




sentence on each task, tasks match schedule


: To gather information on how electromagn
etism was used in everyday life and
how to replicate these applications in a virtual world.


: To use information gathered to create an appealing world that allowed for user to
experience the power and application of electromagnetism


Using base design, to code the virtual world and create the appropriate
assists to help visualize this world


: Extensive testing of individual modules and system components to ensure no unwanted
behavior is exhibited


To provide the opport
unity for individuals to experience the world created


: To record all changes and implementations to each successive build of the




1. Understanding

Complete by Early Febru
ary 2013

2. Design

Complete by End of Febru
y 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

Key Personnel

Riley Turbe


is a junior Computer Science major in

the Computer Science and
Computer Engineering Department at

the University of Arkansas. H
e has completed
Programming Foundations I, Programming Foundations II, and Programming Paradigms
addition, he also worked

Emberware Studios for two years as

a game designer.

In this
project, he was responsible for creating the game engine, player platformin
g 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

Emberware Studios for two years as a software engineer. In this
project, he was responsibl
e for coding the camera, creating levels, and addi
ng behavior to many
key modules.