In retrospect, I cannot say I am all that happy with what I produced. I feel as though I could have done better with more time, but that is due to my bad time management and organisation as I put more focus than perhaps necessary into other modules that unfortunately required further learning. I definitely underestimated the size and scale of my project, and I only really realised it after doing the helpful artbook plan how much I needed to do and how little time I really had to do it in. I spent too long in research and battling my own skill level when I should have spent the time drawing, however I have proven at least to myself that I can work fast and efficiently when I am focused, and I have definitely improved technically from the start of the project, as I believe is very evident in my human faces. A great testament to this is the first and last iteration of Thmei’s final pose.
In total, I come away from the project at least far better educated about myself and the conception process, and am aware of the roadmap ahead to be able to further my skill for a professional environment.
Realising the scope of my project was too large for the time remaining, I decided to cut it down to something more manageable, but already knew I would and wanted to put more focus into the characters. I sketched the final poses for all nine of the planned characters, and did all their facial constructs for them as well as an outfit base in time for the critical feedback session.
The feedback was more positive this time and, especially by showing the re-draw of Thmei’s final pose, my improvement on human faces and expressions had certainly improved. The main critical feedback of this was of two of the characters’ final poses – the merc and the machinist. The merc one was seen as a bit stiff and the leaning on black space didn’t work so well, so I changed his to a more powerful pose to show off his brawling nature better. The machinist’s pose was considered too bold for the type of character, so I sketched up three ideas based on this feedback to make him seem more recluse and hunched over. I went with the third pose as it showed that correct nature but still kept his body visible for the outfit details.
Merc Rework:
Machinist Rework:
I then went through all the outfits for the characters, using only one colour to give the outfits a visible base over the basic pose to save time. As I went through I found the process easier, and was able to pick the elements I liked best and sketch them straight onto each character’s final pose. After that came a slightly more repetitive task, which was linearting each character ready for colours. To add a bit of extra life to characters I like to use lineart with tapering, which involves thicker lineart where lines meet, and is slightly more time consuming but I feel gives a more rewarding result.
The final step after this, with the characters, was putting in the base colours and going through any I had time for shading. I did the shading test on Thmei, and found time to shade the merc character as well, which was at least two of the more important characters done. I did have plans to do back views for every character as well, and had them all sketched, but due to a lack of time, I only completed the ones for the more important characters such as Thmei, the merc, the machinist and the A.I.
In regards to finishing off the environments, regrettably I put far more focus into ensuring the characters were where I wanted them to be that the environments suffered. I only had time to fully render and complete one environment piece, which showed the merc character doing suspicious activities on a night. I played around a lot with light sources and colours to get the right feel for the picture, though I feel with more time it could have been far better refined.
My final step overall, before returning to do any additional polish work I felt I had time for, was annotating the artbook to ensure everything made sense and to meet another of my project’s intended outcome.
With putting more dedication into learning for another module, I found time towards the next feedback session to be fast approaching. In time for this I managed to do full-body mock ups of the remaining to be designed characters to show what direction I might be going for with them, and this included the A.I, Thmei’s grandfather, a machine-enthusiastic helper, the Pharaoh’s wife and the Pharaoh’s vizier. These were the characters I had determined to have more individual personalities and contributing roles to the planned rough narrative. The remainder of the characters I had planned to be more general, and was intending to design what different social classes might look like including the royal scientists and royal guards. I also made a list of the potential environments I could do.
Initial character mock-ups:
The feedback this time was similar to before, in that the humans lacked expression in their design. I went back to a different route this time, as I already had the characters determined, and worked once more on just human faces themselves. By sitting down and just drawing human face after human face, working both from other artist images supplied in tutorials or from photographs, and I felt I made good progress with this. Something else I picked up from a fellow student though was doing a rough plan for the pages of the artbook in my project, which turned out to be very useful in focussing my direction and highlighting exactly what I needed to do. It finally let me be able to realise the full scope of my project, if I wanted to achieve a maximum mark that is, so it was a bit ambitious.
The full artbook plan:
Practising human faces:
Regarding environments, I struggled quite a bit. I did very rough sketches of a couple of planned environments, but I found myself struggling with specific compositions and especially on perspective. I turned to Unreal Engine to ‘build’ these environments instead ready for future paint overs, using just the basic brush tools available. This felt a much easier way to get the environment idea from my head and into something visual and, even though it was just boxes, it worked for me.
Protagonist’s room idea 1:
Protagonist’s room idea 2:
Mock-up of a potential street view, outside a shop:
With the necessary research in place, I spent time working on the protagonist of the cyberpunk story first, and used her to work out a skin colour test for what Ancient Egyptians skin tones might be like, which I figured from doing research into how present day Egyptians looked like and from my previous research. I also did shading tests on her skin tone and eyes, and on the few hairstyles I came up with. I already had a good idea in my head of what I wanted her to look like, so I felt I didn’t have to do many tests with her hair before I had a solid picture down. I then moved onto how her first outfit, by outlining a basic pose to design upon then drawing an outfit on top. With this done I felt I should explore a couple of other characters before the first progress presentation, and managed to finish the preliminaries on the Pharaoh and the A.I as well to show.
The feedback from the presentation stated that my human drawing skills had improved and the quick story was a good idea to aid in the design direction, however my humans lacked emotion or expression, so I needed to put something behind them to improve upon that. Whilst I now had a story I had no character development, so I went back into a text document and developed character biographies using bullet points for each character I had planned, adding more whenever I thought of it to better develop the characters. Going forward, I spent time trying to sketch out some of this personality as I was trying to design them, adding better expressions for example when designing faces and hair. This became apparent first in the designs of the merc character. I also went back to Thmei and finished designing her outfits, asking friends which they felt worked best and mixing favourite outfits together to produce a better result.
The feedback on the merc character asked that the he show off his robot arm instead of hiding them under a sleeve as something to be proud of and show off the more cyberpunk nature I was going for. I decided from this to make both his arms robotic and proceeded to sketch design ideas for them, whilst at the same time trying to keep the bend of the arm in mind, hence why there are two positions for the design, one bent and one straight.
I realised that I didn’t see why all fifteen of my characters needed to be human, and as cats were highly regarded in Ancient Egypt, it made sense for them still to be so in my created world. I decided then to give my protagonist, whom I’d named Thmei (after the goddess of truth, justice and morality), a cat companion. I looked into what types of cats could have been around in Ancient Egypt and proceeded to do a study into cat anatomy to improve my drawing ability on it. I found the three main cat breeds of Egypt to be Egyptian Mau, Abyssinian or Sphynx, and decided to go with the Egyptian Mau as it was the most common to be found and had an interesting fur pattern to try and replicate.
Despite all my research into artists and themes, I found myself a little stumped early on with the direction of my concepts. After a little revision, I found the cause of this to be due to a lack of context to the world I was trying to concept, and as such I could create no context behind the characters and settings. To rectify this, I went back into my research again to create a basic plot which fits the project theme and creates enough context needed for the concept work to be both interesting and make sense.
One of the main ways in which this world would be identifiable as cyberpunk in genre is its story, so the first thing I looked into was what made a story particularly cyberpunk in nature whilst at the same time trying to avoid a simple re-telling of a story that has already been written before. One interesting article I came across when trying to decipher the cyberpunk genre in writing was that posted by one C.T. Phipps on blogspot, where they explore in detail what they believe it means for material to be cyberpunk whilst citing some key Cyberpunk works, which I then also looked at to add to my cyberpunk visual references folder.
Not being a narrative designer, I was only intended to create a very basic narrative to help me create the environment of the project from the correct perspective. The most useful website for came from Tvtropes, which had a good comprehensive list of what is associated with a cyberpunk story and setting, as well as dividing the information into sections of what is ‘necessary’, what could be considered, and what to avoid when creating the narrative. The page was presented in a clean and easy to read manner as well, so I did not have to go through a wall of text to be able to find relevant information. It also had a list of cyberpunk material to look into for further reading, and even hinted at possible styles that could be considered within a cyberpunk universe, such as film-noir used in Blade Runner, which I had not considered for myself. The only downside to this source of information however was that it was just one source telling me which direction to go in with my world-building, although it was satisfactory in this manner for my basic needs.
Thumbnail illustrations:
From this, I drew up some small thumbnails of illustrations alluding to the potential narrative, and adapted a basic story as follows:
• The Pharaoh is a very old man clinging to life on a support machine. He is plugged into an A.I to control his civilisation whilst in this state.
• The protagonist is a fallen engineer/scientist (for doing something forbidden) who had a part in the A.I’s creation. The A.I enlists their help in wanting to be free of Pharaoh and become its own ‘God’ of the civilisation.
• They cross paths with a contractual mercenary-type character who has their own reasons to have Pharaoh overthrown.
• The mercenary turns out to be Pharaoh’s heir and wants to take over.
• The engineer must choose to follow the dangerous mercenary as Pharaoh, who could make the current dystopia worse, or choose the inhuman and logic-driven A.I as Pharaoh.
• The story ends with the protagonist having to make a choice between the lesser of two evils.
I felt this narrative suited my needs perfectly, and I felt more invested in my own work especially as it now had better direction.
Something else I came across whilst constructing research was the game ‘Remember Me’, which was an action-adventure sci-fi set in a Neo-Paris, and supported a lot of cyberpunk themes in its story and structure yet still kept to a lot of its architectural roots. One matter I had concerns about in this project was attempting to merge the darkness and neon lights of cyberpunk with the brightness and oranges and yellows of the Egyptian desert. Remember Me showed me that I was potentially taking the wrong approach, and was a reminder that I was trying too hard to mash the two subjects together evenly, when my project was Ancient Egypt with cyberpunk themes. This game was a huge help in putting my design decisions in the right direction again, and solved a lot of my merging issues.
Remember Me screenshots & concept art:
References
Phipps, C.T (2014). What is Cyberpunk?. Retrieved January 7th 2016 from: http://unitedfederationofcharles.blogspot.co.uk/2014/08/what-is-cyberpunk.html
Tvtropes.org (n.d) So You Want To / Write a Cyberpunk Story. Retrieved January 7th 2016 from: http://tvtropes.org/pmwiki/pmwiki.php/SoYouWantTo/WriteACyberPunkStory
Remember Me (2013) [video game] Developed by Dontnod Entertainment. Publisher: Capcom.
The next important matter I needed to look into was research into my chosen civilisation, Ancient Egypt, and my chosen theme, Cyberpunk. With a venture to the library I got a copy of William Gibson’s 1984 novel ‘Neuromancer’, a seminal work in the cyberpunk genre. Being a non-visual work, Neuromancer was more a source of immersion into a cyberpunk world, and how it might function rather than a visual reference, which is useful for world-building what I was attempting to concept. To save time I did not read the book in its entirety, only reading enough to get the understanding of the cyberpunk world, and then used online resources to understand the story. It was useful for a background in cyberpunk, however, it was difficult to visualise without a frame of reference. I turned to director Ridley Scott’s 1982 film ‘Blade Runner’ to give myself visual stimuli. The main thing I noticed within this film was how sharply contrasting in colour a lot of the scenes were, with near black mixed with bright lights, or that the film itself tended to boast dark scenes. A bit of research into the film revealed that this was due to its film-noir cinematography, and as such I determined it to not be greatly useful regarding a colour palette for cyberpunk, and instead focused on the designs of the buildings and interior decoration.
Regarding biopunk, the main frame of reference I turned to was Irrational Games’s Bioshock video game from 2007. It is one of my favourite games of all time, and its setting boasts themes that sit somewhat between cyberpunk, steampunk and biopunk. Biopunk is similar to cyberpunk but has a focus on biotechnology, such as merging organic tissues together or with mechanical parts. Bioshock’s splicers gave me ideas on how the slaves or ‘labourers’ of the Egyptian society I was creating might be controlled, or might even end up looking like as a result of augmentations they are given to keep them slaves. This same type of obsessive augmentation is what also inspired one of the characters I’d like to design, known as some sort of ‘mechinist’. Bioshock was the most useful source for biopunk ideas, but its mix of themes left it unhelpful for much else.
In regards to Ancient Egypt, I did google image and web searches to understand the culture hierarchy, clothing and architectural style. Due to Ancient Egypt being an old culture that existed between 3100 – 332 BC, what is left to study visually comes from archaeological finds and artistic interpretations. I used image searches to study photos of surviving Ancient Egyptian buildings and archaeological finds, which were as close as I could get without flying to Eqypt myself. To get a better artistically visual reference, I watched the 1999 film ‘The Mummy’ and its 2001 sequel ‘The Mummy Returns’, where they spend a lot of time in Ancient Egyptian ruins or in Ancient Egypt itself within flashbacks. Although both films had a more fantasy element, in terms of visual reference it had a lot of cultural style to draw upon. Another film I looked into was an animated film from 1998, ‘The Prince of Egypt’ released by DreamWorks Pictures. It is an adaptation of The Book of Exodus, which details the liberation of Hebrews from Egypt by their prophet Moses. The film was a good example of the divide of hierarchy between Egyptians and non-Egyptians, which I employed into this project. It also showed a great deal of the Ancient Egyptian setting and general clothing of Ancient Egyptians, however due to it being a traditional animation, which was very time consuming and costly to make, these outfits lack detail and only gave a general ‘overview’ as it were of the design. Regardless, even that was still useful in pointing out the required elements that made Ancient Egyptians so easily identifiable.
During and after conducting this research, I compiled it into four separate moodboards. One was for cyberpunk design, the second for Ancient Egyptian design, the third for cyberpunk environments and the fourth was for Ancient Egyptian environments and architecture. All of these drew upon various sources of imagery including those mentioned above, as the main purpose of the moodboards were to act as visual cues to which I could create my own ideas from. Even after the moodboards were compiled, I continued to add references into organised folders whenever I came across something which I found to be of interest in my designs.
Character moodboards:
Environment moodboards:
References
Gibson, W. (1984) Neuromancer. ISBN: 0-441-56956-0
Blade Runner (1982) [Film] Directed by Ridley Scott. USA: Warner Bros.
Bioshock (2007) [Video Game] Developed by 2K Boston and 2K Australia (later known as Irrational Games). Publisher: 2K Games
Reshafim.org (n.d) An introduction to the history and culture of Pharaonic Egypt. Accessed Novemeber 17th 2015 from: http://www.reshafim.org.il/ad/egypt/index.html
Wikipedia (n.d) Ancient Egypt. Accessed November 15th 2015 from: https://en.wikipedia.org/wiki/Ancient_Egypt
The Mummy (1999) [Film] Directed by Stephen Sommers. USA: Universal Pictures.
The Mummy Returns (2001) [Film] Directed by Stephen Sommers. USA: Universal Pictures
The Prince of Egypt (1998) [Film] Directed by Simon Wells, Brenda Chapman and Steve Hickner. USA: DreamWorks Pictures
The first matter I decided to look into regarding my honours project was artistic style and study. In doing concept art, I was aware of the importance of finding artists I admired or enjoyed the work of and finding the best examples of their professional workflows from projects they have participated within. The biggest challenge was trying to find a style I could mix with my own, one that was only semi-realistic, which was the type enjoyed, but not as cartoony as what I was used to. One of the places I looked to learning style from was that of the Mass Effect artbook, which had a section near the start of early concepts of the human faces for the main characters in the game. Although Mass Effect itself uses realistic meshes and textures of the human forms, these particular concepts boasted something closer to what I had in mind. I found the artist to be one Matt Rhodes, and was able to find his blog where he had helpfully posted more development images for Mass Effect.
Concept art from Matt’s blog and a photo from the Mass Effect artbook:
One of my easiest artist choices was Claire Hummel, one of my favourites I follow, who has worked on numerous Microsoft titles as a freelance artist with the latest one being Fable Legends. She posts a lot of her works in progress and process images onto her blog, which is incredibly useful for study, and she shares the right semi-realistic style I was looking for. Through looking at her work, I came across her Sunset Overdrive concept pieces, and the style of the humans within that game drew my interest for further study. By searching for other artists who aided in its concept, I found the work of Vasili Zorin, who played a large part in Sunset Overdrive’s development and was featured in a developer diary from the game focussing on the character customisation. The last artist I looked into was Robert Porter, another artist I follow and part of the UDON Crew, however his art style is too far in the anime/manga or eastern cartoony style for what I was aiming for. His knowledge of proportions, composition and his workflow were the reasons I chose his work for study.
Examples of Claire’s work:
After studying finding the styles to work with, I had a look at the artists’ workflow. Claire does a lot of realism study in her drawings to ensure everything has a basis of real life in it, and her strengths lie particularly in the groundwork of her images. This means she has a strong sketch, lineart and base colours, then uses minimalistic shading colours to add the mood, often using monochromatic in her shading. She often uses a contrast of warm and col colours to highlight certain places, such as using warm colours for light and cold colours for shadow. This workflow is quite similar to my own current working style.
Some of Vasili’s outfit concept art for Sunset Overdrive:
Vasili developed his characters using one base for male and one base for female, and designed outfits over the top of them. This way he could concentrate more on the outfits and designs of the characters rather than their proportions, and since the purpose of what he was doing was to display outfits and not character personality, the poses use were kept quite static. Claire takes a similar approach in her character designs, although tends to start with rougher sketches or paints over the created 3D models, as evidenced in her designs for Powerstar Golf. She also loves constructing her outfits in a layered manner, especially historical ones, to show how each item of clothing involved in the outfit works on the body in stages.
A few of Robert’s sketched illustrations:
Robert’s approach to work is to start very loose to get the groundwork in, his initial ideas taking the form of blockouts made with barely removing the brush from the canvas, then work neatly straight on top of that. He has been practicing his methodology for long enough that he understands his blockouts enough to proceed straight to neat lineart from them, which greatly speeds up his process. Unfortunately, I was unable to find examples of his character design workflow, but he posts plenty of gifs and videos of his art process for study. One main technique I learned from his was his use of monochromatic colours to help define composition, distance and importance within his larger illustrations, which I found to be a very useful technique when working with environments.
Preliminary Designs:
My next step from this was to do a simple image search for both ‘Cyberpunk outfits’ and ‘Ancient Egyptian outfits’, in an attempt to come up with some preliminary designs for outfits to get a feel for the style mixing these two themes would produce. I made a male and female character base and drew the outfits over them, as adopted from Vasili. I also practiced the human face using references from both Claire and Matt’s styles, including drawing it at different angles, for practice and to try and get used to it. Finally, I used ‘Senshistock’, a pose reference website with an application for quickly sketching poses from reference photos as practice for just that, in the hopes to improve my anatomical ability and speed up my workflow.
Practice using ‘Senshistock sketch’:
Facial practice:
References
Rhodes, M (2013). Concept Art – Behind the Scenes. Retrieved October 15th 2015 from: http://mattrhodesart.blogspot.co.uk/2013/07/concept-art-behind-scenes.html
Hummel, C (n.d) Portfolio of Claire Hummel. Retrieved October 13th 2015 from: http://www.clairehummel.com/
Hummel, C (n.d) Personal and art blog of Claire Hummel. Retrieved October 13th 2015 from: http://shoomlah.tumblr.com/
Zorin, V (n.d) Professional artist Facebook page for Vasili Zorin. Retrieved October 13th from: https://www.facebook.com/zorin.vasili/
GameSpot (2014) Sunset Overdrive – Developer Diary [video online]. Accessed at: https://www.youtube.com/watch?v=fE5RTR6Idbw Retrieved October 13th 2015.
Porter, R (n.d) DeviantArt page for work of Robert Porter. Retrieved October 13th 2015 from: http://robaato.deviantart.com/
SenshiStock (n.d) Pose Reference by Artists, for Artists. Retrieved October 10th from: http://www.senshistock.com/sketch.php
Using my research from my visually rich research document made for DD3000, I have identified an issue regarding blood donations and have proceeded to create an artefact that either solves or raises awareness of this issue through the use of the video game medium. The main issue I have chosen to focus on is that of the excuses potential donors give for not donating, which are generally based around the fact that they do not know the blood donation process or how vital and needed it really is and continues to be.
Marketing & IP Opportunities
PC and mobile gaming are two of the widest-reaching video gaming markets to date, with almost every household owning a mobile device and/or personal computer. That makes this market the most accessible in terms of releasing games as, particularly on PC, the systems are not controlled by ‘gatekeepers’ which restrict access for developers to release on certain platforms. Developing for PC or mobile also tends to be far less expensive, and the sales are primarily made through digital purchases meaning no cost would have to be spent on creating physical copies.
For these reasons I have decided that PC is the primary platform my chosen game artefact would be developed for, and can utilise a keyboard and mouse or a plugged in controller. Keeping it on PC also give the opportunity for it to be hosted on blood donation websites for ease of access, and keeps it close to its educational source material. Proceeds for the game could also then be donated directly to blood donation organisations, and enable them to fund further research into improving donation techniques or fund the research of artificial blood.
The game is not intended to be graphically or mechanically intensive, and as such be easily converted to a mobile port at a later date so that it can be played on the go. Making it mobile also makes it the most accessible to users and appeals towards its ‘pick-up-and-play’ approach, which is what most casual and mobile gamers want on their devices.
Games Studied
The first game that I researched when coming up with initial influences and inspirations for the game concept idea was that of Sega’s Crazy Taxi. It sounded very similar to the game I had in mind and the core game flow was almost the same with finding a customer and then taking that customer to their destination as quickly as possible, except in my game it was patients. However, after looking into the game more closely, I found that I had perhaps remembered Crazy Taxi more fondly as a game from my childhood. Playing it recently I found it had not held up so well over the years, the U.I on the HUD was too large and obstructed the gameplay a fair bit, and the game felt far too fast-paced in relation to the game I wanted to make. The chaos and speed of the gameplay would not be constructive to the game’s core principles of teaching about blood donation since there is very little a player will learn if their minds are thinking too fast, so information passes quickly from their memory centre. Still, the game still served as a good basis for designing my game upon.
The next game I looked into was Capcom’s Deadrising and Deadrising 2, mainly for the purpose of researching into their use of the user interface (UI). I used Fitt’s Law and how it was possibly applied to Deadrising’s UI, alongside the core principle that the only information on screen should be that which is relevant to the player but kept out of the way of their game play. In Deadrising, the player actually has quite a lot of information displayed on the screen at once, but the UI is kept to the edges of the screen and fades into the game play area. This sort of creates a border for UI to be contained within on the screen, and keeps the key game play area unobscured. The fade of the UI information lets it blend into the background, making it soft and less distracting to the player, and as such doesn’t draw their attention unnecessarily. Not all the UI is on the screen at once as well, as timers appear and disappear as needed for the player’s objectives in the game. I like the style of the timers, and believe they would work well in my own game, and are quite easy to replicate.
Another game I came across to look at was Maximum Override, an early access indie game title released on Steam in January 2016 by Alientrap. I was immediately caught by the style of the game, and believed it to be a perfect example for the art style wanted in my own game concept. It shows how simple block colours and models can still be used effectively to create an environment, which leaves the ability to create more and wider varieties in a shorter amount of time and processing cost. This game became a large influence on newer design decisions for my game concept, particularly the random generation of the map to keep each game different from the last and add replay value, as well as the more cartoon-like and charming art style of the game.
As I was making a game with the intention to teach, I tried to look at existing games with the same educational intention. One of the first places I looked to was BBC Bitesize, which is a child-website of the BBC aimed specifically at revision and education for primary and secondary school students in the UK. I remember being led to this website a lot during those educational years, mainly to reinforce classroom learning and for revision purposes, but it is updated constantly to keep information relevant and up to date. The main reason I looked to this website however was because its sole purpose is to help its visitors learn, so is built to do this in the best way possible and has many years of constant refinement behind it. The website is very interactive and has a lot of games and puzzles involved to apply gamification to learning. It was a good influence on one of my initial ideas, and gave me some good ideas on how to display my information attractively to those I wish to learn from it.
The next game I looked into was a very interesting one. Hiragana Battle: ‘Learn Japanese to Survive!’ is an RPG-maker game by Sleepy Duck Educational Games that was released on Steam in February 2016 and, as it says in the title, it is a game based around teaching its players Japanese. This learning game forces the player to learn Japanese to win its RPG-style battles, through repetition and engaging gameplay. It is designed to teach effectively in this manner, and from the response on steam, it is considered to be quite effective at remaining fun whilst being very intentionally educational. It was very useful to look into to see how people found it effective and engaging.
Design Decisions
Initially I attempted to come up with three different concept ideas on what kind of game to approach this issue with, however one of them instantly stood out as the most appealing and made the choice fairly simple. One of the ideas was based on a narrative experience in which the player plays the role of an individual whose life is changed once they discover they have a debilitating condition that requires frequent blood transfusions to survive. The player would then play through various events in their life and come to understand the troubles these kinds of people face with a constant shortage of donations. The second idea was a bullet-hell game inspired after playing Undertale, in which the player answers multiple choice questions on blood donation, then enters a bullet-hell game depending on the answer they give. If they give a correct answer, the player gets a bullet-hell of the same difficulty as previous, but an incorrect answer makes the bullet-hell harder and they can never get easier again. This is both a test of endurance and knowledge, and engrains blood donation information into the minds of players through repetition.
The design I chose to develop was an isometric sandbox game, in which the player plays as a customised self-proclaimed super hero who traverses the city helped those in need of blood by finding them donors. The player finds an individual in need of help, and listens to the person explain their condition and what they need, so the player can then set out to find them a donor. They can interact with the people walking around on the streets and ask them to help donate, but they will give an excuse as to why not. It is then the player’s job to decide if the person they are speaking to is eligible to donate and they have to convince them to do so. All the while the patient in need is on a timer for the player to find them someone as quickly as possible, and once successful the player then takes the donor to the hospital to save that patient. Rarer blood types are harder to find.
To add a bit of direction for the player, they are informed by a doctor at the hospital of people who are in need and directs the player to them, acting as a sort of operator for the player. The doctor is female and acts as a friendly face for blood donation, and also as the player’s point of information on blood donation.
Initially the game was intended to be based upon the style of Crazy Taxi, but after researching into the game and finding it too chaotic for effectively getting information to the player, I came across Maximum Override and found the style to be a perfect example of how to display this game. Maximum Override is still chaotic, but is for the most part played at the player’s pace, just with the odd timer to hurry them along. I have employed this into my own game, and have adopted the blocky colours of buildings and the randomly generated maps to give the game its own look and improve replay ability. I also chose to make the characters in the game more simplistically stylised than realistic, to add to its own style appeal.
After getting feedback for the name of the player character, I opted to allow the player themselves to name the character to create another level of personalisation on top of the character customisation. One of the suggested names was ‘The Haemogoblin’ and, although I didn’t feel it sounded particularly ‘heroic’, I liked the name and have chosen to make him an antagonist for the superhero protagonist. He has a small impact on the game where he will spawn randomly and spread misinformation about blood donations, and continue to make it harder for the player to convince potential donors to help for as long as he is around. He forces the player to make a decision as to work around him or deal with him, as both further impact the game.
Another feature I later chose to add was a ‘level of violence’ mechanic, to create an extra layer of gameplay for the player. This makes them more accountable for their wanton actions, and appeals to the destructive nature of some players. Whenever the player punches someone, including the ‘Haemogoblin’, causes car accidents, goes through walls or other acts of vandalism and violence, their level of violence meter is added to and they have some of their score detracted. Once the level of violence meter is maxed out, regardless of the game mode, the player’s game ends in ‘failure’. This means the player can go around punching people or breaking things if they wish to, however it is still condoned within the game rules and results in making the game harder for the player and reduces their overall achievable score.
Bibliography
Greenspan, D., Boyd, S.G., Purewar, J. (2014) Video Games and IP: A Global Perspective. Retrieved April 2016 from: http://www.wipo.int/wipo_magazine/en/2014/02/article_0002.html
GameDesigning.org (n.d.) The Current Video Game Designer Job Market. Retrieved April 2016 from: http://www.gamedesigning.org/career/job-market/
Sega. (1999) Crazy Taxi [video game]. Available at: http://store.steampowered.com/app/71230/
Capcom. (2006) Deadrising series [video game series]. Available at: http://store.steampowered.com/sub/93390/?snr=1_7_7_151_150_1
Gokturk, M. (n.d.) Fitts’s Law. Retrieved April 2016 from: https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/fitts-s-law
Alientrap. (2016) Maximum Override [video game]. Available at: http://www.alientrap.org/games/maximum-override
BBC. (1998) BBC Bitesize. Available at: http://www.bbc.co.uk/education
Sleepy Duck Educational Games. (2016) Hiragana Battle: ‘Learn Japanese to Survive’ [video game]. Available at: http://study-japanese.net/
Fox, T. (2016) Undertale [video game]. Available at: http://undertale.com/
I finally decided on a cut off point for the game and, instead of putting Phil’s new level in the messy project file we had all used for testing, I decided to set everything back up in his newer blank project file that contained only the new levels, meshes and textures. I set up all the necessary blueprint again in a far more organised manner, and left spaces for Will to implement his models and textures from the characters and assets.
I also changed the dialogue widgets to update them with the new graphics, and used the event construct within the blueprint to fix the previous displaying issues. The project file was then handed over to Will so that he could implement the character meshes, textures and animations to complete the game’s visuals, before coming back to myself to fix any issues Phil and Will had noticed when having the project file.
I did some final tweaks to the project – fixed collision issues, added the mouse back in and fixed some incorrect values – then ran through the game a few times to test that everything was working as was intended, and have now put my foot down on doing any more work with it for hand-in. The game artefact is complete.
I base coloured the main menu screen and implemented visual and audio feedback on the menu options, so they make a ‘click’ sound when the mouse hovers over them, and they light up as well. It was looking very nice visually. I also made the game over screens for both the deaths of all the A.I and the timer ending, utilising sound and the event construct to make them more dramatic to the player.
The biggest task completed at this time was the score screen, which is shown when the player completes the level. It involves a timetable that uses blueprint to add or subtract values together. It displays the player’s score in the game level, the score the player gets for the amount of time left, the score taken away for the number of deaths, and the total for all three. The player can then select to try again for a better score, or quit the game.
I then had a go at creating the countdown timer for the game and making that a game-fail state if it ended before the player was finished, then coded that to the HUD. I did encounter an infrequent bug where the timer would end too early, but determined it to be a program bug rather than a blueprint bug, where the delta seconds became de-synced. The only fix for this when it occurred was closing and re-opening the project.
I changed the menu screen with a sketched out version to see how it looked, and it turned out very nicely. I re-coded the controls, options and main menu to fit with the new menu screen, so it wouldn’t have to be replaced later. I also added controls to the pause screen to enable the player to view the controls whilst playing, in case they needed reminding.
I started messing around with how to add dialogue from the tutorial teacher ghost, trying to get it to pop up and stop the player moving when it is there, so that they read it. I managed to code in one line, but was unable to get it to cycle through the different dialogue lines on a button press. If I had time, I intended to look into getting it to type out as well.
It getting late in the development stage, we decided to cut the introduction sequence from the game as there just wasn’t enough time to draw and implement it in, and it seemed a better idea to put more focus into improving the mechanics we had than to add something completely new at this stage. We have also decided to settle for more basic textures in the game, as there is a lack of time to complete all of them.
After watching more gameplay of The Haunting, a 1993 Genesis game, I determined that the level itself could be done a much better way, and would avoid the need to code the mechanic of hiding walls into the modular wall pieces. I spoke with Phil, the level designer and 3D artist, to get his thoughts on the matter as it would mean more work for him. He liked the idea, and didn’t believe it to be too difficult to do, so he agreed to produce the work as soon as he was able.
The level was changed accordingly, and the vertical slice protorype was now split between two level blueprints. One has the outside of the house with an introduction to the gameplay, and the other is entirely the inside of the house where the main gameplay will take place. It looks a lot better, but the layout needed a little improvement, so I worked with the level designer to implement this.
Our audio engineer collaborator’s honours project was due, so I spent time working with her to implement in what sounds she needed to show and submit for her project, blueprinting them into the game. It sounded good!
I successfully got the mouse to move, as it turned out I had just missed a checkbox. Coming back to the issue with a refreshed mind helped find that. I also finally managed to stop the A.I from leaving the house when they weren’t supposed to, but can still leave when fleeing the player.
I finally coded in a game-win state by creating a killzone the player cannot enter over the end of the A.I’s fleeing point. When all actors of the A.I class is destroyed (upon entering the killzone) the player wins. My next job was to try working on a way for the player to fail if all the A.I die, but I wouldn’t be able to use the destroy actor node as that is used for triggering the win state, and we also wanted the bodies to remain in the level for the player to see. By using a variant of the coding in the win state, but instead using the ‘dead’ Boolean, I succeeded. The job after that was to code in a partial win, where at least one A.I dies and one escapes.
I changed the behaviour task to make the A.I move randomly instead of point to point, to stop them from following each other. It also allowed for a different experience each time, and made the A.I more unpredictable to the player. The next task to solve with them was to stop them from leaving the house when they weren’t supposed to, as they kept escaping out the open door the player enters in through. In trying to block the A.I from leaving, I messed around with the collision on both the A.I and the player character, and successfully fixed the bug of getting trapped in possessed objects. The player also now goes through the A.I, so they do not collide together, as a ghost should.
Decided to research other ways to fix the escaping issue, and came across the option to filter navigation classes to create different types of navigation. This seemed like a plausible solution, but needed some more extensive research putting in. I also made a small mouse A.I for the player to practice scaring on before entering the main house level, which only has the one task, but I could not figure out how to get it to move, I couldn’t understand why.
With it approaching the end of the development time, the game itself was looking very good and we had a lot of assets to utilise, however we were very much lacking in textures. I decided to start trying to work on potential contingency plans.
Returning to class following Maria’s visit, I chose to focus on bug fixing now we had a compiled game.
I succeeded in stopping the A.I from playing the death animation when they weren’t actually dead in the behaviour tree, which had then caused them to slide along the floor as they continued to move after the animation had played. It turned out to be that the float numbers in the ‘scare’ blueprint and the animation blueprint were different. It was a hilarious bug but had to go.
I also coded into the character blueprint that once they energy bar is depleted the player was then kicked out of possessed objects, which prevented the player from getting permanently stuck inside a possessed object. They could still get stuck and be forced to wait for the energy to deplete however, which was another bug to look at.
We learned a lot from Maria Stukoff’s visit. She gave us all a good lecture on Sony’s approach to indie development, and ran us all down on how to make a good game pitch and pointers on how to work on our games. Four group’s games were shown to her, and we showed our ‘Spoopy Brigade’ third. As team leader I did most of the talking, and took on board what she had taught us about pitching in the lecture and the feedback she gave the groups prior to us. The game and pitch seemed to be very positively received, and she was impressed with the work we had done so far and liked the direction we were going in.
My biggest concern in showing her was her witnessing any of the aforementioned bugs but, somewhat thankfully, she did not play the game herself and instead watched us play, so we were able to circumvent them by intentionally avoiding what was triggering them.
After enjoying a Valentines weekend, we all returned to work for a very long crunching session through the Monday and Tuesday to put the game together for Maria Stukoff’s visit, a representative from Sony, on the Wednesday.
The game finally became a proper playable demo instead of a whitebox room. It was unfortunate that it took such a crunch session to get it there, but it was amazing to see it all finally working together. We used base colours whilst we didn’t have textures for our objects to make them look nicer and pop out, and Will had added small animations for reinforcing the scared people and an animation for the scaring itself, giving good visual feedback.
Bugs became apparent after the game was together, such as getting stuck against objects, getting trapped in objects and A.I triggering the possession mechanic, but this was okay for Maria’s visit as she was aware they were in-progress prototypes.
