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.
One of the fastest ways some companies can make some money on mobile gaming is to release an already released game for the desktop on to the mobile. For those who have attempted to play the same game on the desktop as well as a mobile device will notice that there really isn’t much that crosses over from the desktop to the mobile device.
The game on the mobile device will often tend to be much smaller in scope, and due to its very limited processing power, will rely more on its game play rather than its visuals. If you also carefully read the description of these mobile games, you'll notice that they will often provide you with enough adjectives to visualize their world, and hopefully tip you over to buying the game rather than leaving you undecided. You will also notice that the screen shot most often provided will be of an exciting and colourful moment.
While on the desktop you have room to maneuver your arms/fingers to easily press specific key combination's, on many mobile devices you will not have this luxury. For example, if they were to ship the Gears of War (2006) game to the mobile device, I can already see the many problems one may have with the button combinations. While on the keyboard, you have ample room to spread your keys out for changing weapon, crouching, running, zooming in, reloading, etc..., on mobile devices playing with your thumbs will shortly become frustrating. Even on larger mobile devices like the PSP, being able to carry out that many functions at the same time will become exhaustive. Therefore, to counter problems like these developers use well known and established game play mechanics that have already been established and instantly recognizable, such as Tetris, Space Invaders or Poker. By using these strategies, the developers reduce the amount of risk the customer feels when purchasing a game.
Specific Limitations
Limited Memory – Most mobile devices have a very limited memory storage. Due to this constraint, you can either have a very detailed short game, or a significantly lower detailed lengthier game. There simply isn’t enough room to transfer games over at their full capacity.
Limited Processing Power – Many of the online games provided over the wap internet require faster processing powers and memory levels. There is no use having a faster wap/wifi connection if the processor cannot keep up. This also means there is no point in packaging games for mobile devices that are heavy on the processor as the user will encounter heavy lagging during game play. Due to the release of Intel’s PXA250 and PXA210 chip, mobile phones and PDA’s have been able to recently handle delivery of media at higher speeds and better quality. Although there is still a long way to go, I think this is a step forward to better processing speeds.
Different technologies and Standards – Until a few years ago, vendors competed to providing mobile games/devices without adhering to any particular standards. It has since changed (for many) as they have realised that it is in their particular interest to cooperate and use open standard technology. Doing so will open the door to players (and cross platform synchronisation) as well as more collaborations. A good example of this can be of when Nokia and Siemens Information and Communications Mobile announced in May 2002 that they had agreed on a framework of collaboration to create and drive the implementation of mobile terminal software based on open standards.
Small Keyboard and Input Method – Most mobile phone devices only have a numeric keyboard and a small number of curser keys. This limits their usage and makes it more difficult for users to navigate their way around certain services and pages with large content. As of yet, only a handful of devices have managed to successfully work around this by implementing touch screen/stylus functionality. I have also witnessed some voice activated input services, but they still required further refinements to function reasonably.
Screen Size and Colour – As screen resolution continues to improve (and monotonous screens become a thing of the past), screen sizes are likely to remain a controversial topic. Mobile phones can’t have screens being too big as nobody really wants to carry a brick (remember the N Gage?), and every other handheld device with a reasonable screen size gets released will have flaws either with the screen clarity, resolution, colour depth, etc. I believe once the electronic paper innovation becomes commercialised, handheld devices will become revolutionised. It will allow the paper (screen) to be rolled open or closed to what ever size the user requires while retaining the image clarity.
Simplicity of GUI’s – When you are on the move, you cannot afford to read instructions or manuals when you need to get a job done in short time. The ability to access the application and data within, literally, a few keystrokes is really important, especially while the user is on the move. The user interface needs to be friendly and welcoming, which brings us back to the memory/processor constraints.
Battery Consumption – Battery life is important for the mobility and portability of mobile devices. On processor/memory heavy games, the battery drains very fast, this becomes a fast problem when user are out on the move with no place to charge their devices from (the purpose of it becomes redundant then, doesn’t it?). There is an ongoing effort to reduce the consumption of power and increase the battery life for mobile devices, and although they have the fuel cell technology, it is yet too expensive to be implemented while retaining the price within an acceptable band.
Stability and Connectivity – For many users who access their content online, connectivity is very important. In order to maintain connectivity and dropout, mobile devices must have the ability to save and minimize the loss of data when connection is lost.
Voice Recognition – While stylus based interaction on a touch screen has replaced the mouse, voice based interaction could be the future to replace the stylus. At the moment, it is used for dialling numbers and calling up certain applications, this is after a much needed voice training session – and even then those with accents may require further refinements. I don’t know how sure I am that this will be able to cross over from simple command executions to character commands within a game play scenario.
After absorbing all the critiques I had received, I began doing quick mental developments on the concepts and those which I could develop the furthest successfully. I eventually settled on concepts 3, 5 and 7, each of them due to their own development and aesthetic reasons. Below I have each of the concepts which were developed following three separate themes; they each also have a short description in relation to its game play.
Concept 3 (dodge ball inspired base concept):
1. This is a modern day space invaders inspired game. The scene has a backdrop of a futuristic/alien city. The alien space craft conceals itself most of the time in the sky behind the clouds while shooting down at the humans, the player in return must shoot back with their own cannon.
2.Concept number 2 is set inside the mouth, much like a children’s cavity game. The bare gums at the bottom each have a unique design at their root. The player’s avatar (tooth fairy) must stop all the teeth falling down in to the wrong slots while only allowing the correctly matched roots through.
3.Inspired by the farmyard games I used to play as a child, the player must save as many of the golden eggs as he can before they smash to the ground. The player’s avatar is the empty nest at the bottom. The player’s opponent is the chicken on top laying the eggs.
Concept 5 (fairground wire game inspired base concept):
1. This game was inspired by nature’s greenery. The player must successfully navigate the water bubble from one end to the other while keeping it on the line, they must also avoid the spinning and moving elements from bursting the bubble.
2.This is an amalgamation of the wire game with some theme park elements. The player must navigate the ball through the moving courses getting on and off at the correct times without falling off or jumping in to the wrong end of the obstacle.
3.Concept three is somewhat similar to concept two, with a slightly darker twist. Following the story line, there are two lovers who are joined together by their deformed nail. The player’s task is to navigate a ring from one finger to the other without making contact with the skin, nails or anything that might crawl out from the cuts and wounds.
Concept 7 (school / infant scribbling inspired base concept):
All the games in the 7th concept have the same objectives, the player is rendered a random scribble which they must then draw on and turn in to a comprehensible drawing.
1.This concept was inspired by the drawing / black board everyone used to get taught on in school. The player has the ability to draw with a piece of chalk and erase with a duster.
2.The interface here was inspired by a notebook. On the right side of the screen you can see the inside of a pencil case which is holding all the drawing elements the player can use to draw. This includes a pencil / pen, rubber / tipex, etc.
3.The wall concept is a bit more graffiti inspired and something which I hope does not endorse in reality. The player is provided with a spray can and a brush to get active with, while the scribble on the wall will be a bit more graffiti inspired. This should allow the player to influence his final outcome more towards a graffiti style rather than a normal illustration style.
Now I will be moving on to seeking out snippets of code that will help me with the coding process. I know there are forums out there targeting the Flash Lite language, so I may join up and start threads asking other members for help when I get stuck. I used to use the FlashKit community to get some help when I used Flash to code my websites, but I am currently unsure whether there will be anyone there that knows the Lite language.
We’re looking at persona's and scenarios today. I was very confused on this specific topic as there is a lot of noise on the surface, as well as the many different ways the terms are heeded in the various sectors.
In relation to gaming, here is the simplest form in which I can understand both of these terms:
Persona's – this is where fictional characters are created for a game which reflects certain characteristics of the targeted users of that game. The characters may have similar behavior patterns, vocabulary, clothing, etc. By doing this, the developer attempts to have the user ‘accept’ the character as one of his own.
Ofcourse we know that these ‘characters’ are all just empty dolls wearing a mask, one that the developer hopes covers enough ground for the targeted user to find interesting enough to pick up on. In reality, all the developer has to do is complete a template of requirements for the social cluster that will be target before applying those values to a ‘blank’ character. Developers must avoid creating stereotypes though, as this will only fuel the misconception that all games are alike and only targeted at a specific cluster of people.
Scenarios – The scenarios are created by using descriptions from the persona. If the personas are weak, then this will be reflected in the scenarios. The scenario can be seen as the four walls that keep a house upright, it consists of the persona, the goal, setting and hindrances between the persona and the goal.
Developers will often try and use real life situations that their audience may be familiar with to try and attract them. They may also use fantasy themed elements within the setting, by doing so they allow the user to attempt acts which are not really favourable in reality.
So far in my studies, I have learnt to write in numerous programming languages, such as: Turbo Pascal, Visual Basic, C++ and even Java. The problem was, when I start learning the language I could eventually write it and speak it fluently as if it were my second language. But once I stopped practicing it, I ended up forgetting how to even define the simplest of things like variables.
So looking at the language for Flash Lite brought back some memories, but I already knew that some of the designs which I might want to develop will not come to fruition due to my lack of knowledge (and to some extent, motivation).
So today we had some basic code broken down to us. I found quite thorny to wade my way through all the lines, I figured out what the line was doing more or less, I just couldn’t understand the lingo. I eventually managed to work through the code to understand its core task, all it was simply doing was listening out for any key presses and then taking the user back/forth to the next screen.
// set up
fscommand2("FullScreen", "true");
status = fscommand2("SetSoftKeys", "left", "right");
doStart();
// trap key presses
var globalKeyListener:Object = new Object();
globalKeyListener.onKeyDown = trapKeyDown;
function trapKeyDown():Void {
var keyCode = Key.getCode();
var theFrame = _currentFrame;
trace(keyCode +" / "+theFrame);
switch (keyCode) {
case ExtendedKey.SOFT1 :
switch (theFrame) {
case 2 :
doGame();
break;
case 3 :
doStart();
break;
case 4 :
doStart();
break;
case 5 :
doStart();
}
break;
case ExtendedKey.SOFT2 :
switch (theFrame) {
case 2 :
doExit();
break;
case 3 :
doExit();
break;
case 4 :
doBye();
break;
}
}
}
Key.addListener(globalKeyListener);
function doStart():Void {
gotoAndStop("start");
trace("doStart");
}
function doGame():Void {
gotoAndStop("game");
trace("doGame");
}
function doExit():Void {
gotoAndStop("exit");
trace("doExit");
}
function doBye():Void {
gotoAndStop("bye");
trace ("doBye");
}
My test screens using the code above
I think over the next few days I will concentrate on deciphering the above piece of code till I become a little bit more familiar with the lingo.
