Moo - The development of the second game of my course

This post will discuss and outline the development of the second game of the first year on the course. The team consisted of a total of 4 members and there were two briefs to choose from. One was to create a game that could be used in social networking and the other involved designing a game with viral marketing in mind.

Initial Ideas

Initially I went with the social networking game idea because although I do not play them often I did understand that the connectivity with friends make these games intriguing and added another level of interactivity t them with team work, giving friends gifts, making new friends and the way the turns may take up to a few days instead of the usual instantaneous feedback games usually supply. An example is Farmville, which I played for about two months a few years ago, I really enjoyed the competition and the cooperation the game allowed and how you had to wait a wait for the crops to grow, allowing the player to return to the game later and see how things have changed;  sometimes not in your favour; crops die if not picked soon enough.

However, the viral marketing brief allowed the team to make a quirky and unique game with the sole player's experience in mind. We picked this brief and were on our way with brain storming.
For some strange, or brilliant, reason, we wanted to go with a food theme and our love for ice cream carved the way for our viral marketing game.

The game was based on making ice cream, selecting flavours as shown and making sure the correct ones are chosen and in the right order. Our aim, as per he Game Design Document, was:

We plan to create a game that could be used be used by an ice cream company to promote their product virally, we plan to do this by making the game challenging so they are played again and recommended to friends. Also, we will use quirky graphics to portray the tone that some ice cream companies utilise to appeal to a certain audience. While some companies use muted colours, sophisticated graphics, images and typography to appeal to a mature audience, our game will depict a more colourful, vibrant and fun brand, also exploiting the association of ice cream being comfort food to one audience as opposed to a fancy dessert to another audience.

The High Level Concept

There are a bunch of sad and depressed people who need cheering up, the player will have to utilise their ice-cream making skills and more importantly timing to whip up a perfect freshly-made ice cream for the freshly-dumped customers.
Players have to pump the right ingredients in ice cream cups on an increasingly speedy conveyor belt. 

Verbs

And the verbs used to describe the actions taken by the player and the game were as follows:

Players have to time the positioning of the ice cream cups and funnels and click on the right ingredient in order to have it drop into the cup. Shape/colour recognition will be used to get the right ingredients in the cup. If the player misses the cup, the ingredients will fall onto the conveyor belt and jam it, a cleaner will have to be dispatched to clean it up. The conveyor belt’s speed will also increase, so ingredients will have to be matched and picked faster.

Mood board

Above was our moo board, spelled deliberately wrong in order to convey the theme of ice cream and cows! We thought that was really clever and decided to name our game Moo!

The moo board portrayed the basic ideas we were to implement in our game; a timer, a conveyor belt, flaours of ice cream and vending machines dispensing different ingredients. The colours uses allow reflect the theme we were aiming for; quirky and vibrant, this was to keep the idea fresh and bold and striking.

Paper Prototyping the Game

Above is our paper prototype we used to see if our game had a legitimate challenge and if there were any loop holes and inconsistancies in the game. There were only 4 flavours available for this prototype. One person, acting as the computer, would pulled the paper conveyor with the contaienrs on it and the player would simply tap their finger on the flavour for it to be selected, making sure the container was below that particular machine. The first container only has two flavours while the second one has three, this shows the incrementing challenge in the game so the player is learning and being challenged throughout.

What we learned from paper prototyping

1. The ingredients need to clearly convey the flavours, some people will match the colours together and some will not, so they have to be clearly defined.
2. The challenge has to increase, we need to consider speeding up the conveyer belt too in order to keep the game dynamic.
3. Negative and positive feedback is essential so we need to make sure we give the player information when they succeed and fail, so sound effects and animations or visuals indicating the feedback will be super useful.

Finite State Machines

The finite state machines were detailed enough for the programmer to refer to when coding, the ice cream cups states are indicated and the chart shows decisions and options available and the actions when the decision are taken.

The conveyor belt is shown to have a 'broken' state which did not make it into the completed game, this feature involved the conveyor breaking when too many ingredients missed the containers and fell on the conveyor belt; consequently jamming it. The player would them have to press a button on screen in order to free it, taking up valuable time where they could be making ice creams. his was a good example of negative feedback, however, time constraints meant this could not be implemented.

Storyboards

