Final Report

jockeyropeInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 9 μήνες)

189 εμφανίσεις

Joey Peters

CPSC410

12/2/08

“AraFell”
Project Final Report


The large software system I have create
d

is a two
-
dimensional role
-
playing game. The
problem
solved

wa
s the need for an efficient and multi
-
threaded role
-
playing game that
implements an easily mo
difiable tree hierarchy in its code structure. By solving this problem,
the end result
is

a fully functional two
-
dimensional role
-
playing game that can be played on the
Xbox
360
console as well as any computer running Windows.


The project ended up being
over 12,000 lines of code long,
written in C# using
Microsoft’s XNA framework,
and

it
produced better results than expected. The quality of the
final program was outstanding

and
far
exceeded expectations.
The level of artistry in the
graphics is top
-
notc
h and the smooth controls of the game are well
-
done for
its respective

genre.
The only thing needed for this game is an installer file that will install the drivers, frameworks,
and .dll files required to run it.

These files are already installed on all
Xbox 360 consoles, so I
did not create a Windows installer for the game.
The only thing required to run this game on the
Xbox 360 is to open the executable file of the game, which the Xbox conveniently puts in a
single button in the user’s game library.
Since the game has not been released yet, the only way
to run it on the Xbox 360 console is through debug
-
mode, which requires an active connection to
Xbox Live due to licensing issues. Xbox uses this forced Xbox Live connection to verify that
the person
running the game has purchased Microsoft’s “premium Xbox Live membership” in
which they require all users to purchase if those users want to create their own Xbox Live
Arcade games. Once a few bonus features are added to the game to improve even further b
eyond
its current capabilities, the game will be submitted for review by both Microsoft and the XNA
Creator’s Club community. These people will review the game and then approve or deny it. If
the game is approved, Microsoft will put the game on Xbox Live

available for download for a
price set by the company I work for, Intuition Entertainment. Microsoft will then handle all
publishing issues in regards to the game, as well as bandwidth costs required to transfer the game
to customers. In return, Microso
ft expects a cut of 30% of the game’s revenue. Also Microsoft
can choose at any time to show case the game on its main page and advertise it heavily without
the permission of the creator. In return for this service, Microsoft takes 70% of the game’s
reve
nue.


As a secondary source of revenue for this commercial project, it will be published online
for a publisher’s fee of 15%. This will create a secondary source of revenue as well as open the
game up to many new potential buyers in the PC
-
gamer market.
This will create a great deal of
potential for the game if it becomes popular. It will also prevent any Microsoft legal issues to
choke off all revenue earned by the game.


I decided to make a video game for this project because
video games incorporate a
great
deal of operating system principles into their designs in order to run a
t

peak efficiency.
Most
o
ften video games are cast off as a waste of time or simple entertainment, but most video games
are much more complex than the latest advanced software c
reated in other fields. Video games
are required to maximize CPU and memory efficiency in order to achieve an acceptable frame
-
rate and game
-
play. Also the video game market is extremely competitive because many people
are willing to create games for fre
e, as a hobby as opposed to being paid to create games.
This
puts an added level of pressure onto game developers. Also video games are so advanced that
they are the ones pushing the video card industry to constantly advance and improve their
products to

create faster personal computers. For all of these reasons I find video game
development to be fascinating, and that is why I thought a video game would be a fitting large
software project.


After analyzing my large software system, I have found that it
has met and exceeded all
expectations.
The exceptional quality of the game, and its impressive 60 frames
-
per
-
second
frame
-
rate has proven it to be a great looking game.
Behind the great looks of the game lies very
efficient code that utilizes as little m
emory and CPU power as possible. In order to accomplish
such efficiency, many operating system principles were used. Upon further analysis of these
operating system principles used, it seems they have been well
-
applied to the

architecture of the
software
.


Throughout my experience of creating this game, I learned that the tools and amount of
source code available online to help others create games is truly abundant. There are countless
tutorials and examples posted online that can guide a person through
every aspect of creating a
game using Microsoft’s XNA framework, since so many people enjoy game development as a
hobby; especially for the Xbox 360 console.

Though even with so much information available
online, I still found this project to be difficult

and challenging. I discovered that a lot of time
goes into creating even the smallest details in video games, and many of the features that you
would normally not even notice in a video game can require countless hours to create.
I gained a
new apprecia
tion for game developers in creating this game.


The special features I embedded into the game I created are an audio streaming engine,
file manager, XML database,
multiple platform support, gamepad support,
user
-
friendly game
designer

tools,
robust artifi
cial intelligence, dynamic menus, and
complex collision detection and
movement correction.

I will explain each of these features in detail
in

the following paragraphs.


The streaming audio engine included in this
game is capable of handling three types of

