Matthew Stracey
Mobile Tower Defence
Developed as an introduction to mobile development, using Unity, I created a tower defence game that consisted of the player being able to create their own roads in the game.
Made for: ARU 2nd Year – Trimester 2
Duration: 4 Months
Engine: Unity
Language: C#
Position: Individual project
The Artefact
The artefact created will apply traditional and unique mobile development practices to build my own idea of a tower defence game.
The game will be round based and will ramp up in difficulty as the player progresses, there is no predetermined end to the game, the player’s goal is simply to survive as long as possible.
The artefact is primarily designed to work on a mobile phone, but consideration will be given in the later phases to understand any problems associated with using larger mobile formats such as tablets.
Aims and Objectives
Aims for this project include creating a game that is easily accessible for mobile users, this primarily includes implementing UI which complements mobile resolution and touch screens. Exploration should be done to see what different mobile practices fit when it comes to games, this can be achieved by exploring methods that are used in general mobile applications.
These mechanics must work in conjunction with the tower defence game, so that the artefact can show how these methods came be used in the games industry.
the game itself would include the player being able to build on a grid from a top-down view, which is seen in a variety of mobile games. The aim for this tower defence game is to explore unique ideas that can be implemented into the traditional idea, either by making the design better, or by adding to it. This will allow the chance to research the pros and flaws seen in released tower defence games and mould the artifact around designs and unique ideas to be tested. This could include buildable roads, map editing, resource management.
In a much broader aim, mechanics should be approached and implemented with UX in mind. This includes optimising the game for better performance for mobile and improving user experience through allowing several varying interactions within the game. I want to be able to effectively implement my ideas for mobile mechanics into the game, to show how they could be used for future projects for app development.
Approach
Approach 1: Zoom
In the artefact, the player will have a large map for them to traverse. And as it’s a tower defence game, they are going to be needing to keep an eye on locations and defences that are not efficient, so Pinch and zoom is more of a suitable fit for the game.
It’s important to take note here, that if the artefact is committed to pinch and zoom, then it’s also committed to being a game that is to be played with two hands. This is because the efficiency of pinch and zoom is lost when trying to do the motions with one hand, as users would have to position their hand awkwardly on the touch screen, causing less accuracy. When developing the pinch and zoom mechanic for the game, there are some key points to consider.
How will the boundaries be set for the camera?
Boundaries can be set via the use of empty game objects that could be placed on each corner of the map, then use the objects transforms to limit the cameras X, Y and Z values.
How far can they zoom in and out?
The player should be able to zoom out so the map is entirely visible, this allows for a better overview of the map and the player can move across to locations with efficiency.
Approach 2: UI tabs and scroll menus
As the game will be on mobile devices, its important to make sure that UI such as tabs and scroll menus are a significant size. This will better the user experience as it will avoid miss taps and make it clear what the UI is trying to show. When it comes to mobile, there are a few major points to consider for accessibility. When positioning UI, it’s important to think about hand position and mechanics like tabs can be easily accessed.
How will the UI be laid out?
To make the UI elements accessible, its best to place them in areas that are closest to thumb inputs from the user. This could be vertically to the right but can also be on the left for two handed games. Another option is horizontally across the bottom of the screen, which is a better option for when it comes to implementing drag and drop which can be seen below.
Approach 3: grid system and drag and drop
This element is an important mechanic that is to be discussed, this will be what ties the UI to the game itself by allowing the player to drag items off from menus and onto a grid layout on the map plane. The goal for this mechanic is to make this motion as fluent and easy to understand for optimum user experience. When the player has access to items should be clear, this includes greying out items that cannot be dragged off from the UI due to lack of resource.
How will the snapping grid be Implemented?
After doing some technical research in Unity, the engine contains an inbuilt system that sets out a grid in a 3D world. This grid will lay on top of the map so items can be snapped to certain locations of the grid, the implementation of this grid system also comes with a library of functions that assist of the making of this mechanic (snapping an object’s transform to the nearest grid section).
Approach 4: resource mechanic and gameplay
As discussed in the background and context, the way the developers of Plants vs Zombies have designed the games loop if far superior to that of Bloons TD, as the game should be designed to allow the player to make mistakes to learn from without the sacrifice of the entire run. The artifact is to be created with a similar mechanic of collection of resources that are gained by other means rather than killing enemies. Also, the gameplay will consist of another mechanic that will use the drag and drop feature discussed in approach 3, allowing the player to build their own roads to resources and using strategic methods to deliver the most amount of damage to the enemy.
How will the resource mechanic be implemented?
Resource stations will become available to the player after every round. The player can then build roads to these stations to collect the resource overtime.
How will the resource mechanic benefit the player?
Resources can be used for different kinds of defences, which the player can place at strategic points, or build strategic points with roads.
Implementation and Outcomes
resource mechanic and gameplay
This shows the result for the resource mechanic in the artifact, the functionality of the resource stations work well and there has been no encounters with bugs so far. However, there have been some difficulties when it comes to the gameplay of this tower defence game. Although the implementation of the resources themselves was not a challenge, the design of allowing the player to build their own road paths had clashed with the resource mechanic.
In this artifact, an attempt was made to try something new and unlike other tower defence games. This mechanic allowed the player to build their own roads as a strategic advantage. Problems had occurred with this design when a resource had spawned in a random location and the player would not have enough building materials to reach it, soft locking (a game bug that stops the player from progressing) the player from being able to continue as all resources needed to be able to reach the safehouse. This problem was fixed by allowing the player to activate and deactivate resource stations, allowing them the choice to swap roads to different resource stations.
After implementing the road building mechanic, it’s now understandable to why tower defence games have not adopted it. Allowing the player to manipulate the direction of where the enemies are travelling gave the player too much power, turning the feeling of the game into a sandbox or TD (Tower defence) simulator. Although this mechanic did not work in this game, there is a possibility of implementing this type of idea into a multiplayer player vs player tower defence game. For example, one player controls positioning of towers, while the other controls the pathing of the enemies.
Zoom
After doing research about different types of zoom as seen in the approach, its safe to say that the pinch and zoom method was the correct method of movement for this game. The mechanic feels very responsive and easy to use, while allowing the player to easily pinpoint locations to zoom in to. This method of zoom was vital to move across the map quickly and efficiently.
During development, the was a problem that had occurred which was unnoticed when on the approach stage. The problem was even though the boundaries did stop the camera from going out of bounds, it didn’t stop the view from seeing the outer edges of the map. This meant that if the player moved to the edge of the map, they could see beyond it. Trying to find a solution to this problem was taking up too much time as the system would be very complex, so instead, there was a slight design change to set the camera background to a solid blue colour. Although its not perfect and there could be some improvements, the functionality of the camera works very well.
UI tabs and scroll menus
As discussed in the approach, the goal for this mechanic was to keep the UI accessible. To do this, the style was kept very simple with clear understanding of what tab the player had chosen. After some experimenting with different positions of the editing menu, it was eventually decided that it should sit at the bottom horizontally as it was much easier to tap on mobile devices.
Unfortunately, the scroll function that is in the game can’t be used to the best ability, as the game simply does not have enough items in the list to make the scroll function visible. However, the functionality is in the game, so if the artefact was expanded later, the scrolling system would work automatically.
grid system and drag and drop
This mechanic was quite possibly the most complex one attempted with this project. It took a while to get a grasp on how drag and drop could be implemented, this was something that should have been looked more into on the approach to this artifact.
Although it took some experimenting, the drag and drop works well and ties the UI to the game. The way that this was achieved is the actual draggable part in the Ui is an image, once let go, the game recasts to that position on the grid and spawns the correlating object, the image then returns to the original position.
This system is essential for this artefact, without this mechanic, it would be hard to get a good user experience for placing down objects. The reason for this is there needs to be a location for the object to spawn at, and the drag and drop mechanic allows the player to choose that location. You could make this the same position every time, but them the player must find the object when they place it. Making the drag and drop mechanic makes it clear to the user that the location the object will spawn, will be where they place it on the screen.
Conclusion and Evaluation
game that is easily accessible for mobile users?
In terms of applying traditional and unique mobile development practices, its safe to say this was achieved to a high standard in the artefact. Though there were some challenges, the end product shows how functions like drag and drop, tabs and scroll menus and zoom can be applied to mobile games.
However, there were some things that did not fit right with these functions that could have had an alternative to fit the situation better. One example of this was the road building. Although the tower defences did work well with the drag and drop system, the road building did not. This was because it made the road building a very long and lengthy process as the player could only drag one road part out at a time, and then rotate the road if it was facing the wrong way. If this was to be done again, more research should be done on how to develop auto building, or perhaps road drawing. This would allow for a better user experience by cutting down the time it takes to build roads.
Another mechanic that could possibly be developed further is the zoom mechanic. The zoom in the artefact does set out what needed to be achieved, but there is room for improvement. To make the zoom better, it should be able to hide the background of the scene out of view, this means the player can only always see the map and nothing else can be seen anywhere on the screen. This would not improve what its set to achieve, but rather to make the game feel more polished.
Did the artefact explore unique ideas that can be implemented into the traditional idea?
The artefact does successfully explore unique ideas that can be implemented into the tower defence design. However, some of these designs simply did not fit right for the game made.
The outcome for researching new designs that can be implemented into the tower defence game came to a positive, but when it came to implementing it into the artefact, the outcome felt very unsatisfactory. To start with, the unique idea for road building did not work in this scenario. It gave the player too much power and made the game feel less like a game and more like a simulator, which ended up ruining the general enjoyment of the game itself and the game loop felt disjointed. With that said, there is a place for this mechanic in tower defence games, with the idea of adding pvp multiplayer, which could split the power between the two players and have them compete against each other to win.
As for the resource tower building, there is potential for this mechanic as it did work well in this artefact. Having the player collect resources by farming them overtime, rather than killing enemies, removed from the equation the possibility of the games feedback loop working against the player. Having different types of resources also gives the player choice to decide on what they should invest in for their defences. For this mechanic, it can be said that this was a positive outcome, as it meets the goal for being a unique idea that reflects on the traditional tower defence game nicely.
Overall, there is mixed feelings on the outcome on this project. When it comes to accessibility for mobile, the artefact excels in this area as the mechanics that were set out to explore worked well with the game and made for a good user experience. But as for the game itself, the same cannot be said. As it stands, the game would not be suitable for public release as some of the ideas that were explored were part of the main gameplay, and simply just did not fit for the type of game being made. With that said, the goal for this project was to explore ideas that ‘could’ be implemented into the tower defence game design. Although some did not fit in this occasion, it can be said that the ideas could easily be fitted in if the main game was changed slightly, e.g. multiplayer. So even though the ideas did not fit this artefact, the goal to explore new ideas for tower defence games was successfully reached.