I really enjpy drawing up the storyboards and this game with its unique use of space was an interesting one to visualise and draw and soon I was an expert at drawing various ingredients and flavours! The art style carried onto the finished game, with added colour and vibrancy too.

Below is a depiction of good and bad play, the player here drops some flavours on the conveyor belt. The storyboard shows what happens, ingredients are seen on the belt. However, it does not show that ingredients have actually gone into the cup which showed us that we need to have clear containers, this was basic stuff but was overlooked, teaching us to look at the fundamentals first before stepping to the more difficult and complex matters.

The defeat conditions involve using the wrong ingredients a number of times creating the wrong ice creams.

Below was another initial idea which let the player control the conveyor belt and dispensers. The left and right buttons would control the conveyor and the space bar would dispense the one flavour available. this idea implemented timing and space. In the end we took that control from the player which actually increased the challenge in a natural way and caused the player to rush to find the correct ingredient and select it in time as the container travels below.

Below is a storyboard which involves some grim ideas about food health standards, there were to be spiders which which would fall into the ice cream containers, the player had to dodge these by not moving forward when a spider was seen descending. Sludge had to be dodged too, it gave the game an interesting but unneeded dynamic. We removed it because it was not appropriate for the age group and mainly for the theme, this would make it less quirky and jovial.

Below, a basic portrayal of how the final idea would be used and how much choice the player has and how timing is crucial. It also shows the ingredients falling into the container, a basic but important visual for the player.

Below is a storyboard showing how the conveyor belt can become jammed. Once the player drops a certain amount of ingredients on the belt, the belt will jam and the player will need to hit a button on screen so a worker can come along and clear it all away to get the belt restarted. This idea was scrapped, however it would be a great way to negatively reinforce ideas so players learn.

This storyboard shows the basics of the input and output which was scrapped, now more than one ingredient is available. This idea was mainly about timing as well as recognition and selection.

The Final Game Screen Shots

Below, we can see the player has not successfully made the ice cream and has dropped a lot of the ingredients onto the conveyor. This will affect the player's overall score.

The vibrant and bold colours and clear ingredient images make the game a visual feast and if it can make players want an ice cream in reality*, it has technically achieved two things, the viral marketing and making the player continue to play the game!
*Unless the player does not like ice cream!

The idea of having the factory be in a field with grazing cows in the background was the artists idea, we loved how it looked and immediately used it, it lent an airy, free and peaceful glow to the game which would not have been possible if the interior and background was a grey warehouse setting.

The Termination Condition Screens

To reflect the game's theme throughout the game, we decided to make the ending screens humorous with the cow complaining about the icecream if you lose and the cow complimenting you if the player succeeds. The visuals were simple and quirky and got the theme across nicely and effectively.

The Title Screen and Menu

The title screen reflected the game's theme before the player jumps into the game, its funny and simple and the 'Help' button is integrated into the setting of fields and hills. The minimal colour keeps the visuals striking and aesthetically pleasing.

Conclusion and Evaluation

The game is really polished, looks great, plays great, I am really happy with this game because it reflects the themes we wanted it to and is challenging and keeps the players on their toes. Th game has humour and is quirky and would be effective as a tool of viral marketing as it would be a talking point. The potential of the game means it could be re-wrapped for different themes, so it could be about breaking up and having the ice cream serve as comfort food. Or it could be aimed at children with the aim to create new flavours of ice creams.

We were all pleased with the finished game and believe it follows the brief and keeps the players engaged with the increasing and dynamic challenge.

Lessons Learned

To clearly label the challenge and see if it is challenging enough by making a paper prototype and even a digital prototype if the former does not properly demonstrate it.

To make sure there is enough time to implement all features and to manage it more effectively by handing out tasks and co-operating with assets and content so programmers are given finalised art work instead of lots of placeholders.

To effectively play test the game to find loop holes and see what peole think of the game and see how it can be improved.

Icarus Meltdown - development - The first game of my course

Icarus Meltdown was the first game I ever made. And the rest is history!

We were put into a team by our tutor to get ourselves into the design process quickly.Our team consisted of a total of 3 people.

Before we were put into teams, the tutor went through the course structure and then a description of the design process. In words it seemed quite fun, but in practice it was a whole other ball game. We learned this when we were given the brief, which was to create a game based on a folklore or mythology using Flash Action Script 2.

