First piece of Advice - have ‘No Scrolling’. They said that scrolling maps reduce the ability for the player to focus on what’s important, and also increase the stress of the player because the player spends mental energy worrying what is happening off screen. Many Tower Defence games can simply overcome this issue by having the entire room size match the view size, meaning that there is no need for scrolling whatsoever. 

For my game, however, scrolling will be inevitable simply because of the game’s design, and changing these fundamentals would simply cause more harm than good. Regardless, this advice did get me thinking – even if scrolling is inevitable, are there ways that I can reduce the need for it?

Turns out there are. I discovered ways that I could automate certain processes, reducing the need to micromanage mundane tasks. I also added a ‘zoom out’ control, allowing players to see more of the screen at once. The effect of these changes has been that the game is now more fun to play, because people can spend more time focusing on what’s important and engaging, and less time navigating around the screen. 

Second Piece of Advice - provide ‘Total Information’. The writers suggest that providing total information (i.e. precise numbers about hit rate, damage, range, etc) creates a game that tests thinking, as opposed to the player’s success relying on guesswork, or simply luck. They mention that developers can add challenge by intentionally withholding information, but that often unintentionally frustrates the player.

​As a result of this feedback, I have started adding healthbars to all enemies. I do feel that the healthbars subtract from the game’s aesthetics, so I have made the display of healthbars optional. I think putting the choice of displaying stats or not in the player’s control is a good move, because it gives the player a chance to choose the experience that suits them best. 

Third Piece of Advice – provide 'Total Time Control'. When I used to play Plants vs Zombies 2, I would often reach a point where victory was assured. From then on, there was nothing to do except wait. When a game loses that interactive component, it can become boring. However, a few updates later, PVZ2 had introduced a  ‘fast forward’ button, leading to wait times being greatly reduced. Even though this was not a game changer, it was still a feature that did improve my PVZ2 gaming experience – it simply makes sense to offer the same convenience to people who play my game, so this is definitely a feature that I will include. 
​

The problem is I did not know exactly why the levels weren’t engaging. I could feel the effect, but I didn’t understand the cause. I didn’t know enough about what makes a good level to start creating them myself.

At that time, I could not find any definitive guide to creating a good tower defence game (my game will be this genre), so I asked myself – how does one of my favourite tower defence games (Plants vs Zombies 2) approach level design? 

They follow the 'Introduce -> Practice -> Integrate' formula. First they introduce a new plant, then they give you a chance to practice using it and finally, they help you to understand how this plant works in relation to other plants.  Once you fully understand how a new plant works – both in and of itself and also in relation to other plants – then they introduce a new concept/plant. Another way of saying this is that they don’t take you to the next stage until you have mastered the current one.

​Applying that to myself, I realized that my levels were too rushed – I was trying to introduce too much, too quickly. Implementing this principle to my own game has made me ‘simplify’ each level to an extent. I think this has helped me to start developing better levels.

For example, when they introduce flying zombies, in that same level, they also introduce a plant that can blow away flying zombies. When you think about it, all tower defence games follow this principle: Over levels, they upgrade or introduce new enemies, while at the same time, they let you upgrade your units or make new units available for you. What effect this has is that it keeps a good balance between ability and challenge, which is one of the conditions for a flow gaming experience (which I blogged about last week). 

​I know these principles sound so basic and simple, but I guess I had never really thought about them before. Haha, sometimes I take awhile to catch on :) Since Wednesday, I have found a few good articles on tower defence level design, so I will likely blog about what I learned from them (and what changes I have made because of them) next week. In the meantime, I am sharing two links.
 
1) This link takes you to a powerpoint presentation by Popcap games which outlines the PVZ2 development process.
2) This link takes you to a proposed list of the top ten free tower defence games of 2015 (subjective).
 
Hope you enjoyed this blog, and have an awesome week!
 
Cheers,
McDeezy

As I started designing levels for my new game, I decided to do some research into level design principles. I was not able to find a definitive guide that applies to non-platform games, but I knew that one thing I must do is get the balance right between novelty and familiarity, as well as between ease and difficulty. 

​People can enter a state of flow through many different forms of activities, with games being one of them. Do you remember a time when you lost yourself completely in a game? If you do, then it is likely at that point in time you were experiencing flow. 

The key lesson to take from this is that we should try to create levels that balance difficulty and skill, while also balancing novelty and familiarity. This is a good guide to ensuring that we make the kind of levels that do our games justice, and create the experiences that gamers deserve.
 
If this was useful, feel free to leave a comment and share. If you want to find out more about flow, then I suggest looking at Mihaly Csikszentmihalyi’s Ted talk. Thanks for reading guys and have a great week!
 
Cheers,
McDeezy

I recently re-read a Gamesutra article called ‘how to be a terrible game designer’. Amongst other pieces of advice, it warned that not using ANY feedback, or alternatively using ALL feedback are both recipes for disaster.

I believe that there are four different questions you should ask yourself and weigh against each other when you are deciding whether to listen to particular feedback or not. They are:

1) Is the feedback true to your vision? – Every game designer should have a vision for what his or her game will eventually be. He/she should know what tone they want their game to have, how it should make people feel, and the gameplay necessary to make that happen. Would implementing the feedback you’ve been given take you closer towards that vision, or take you away from it? The clearer the vision you have of your game, the easier it will be to know what feedback to listen to and what feedback to disregard. 

2) Is the feedback from a credible source? – What I’ve noticed as I enter this industry is that everybody – including people who don’t play or design games – are keen and willing to give you advice. When this happens, remind yourself:

​3) How many people are giving you the same feedback? There is a great quote from the movie ‘Lucky Number Slevin’ spoken by one of the main villains:

​If you get the same feedback from a diverse range of sources – even if the sources are unqualified - what it means is that a large number of people find that the game is not meeting their expectations in that particular way. At the very least, this feedback is something that you should seriously consider implementing. However, just because many people say it, does not make it right. For example, if you watched the movie ‘Casablanca’ you would know that it does not have a traditional happy ending, but it is the ‘right’ ending, and helped to make Casablanca the iconic movie that it is. So if you choose not to implement the feedback from the majority, make sure that you deeply understand your purpose for not doing so. 

One of the questions you can clarify whether the feedback is worth the time to implement is to ask yourself: what features are fundamental to make the game worthwhile, and what features are nice extras but not essential? Knowing the difference between these helps you to balance the difficult relationship between time and quality. ​

So to summarise, knowing when to implement feedback and when to ignore it rests on answering four questions:
​
1) Is the feedback true to your vision?
2) Is the feedback from a credible source?
3) How many people are giving you the same feedback?
4) Will implementing this feedback be worth the time it takes to do so?
 
If you liked this article, please share it with whomever you think will find it interesting. Until next time, have fun and good luck!
 
Cheers,
McDeezy