UI and UX can be used interchangeably but have key differences between the two. Both UI and UX are relative to the way a player interacts with the game. UI, User Interface, is the visual way a player interacts with menus. UX, User Experience, is how the player interacts with menus. Developing UX is having a exit button at the bottom of a menu or a title at the top, increasing the usability of menus. Development of UI would be the look and visuals of the menu, keeping the exit button the same size and colour, bottom right and red for example.
My initial research into UI is summed up inside of a power point:
In this PowerPoint I focused mainly on the design of the HUD, Heads Up Display, as I would say it is the most important aspect of both UI and UX as it is what the player is most consistently interacting with during active gameplay. Three aspects that I point out about HUD are that locations, layout, consistency and the game genre and target platform are all important to create an accessible and understandable HUD.
Location and layout
Location and layout is important as it keeps the players mind consistent with what they are seeing and thus makes the experience clearer to understand. Cyberpunk 2077 and the Witcher 3 are both made by CD Red and is a good example of keeping layout and locations consistent. Health, XP, level or toxicity are all kept in the upper left corner in both games. The same applies for the mini map and quest. The lower half of the screen does not keep the same location and layout with Witcher 3 having consumables in the bottom left, Cyberpunk 2077 has its consumables in the bottom right as the bottom left slot is filled by the ammo counter and weapon display.
There may be reasoning behind this. Perhaps the bottom left corner is preferred retail space for UI and that is why the consumables are in the bottom left in Witcher and the ammo counter might be more crucial to gameplay which is why it takes that preferred spot for UI.
Genre & Platform
Genre and platform can drastically change what the UI looks like as the way the user interacts with the UI is different for genre and platform. For a comparison Mobile and console, comparing CoD Mobile to CoD Black Ops 2. The way that players interact with both games is a completely different experience. On CoD Mobile the player interacts with the game through an expanded HUD where there is all the same information as the same game but with more interface in order to interact such as a digital analogue sticks for movement and several buttons for various actions such as reloading, shooting or aiming. The layout of the interface on all platforms as an extensive task for UI and UX designers but is more so on the mobile platform where more interface is needed in general. The range of UI used in mobile games is also reflected in the design of various accessibility-designed controllers such as the one Produced by Xbox.
The importance of UI and UX isn’t just for the average player but the accessibility of a game is dependent on how the interface is designed. It is worth it to design UI with simplicity and accessibility for usability.
UI and UX needed is also dependent on the genre of the game, an immersive survival game would need much less UI then a RTS.
The range of information that the player needs on hand in the hud alone is different for each genre, for a survival game like Valheim you need crucial information such as health and food/stamina as well as active effects and hot bar items, in a civ sim you need a list of resources, build menus, population etc… The amount of information given to the player at all times varies from game to game and how that information is delivered to the player at all times is crucial to what User Experience is.
Consistency
Keeping the design of UI consistent is a major focus on the UX, changing where the player can find information from menu to menu can be confusing and tedious. Fallout 4 as an example, keeps the Pip Boy pages consistent between most menus. In the weapon menu, a list of weapons is along the left side and to the right at the top there is a image of the weapon and beneath that the stats of the weapon. In the quests menu, a list of quests is along the left with a clip art for the quest at the top right and stages of the quest at the bottom right.
UI in games
To properly understand how to effectively understand how to create UI and UX it is important to know how other games have done it. I am going to do a case study of Risk of Rain 2 to understand how this game uses its UI and creates a smooth UX that is needed in the fast paced roguelike genre.
To initialise this study, I will start with the main menu and then go through to the singleplayer section of the game.
The main menu is simple with the main buttons being located in the bottom left with the version number and copyright being in the top left and the only other interactable buttons being the profile and language option. The main section of the menu follows the same pattern of grey blocks with a white outline and bold large text for what each button takes you too. The first menu, Single player and Multiplayer buttons are likely at the top as this is a common place for it to be and they are the two main game modes.
Clicking on the Single player option takes you to the character and rules screen where you can change your character, difficulty, expansion packs and artefacts (unique modifiers that change gameplay). The character select screen gives an overview of all equipped skills with a in depth description of what the skill does, how much damage, status effects etcetera.
Going into the Loadout section on the character selection screen takes you to a page where you can change the equipped skills to skill which you have unlocked and see what else you can unlock. The active expansions and artefacts can be changed by clicking on the box with a pencil on the left of each rule heading which opens up the page seen in the middle of the screen. The Single player menu also has two other buttons at the bottom, Ready, which starts the game and Back which takes you to the main menu.
The main viewport is the centre of the screen so it is kept clear from all UI other then the crosshair and all other information is located around the outside of the screen such as the health and experience bar in the bottom left and currency, item and difficulty + time scaling bar along the top. Abilities, equipment and controls for sprint and inventory menu are in the bottom left. When an equipment is on cooldown, the timer is shown in large bold numbers to be easily visible.
When the player dies two menus pop-up, one for stats of the ‘run’ such as time survived, most damage dealt etcetera, and the other menu for information about the run such as what killed you, items picked up and log books/ achievements. As you can die anywhere, the menus have a transparent background of grey and then information on a darker transparent background to make everything stand out against all locations. The game is also blurred so that everything is easier to read.
The intent of all research is to better your own understanding of a subject, even points I have researched up to this point might not have a direct and notable effect but do have an influence on everything I do in this project and will have effects on future projects. In terms of influence on my project, there are some key points I have found that I would say have a direct effect on my product. Through a case study on Risk of Rain 2 and logging many hours in the game during this research the UI doesn’t stick out as it is all the same. The player sees the UI and knows what it is as it is kept simple and consistent throughout the entire game. In the game there are five blocks of UI: currency, items, difficulty and objective, ally health, health and level and skills. Each piece of this UI sticks out against all backgrounds of the game which makes the unobtrusive UI notable as it is an example of keeping UI simple concise and consistent in order to better and simplify the players experience. This point does not have to much influence on my game however as this research is for a web game which is likely to not have the complexity for a large scale multi stage UI as RoR2 has but it does make a point of keeping the UI out of the players face, reinforcing points I had made in my first presentation about UI.
Environmental Web game
I need to make a web based game with the goal of environmental awareness for all audiences/family friendly. Making a game family friendly means more then no graphic content but what the gameplay is, having a complex game rules out a wide range of people such as those to young to understand certain nuance with games, older players who may lack the enhanced reflexes needed or any one who doesn’t play games. Luckily, complex games are rules out by the fact that this a web based game, which has limitations in what can be reached in terms of gameplay etc… I have made multiple web hosted games in the past and understand what limitations I need to put into place before starting idea generation.
The client needs a web hosted game with a theme of Environmental Health to raise awareness for the issue. The game must be Family Friendly and not contain any graphic content. The client would also like to oversee development and have consistent updates throughout the project. The client does not have a background in Games Design so explanations are needed for complex areas.
The user needs to have a playable experience on a website, the game bust be traversable for all ages, UI and gameplay alike, and has to represent some form of environmental issue.
As initial thoughts, there are some areas of interest for research such as other governmental games, mainly other environmental gov games as well as environmental games in general, larger issues in Lancashire in terms of environmentalism, water pollution, carbon emissions etc… In one of my previous projects, I had a theme of fly tipping for visuals but not for awareness and the gameplay was targeted towards a much younger audience then this game would be for.
After researching into the traffic of the Lancashire website, I have found that users are only present for 4 minuets and view around 5 to 6 pages on average. Over 50% of arrivals to the page come from direct keyword searches, meaning that giving the game a simple name would lead to better click revenue as it would keep in line with how a majority of visitors arrive on the website. Due to the older age of visitors to the site, I will target my innovation towards games that this older audience enjoys, primarily mobile games such as match 3 like Candy Crush. The average age in Lancashire is 41 to 42 and the majority are women, which gives a better idea of who the overall average audience would be. Taking into consideration the client brief, targeting a game to just this audience would not follow along with the information given as the game is intended to be a generalist family friendly game.
For the produced prototype game for the Lancashire website I will be making a Match 3 game from derivative ideation from games inside of this style such as Candy Crush or Bejeweled. In order to bring environmental awareness and tie it into gameplay, the player will match varied pieces of litter which then would fill up a recycling bin, raising awareness about environmental safety. This comes from the audience research I have done, it will be easier to have a key word name for a small game, the majority population is known by game analytics for enjoying the puzzle/match genre and due to the simplicity the game will be family friendly.
As for alternate ideas, there are many avenues to follow as Match 3 games are not the only family friendly game, the client brief outlines Fly Tipping as an environmental issue, where large amounts of litter are placed in one location where it is not supposed to be, the unfortunate side of that is that my last game would match the brief of the client as it is webhosted, family friendly and has a theme of environmental awareness for fly tipping. Tip Slingers is an alternative solution to the clients brief, meeting the requirements and needs of the client and user.
Another solution to this theme and topic could be a range of different games with a range of different environmental topics such as a tower defense game about protecting trees, wildlife or habitats, similar to Rogue Tower but with an environmental twist on the gameplay. Or a puzzle game where you move people in cars into environmentally aware public transport such as busses, trams and trains or bikes. Creating solutions to a brief that has been analysed into its key parts makes creating general ideas that math the brief much simpler and allows for the creation of many alternate solutions for a theme and topic, I could develop any of these ideas into the web game but given the audience research and prior knowledge of that audience, going with a Match 3 game is the best choice out of these ideas.
UX strategy
The focus of UX for this game is to keep the UI simple and understandable for a wide audience, keeping in line with the clients brief. There are various goals that can be placed in order to achieve this strategy. Making the UI understandable is not as important as making it useable, if you understand that a cog symbol commonly means options in games but you cant click on the cog to go into the options then what point is there to having the button to go into the options. If you don’t know that the cog means options but you can click on the cog then you can figure out that it represents options through symbolism.
To eliminate this issue all together, you can make a large button which can be easily clicked that just says options. understanding that usability and understandability are more important then sleek designs is a part of designing around accessibility, which is what an efficient UX strategy aims to do. This approach and strategy for design is focused around the clients brief and users need. As I have stipulated earlier, the likely age range of visitors to the website would be an older audience and so I need to design the UI in such a way that the users experience in the game reflects the older age bracket.
Another factor in accessibility is colour blindness, having options for colour palettes is not common but is present in some games in order to make the experience usable for more of your audience. On way that this could influence the UI and UX is making the pieces of litter visually different, for example a square and a sphere rather then a green square and red square, or a play button that stands out to all ranges of colour visibility.
What I would need in order to do this is research into various issues within accessibility in games in order to effectively know how I can make an impact on the UX of my game before I make the game. There are resources made with the intent of making it easier for developers to design with accessibility in mind such as Game Accessibility Guidelines (GAG) and Can I Play That? (CIPT). GAG provides specific resources about specific issues, for motor issues there is a page about why it is good to have remappable controls and provides examples about games that do it well and then resources that assist in making remappable controls easier to develop. CIPT does not provide resources like GAG but consists of revues of games based on accessibility, highlighting good and bad examples of accessibility written by a disabled person. Reading through articles that highlight what games have good accessibility which you could then use for examples in your own development.
The aim of the game is to present to the audience the simplicity of recycling and what effects it can have on the environment, making it more accessible would help spread this message and appeal to the client brief by being more family friendly.
Returning to colour blindness, there is a wide range on what colours colour blindness can effect, I have put the same image through a range of filters to identify the basics of the range of colour blindness
In order of the first image then to the right :
- Standard blue/orange image
- Protanomaly – Weak Red
- Deuteranomaly – Weak Green
- Tritanomaly – Weak Blue
- Protanopia – Red Blind
- Deuteranopia – Green Blind
- Tritanopia – Blue Blind
- Monochromacy
- Blue Cone Monochromacy
Wireframe UI
Before production starts it is important to know where to start, which is done through planning and when it comes to UI there are various stages of UI planning and design, the first is a low fidelity wireframe layout that gives a simple idea of the layout of the game
This is an example of the main game scene. The game itself would be where the large X is. The space on the right of the screen is where score, time etc. would be tracked as well as the recycling bin in the bottom right. I chose this spot for the recycling bin as it where various bits of information can be seen in multiple games such as ammo counters in Borderlands or available skills in Risk of Rain, so it is some where where a notable piece of UI would be found naturally in games.
Apart from this design, there are different ways to go around a UI for any game, especially for a game that is as simple as this, changes can be made about the mechanics too as in this prototype UI, the game has a recycling bin to mark the players progress to completion which may not be a mechanic that ends up in the final version the games which I will make apart in the next prototype of the Wireframe UI.
In this wireframe UI prototype, I have changed the viewport to portrait for the game to be better accessible on Mobile platforms, I have also changed the recycling bin out to focus more heavily on the game screen with minimal space for necessary UI, pause and Score as the player needs access to these more then anything else and providing a bigger viewport for the game rather then the UI would be better for the player.
The game which my idea mostly comes from (candy crush) is made for the mobile and as such it is important for my game to be most friendly to that platform which is the metric that I will be deciding my UI on. The mobile platform is mostly held portrait which is why many casual games are built in that way, games like Dead Cells or terraria on the mobile platform are played landscape but those are not casual games like mine and as such, given how the second design better conforms to the mobile portrait screen, that shall be the design I go with. Another reason to with design two is to keep the game simple as having the recycle bin idea where dozens of unneeded sprites to be kept on screen could lead to performance issues on some browsers, which is where this game will be played, as per the client brief.
Predicting issues
There are various issues I could encounter during production and as I have done in the past, it is a good idea to identify potential issues in order to counter problems before they appear. As I am working in Unity on a 2D game, most of my knowledge of Unity isn’t as useful and my knowledge of 2D games isn’t as useful as I made my 2D games in construct 2/3.
In my last project, a litter based physics game, I used construct 3 as the engine and with my experience with the engine I was able to have mouse and touch controls in the game at little extra work, having a game capable of being played on multiple platforms would further assist the client brief by allowing a wider audience access to the game. The issues I foresee with this is that I do not know enough about C coding.
Multi Stage User Interface
I have created a medium fidelity wireframe of the UI to have a design template to work from when it comes to production of the game as well as to keep the client up to date with on-going work. Wireframe is the technical term given to a template of a UI. Medium fidelity refers to the level of detail given to an outline of the wireframe, Having a medium fidelity means that it represents the final product with less detail then high fidelity. This wireframe has accurate spacing of UI elements, buttons, titles and other interactable elements which is what gives it its classification of fidelity.
GDD
Before starting development, it is important to know the ins and outs of the game so that time isn’t wasted and development doesn’t go off track. With a match 3 game, that is unlikely to happen but it is still useful to have the overall designs and intentions for the game written down for reference, the most encompassing solution for this is a GDD that covers all aspects of the game from core mechanics to audio design. Planning out a game in detail through a GDD makes you ask questions that you didn’t think off, in the case of this project, whilst planning out audio I listed as litter replacement as a sound effect but after thinking for a moment, having the litter replaced might not send the right message to the player, along the lines of futility of making a change no matter how small, such as recycling a plastic bottle. Not having replacement blocks in a match 3 would change the core gameplay of the game which is something that I would have other wise not thought about. I have made a GDD that outlines what the project is as a whole, assets needed, main gameplay mechanics, audio needed etcetera.
Creating a prototype
Before starting to make art or set any plans in stone it is important to know that the simplest basics of the project are possible and the easiest way to do that is with a prototype. With match 3 games being relatively simple and popular with many audiences, finding a variety of resources to make the process easier is easy.
As I have little experience in coding in Unity in 2D, finding and following a tutorial on how to produce a prototype is going to be useful as from then I will more then likely be able to continue on with my own modifications to a baseline product.
For my initial prototype I followed along a 3 part tutorial video. The tutorial was in depth and allows for some customization of the game through swapping out the sprites as they are coded to match as numbered elements rather then sprites so these elements can be swapped out for a suitable file type in order to change the theme of the game simply.
The only change I have made to the tutorial so far is changing out the sprites for recyclable item PNG’s such as cans, bottles and cardboard, this was to give the game rough visuals of what I intended it to be rather then leaving it with shapes as the tutorial does.
To test some new changes to the game (score and UI) I have tested the program on my phone in order to accurately represent how the game would be played if it where to match the client brief and be uploaded onto the Lanc Gov website. The gameplay goes over the basic implemented features of buttons going to new scenes, loading the game and having working match 3 gameplay online on my phone. I have used touch controls once in the past (on my physics arcade game similar to angry birds) but that was in Construct 3 where I wasn’t relying on scripted controls for a game but a blueprint esc system. Creating touch controls inside of Unity is a different skill set to that of Construct and was quite a challenge to develop and overcome.
User testing 31st March
After releasing the game in the state seen in the video above, I have conducted some user testing with a limited audience. There are multiple reasons to test the game with people outside of development, understanding how the user expects to interact with the game or how satisficed they are with the experience. The user testing for my game resulted in an expected outcome, the players didn’t want to stop playing. With my past games, players didn’t actively play the game for more then 2/3 minuets on average, partially because some where unfinished products (Viral) and some where short experiences(Tip Slingers). With this game I have yet to implement a finish state a point where the player stops playing. I presentiment of this happening due to the ‘addictive’ nature of match 3 games, simple and satisfying gameplay. This lead to my users spending a considerable amount of time just playing the game, my intention was to have they play until they where bored of the game but after 15 minuets that still didn’t happen and by the end of the allotted user testing time slot, the players where still playing and the end score for two players where astoundingly high, almost hitting 5 thousand for one player. The addictive quality of a match 3 was unpredicted to be so high and has put furthering user satisfaction on hold and moved a finish state higher up on the list. Perhaps in a final release, I could have different game modes that change gameplay, an endless mode with the game as it currently is, a time trial mode where you attempt to reach the highest score in an allotted time and then a standard mode which I am working on where the game reaches a set score and the player wins.
Going into the needs of a wider diverse audience, I had the chance to talk to a player who has visual difficulties. The player didn’t struggle with any of the UI and was the player who interacted the most with the game, showing (on a very small scale) that the rough wireframe basics of my UI complies with my client brief and is accessible to a diverse audience. Analysing this batch of user testing against general criteria of accessibility (players with different hinderances have little to no trouble interacting with the game) I am only partially ready for a wide audience and full release. If I where to have players who struggle with hand related motor disabilities, they would not be able to interact with it as the only two control methods are touch and mouse which some people may not to be able to use. Having touch and Mouse controls does mean that in terms of accessibility that my game is available to a wider audience who may not have the fine motor skills that are needed to navigate with a mouse or people who cant interact through touch.
Continuing development
Now that I have a game at a point where it fulfils the basic asks of the client brief, there are still plenty of things to do in order to match the desired quality that the client brief has set. Excluding the win condition for the game which I am still developing the code for, matching the visuals of the game to that of the Lanc Gov website is a step in the right direction for the users visual experience being better as well as bringing the game up to par with the client brief.
The client website has a theme of simple colours, a few shades of grey, one shade of red to indicate highlighted items, the same font for text in different sizes which are either blue and underline, white or black depending on the background of the text.
The main interactable buttons on the website follow the same pattern of starting of text with a ‘>’ (greater then) sign to act as an arrow for the text which is then followed by large white bold text on a grey background and when the button is hovered over it turns red and when clicked turns a darker red. The game itself already follows the design of the website, content on a white background which means that much doesn’t need to change there but the Score counter font will need to change. As well as these changes, now that development nears its end, it is time for the game to have a proper name and logo in order to further mimic the design of the client site.
Changing these features of the game was mostly a long and tedious process and the only work I have done moving from one version to the current (1st Apr) version is introducing a win condition. The win condition was scripted much simpler then I anticipated, I expected for the feature to be most of a days work but I was able to work it into the game in 2 hours. The current win con works by checking if the score int is greater then or equal to a WinScore integer which is public so it can be changed inside of Unity rather then needing to open VSC every time I want to change it and ‘if (score >= WinScore)’ the game sets the win screen active so the player cannot interact with the game and displays some text showing that they have won.
The way it works currently is quite simple, much simpler then what I had thought, but it took me quite a while to publish the current build as I was working on a pause function. In the past in Unity I have used a pause in a 3D world where it is common practice to haven a key press designate a pause such as escape but in 2D it is common for there to a pause button somewhere on the screen. The issue with this is that I know how to pause the game on a key press but not how to pause the game with a button. I spent a while searching how to use buttons like this but could not find something that fit my needs. I moved on from creating a pause as it isn’t necessary, the game has no timer, has nothing moves or changes as time passes and can be put on hold without any side-effects which means that the game needs no pause. Commonly I implement a pause feature as I would say it s necessary for a range of reasons, accessibility or thinking of the player as a person who cant spend 100% of time playing the game playing the game but that isn’t the case here as there is no need for it, not due to y own choices in design of how the game should be played.
For the next steps in development, I would like to make some changes, having options, different game modes (time trial, endless, casual(the current way to play)) and apart from what I want for the game, I should think of a name and give the game some from of visual / art overhaul. One thing I think will need to change is the points needed to win, after some in-house testing, I can beat the game in about 20 – 30 seconds but this be due to overplaying the game and experience from making the game. Having another batch of user testing would be useful at this point but will be put on hold for a while whilst I work on other assignments and possibly change the game in some other aspects then what the user testing is needed for.
One feature in active development is an option which I think will increase the accessibility though platform, screen scaling. I can not do this automatically as I don’t know how to or know where to start but I have something in the works for the player to do this in game. The system I have for this at the moment id not very well – thought out and was mostly created through fiddling around with features whilst creating the pause function which was cut. How it currently works is by having all of the features of the game inside of an Empty which is set to the center of the canvas which parents all of the game which can be scaled up and down which just increases the size of all things it parents. I now that this will lead to some issues with upper and lower limits but at this point, I don’t know how I could have an option changed in one scene and effect another scene as it is something I have never done. If I want to do this I will need to learn how to but if I do do this then the option screen will not be completely empty apart from a button to return to the main menu. The Credits Menu is also empty at this point but does not require as much work as creating features for the option menu as the credits are just text which can fit on the screen at the same time so no scrolling text is needed for the scene.
Overhauling the visuals
The visuals currently in the game where never meant to be the final versions and where placeholders for the graphics to make the game more visually appropriate for user testing but they have been placeholders for long enough and it is time to move on to making the graphics for the game. There is a list of the graphics needed for the game inside of the GDD but as the list is short it won’t take too long to finish the task.
- Aluminium can
- Cardboard box
- Water / plastic bottle
- glass bottle
- Tin can
- background
- banner (Itch)
- Logo (Itch + game)
The first hurdle in creating the graphics is deciding on a visual style, as I am not an artist and my skills lead something to be desired visually I want to keep the visuals simple for my sake of creating and the players sake of poor quality visuals. The first thing I am going to work on is the match pieces as these are what make up the gameplay and what the player is going to be paying attention to the most.
There are multiple ways to go creating better visuals for the game, I can create flat 2D icons of the objects, create stylised versions of icons or I could use 3D objects and render a 2D image and use that as a higher quality icons.
Taking on some advice, I have made some more examples not using white as the background. After changing the colour to some random choices, I have thought that I could utilise this in the accessibility of the game, changing the background colour of each piece to something that stands out from each other in as many different spectrums of colour blindness possible in order to make the shape stand out from the circle background and if the player cant differentiate from the shape to the circle colour of the shape then they would still be able to match the same colour sphere.
Before I move further on in development I think it is a good point to look back at development made and evaluate my position in the project. Summarising the points I am about to make, development has went well, I have learnt a substantial amount of knowledge as I did not have knowledge about 2D Unity prior to this project. Development has went well, I have not encountered many issues over this time and for small issues that did occur, the solution was simple to come across, such as the score system. I had troubles creating that as I have not made on of scripts before but the process was much easier then I expected.
The score starts of with declaring two variables as public, a WinScore and score then having “score++;” in the same position in the code where matched pieces are handled so that when a piece is matched, the score variable ticks up. When the score adds up to the WinScore value, the player wins. The value of the WinScore is public so that it can be changed inside of Unity rather then inside of the code to avoid compiling. Recently I have made the game difficult by taking away points when pieces are flipped but matched. Making this was as simple as adding to the score:
When a piece is flipped, if it is flipped back because it didn’t make a match, take away 1 from score. Creating the score mechanic was much simpler then I thought it would have been and the most trouble I had was finding out how to have score show up in Text as I need to have a public text object that I can place inside of the engine in order for the score to be visible to the player.
I only had the score tick up in the past but following on from a large batch of user testing where several replies talked about how the game had no drawback, I decided to add the takeaway score mechanic for unmatched pieces. Aside from this I have also made several changes relating to that user testing such as one specific request about new pieces. When pieces are matched new pieces come in from the top and the old ones fall off screen, this request was about changing the speed of these pieces as they where to fast and can be distracting so I have halved all of these, fall speed, fall force etc…
I have continued development of the game, marking of the last things on the to do list such as changing gameplay in accordance to the users experience, new visuals, UI and backgrounds. The game is now complete and has had a significant upgrade visually from the last update.
Presentation
Now that the game is feature complete, had a visual update and changes to the UI and UX according to player feedback it is time to look at the presentation of the game on Itch.io where the game will be published online and can be played on both Mobile and PC platforms.
At this point in time the page is quite simple, with the only things present are the game and text about the game, how to play, the aim of the game etc… The page needs touch-ups, a logo at the top, some screenshots of the game…
Even though the changes made to the page are simple I have made several, a slight change in the colour palette, logo, screenshots and I have also made several logs of development public so that if people want a brief description of the changes made version to version, they are accessible.
History of the Match 3 Genre.
The history of the Match 3 starts with the Tile-Match game SameGame or Chain Shot!(1985) which plays quite different to the contemporary match 3. Rather then match 3 pieces, you click on a section of conjoining blocks with the same colour which are then removed and the pieces held up fall down, allowing for pieces that didn’t match to match. The history of match 3s can aslo be traced to Tetris (1984) due its colour/ shape matching gameplay which made puzzle games boom in popularity; along with SameGame and Chain Shot!. With Tetris commonly considered the first casual game, it is not too surprising that one of the most popular genres of contemporary casual games can trace a lineage back to it. The rise of puzzle games from the mid 1980’s lead to games such as Dr Mario and Puzznic. Puzznic is a notable game due to its gameplay. Whilst Tetris and Dr Mario shared similar gameplay and SameGame! was different to those two, Puzznic had the player move pieces around a grid themselves, solving puzzles and matching tiles in order to win, considerably similar to the modern Match 3.
Dr Mario being a Nintendo game which was held in esteem by all involved with games at this point lead to the creation of many tile-matching games over the 90’s which lead up to the creation of the contemporary match 3 game, Shariki or “The Balls” in English. The gameplay of Shariki has the player click on a ball and then click on a conjoining ball which both then swap and if the balls match in colour and are in a line of 3, they are removed and replaced by new balls and points are added to the score.
The creation of the Match 3 can be traced through multiple different game up the modern day after the creation of The Balls, Bejewelled would be created in 2001 and lead to the refining of the mechanics, multiple levels, timer, combo points for matching multiple sets of tiles in one move etc…
The creation and refining of the Match 3 genre from Shariki to Bejewelled lead to the creation of multiple games changing, creating or copying the mechanics of the genre leading to a range of games being produced through the 2000’s Zoo Keeper, Jewel Quest and Tidalis which was made with the intent of changing up the formula completely and doesn’t play like the average contemporary match 3.
After 2010 is where the Match 3 modernizes and leads to a change in the mobile games industry, King releases Bubble Witch Saga, a match 3 game which used a range of mechanics such as power ups and limited moves giving the game a good amount of replay-ability in a short time span and also allowed for the implementation of a heavy handed microtransaction system. King would go on to produce candy crush saga in 2012. There has been no major changes in the precedents of match 3’s since Kings success with Candy Crush with it earning over £70 million in its first year alone.
The contemporary Match 3 evolved from Tile-Matching games and after the creation of the match 3 various mechanics were created and changed over time, eventually reaching the contemporary design which is what influenced the design and creation of my own game. The influence for my games came from many things, the success of match 3 games from candy crush, the popularity of candy crush with 40~ year old women and the majority age and gender of Lancashire’s population being that audience as well as the fact that I have taken a liking to developing mobile-arcade esc games.
Evaluating the project
My game was influenced by contemporary games which have developed over a long history of games traced back to the mid 1980’s with Tetris and Chain Shot but how does my game compare to the precedents set by its legacy and against my own expectations?
The game was never meant to be a stepping stone in the match 3 genre like many of the games I have mentioned in the history section of this page but in terms of mechanical gameplay it matches its legacy in some respects as it is visually complete but in terms of historical precedents I could not say that he game is feature complete as it does not feature one major point of many match 3 games, power ups. Power ups would be a whole other topic to go into but that isn’t to necessary as it is a self explanatory mechanic which is found in the main inspiration for this game, Candy Crush. Not having power ups does not make this game any less then its legacy but does mean that it terms of genre precedents the game is not feature complete but still matches and surpasses my expectations for an arcade puzzle game developed by myself.
Audience research
The audience research portion of the project was quick and simple, given the client being the Lancashire Gov and the game needs to be Family Friendly and environmentally aware, the only thing left for me to find out was the average person in Lancashire and the traffic from the Gov website where the game would be hosted. After brief research into these areas, I found all the information I needed, the Gov website is visited mostly through key-word searches and the average person in Lanc is an early 40s women. The average age was more important in the idea for the game as the average audience are the ones most likely to play the game and as such, appealing to that audience with mechanics/gameplay that they enjoy is more likely to bring in that audience. That age bracket is usually known for playing puzzle games with the major one being Candy Crush. Using that information is what made the game produced a match 3. The audience research was unlike research I have done in the past, which is not unsurprising as I haven’t had such a specific client brief and a definable average audience. Coupling this with how I was learning about demographics at the time influenced how my research turned out and was much simpler to compile then in the past and this project will likely have an influence on how I work on finding an audience in the future.
UX strategy
UX is an area of games development that before now I had no experience in and as such this part of the project fell flat as most of what I did wasn’t as useful as I thought and did not have much influence on what I have done. The good part about doing this to what I would say is a low standard for the first time means that when it comes to working in this area on future projects, I will have more experience in what I should do and how to have something to a higher standard for future projects.
The result of this was not too surprising as doing anything for the first time will likely turn out bad but as I have made a point of, that means that each time you do it you get better as you learn what to and what not to do, I have learnt more what not to do then what to do but that means I am narrowing down what to do in the future
UI wireframe
UI is an area of games development where my skills are not too developed, but I do have experience with UI, unlike UX, so I was not starting on a blank slate of skills. In this project my skills in UI where developed rather then refined as I was introduced to parts of the area that I did not know about, wireframes and fidelity. Given that I did not have experience in the specific skill, my wireframe UI designs went quite well and are representative, for the most part, of the final game as I do not have an options menu, pause button in the game and on the credits page I have two buttons at the bottom, one to return to the main menu and one to go into the game. My UI skills have developed well and will influence how I design my game in the future as I will more then likely include a wireframe design of the UI in the GDD.
Predicting issues
I did not have many issues to predict and that shows as the only issue I did predict was my coding skills as I was not sure if I could code a match 3 game and that issue was circumvented by following along with a tutorial for making the game. I did code some parts of the game such as the menus and score system but for the most part I did not have to worry about coding skills as they weren’t used enough to raise issues. I don’t have any amendments to make to that section either as I didn’t encounter issues with code or with design as the code I did was simple and the design was laid out in my GDD.
Game production
The production of the game went well, I had no hiccups in development it went smoothly then any other productions, I had no issues with game breaking bugs, the development is well documented through this blog as well as some posts on the Itch page. This game has not taught me anything to improve on but is likely going to be a large project to look back on in future productions due to the overall ease of development. There where several changes in design as the project went along which where influenced by response to user testing.
I made several choices through development that reflect on research I have done that are reflective of work done previously in the project such as the final visuals of the game pieces, all of them are different colours and in different types of colour blindness which was done in correspondence to the UX strategy work and my research into colour blindness. In the same vein, the name of the game is simple and one word, this comes from something I found early on about searches through to the Lanc Gov website (where the game would be hosted from the client brief) was getting its traffic through key word searches, which is why I chose to name my game “recycler” which matches the style of traffic that travels the website. Making small decisions like these to appeal to a wider audience and approaching the hosting website with thought is not key to the game but is part of a successful game as well as matching up with some points from the client brief.
User response
My evaluation of the game is important but the users response to the game is just as important, if not more so, I can learn a lot from creating and evaluating my game but I make games for people and what those people think will have a greater effect on what I should make then my own opinion. To learn what users think of my game in an unobtrusive way I have asked players to fill in a form or leave a comment on the page. I placed this below the controls but above the description of the game. Reading the description is optional and so the players who want to know about the game are the ones likely to see the link and more likely to have constructive input on the game and what they thought.
The main criticism received from the final version was the length, the singular level was too long and that it should be split up into multiple levels and having the game progressively get harder, in summary, the game needs more content. Given that this was a “mini playable game”, if it where to be developed further that is the major avenue of development, creating new levels and possibly adding new mechanics to create complexity rather then difficulty.
In the past, I have received much more user testing and looking back on development, mainly the 5th May update which was further along in my own development plan as well as reflective of what I received in the large batch of user testing. Several changes where made to the game by acting on input put forward by user testing. Changes to the speed of falling pieces or developing the score mechanic to reward or punish the player.
Jacob's game journal 