It was interesting seeing how a challenge can be un-challenging, we had to imagine the scenarios in our heads to see if they would make the player struggle because without it, the player would get bored, a big no-no for any game.

Our first action was to remember all the tales we were told as kids at home and school and supplemented these with research on the internet. We focused on Icarus and Daedalus’ tragic journey of flight because it was dynamic and there was a clear motive for the player too.

After finding a myth, we needed to set out how we would make it into a game. Who would you play as? What would the screen look like? What will the challenge be? Will the player be above to move left and right? What’s the aim?

It seemed the best way to figure it out was to just talk. We just threw out ideas and if we liked it we would elaborate, if we didn't we would leave it. The idea was formed when we decided that the player, Icarus, would have to dodge sun rays. Now since light from the Sun travels at around 300,000km per second at a constant rate in vacuum, it would seem we would have to refute what scientists like Einstein and Ole Romer theorised, and taught us, in order to make the challenge in our game viable. So the player, we decided, would have to dodge sun rays by flying through the thinnest point in the light ray. 

Apologies to astronomers and physicists, I feel your pain, but, Icarus needs to escape Crete! And we all know he needs all the help he can get, what with the wax holding his feathers together.

So we had established a challenge; to dodge sun rays, but how? The player choice was our next decision, but before we could go about that, we needed to work out how the screen would be composed.

One decision was a bird’s eye view, with the sun in the middle and Icarus flying around it through the thinnest part of the sun ray.

 

The image above is a snapshot of ideas we went through, one idea was to have the player control the Sun and have to aim solar flares at little Icarus' and Daedalus', with extra points given if the latter is destroyed. However this didn't ring entirely true with the myth and it seemed that the player would be more invested in Icarus as he tries to dodge the rays than if the player was the Sun. The human motive will make the player root for the little character on screen.

Another idea was for the Sun be in the center of the screen, this way the player would see the upcoming rays of light and this would decrease the challenge as not knowing where the gap is would constitute a challenge. The idea was scrapped and we thought about only showing a segment of the Sun.

 Above is the storyboard depicting the areas in which the player can safely traverse through the rays of sunlight. Bad play was defined as flying through a thick part of light and other components were added like rain clouds which made you lose feathers from a finite amount in the counter, this was basically the health counter/gauge. One idea was to include clouds which would protect you for a moment, however it did not make it into the final game as this was too beneficial for the player and reduced that all-important challenge.

The above storyboard shows a new feature in the form of a flock of birds, once flown through, Icarus will grab as many feathers and this will replenish his feather counter, call it Grand Theft Feather if you will.

Now that we'd figured out the screen composition, this left us with another important decision, how will the player control Icarus? One option was when the player presses down on the keyboard, Icarus moves down x amount, same for up. Now we left out left and right because the sun rays would move and give the impression of progression in the game.

While moving x amounts up and down worked, it seemed a bit stiff and not dynamic enough. Also, it would decrease the challenge if the player had total control, so we instead used a mouse click which pushes Icarus up. Introducing gravity as a state meant that the player would always be falling, so a mouse click would make them rise again. So now we had this tactile and dynamic mechanic which stayed true to the myth, Icarus would have been aware he only had a certain and finite amount of lift.

Now for some screen shots, below, Icarus is getting ready for some feather stealing which will increase his feather count. Other things he can interact with is lightning bolts which electrocute him and decrease his feather count, flying into rain clouds will make his height of ascent decrease for a while so the player cannot fly up for as long. Winds will make Icarus lose feathers while he spins out of control from the buffeting breeze.

The art style is vibrant and simple due to the myth being so referenced we decided to simplify the message. Below, the player has led Icarus into a sun ray and the importance of negative feedback is shown, the character looks fried and hurt and shows the player some of their health gauge has decreased. This lesson is important because if the player is unaware their actions have any consequences then they will be confused and this will affect their enjoyment of the game. Consequences of actions are essential and getting other people to play test the game is incredibly useful as it lets neutral eyes tell you what they are seeing, and sometimes, not seeing.

This screen shot below shows a dying Icarus falling into the ocean. Here, Icarus was defeated by the player simply flying too high and into the Sun, incorrect but a very important feature because it is negative feedback for the players actions. His wings have disappeared and his face is red, poor Icarus, but luckily for this reincarnation, he can re-spawn and try again, the power of games!

