Now that I am at the end of this module, I can look back to the beginning compare my understanding and knowledge of the mobile gaming platform and the different elements that contribute to it to make it a success.
I understand now that mobile phones can actually have an influence on handheld gaming devices which were primarily created to play games. It is evident that the portable gaming device developers are attentive to what other devices have implemented, and whether it is something they can implement on to their own device to make it function better (e.g. iPhone’s influence on the PSP Go and Nintendo DSi).
I have also familiarised myself with the numerous mobile platforms that are available for gaming, each have their own drawbacks as well as their own benefits. It seems many of the developers used to previously target a very specific audience, something Nintendo have always managed to work around by supplying games for a wide range of audiences while keeping their base device either neutral or very colourful.
I think one of the most interesting parts of my research was looking at the historical perspective. By doing this I was able to immediately notice how developers seemed to continually reiterate their base designs while simply tweaking specific elements to make the functionality greater (this is especially evident in the Nintendo Gameboy series).
By working in Flash Lite, I have learnt to appreciate the functionality of Device Central. Due to the number of times I had to simulate my game in order to find out what the problem was, I was quite exhausted from simply running it through Device Central, the only other alternative would be to upload it to my phone and attempt it there. It was obviously a no brainer for me to ensure that which ever machine I was developing this game on had a functioning version of Device Central; doing otherwise would be akin to looking for a needle in a haystack.
During my personal study time, I was also able to put to practice my obtrusive and unobtrusive observational skills while presenting my work to random students. By doing this I understood much more clearly what the drawbacks of my design were and which aspects functioned well. I particularly liked this method as it was one which I had never thought of using, the results I collected were clearer and overall it was more efficient.
Apart from the skills I learnt specifically for mobile gaming, I have learnt other skills which I can easily adapt to use in other sectors. Lo-fi prototyping was a technique I was already familiar with as I use it to help with my compositional drawings, so that technique didn’t really contribute much towards my skill base. I believe the most important skill that I learnt was the observational skill. When creating illustrations for clients that require feedback from the viewers in various forms, I could trial it on the client using these new observational skills without them realising it in order to get a genuine feedback of how it will be received. And when I am half way through a project where I am unsure if my artefact will stir the correct combination of emotions, I could always run the unobtrusive observational test on a subject and read them to see where I went wrong.
I believe overall I uncovered a lot of influences in the mobile gaming sector which I could use for my own development, but due to the heavy restrictions on the aesthetics and game play I will have to only work on similar projects in my spare time. Regardless of this, I now have much more appreciation for mobile gaming devices. I used to believe before that due to it being smaller in size it should be much easier to develop, but due to it being smaller in size the developers will have to work harder in capturing the players’ minds.
From this point on, I am mainly going to be focusing on my project and checking to make sure all the functions are in order. I will also be working on my reflective essay and the multimedia presentation.
Unless you haven’t been on the internet, watching TV or have been stuck in a cave for the last few years, you’ve definitely heard of the Apple iPhone. There are many reasons that this device is popular, but one of the main reason reasons in my opinion is due to its open API that lets people easily build and distribute their own applications. By doing this, not only does it allow individuals to get some exposure, it also allows the iPhone to cater to more user requirements without having to create the applications themselves.
Upon taking a look at Rubicon Consulting’s iPhone impact study (which was carried out in 2008), I have noticed a pattern which is starting to become more and more habitual by individuals. On one hand the positive impact consists of:
- Users reporting high satisfaction with the device
- iPhone user report increased mobile web browsing
- One quarter reported it displaced computer notebook usage
While on the other hand, there were somewhat contradictory impacts, such as: - Email in the number one function…for reading emails, not writing them
- One third of iPhone users carry a second phone. Why? According to the study, for making voice calls and composing emails
- It increased phone bills. The survey cites an average increase of 24% annually
We can see from the contradictory points that people carry a second phone with them whilst carrying the iPhone, where the second phone is used for making voice calls and as well as other basic procedures. This makes you question, so what is the iPhone carried for? This brings me to believe that the iPhone has now become something of a passport for becoming acceptable for social circles and such, rather than having ‘much’ obligation to its initial purpose as a mobile phone. I think the tech community had been waiting for something like the iPhone to come along as it would fulfill their need for a ‘platform shift’ as well as ‘mobile cloud computing’. I think you could go as far as saying that these are more than just smart phones, they are major computer platforms for specific applications that cannot be run on a PC, but can easily compliment a PC the way a desktop computer can compliment and augment a mainframe.
In the past, there have been other attempts made to conquer the same niche market as Apple have done so well here, one attempt was made by Microsoft. When they initially released their device, the entire thrust was to do nothing more than miniaturize the desktop PC, in other words give users a PC in their pocket. There was noting really unique about the Microsoft smart phones, they stored PowerPoint presentations and Word Documents and ran Windows software as best as they could – if at all. The end result was a dilapidated smart-phone business that looked to be dead in the water, or at best, an odd niche market.
Another Swedish company named Neonode attempted to improve upon this segment by creating a gesture-based phone with similar touch sensitive capabilities as the iPhone. Needless to say, this was also dead in the water. Due to the acceptance of the iPhone, it has set a pretty high benchmark for all other devices that plan on breaking into the same sector. I think one of the main facets that contributed to the acceptance of the iPhone was its ease of use and how smooth it would run in general. Due to it being able to remove all the noise that was present with the predecessors between the human / machine interaction, Apple have managed to console their customers that they can be relied on. And by using this as a leverage / selling point, they will be able to bring out an extended line of products bearing the famous ‘i____’ name, without fear of capital deficiency.
iPhone game platform
If we go back to early last year to the Game Developers Conference held in San Francisco, you'll read that Neil Young (iPhone developer) claims that the “iPhone is set to become the dominant gaming platform because of connectivity and the strength of the App store.” As seriously as I would like to accept this statement, I would have to half heartedly decline, mainly due to his opinion being biased. That’s not to say that he is completely wrong, to some extent he is right. For example, since 2008 the App store has seen more than 800million downloads with the gaming category being the most popular, while in their top 100 apps 60% of them are games. While at the conference, Neil Young was also encouraging the masses to continue developing games for the sake of gaming, and also to ‘not let the haters tell you it sucks…’
I think the reason the iPhone works as such a good gaming platform is down to its multi-touch capability, accelerometer and the screen size, as well as how they each compliment each other while also integrating so well together.
Following the release and success of the iPhone 3G S, it is even more visible now why it is preferred as a gaming platform over the pre-existing ones. The current 3Gs has had an upgrade on its processor and ram size to make it 2x faster overall. This will matter particularly with game loading times and help avoid those game crashes.
The iPhone 3G S is also one of the very few smart phones that comes equipped with Open GL 2.0 functionality, this allows the device to have a more robust out put of graphics and effects.
It also has the possibility to now run larger app sizes. Now that 16 is the new 8 and 32 is the new 16, there will be more room available to store more software. File sizes are already creeping up in size as they make the most of this opportunity; some games have even reached file sizes of 0.75GB. And if you notice, you'll see that other developers are beginning to share common assets with their newer models. For example, the PSP Go with its 16GB of memory looks even more like a direct attempt to take on the iPod Touch, aesthetically and technically. You then get Nintendo’s DSi which not only shares an ‘i’ in common, but also has its own online store, touch screen capabilities, camera and music playback.
Nintendo DSi: http://www.mobilemag.com/wp-content/uploads/2009/05/image_3905_superimage.jpg
PSP Go: http://www.hypegeek.com/theSexDrivenGeekBlog/wp-content/uploads/2009/09/PSP-GO-11.jpg
iPhone Touch: http://toppayingideas.com/blog/wp-content/uploads/2009/09/apple-Ipod-touch.jpg
Everyone knows that the customers control the success of products, and from looking at the sales of Apple’s iPhone series its evident that the formula has been successful as they are steadily catching up to their predecessors (Sony and Nintendo) after only a years release of the iPhone 3G S. iPhone/iPod Touch owners are currently at around fourty million, with Sony at 50 million and Nintendo at 100 million. I think with a little bit more of a push from Apple, this could soon become a triple platform race at the beginning of 2011.
At the moment I have pretty much completed the main piece of the game, I’m focusing now on the rest of the screens and also on getting the colour schemes right.
I’m thinking of using similar colours as the main game screen, but may make it more saturated and warmer to give the screen a little variety. After that I’ll need to work on my intro screen, help screen and the end score screen. I’m going to try and use similar colours / theme throughout the whole process so that they all have a visual connection between each other. I’ve done similar work to this, so this shouldn’t be too complicated.
User guides are the first port of call when something needs to be read. As many people read the user guide when frustrated and after loosing patience with their software, you need to write your material so that it addresses their concerns quickly. User guides are often written for non technical individuals.
Identifying your audience – as with all types of writing, the first step is to define your target audience. As different readers have different requirements, you need to consider their specific requirements:
- Identify who the target audience will be
- Identify the technical knowledge of the target audience
- Identify how they will use the guide
For a game to function, the user needs to carry out specific actions. Users want to know what to do to better understand the game and how to advance, for example, how to score bonus points.
They are not generally interested in the nitty gritty technical details, they just want to know how to click a button and get the result. The user guide is to teach them how to accomplish almost everything possible with the game. Each user guide consists of a front cover/content page, body section and a back page.
It is also a good habit to use images of elements from the game which you may be referring to, rather than to describe them as it give the user a visual of what you are referring to.
Identifying the task – When writing a procedure, attempt to identify what the task is before addressing it. If it is a major task then separate it in to sub tasks before approaching them methodically. You also want to avoid text walls as the last thing the user wants is to be overwhelmed.
If-Then approach – When users are allowed to make decisions, make use of the If-Then approach to show the different result of each decision they make.
“If you go up then you will enter the bonus round. If you continue on straight then you will enter the next round.”
Addressing the user – When writing procedures, use the active voice (e.g. Click this) and address users directly, e.g. write ‘You’ rather than ‘the User’.
When explaining an action, use the ‘command’ form of the verb:
“Choose an option from the menu and press [ENTER].”
Presenting your material – You can improve the readability of your pages by using specific formats to distinguish different types of information.
For example, you can distinguish the users input from the systems response by:
- Indenting text
- Using columns to layout text
- Providing illustrations that highlight key areas
- Using different font types and features (e.g. bold, italics and underline)
Non verbal devices, such as icons and diagrams, help supplement verbal instructions.
Left: Clean and segregated help menu http://www.dalasoft.co.uk/thetimepro/images/HelpScreen.png Right: Information overload on a help screen http://daringfireball.net/misc/2009/03/gpsguide-help.jpg
Once we make the game for the device and know that it is functioning as we want it to, we need to find out if the user also reacts the way we want them to. To do this, we hand the device over to them loaded with the game and observe while taking notes.
There are two different ways in which we can make observations, obtrusive observation and unobtrusive observation. Unobtrusive observation means you simply observe what the test user does and refrain from interacting with them, with this method you realise whether the system is user friendly and if it is ready to be published. In no way can you influence what they do by explaining designs or asking any questions.
Using the obtrusive observation method means you are able to interact with the test user, e.g. by asking questions. Using the obtrusive observation method, you are able to learn more about the usefulness and acceptance of the system.
By carrying out these tests, you can evaluate the ease of use and learning for the game. During usability testing, a real future user should be used to give you the most accurate results. I don’t think neither method is wrong, but to get best results you should use a combination of both tests in an efficient manner. For example, each time you start a usability test you could start with the unobtrusive observation: you observe how users execute the tasks you give them. After that, you reserve sometime to ask some questions, explain the design process, and answer the test user’s questions.
I’ll be going into a little bit more detail on both of the methods so that the differences are a bit clearer.
Unobtrusive Observation:
1. Observe: be quiet, watch and understand
- Don’t explain
- Don’t ask the test users opinion
- Don’t defend the design
- Don’t apologize
- Don’t suggest
- Don’t contradict the test user, nor agree: stay neutral
This is actually harder than it initially seems. It is in our nature to help others when we see them in trouble, even more so when it is with a design we have worked on ourselves. Just keep in mind that you are there to learn about the test user’s behaviour and not teach or convince them.
2. Only help to overcome the limitations of the prototype
Explain briefly and in a neutral way what would happen in the future system.
3. First observe, then take notes
Don’t let your note taking get in the way of your observation; you'll end up missing some details. You don’t have to write down every observation you make, just the key ones. As soon as the observation in complete, take a minute to write down anything you may have not already while it is still fresh in your head, wait too long and you’ll forget the important details.
4. Stimulate the users to think out loud
But use neutral points, e.g. “What do you see, what are you thinking, what are you looking for?”
5. Limit the time test users have to execute a task
Don’t prolong the test users suffering more than necessary. If the test user is stuck on a certain task and you have learned of the reason, get them to continue.
6. Extract detailed information
Test user: “I see a lot of information.”
Observer: “Could you tell me what information you see?”
7. Answer test questions with questions
Dealing with test questions is probably the most difficult part of unobtrusive observation. Before the test you should explain to the test user how you will be conducting the test and how their questions will be dealt with. You should encourage the test user to ask you questions as they will help you figure out what is not clear with your system, and also that you will only write them down for now and answer them at the end of the observation.
Test user: “What does this text/symbol mean?”
Observer: “What do you think it means?”
Test user: “Should I click here?”
Observer: “What do you think happens if you click there?”
Obtrusive Observation:
1. Think of what you want to ask them before the test
When you have just completed you unobtrusive observation with the user, you will obviously have questions from them which you will need to answer. But you must also have your own checklist with things which you would like to know from the user, e.g. functionality, acceptance, etc.
2. Ask open questions
Try and avoid closed yes/no questions, by asking open questions you will bej able to draw out much more detailed answers.
Bad: “Do you understand what this means?”
Good: “What do you think when you see this?”
3. Don’t blame the user
Remember, your testing the usability of the system, not the computer literacy of the user. If there is something the test user does not understand, then it is something that will need to be reworked in the design.
Bad: “Why don’t you understand this?”
Good: “Could you tell me what this mean for you?”
4. Don’t ask the test user for design solutions
Test users are not interaction designers, that is why they will not provide you with any good solutions. Don’t bother asking, but take notes of suggestions they make spontaneously.
Bad: “Do you need a button here?”
Good: “What information would you require at this point?”
5. You can do obtrusive observation with groups of test users
You will get much more feedback using this route, but it may end up being a little overwhelming. People often find it easier to form their opinions when they are confronted with the opinions of others. You can also learn much more on the usefulness of your design as well as its acceptance amongst the group as they discuss it. Your role will be to facilitate and focus on the discussion.
So after the critiques and my many failed attempts at getting a basic functioning Concept 7, I ended up settling for Concept 3 as it seemed the most feasible.
I began the development of Concept 3 by giving it a new background. Since it was a game involving hens and eggs, I decided to make the background resemble a hen house.
A semi lo-fi sketch of a new background
By using this instead of the gradient I had, it makes the background much more relative to the game as well as set the atmosphere. I then experimented with various colour palettes on the background to see which worked best. While doing this, I also worked on the chicken a little bit more so that it looks more integrated in to the scene. Below you can see these experiments:
Replaced the hen with one a bit more clip art toon influence.
The new background has also had a RYGB influenced make over.
By using natural colours, I tried to make all the elements on screen look like they belong. But I still encountered problems though, for example:
Blue / Turquoise: looked like it was set in the night time, I doubt this is the time eggs are laid.
Green: gives me the sense that the hen house is located in the forest and surrounded by bamboo. I also doubt this colour is common around the farm environment.
Sepia: this is the colour that looked most appealing to, regardless of it being quite desaturated. I can see this colour being used in a farming environment as it is a more earth / sunny colour.
Red: it looks like there is a very angry sunset taking place in this scene. The look I was aiming for is slightly less dramatic and a bit more relaxed. It also seems a bit too saturated near the top.
After settling on the colour, I decided that since there will be three eggs dropping at the same time, it only makes sense to include 3 hens sitting at the top. This would not only make sense, but also give the whole scene an overall sense of balance when the eggs begin to drop.
I didn’t like the eggs sitting beneath the hens, most likely will take them
out at a later stage
I think by tweaking the sepia towards a warmer orange, the scene overall seems like its basking in sunlight, it’s also closer to the natural colour of wood and is therefore more acceptable. I’m still not happy with the look of the hens as they now seem too uniform, I also think the background looks a little too flat and may require more saturation. I’m going to have to slow down a little on the gui and focus a bit more on the coding language.
I have been receiving some help online as well as following a lot of tutorials online to understand how to write conditional successfully. One of the ways I practiced this was to download pieces of code with their visual counterparts and then decipher the language line by line. When I thought I understood a section I would apply my own conditions to it and execute it again to see if they applied the way I expected them to.
After much trial and error of this I came to the following conclusion; if I include a basket / nest at the bottom to catch the eggs then the condition could be set in the following manner:
If the egg is at x-pixel (bottom of screen) then -1 point from life.
If the egg is at y-pixel (just above basket) and the basket is in the same field then +1 to point.
Egg re-appears on the top with a random speed.
(Well something along that line anyway)
Rather than having three separate eggs falling down and then three separate pieces of codes to control them, I was advised by a user on the Nokia Forums to just create three separate instances of the egg with a single piece of code, and then a separate piece of code to drop them at random speeds. The duplicating would simply be executed by using the following piece of code “duplicateMovieClip(“eggsample_mc”, “eggsample1_mc”,1); etc… for the next two.
Then following that I would need to declare each of the eggs positions on screen (by pixels) and tell it to descend at a random speed.
I had this piece of code working semi-successfully after tedious editing and researching. The problem I encountered now was, if my basket was already on the left and I pressed left again, it would disappear off screen – and the same goes for the right side. Then after much lurking on the forums (stated previously) I figured out what the problem was, I had forgotten to state x and y dimensions / properties of the basket, hence why it kept moving off screen. So by setting this, I countered that problem.
The rest after this point was somewhat easier since the same principles applied to the normal Flash lingo. I just had to include two dynamic text boxes on screen to collect the life and score points, and then one for the end when the final score would be shown.
