At the heart games are about solving problems. So my question is – How can we as game designers come up with new and interesting problems for players to solve? Firstly we must understand what a problem means in a game.
As an example a problem could be a deadly pit ahead of a running hero, precise opponent’s troops positions that surround the king, lack of wood blocks for building a house, or simply keeping your headshot streak high in a shooting game. I think you get the point. They are all obstacles in the progress of the game, and players have to deal with them in order to get the desired result.
Now how does the player actually deal with it? That is, what actions are available for execution? For the previous examples it might be pretty obvious… Well you jump over the deadly pit. And in order to save the king you think through it and effectively destroy enemy troops. To build your house out of wood you will have to go into the forest and cut more trees. And finally to keep your headshot streak high you must aim precisely.
Guess what? All of our actions are secretly just verbs – Jump, Think, Destroy, Go, Cut, and Aim.
It might be a fun little practice to pick your favourite game and list all of the verb-actions you can possibly think of doing in it.
All you have to ask yourself is – What can I do in this game?
In fact that’s exactly what I’ll do now.
Verb-Actions in Games
Team Fortress 2
Some of these might seem less like immediate actions and more of a play style, but they still work because they allow for alternative solutions. So let’s remember that verb-actions are tools and ways that allow player to solve specific problems in games.
It’s really easy to come up with verbs for a new game, in fact it’s as easy as picking random verbs from the dictionary.
The real beauty emerges when you think of an individual verb-action acting upon multiple objects. Let’s pretend we like the word Gather, and let’s ask ourselves – How many other objects in the game world can we gather? Actually the more the better! This will greatly increase game’s emergent behaviour. As in Minecraft you can gather every type of block and then you can also place it anywhere. Each one having a slightly different property. Another verb-action would be Shoot – Can you shoot the car, glass, mushrooms? Or Walk– Can you walk on the walls, ceiling, or the moon? It get’s pretty crazy fast, but most important it forces you to think.
Another important question to ask is – How many different ways can we Gather, Walk, Shoot? Multiply the number of objects by the number of ways and you will know exactly what value you’re getting from a single verb-action.
One Step Further
What if we take the opposite of a verb-action? What about its neutral state? That’s an interesting question. Opposites could be used against you by the opposition or a penalty to hinder your progress. Opposite is basically the negative effect of what you’re trying to do. You can think of a medic healing a heavy, who is taking constant damage. Or collecting and spending resources in StarCraft. It’s a problem and needs to be handled with care using appropriate actions.
Neutral and Opposite
Have a go and make your own list of interesting and creative verb-actions. Once you do you will know exactly what is in player’s control, and you are now building problems appropriately for the players abilities.
I would argue that player’s input is the single most important element in games, and the biggest reason why people play them. We must explore further! We must create more problems and empower players to solve them in a creative and unique way.
I wanted to write on this subject for some time now, actually ever since the game was released a year ago (got to love my timings). What I want to do in this article is to break up the game and it’s process. The mistakes that were made during development, how the game lost it’s real direction, the importance of communication in a team, and a bit about publishing the game.
As we go I’ll also post a few simple lessons that I learned from my mistakes.
Everything began with a discussion with Gonzossm – a popular animator from youtube, a really good friend of mine, and the future artist/animator of Deadly30. We had never worked on a game together prior to this, but the eagerly awaited event was right on the doorstep. The idea we had in mind is to make a simple flash game, playing as a character surviving in the wild that would involve tower defense elements and exploration for resources.
We thought the idea was interesting and unique, which would probably take us less than a month to make and get us some quick cash from a sponsorship and licensing from flash game sites. Plus we had nothing better to work on anyway.
Trying To Design
The first design was actually based on a completely different theme from the final. You would play as a king who builds up his castle with resources he finds outside, to defend from crazy animals at night.
I don’t really remember exactly how we went from that, to shooting zombies with guns. But I remember we liked the idea of having special kinds of character classes for different tasks, think of TeamFortress2.
Assault – The one with powerful firepower.
Engineer – A mechanic who builds turrets and repairs walls.
Medic – This one is obvious. Hint “healing”.
Not long into design, it showed that it would be impossible to play the game if one of the classes wasn’t around at all times. So we instead mixed the abilities and went only with a weapon class system.
American – Uses automatic machine guns.
Russian – Uses long range and sniper rifles.
German – Shotguns, can’t miss these in a zombie apocalypse.
The problem with the design is that that’s all it was – Three characters that utilize different weapons, who upgrade and defend their base at night from evil zombies, and go out searching for resources when the day comes, oh and make it last 30 nights!
At the moment it seemed fine, what more did we need to know? Well how about the huge amount of technical details that were completely overlooked. Our “design” sounds more like a scenario from an action movie.
Controls? What moves can the player execute?
Any distinct enemy types? cool mechanics?
How do enemies spawn? Different for night & day?
How long does a night & day last?
How far can you explore? Any limits? Endless repeating background?
What resources can you find? What can you do with them?
What weapons and tools do we have? Are they all interesting?
Do we have enough progressive content to last 1 – 30 nights?
How about balance? and strategy?
And a million more things!
We blindly began working on the game from a simple concept, as if we knew exactly what we were doing.
I strongly feel this was a prime factor that crippled the whole game. We began noticing huge design flaws half way in the game. Good example would be at the moment in development where zombies were all kind of.. the same and plain boring, walking and attacking with their hands.
This is when we decided to add *drumroll* a crow! A pathetic attempt at trying to add a new gimmicky gameplay element, with different movement and attack.
Adding it to a system that was designed only for walk-able enemies caused tons of bugs. Turrets and AI companions were terrible at dealing with something that wasn’t on the ground. The attack of a crow was pointless too, once it got close to a survivor it died by getting slashed, doing no damage.
This was only one of the problems when adding a new feature in the middle of the game to a system that doesn’t support it. If only we had invested some time into thinking about technical design it would have paid off immensely.
Lesson 1. Games are much cheaper to make on paper.
I should however note that you can’t design a complete game from the start. You will get interesting ideas as you go along, sometimes it works, and other times it’s like a dead end in a labyrinth. Which will cost you dearly once you decide to turn around.
Let’s Get To Work
The first few weeks of work kept a steady progress. One thing I really liked is how Gonzossm presented the artwork to me. It was a bunch of simple sketches that quickly gave the feel for what the game might be. It also allowed us to make any graphical changes with out sacrificing a lot of hours as it would if the artwork was finalized.
The code was in ActionScript 3.0 with decent object oriented principles. I spent no time thinking about a game architecture and got right into the code (Again a poor decision).
1. Clashes in Development
When you have two people working together on a single game – an Artist, and a Programmer. I think it’s important to have both members doing game specific elements.
How much health do green zombies have?
How many zombies do we spawn at night 8?
How much scrap metal can you find each day?
Properties / Statistics / Balance etc..
This was not the case with Deadly30. I did blame Gonzossm for it, as if his thinking was “I’m an artist I do art and animations for the game, Iggy is a programmer, he will deal with all the numbers”.
But I come to realize that infact it was my mistake as a programmer who failed to give the right tools to the team. Game scripting is what I’m hinting at, which would allow anyone to edit simple text files that store properties for game elements with no need to recompile the game. Deadly30 had no scripting. Everything was hard coded, only for my eyes, yet I was angry at Gonzossm for leaving me on my own in this area.
The final game turned out to be coded and balanced all the way by me, with some feedback from a few testers. Gonzossm took care of the aesthetics – art, animations, cutscenes, he also licensed music and voice actors. Which was great, I couldn’t have done better, however I strongly feel we did a poor job working as a team.
Lesson 2. Work closely with your team members.
2. Hopeless Hope
Few weeks into the project you have your player running around, shooting zombies and repairing the fences. You think to yourself “Yeah this game is definitely going to get done by the end of the month”! And right after that think, “Oh why don’t we add this feature, it would make the game so much better”!
Well that’s pretty much how the entire development process went on until the end. Lack of direction but a constant stream of new ideas on the go. My list wasn’t getting any smaller, and I could not predict the next thing to expect on it. This was very bad, because how can you design a system for something like that? You’ll have buggy code, or end up spending hours rewriting it again.
Worst of all it feels like this hell is never going to end. The problem here is you never estimated how long the game would take you, because quite honestly you couldn’t have, not with the sort of design we had. A month seemed reasonable back then, which at the end turned into 7 months.
3. The Hellish Phase
I think most game developers can relate to me here. Yes! That moment when you’ve been working on the game for longer than you should have. You start to HATE everything about your game, it just seems plain stupid and boring. Why are you working on this? The code is a mess, the design is flawed, the best thing that comes to mind is to start a new project. Start with clean design and clean code, that’s a very strong temptation!
I think after the first month of working on the game that’s when I felt it. It’s very demoralizing when you can’t trust your own deadlines anymore.
I have to say that the hardest part of making Deadly30 was this hellish phase of development. I almost gave up a couple times. What got me through is the support of the people who believed in the potential of the game.
The only thing I can recommend in this case is keep yourself motivated. Work on the things that you enjoy, work fast and keep a steady progress.
Lesson 3. Progress is a powerful ingredient to motivation.
4. Unexpected Surprises
If you started out to make a simple flash game, then do that and just! We didn’t and it bit us.
We chose Flash because it’s easy to use and a great platform for simple lightweight games. But once we turned our small game into a big game, this was a bottleneck we found ourselves stuck in. Something of Deadly30’s size and requirements really pushes the border of Flash. All graphics were stored inside “Movieclips” as vector graphics which are rendered using CPU (I can’t stress it enough how slow this is). This problem is tightly related to design and careful planning for your exact needs.
Another thing is that we used a non-standard resolution (750 x 460) because it doesn’t matter as much for games you play on the web. Imagine the surprise on my face when I figured we had to be able to run the game in full-screen.
The biggest question people are still asking is “Why isn’t this game multiplayer?”. Because quite frankly this game looks like the kind of game you would play with your friends online. Unfortunately this was another case of poor planning and another one of those things we couldn’t foresee in the beginning. In hindsight we were limited by the capabilities of Flash, something we should have looked into earlier.
Publisher / STEAM / Greenlight
When the game was nearing completion, or rather a state it was mostly playable, it was looking a lot better than something you would play on web portals.
Games like VVVVV and Binding of Isaac were both made in Flash and had success on Steam. This is when we decided to try our luck with getting Deadly30 on Steam.
Gonzossm and I put together a little trailer for the game to raise publicity for the game, in hopes get good feedback from the community and be able to show it to Steam.
Gonzossm is very popular on youtube, so we used that to our advantage with the trailer. After around 120,000 views and lots of amazing comments on the trailer, we sent out the application to Steam, to which they never replied. Not even mentioning any reasons why this might not be a game for their platform. I understand they are big and probably have too many applications to go through each day, but I felt it was very unprofessional. Like an option to answer or ignore an incoming call there should be a reject button, so people wouldn’t be waiting for many months in hopes.
Not long after that Gonzossm received an inbox message on youtube from a publisher by the name of Headup Games, they were very interested in publishing the game. They were so sure the game would get on Steam, as if they knew someone on the inside. I personally thought that was a great catch, maybe that’s how all games get on Steam in the first place? I wouldn’t know. I’ve never dealt with retail publishers before, all this was completely new to me.
So they asked us for a 50% cut of the profit. I spoke with Gonzossm and a few friends about it, and it seemed like a reasonable cut. “They get us in, we both make a lot of money!” So we agreed on it, signed a contract and got to work.
Many months in and the publisher had no luck in getting the game on Steam either, what a shame. Now we were pretty much self selling the game on Gonzossm’s advertising power. The only people buying the game were his fans from youtube and facebook, and we were giving away 50% profits for what exactly?
Now I’m not saying the publisher didn’t do anything at all. They spread the product to sites like Amazon, Desura, Gamersgate. They also got many review websites to write about Deadly30. It’s important I just don’t think it’s worth fifty percent.
Also many thanks to everyone for buying the game, it keeps me independent for the time. In total I believe the game sold over £10,000+. Not very sure of this though because all the sales information goes straight to the publisher, I only get my cut later. I have no control, no stats, and this is very bad.
There are serious costs to pay when you surrender control. There is a time and place for publishers, but I’m pretty sure I’ll be self publishing my next game.
Sometimes when I look back at this game the word “failure” pops up. Probably because there were more mistakes made in development than there should have been. Still, regardless of the faults, this is the biggest game I’ve made, and I’m proud of it.
It was a very expensive learning experience to me personally, I don’t think I’ll ever forget.