Speaking of creative leeway, we decided to let the player win the game, even though in the myth he never really escapes form King Minos in Crete. After a set amount of distance is covered does the player win the game.

One of the big issues we had was with the coding, Icarus would seem to go through all his animations of he hit anything. For example, if he hit a sun ray, the player would see him stealing feathers, being blown about by wind, dying and being electrocuted. The issue was solved by having an intermediary state change be used as a timer for how long he should be shown being electrocuted by lightening or stealing feathers. The problem took about 4 lessons over 2 weeks to solve, but it was great knowing we finally had fixed it because it was at its finishing stages of development. 

Below is the title page, the first title page I ever made for a playable game. Looking back as a third year student, I can say I have improved since then and can see the negatives and positives of the screen below. I like the simplicity of it all, it can be easy to fill up all available space on screen. However, the logo is too compressed and looks it compared to the rest of the art and the colours don't work too well together, especially the red blocky text.

I enjoyed making our game, it was a great experience because we were all in the same boat and approached the game from different angels so it was interesting communicating my ideas, although this was difficult because it can be nerve-racking having your ideas shot down. It also taught me a really important lesson - that sometimes you have to sacrifice ideas even if you nurtured them and storyboarded them, if they have to go, they have to go.

Communication was another lesson I learned and am still learning and improving upon. I learned that by doing a quick story board of an idea it is easier for me to describe what I trying to communicate. My art work has improved and I am always looking an unique visual styles we can use to tell our story, it's exciting being able to change style for each project as it keeps the visual style fresh and exciting and more importantly it keeps the artists on their toes.

Also, this was the start of something awesome - I realised I really enjoyed drawing up storyboards, it wasn't a totally artistic endeavour as it was about description and visually explaining things. Ever since, I have done the storyboards for all other games and have enjoyed the challenge of describing complicated things with the minimal of fuss and in an efficient way.

Talking about the development for my first game almost two years after I made it has definitely allowed me to look back at the work with an unbiased eye. As they say, retrospect is 20/20! I will have to look back on 'Fun Guy' and 'Taking Care of Buzziness' in a few years time to see how far I have and haven't come and what I need to improve on and see what I consistently do and don't do.

I may even make a sequel!

Taking Care of Buzziness - The fourth game of my course

Developing 'Taking Care of Buzziness'

The second game of my second year had to follow the brief of being a game with emergent properties. So the first thing I did was borrow a book by Steven Johnson called 'Emergence: The Connected Lives of Ants, Brains, Cities and Software' from the university library. It was surprisingly readable for a book about complex self organising systems. I bought my own copy shortly afterwards to read over the holidays and it was really thought provoking, at first I had difficulty understanding the concept because it didn't seem tangible, but this book gave great examples of emergence and how it works.

Steven Johnson, in Emergence (2001), states that emergent systems;

'Solve problems by drawing in masses of relatively stupid elements, rather than a single, intelligent “executive branch.” They are bottom-up systems, not top-down. They get their smarts from below…. The movement from low-level rules to higher-level sophistication is what we call emergence (p.18)'.

In his book, he outlines the historical phases of the study of emergence, the first phase was when ‘inquiring minds struggled to understand the forces of self-organization without realising what they were up against’. The second phase saw ‘certain sectors of the scientific community… see self-organization as a problem that transcended local disciplines and set out to solve that problem’. The third wave sees that we use emergence and actively set about to have it help our lives through city planning and software.

The Initial Idea

Our team’s original idea was about a worker bee having to sort through different types of pollen as other bees dropped them into the bee hive. The trajectory of the bouncing pollen would pose a challenge and the player would have to negotiate the angles and try to bounce them into the correct pollen tube.

The above storyboard shows the simple mechanic of the trajectory of the pollen as it bounces off the bee. It describes it falling into the right tube, showing positive feedback and also demonstrates negative feedback by showing what happens when it falls into the wrong tube. Using red for a symbolism of failure and green for success is simple yet effective and is hardwired into our brains, its semiotics are plain and universal.

  

However, a critique showed that it didn’t pose much of a challenge and more importantly it didn’t follow the brief, so we decided to focus on the concept on ‘growth’. It was after our research when we really began developing our new idea, we looked at games that employed emergence as a primary tool and games where it was totally spontaneous and a surprise to even the developers. 

