Hi, I'm Blake. My first game was '89 Doors', a rage game where you escape mazes whilst being pursued by an insatiable creature of hunger, and now I'm working on a tower defence game called 'Forgive Me My Henchman', where you play as a typical head 'bad guy', deploying henchman and sabotaging a building in an effort to stop a one man army action hero.
The advice I took and changes I consequently made are what I wanted to write about today.
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.
Final Thoughts - What I’m noticing is that my game keeps on evolving. As I am going through level design, and playing the levels, I am discovering what features add to the fun experience, and what features detract from it. As a result, I am always making constant tweaks to my game. Although these tweaks slow down the development process, it will definitely be worth it.
If you want to read more about some Tower Defence design tips, then I suggest reading the links that I did. They are:
- Optimizing a tower defence game for focus and thinking
- What makes a good tower defence game?
I wanted to end this by saying that this is my last blog entry for the year – I will be taking next Sunday off, but then will be back at it next year. I wanted to say happy holidays and thank you to those who choose to read my blog. I hope you have enjoyed it and found it useful and/or entertaining.
Next year will be a grand one, and definitely a year of big changes and growth.
See you in 2016!
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!
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.
So how do we create flow experiences in games?
So how does this apply to level design?
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!
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:
"don’t get law advice from a plumber and don’t get a lawyer to do your plumbing"
Make sure that you are keen to listen to feedback from those who really understand the subject matter and have a track record to prove it, and give less attention to those who don’t. For example, if Matthew Hall, Tom Francis, or Hideo Kojima provide game advice, it is smart to take it seriously because what these guys say carries weight in this field. On the other hand, if Arnold Schwarzenegger – who is not a gamer - gives gaming advice, it is better not listen to it because he doesn’t have the experience or qualifications necessary for his opinion on this particular matter to carry weight (sorry Arnold).
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!