audio formats: PCM, ADPCM, and WMA. Of course it can also support the XMA audio format
required for the Xbox 360 console. These 3 audio formats allow for custom compression levels
to be set on the audio files, which can be selected at the whim of the ga
me designers working on
this project, and the various compression levels allow those designers to choose an appropriate
balance between sound quality and audio file size.
Once these files are created, the audio engine
allows for all audio files (ambient,
music, and sound) to be loaded instantly when needed, and to
stream instead of loading completely into memory. This works by loading 1 second intervals at
a time into memory as opposed to loading an entire 1 or 2 minute song. By doing this, a great
deal
of memory is spared and the excess CPU power that is available can be utilized for reducing
the amount of memory required.


The file manager included in this game is capable of dynamically loading XML files and
turning them into game
-
usable objects. This
file manager is also capable of cracking open the
archives used in the game that store audio files, which allows for even further compressed audio
as well as encrypted archives to store audio files.
Having encrypted archives storing the content
med
ia file
s of the game deters the amount of pirating of the game’s audio files and graphics.
Even though copyrights will be taken out on the content of the game, this extra level of
protection will serve
to discourage content pirates even further.


The XML databas
e used in this game is dynamic, efficient, and very effective. It is used
to store the data for maps and tile
-
sets within the game.
Whenever the player walks to the edge
of a map in which they are teleported to a new map, the XML file containing the new
map’s data
is read and all of its information is used to create a new map object that can then quickly
generate the necessary non
-
player characters, monsters, item
s, and terrain for the next map being
loaded.
Using XML files for the maps and tile
-
sets als
o allows for modification of the game’s
content while the game is actually running. This is very convenient for debugging purposes,
since the game developers can simply overwrite an existing map file or add in a new map file,
and load it up within the gam
e without having to reload the game. This also provides for easy
maintenance in the future, since all that will be required to edit game content is to modify, add,
or remove existing XML files within the game’s data folder. The decision of whether or not

to
encrypt these XML files into an encrypted archive has not been decided yet, since having the
XML files unencrypted would allow for the user to simply change maps around to how they see
f
it.


This game supports multiple platforms as mentioned earlier.
It utilizes the XNA
framework to provide common framework calls and resource management on both the Xbox 360
and Windows platform.
The only part of the game requiring modification when porting it ove
r
to the Xbox 360 console is
chang
ing

the format of the
audio files to XMA.

Having two potential
platforms for the game allows for an increased market for future commercial sales.


The artificial intelligence used in this game is very robust, and allows for complex
actions to be taken by the player’s opponents
. This creates a challenge for the player, as opposed
to having a simple “hack n’ slash” game in which the player can easily cruise through the game.
By having artificial intelligence that will challenge the player, the level of fun of the g
ame has
incre
ased drastically.

Also, the artificial intelligence is dynamic only to a certain degree, since it
is programmed in a hard
-
coded manner, and does not utilize neural nets. The reason for hard
-
coding the artificial intelligence of the game was using neural
nets for such

basic actions would
simply be too much and unnec
essary
.


This game comes with multiple user
-
friendly game designer tools for the game designers
to quickly develop and debug the game. For example, one of the tools that comes with the game
is
a Windows form that allows the player to select a map to instantly teleport to as well as a
specific location on that map. This lets designers test their new maps very quickly, especially
with the ability to dynamically add in new XML map files.

Other to
ols that come with the game
are spriteset and tileset slicers that divide large spritesets and tilesets into multiple smaller files,
with a numbering system supported by the game’s code.

This is useful because the large graphic
files created by the game’s

artists need to be cut down to manageable sizes since the maximum
file size supported by the average video card is 2048x1096.
These tools have saved the other
people that work
ed on

this game a great deal of time, not to mention motivation, since the
tedi
ous task of cutting up large files can sap anyone’s motivation.


This game includes a number of dynamic menus that allow the player to sort through
content he or she has earned throughout the course of the game. For instance, the “Items Menu”
allows for t
he player to browse the items he or she has gathered so far in the game. This menu
dynamically updates and refreshes when the player receives new items or loses current items.
This menu also allows for the players to equip and use various items. All of
the menus created in
this game provide this level of usefulness, and enhance the game
-
play greatly.


The game also includes a complex collision detection and movement correction system.
The collision detection uses a bit
-
mask for every tileset that is loa
ded into the game, and checks
the bit
-
mask for different colored pixels to determine how to appropriate respond to a player
running into this portion of a tile on the map.
Depending on the color read in the bit
-
mask for
the current location, the player wi
ll move, stop moving, or slide in a similar direction. The
sliding is handled by scanning all of the adjacent pixels within the bit
-
mask within a range based
on the player’s movement speed, and then
an appropriate angle is determined to push the player
in
. The end result of this movement correction code is when the player runs into a sloped wall,
the player will slide in the direction the wall is sloped, and will slide at a distance based on the
intensity of the wall’s slope.

This provides for a smoother

game
-
play for the player, and lets the
player think he or she can run into sloped walls and move about the map lazily and still reach the
intended destination.

This increases the fun and appeal of the game.


The operating system principles incorporated i
nto the game are
multi
-
threading, delay
avoidance, a graphic user interface,
and
memory management.