High Level Concept for our new game

The High Level Concept of our new idea was:

As a dedicated worker bee, work against the clock of nature to nurture grubs into bees, paying attention to their needs and prioritising between nursery, primary school and high school grubs!

Moodboard

The aim is to feed the grubs and transfer them to bigger honey combs as they grow, the first is the nursery combs, the second is the primary combs and the last is the high school comb. We agreed to name them after human concepts of education so it would be approachable for players.

Goals

Short term – keep the grubs happy by feeding them and moving them when they become too big for the honeycomb.

Medium term – Make sure honeycomb spaces are not ruined and filled with dead grubs.

Long term – Sustain the optimum conditions and make sure a lot of grubs grow into young bees.

Challenges

·     Worker bees take time to reach a grub to feed it.

·     Grubs will be needy and will become hungry quickly.

·     Grown grubs need to be moved to a bigger honeycomb.

·     There may be several grown grubs which are suffocating and need to be moved.

Increasing the Challenge 

·    

     More eggs are laid so player must be aware of the environment as new grubs are being born.

·    Dead grubs occupy space so there is less space for potential new grubs to grow.

Strategies and Tactics

 Remember which grubs have been fed once before.

·    Sacrifice a grub which has not been fed, in order to feed a grown one in order to get it to the next honeycomb.

·    Click the nearest worker bee to the grub.

Termination Conditions

·    WIN – if a certain amount of grubs have grown into little bees and left the high school honeycombs, the player wins. A screen at the end of the game conveys the positive feedback with a formation of bees flying happily over a park that has an abundance of blooming flowers.

·    LOSE – if the number of grubs have grown into little bees is not enough, then player loses the game. A screen at the end of the game depicts the negative feedback by showing a few bees flying, teary eyed, over a grey and desolate park landscape. 

Storyboards

Easily my favourite part of the conceptualisation of the game, visually explaining how the player will interact with our game and possible ways they could lose and how they can defeat the challenge and reach the goals.

The selection of story boards below show what the player has to do in order to win the game. It also includes element of incorrect play, so when coding, we’ll know how the negative feedback will work and look.

The first set of storyboards describe how the player will use the interface, here we have the XBOX controller and what the buttons will do.


So once a grub is fed, it grows and after a while it will get stuck in its honeycomb block, suffocating inside. The player will have to drag it to the next honeycomb. If it does not, the grub will die inside the honeycomb, making that space void, so no other grub can be placed their.

Once the player clicks on a hungry grub, a worker bee would fly along to feed it, this took a certain amount of time so posed a challenge, only a certain amount of grubs could be fed at once, so extremely hungry bees would have to be fed first, or even sacrificed.

As the game progresses, its challenge increments, leaving the player with a bewildering amount of grubs to take care of. The player will need to carefully pick which ones to feed first as the worker bees take time to get food and deliver it to the baby bee.

The above storyboard shows how void spaces are created by dead grubs. This is negative feedback for the actions or omission of the player.

Below the nursery grub is ready to be moved, however another grub is getting hungry, so here the player chooses to feed the younger grub, this could be seen as a bad tactic as the older grub has more of a chance of becoming a grown bee if feeding attentions are focused on it. The player can choose to use these strategies in the game, they will learn these by simply playing the game and seeing what happens and how they can make best use of their choices and options. 

Finite State Machines

The finite state machines for the worker bees and the grubs described the details of the states and their possible choices. It works like a flowchart and describes how the game can be won and lost. While the worker bee's state machine was simple, the grub's state machine was more complex and required a few re-drafts in order to iron out exactly how things would happen. We had to ask ourselves 'what happens if you have already fed it once?' and we'd ask our selves the same question after another action has happened. This activity allowed us to gain a better understanding of the system of our game from a logical and technical point of view.

Concept Art

  

Another one of my favourite parts of design, the concept art! I had (reasonably) free reign over the design, although I did take note of the restraints of time, we had about 4 weeks of produce the game, and the sizes and proportions of the objects in the game space. This was after we learned about the importance of sizing from our old game: Fun Guy. Instead of resizing a whole bunch of sprites, we decided to stick to a decided number.

I first began with a google search of 'bees', I hadn't really drawn bees before, other than little dots with buzzing blurred wings, but now I knew the body parts of the insects, you learn something new everyday!

