Archive for April, 2010
My Internship hunt for Summer 2010
As I’m sure anyone who knows me is aware I went on an internship hunt this year fairly determined to not end up doing nothing with my Summer. My hunt began around January of this year. I applied to Google (Why not?). To my surprise I got an interview. It was my first ever interview, not a bad place to start I suppose! It was a telephone interview and although the content of it was not that hard I was extreamly nervous and I thought I performed fairly poor and didn’t represent myself well. It was a nerve wrecking 50 minutes but although I didn’t make the cut I thought I learned a lot.
Google! My first interview and first rejection!
After a “no dice” verdict from Google I began to get more serious. Applying to Ericsson, IBM, Oracle, ODCSSS and CLARITY. Both IBM and Ericsson seemed to be very much about debugging and did not interest me too much but I thought I’d apply anyways! Oracle’s position was very general just advertising “Engineer – Intern” without very much detail so I was rather aprehensive about the whole thing. The CLARITY internship I put as my first choice was “Recommending tweets with augmented reality” . I found the project fairly interesting as I’m a twitter user and I have an interest in learning more about Recommender systems but the thing that really caught my eye is that it involves development on the Android platform which is what I’ve been learning as of recently. This internship seemed to be something very much suited for me so I applied. Following my application to CLARITY I made my ODCSSS application. I applied to Adapting Heystaks for Google Chrome , BlueTweet – Personalised Context-Aware Tweets & News and Automatic Feature/Weight Learning for Recommendation . I found all three of these projects rather interesting but secretly my heart was set on Android Development.
A month had passed and I was becomming rather worried as to if I’d hear back from anything I applied to. I decided to pop off an e-mail to CLARITY and ODCSSS to see what the story was. CLARITY replied informing me they where waiting on all project leaders to pick their interns before telling any successful candidates and ODCSSS informed me they’d inform candidates early next week.
My computing history
Following recent blogs from both Chris S and Chris D. I decided I’d join in and list off every system I’ve owned. I’m fairly hazy on the details of the earlier systems as they where family systems and I didn’t exactly have much of an interest in their specifications what with being 5 and all.
P1 Gateway
Pentium 1
I remember playing DOOM and Duke Nukem 3D on this thing!
Windows 95
P2 Gateway
Pentium 2
Windows 98
Same as above!
Dell Precision (something)
Pentium 4 2Ghz
256MB SDRAM
40GB HD
WinXP
I started getting interested in technology about here. Hence the wanting to build my own machine.
Custom Built by me
AMD3200+
1GB DDR RAM
Nvidia 6200
250GB S-ATA
WinXP
22″ Analog
Razer Diamondback
Logitech G15
This was probably my first venture into all things technology, although I spent the majority of my time playing games with it. I did however learn to construct and troubleshoot my own machines at the age of 14.
Custom Built by me 2
Core 2 Duo E6600
2TB HD S-ATA
Nvidia GTX260
4GB DDR2 RAM
Razer Lachesis
Logitech G15
Dual Screen 22″ LG HD monitor + 22″ Analog
This is my current machine! it originally contained a 8800GTS but that burnt out. The hard-drive space was upgraded from 500GB and the RAM from 2GB to 4GB.
OpenSUSE/Win7
Dell Studio 15
Core 2 Duo 2Ghz
3GB DDR2
250GB S-ATA
ATI Mobility 256MB
Ubuntu/WinXP
My most recent purchase! Has served me well through my undergraduate degree thus far.
My first Android application. The conclusion (for now)
Much of the following is lifted directly from my final report on the Wikigolf game…
Android is a version of Java but not quite standard Java. It doesnt have
a “main” method. It rather starts at the “onCreate” method. Which is called when the
Activity is initialised. Android is built on top of the Linux Kernel giving it a stable and
solid foundation. It’s kernel is used for memory management, process management,
networking and other operating system services. The “old reliable” Linux kernel would
come back to haunt my when implementing the Wikigraph database but I will discuss
this later in my report. On top of the Linux Kernel Android has its Libraries (OpenGL,
SQLite, SSL, etc.) as well as Java libraries and it’s virtual machine called the “Dalvik
VM”. On top of these is the Application Framework followed by the Applications and
Widgets. Android is split between various directories. The res directory contains all
resources. Images, XML GUI files and other files. The “src” folder contains my java files.
There is one important file that is located outside of both of these directories and that is
the Android Manifest file. Android requires you to register all activities and permissions
with the application Manifest file.
Implementation of Alvis made Game Mechanics
Alvis had completed a Wikigraph.java file as well as a GameEngine.java file. I then lifted
these files and used them as the foundation of the Android implementation. The
wikigraph.java file was ported over to Android without much change. It required very
little revisions and was only revised twice. One to implemented my loading database
method and on the second occasion to edit the Depth First-Search made by Alvis to
implement Warren’s revision. The GameEngine.java however was a headache. I had a lot
of issues implementing the text based version of this game on Android as much of the
crucial methods (such as shot()) where recursive to begin with. I had problems linking
this up with my GUI and only made progress when the Desktop version’s Gameengine
was revised later on to accommodate Sean’s GUI. The gameengine.java I received was
the original GUI version therefore all bug fixes currently in it where implemented by me.
I also had to change how the methods displayed information to the user and so added in
my own methods as well as edited already implemented methods such as shot() (name
more). Nearly all of my Wikigraph.java file and approximately 60% of my
Gameengine.java file should be accredited to Alvis. I created various input boxes,
buttons, TextView’s and information screens to allow the user to interact with the game.
All of these methods help enhance the users experience.
A typical game involves many methods including:
OnCreate(); - This method is called upon creation of the WikiGolf game.
Generate(); - This method is called from OnCreate, it finds a random start and finish
location.
gamestart(); - This method sets up the variables for a new game.
roundstart(); - This method begins a new round.
inputbox(); – This method asks the user what node he/she would like to go to. It’s
check for errors by inputerror();
shot(); – The shot method runs a DFS from the value entered in inputbox(); to the
targetnode
reachedTarget(); - reached target is called when the user reaches the targetnode. It
decides wether roundwin(); or gameover(); should be called.
roundwin(); – Called when the round is won, displays user score. Calculates user score
and calls roundstart();
gameover(); – Gives the user their total score and asks would they like to play another
game.
GUI:
When implementing my GUI I wanted to keep it simple. I wanted user interaction to be
simplistic and for them to have to put in as little effort as possible when navigating
around my game. I think I have achieved this goal. For images I drew up some Golf like
pictures and use them as both a splash screen and background screen. I think these
images fit in with the feel of the game quite well and stick with the Golfing theme the
project was meant to implement. Android offers many options when creating a GUI. I
tried to implement as many of these as possible without messing up game navigation.
Much of the main menu’s are using a purely XML based layout. All buttons and colours
are defined externally and only referenced within the Java file itself. Android encourages
resource externalization as it makes for a cleaner project. The preference menu’s are
also XML defined. As both of these menu’s are static and their values do not require
changing they have remained purely XML. The course changer however is an Alert box
which was defined pragmatically along with every other Edittext alert box in the project.
This particular EditText Alert Box allows the user to change the database variable and
therefore change what selection of courses they can use. I implemented this feature to
compensate for Android inability to parse through large (18,000+ node) text files. So
that when the game got repetitive the user could then download new text files from the
website embedded in the application and set their course via the course selector. I
researched where Android phones store downloaded content and it can vary depending
on which phone is being used, implementation of Android is in use and user settings. So
I decided it would be best to allow the user to set the path to which they store the
database file too.
The GUI on the game screen may seem a little odd in that it contains text for the
information. This was a conscious design decision on my part. I decided it would be best
to keep everything inside the screen (no scrolling) this is so that the application can be
ported onto multiple handsets. Filling the screen with graphics a clutter would only make
this problematic. The current layout is a good blend between style and practicality.
The GUI itself is split into multiple files including…
slash.xml - This XML file sets up the splash screen.
main.xml - This is the main menu XML file. Contains buttons and backgrounds.
easygame.xml - This is the game backgrounds + buttons.
about.xml - This creates the fancy about popup box.
howto.xml - This creates the howto info page.
settings.xml - This creates the settings tab when you press “menu”
menu.xml - This creates the menu where “Music” is located.
Networking:
I’ve implemented a feature where the user can open up a web browser embedded inside
the application which is directed at a webpage which displays new databases they can
download. I thought that this would be necessary as we are dealing with a small enough
database of nodes. I think that this feature offers scalability and longevity to the game.
Currently the game has X number of nodes. Eventually (pretty soon I bet) anyone
playing the game will get tired of the same old paths. So I’ve created a web page where
new databases will be uploaded when available. The user can then download these
databases. Save them directly to their phone and then switch databases using the
AlertBox in the options menu discussed earlier.
Sound:
Late into the development of the android port I thought the game lacked user
experience. It didn’t really look like golf and had no real feel to it. So I decided it would
be best to implement some music and not just any music but something with comedic
value that a user could enjoy. I then decided Benny hill would be the perfect track for
this game. Since the entire game (including the algorithms in it) are about running
around like a headless chicken attempting to find your target I figure the user should
feel the same experience. The sound is called when both the menu and the game itself is
started. By default it is off but can be toggled on by pressing “Menu” on an android
phone and selecting settings. I understand that after a while the music would become
annoying so having the option of turning it off is always nice.
Database implementation:
This was by far the most challenging area of the implementation. It was the most time
consuming area and also the most mission critical feature of the project. Android runs on
a Linux Kernel as stated above. This Linux kernel is what controls what can and cannot
utilise resources. The Android application life cycle is not overly complex but effective.
The idea is to keep what the user can see alive at all costs. If the system load is getting
high the kernel will kill all processes which are paused but still in memory. If this is not
sufficient in keeping the system load lower then it will begin to kill off more processes
trying at all costs to keep the operating System from running out of memory. If
necessary it will kill the application in the foreground of the phone e.g My application. I
originally without much expectation attempted to parse android through the original
18,000 node+ database. The phone froze up and killed the application soon enough.
Although the application itself was still working the Android kernel will automatically kill
any process which is not responsive to the user within a short time frame. Running the
original database and parsing it through the phone was not an option.
I began to look at alternative methods. I first started by finding out what would be a
reasonable number of nodes for android to deal with (within 10 seconds) and display the
game to the user. So that the user does not grow too impatient and force the kernel to
kill the process too quickly. I found that about 500 nodes was a reasonable number. It
would parse through these and run the Depth First Search within about 10 seconds. I so
attempted to use a 500 node implementation of the database. Of course this was not an
option. The graph was littered with dead nodes making it impossible to find paths. I
began clearing nodes but after taking out 174 dead nodes and countless dead
connections I realised that it would take days or even longer to get this database into a
playable state. I decided the best thing to do would be to start with a 100 node database
and heavily edit it. I did just that and began play testing. Sadly I still encountered many
bugs and the game would often freeze up and fail to work. I then (3:30am on Monday
morning) decided it would be best to implement an 8 node demonstration database. Just
to show my methods are sound and the only issue is the poorly formed databases. I
cleaned up the database as much as possible in the time I had removing some dead
nodes. From play testing I feel that this database is as playable as I can get but some
bugs do still exist I think I’ve proven that this can be done with the right database the
way I have done it. It’s just a pity that a perfect graph is not an easy thing to
implement.
The positives from the method I am using is a low loading time for the user but there is
the obvious downside that the user has a limited number of holes to play. I understand
that this would make the game very repetitive very quickly. So I got the idea of
implementing a course downloader. This would allow me to add more databases later on
which the user could then download and play. It opens up the possibilities of specialised
Wiki databases such as a Star Wars Wikipedia or a Simpsons wikipedia database etc. I
could also add different difficulties of databases. This method insures that the game
would not become bland and dull for the user overly quickly.
I decided to store the database file on the SD-card. This has both ups and downs. The
downside is the database for the game itself is not stored in the .apk file of the game.
This means that the user would be required to download the database when they first
start up the application. This would not be a big issue as a user would be required to
have an Internet connection to download the game in the first place. This however
allows for longevity of the game. Since the database is not limited to one file stored
within the Android application itself further databases can be downloaded and the user
can pick and choose where he or she would like to keep them on his/her phone as well
as choosing which they would like to play.
I feel like the database is the biggest let down of the project. If for example the 18,000
node database we where given could be implemented on the emulator I know it would
run without any problems. Sadly though whether it was a 500,200,100,50 or 20 node
simplification of the database even though it was heavily edited it would still be
incredibly uneven so much so that the game would crash over 50% of the time. I
thought therefore it would be best to insert a demo database of just 8 nodes so that
game can be easily played and tested. The project itself is not computationally viable on
an Android device. Although with the use of servlets etc. it may be. I ran out of time and
so was unable to test this avenue of thought.
Bug fixing:
Much of the foundation of the Android port (Wikigraph.java, Gameengine.java) was lifted
when Alvis completed these classes back in week 4 or 5 and so bug fixing had not
commenced on these methods. Wikigraph.java did not require bug fixing other than the
one fix which warren implemented to the Wikigraph.java late in the project. On the
Game Engine.java file I implemented my own fix for the par bug. This was a bug that
would recalculate the par after every shot leading to the player obtaining a negative
score. I was able to fix this bug on the Android port and then inform my team mates of it
and help them apply the fix to the Desktop version. Another bug which I fixed was that
the information such as par,round,shot,target etc. were not displaying correctly. I
implemented the reload(); method so that these all would update on the GUI as soon
as one of them changed so that the user could be notified.
I applied some fixes to the parts of the game which require user input. There is
exceptions preventing the user from entering an invalid node when taking a shot. I
would of liked to of put more time into play testing and bug fixing but sadly a very large
chunk of my time was taken up in an attempt to resolve the database issue.
Reflection on Project:
Ideally I would of liked to of implemented a high score system. I have the GUI setup for
this and the global high scores setup. The embedded web page points to where the
global high scores for the game are kept. There is currently no local highScores or the
ability to upload to the global high scores on the Android implementation as of yet. When
I discovered a database of any decent size was impossible for an Android phone to parse
through my first thought was to do all heavy computations server side and relay the
results back to the phone. Due to time constraints and tomcat being broken on my
server it soon became apparent that this would not be doable in the time available. I
would of liked to of implemented a multiplayer desktop version of the game. Originally I
had planned to do both this and the android port but due to time constraints this also
became impossible in the time available.
I felt hard pressed for time throughout this project and the words uttered by tony not to
“bite off more than you can chew” where ringing in my ears in the final weeks of the
project. I felt that although my database implementation has an impact on the gameplay
I have proven that a Wikigolf traversal game on the Android mobile operating system is
quite do-able with a few work arounds. I believe I took on quite a daring task and I have
completed most of what I set would to achieve and that with more time I’m confident a
better implementation could of been achieved.More time. There where many brick walls
and work arounds that had to be implemented to complete this port. The largest being
the database implementation which hogged a lot of my time in the last days and weeks.
I do believe though I have learned a lot about Java, problem solving and the Android
operating system from this project and that it was a very worth while venture.
I feel that communication issues within the team often halted development. For example
I spent much of my time debugging the foundations of the project which I received from
else where. I felt that much of the work for this project was done by the same people
and it was very hard to get certain individuals to work. A lot of time was eaten up by
calling meetings and attempting to assign tasks to individuals in an effort to get them
contributing but this for the most part failed. A huge amount of time was wasted on
attempting to get the Android Emulator pulling and popping files to the sdcard as well as
starting up and shutting down. The Android SDK is very unstable and tends to crash /
disconnect every now and then which is quite frustrating and time wasting.
I feel quite let down by the outcome of my part of this project. I feel as though I put a
lot of time and hard work into it but in the end was let down by the database. Perhaps
through some fault of my own not predicting this outcome. If I had more time I would of
probably attempted some sort of JSP file on a server. Making the Android application a
client server application. Sadly though I ran out of time before this was possible. I think
none the less that this was quite a daring venture in which I deliver on almost all I set
out to do. For this I think it’s deserving of a good grade.
One of the reasons why I’ve been busy lately
My SE2 Project thus far.
Error check entering..
The Game, Sadly not the greatest GUI yet!
yaaay
Fancy android.