These multiple operating system
principles are not just incorporated into the game for the sake of fulfilling the project’s
requirements, but are included
because they are essential to the game’s

functionality and
efficiency.

I will describe how they are implemented in the following paragraphs.


Multi
-
threading was used in the game to
implement smooth game
-
play. The game
creates and manages many threads wh
ile it is running, and
uses

concurrency to maintain data
reliability.
The main threads used are a thread for handling the graphics and all screen drawing,
a thread to handle the game logic constantly calculated while the game is running, and
a thread to
h
andle
the music and sound effects of the game. These threads tackle three tasks that do not ever
interfere with one another, so there is no need to worry about the safety of objects.
Also many
other threads are spawned from the music thread since it crea
tes a new thread for each song or
sound effect played. By using multiple threads to handle the different aspects of the game, a
smoother game
-
play is created since the graphics can update more often instead of once per logic
cycle, and the music can also
be looped without a pause or skip at the end of a song, since it is
constantly checked instead of also being checked just once per game logic loop.


Delay avoidance is

utilized in this game
to manage the songs being played by the audio
engine.
Songs are p
reemptively loaded or looped to ensure that they can play fluidly without any
gaps or interruptions. Delay avoidance is also utilized
in the artificial intelligence implemented
in the game. The actions taken by monsters within the game are calculated bas
ed on the
monster’s surrounding environment and then stored in a priority queue. This queue ranks actions
based on their importance or how immediately they need to be taken. If all actions in the queue
are of equal priority, then the monster will simply
handle the actions in a first
-
come
-
first
-
serve
manner. If an action enters the queue of the upmost priority, then all other actions will be
bumped and made to wait longer while the high
-
priority action is executed. This allows for a
very responsive artif
icial intelligence that can react dynamically to its environment instead of
giving it a “scripted” feel.


The graphical user interface used in the game is very advanced since it is a video game.
It contains a great deal of user
-
friendly features, and ente
rtaining graphics. The goal behind the
graphical user interface of this game is to capture the attention of the player and give the player
the impression of being immersed in a fantastical world. Many subtle features are included in
this graphical user i
nterface in order to accomplish this
player
-
immersion, such as grass slowly
swaying in the wind, leaves occasionally falling from trees in the woods,
ripples forming in lakes
as the wind hits the water,
waterfalls splashing and churning up water, and
butte
rflies and birds
slowly
wandering around the map.

The graphical user interface ended up being a great success
in this game.


Memory management is one of the key features of this game, since having so many
graphics and audio files loaded simultaneously is
very memory
-
intensive.
The solution I found
to implementing effective memory management was to preload many graphics needed, and
remove them from memory the moment they are no longer needed. Small graphic files such as
the sprites for monsters are kept i
n memory for the duration of the game, since they require a
small amount of memory and by having them preloaded maps can load much quicker.

The audio
engine implements memory management by
streaming the audio files it plays, as explained in
greater detail

earlier in this report. This increases the amount of strain on the
CPU, but it
drastically decreases the amount of memory required to play an audio file. The average audio
file for the game is 3 megabytes, which would require 3 megabytes of memory to lo
ad it
completely into memory. With my method of memory management, the game is able to stream
that same audio file with only using 2 kilobytes of memory. This is a massive reduction in
memory usage.


Also file management is utilized for the various file
formats used in this game.
File
management is used to dynamically convert encrypted Marshall Ruby files into usable XML
database files,
create and read from encrypted archives,

and

load XNA encrypted media files
.
This method of file management allows for

a safer level of piracy protection in the game’s media
files, as well as easier debugging for the game through its dynamic XML loading capabilities.


All of the methodologies, technologies, and solutions for implementing the operating
system principles li
sted above have been mentioned and covered in full detail in earlier parts of
this report.
Though to reiterate, the technology used for this project is the cutting
-
edge Microsoft
XNA framework, that is only on its 3
rd

publicly released version currently.

This game utilized
the latest video card capabilities, and balances its work load between the CPU and memory very
effectively and efficiently.
Many game programming and game design techniques are also
included in the actual coding of this game, though I
did not mention them since they are out of
the scope of the project’s requirements. But they do show that this
project

is very
technologically advanced.

This project proved to be an invaluable learning experience, and I am
thankful to have received the o
pportunity to do it.


















References

Riemer, John. “Riemer’s XNA Tutorial”, 15 Jan. 2006.
Riemer’s Tutorials
.

http://www.riemers.net


Britt, James. “Module: Marshal”, 22 Mar. 2002.
Ruby Documentation
.
http://www.ruby
-

doc.org/core
-
1.8.7/
classes/Marshal.html


GameDev Team. “XNA Articles”, 18 Aug. 2005.
GameDev
. www.gamedev.net


Joran, David. “XNA Game Studio 2.0”, 13 Dec. 2007.
XNAtutorial.com
.

http://www.xnatutorial.com/


Microsoft. “XNA Creators Club Tutorial”, 29 Jun. 2005.
XNA

Creators Club
.

http://creators.xna.com/en
-
US/