The first thing I noticed was that while our game had 3 different types of grubs, I couldn't rely on bee images to create the different looks of a nursery, primary and high school grub. So I decided to use a grub as a reference image for the first (nursery) sprite and then use a bee with baby-ish features - like big eyes.

Time Plan

As this was a 'Work Based Learning' project, we had to demonstrate professionalism with our time with management skills. Each team member worked together to write down a time plan. It wasn't totally an individual task as we had to co-ordinate what would be done while something else was being done. This involved thinking about the process carefully and making decisions on time and hitches. Some task were prioritised while some were put on back burners. As we went from designers after creating the Game Design Document, we set about getting back into our old technical roles as coders or artists and jumped into the tasks, laying down the foundations of the game space and making the characters.

Below is my time plan. The biggest difference between this game's development and the ones before is that I was determined not to give my team mates too much place holder art work. I felt that rewriting the images and animations in the game to accommodate new sprites would increase their work load and ruin the flow of our development. I kept the placeholder art to a minimum and polished the images before they were transferred to the coders.

I finished the sprites early as I got into the flow of drawing out the animations so I could spend more time on resizing them and pacing them into sprite sheets. This involved some time hitches but luckily it was recoverable and I could quickly start on the screens like the main menu and the win/lose screens.

First sprites and character art - Worker bee

 
This was one of the first bits of art I made, I gave it to my team mate who then had it fly around on screen, this bee would lay eggs in the nursery honey comb and another version of it would feed bees once you clicked on them.

The above second picture was the final art work. Upon a team mate's idea, we decided to give the worker bees a hard hat and visibility vest to reinforce their job role. I think it was quite quirky and fun seeing them float on to the honey comb in their outfits.



Above is a snap shot of the worker bee's development from ordinary bee to its new design. Also, we felt that the new design would resonate better with the players as it added humour.



The picture above is the worker bee with food, I had animated the legs to move and sway slightly as they flew.

The Nursery Grub
 
The first look I drew was the happy emotion. The big eyes and hair was added to allow me to show emotion through anchorage, the player will see a bay-ish grub and will want to help it, seeing it cry will reinforce their actions to want to feed it. However, I could not use big eyes for the next grubs (primary) as I still needed to show that they had grown, so I had to think about this before creating those sprites shortly after the nursery sprites.



The suffocating grub's head was animated to shake from side to side to convey distress. Bright red colour would also act as a flag, warning players that they were about to lose a grub.



Above is the complete set of nursery grubs, one set has not been fed, while the other has, and is slightly bigger to show they have eaten. The dead grubs are grey and upside down while the falling grubs are titled to show they are falling.

The Egg Sprite

The egg sprite was the first thing the players would see moving on the screen, so it was quite important that it looked consistent to how the other sprites and game-objects moved. We had already discussed the amount of animation there would be due to time constraints, so we didn't want a flourish of animation at the start and then have choppy animations at the busy end of the development pipeline. Simplified animations were the way here, with cute movements and facial expressions.


The giant egg was made then resized and very bold cracks for the animation, with the little grub making its first appearance. We had to take frames out of the animation because it was taking too long for it to open and once they were removed, it looks like quirky as the grub appeared, with bits of shell disappearing!

The Primary Grubs

I had to make the grub look older, so I got rid of the grub's silvery body and used a fuzzy outline of an adult bee with small and chubby limbs to make it look younger.

Above is a snapshot of how I created its body separately in order to animate it suffocating. It also made it easier as the body stayed the same while the face changed, and the antennae turned into eyebrows, which was great for conveying emotions, as I no longer had giant eyes to shoe sadness, I used the antennae to show it.


Above are all the primary grubs, I believe the antennae worked well to show anger, sadness and distress. However, I had to think carefully about how I would create the next grubs, as the eyes would need to get smaller and the antennae would be longer and limbs less chubby and more threatening looking.

The High School Grubs

 

After elongating the eyes so it looked less like a baby bee, it made sense that it almost resembled the worker bees. The change and growth followed the brief in a superficial manner, while the newly born grubs being delivered to the nursery honeycomb followed the brief more functionally.
The bee was drawn bigger, with bigger limbs and antennae with prominent faces and features like the mouth.
The first image above has a scan of my hand drawn sketch in the left corner which I used as my initial template.
The second image shows the polarity of how the antennae could convey emotion, from surprised to really sad.


Above, the final sprites for the high school grubs.

Bonus Concept Art

And this is just a bit of quick art that depicts our team, although not mentioned in our time plan, I threw it together and our team had a little giggle at it!


The Game Space

Compared to our moodboard, where the nursery, primary and high school honey combs filled the screens, the final idea was to have gaps in between the three stages to show a natural progression.



Taking the advice of our tutor, I strayed away from using black outlines. I used a light brown which melded in with the orange and yellow colour of the honey combs. I used chalk pastels on paper, scanned them and then used a digital stencil to place the colour in the hex grid of the game space.



Above is a total of 5 pages of different colour palettes, I focused on brown, yellow and orange and when placing them in the hex grid I wanted to convey shading so it would seem the player is looking at something that is inside a bee hive.

Below is the final screen of the background and game space. Since I scanned the snippets at 300 dpi I was able to use these at their original size as the background. I modified its saturation levels to make it seem like it was in the distance.



Screens

I had to make an important decision with the screens because we were on our second to last week before our game deadline, so I needed to work effectively and quickly. Should I make them on Paint and Photoshop or by hand? At the time I was a traditional artist and felt more comfortable with a pencil and paper, now however I feel comfortable a the helm of a graphics tablet!
At that time, I assessed that I would be able to draw the main assets by hand. I set about finding my sketchbook and thought carefully about how I would convey success and failure in our game.



I used colouring pencils and a fine liner to bring out the details to create this depressing dilapidated field of dying flowers and grass.

With Photoshop, I added a modified crying bee onto the foreground and a day dream of what could have been if the player had succeeded.

Here is the final screen for the win screen. I decided on placing the happy bees in a Red Arrows type formation to convey that the bees have a military structure just to show they are proud that they are doing their jobs, just a little something to add some facets to our game, with meaning and semiotics, note: I'd been reading John Berger's excellent book 'The Ways of Seeing' and 'About Looking' at the time, and analysing adverts for an essay, so I took these into careful consideration when designing for our game. The bright palette conveyed success in a simple and aesthetic way.

The Help screen was in the style of a school chalk board to go with the them of growth and school and childhood. As we were using an XBOX controller for our input, I drew out the specific buttons in their colours for the instructions.

Adding a teacher bee and some diagrams wrapped up the help screen.

Or so we thought...

The simpleness of the games characters could have confused players as to what was happening, so we decided that a help in hand was always nice, just in case they needed it, so another help screen was drafted, which described the three important states of the baby bees: Hunger, distress and happiness.

Using provoking colours to describe the three states without words was preferable compared to words as it was streamlined and text light and really showed we could visually describe things too.

I used the same states from each grub to show that these were the emotions the player has to watch out for. I quite liked the coherence of the screen and its composition, a clear distinction between each of the three ages of grubs, showing a progression and what the player was aiming for, grown bees ready to leave the nest.

The Main Menu

I created the main menu last, it began as a sketch in the corner of my book, it was a simple and aesthetic composition of white chalk on black with splashes of yellow to really throw the 'bee' theme at the player. The help button was faded in comparison to the play button because although it was important, once the player had jumped onto the learning curve, they would play it again (hopefully!) and just want to jump back into the game, so the brighter yellow play button would be their target. We hoped simple things like not irritating the player with having to press 'back' would make the entire game experience more enjoyable.

Creating the title was a game in itself, it took a while but we came up with 'Taking Care of Buzziness' and felt it described the 'business' aspect of managing the grubs, while the 'buzz' in the title was a pun, and everyone loves puns!

Buttons and Cursor

I thought carefully about the buttons because I wanted to keep with the theme of bees and felt that it was best to go with black and yellow and hexagons. While it did not seem original and unique at the time, when I drew them up, we quite liked the simplicity of them. Although, I would have liked to tried a funkier approach, maybe with animations for feedback to show the button has been pressed.

An idea was to show what button can be pressed when the cursor hover over a grub, we felt it would help the player. Although, at the time of development, we changed what button did. This was due to a criticism of the control scheme, so we decided it would be beneficial to our time if I draft up all possible button presses, A, B, X and Y. Only the main plain cursor, A and X were used in the finished game.