Bulletpattern Game design, Flash and Unity development

18Jan/170

Creating Game Depth with Adverbs

Intro

One of the first game design books I ever read was Chris Crawford on Game Design. It's a great beginner design book and introduced me to the concept of "verbs" in game design. Crawford suggested that the more verbs a game has, the better the game. A game is great when you can run & jump, but being able to run, jump, AND swim is even better!

However, adding verbs is often very expensive from a development standpoint. No developer ever wants to hear, "Your game is great but could you just add jumping, swimming, shooting, flying, hiding, or something?" Hearing something like this is often a case someone giving you a solution (add more verbs) instead of identifying the issue (gameplay needs more depth).

 

The Pitfall of Power-ups

A common misstep in a "your game needs more depth" situation is to add gameplay modifiers such as power-ups or relying on more content.

A bunch of power-ups cannot save a shallow core game design. In our shooting gallery example (you'll see below in a minute), a 3-way shot might be pretty cool but your player goals don't change. A player would still run out of gameplay when hitting 20/20 targets. Power-ups can make a game more interesting but the game is still built on a base of sand. You must make gameplay deeper before you start layering in gameplay modifiers.

Lots of content looks appealing on the back of a box (More levels! More skins!) but they cannot save shallow gameplay. Again, your core gameplay has to be strong, and not easily exhaustible, before players will keep coming back for more and care about your expanded content.

 

Adverb-ing?

So following in the spirit of Mr. Crawford's verbs, I propose adverbs are the way to add depth to your verbs. It's not just what a player a can do, it's how they can do it. It's also when they can do it.

OK, let's make an example to show adverb-ing in action.

 

Example Game

Imagine you have a simple "shooting gallery" game where objects move across the screen horizontally in 3 stacked rows and a player  can move horizontally at the bottom of the screen and shoot the objects. The verbs here would be "move" and "shoot". This is a simple game type but you want to make it more compelling. The first step is to add a scoring system. (We are going to use this scoring system as a rough estimate of game depth.)

  • Every object you hit is worth 10 points.
  • Each round spawns 20 objects

Now the player has a score delta potential of 0 - 200 points in increments of 10. Players can replay the game but once they hit every object in a round, there is nothing else to do – i.e. no more depth to the game.

Now let's add some adverbs to "shoot". Let's do "shoot quickly". Now each object is worth more points the less time it has been onscreen. Let's say an object is onscreen for 3 seconds and now the score per object is:

  • 10 * (3 - timeOnscreen in milliseconds rounded up)

Now we have a score delta 0 - 600 with much greater granularity. Players are now challenged to shoot every object but to do it as quickly as possible. An additional layer of depth has been added to scoring, but more importantly, now the player needs to make choices since all the objects are not the same value at a given time. The player can ask themselves, "Should I shoot this object that has been onscreen for a while and risk missing one that just appeared onscreen? Or skip it and take a guaranteed shot at more points?"

This is a shooting game so clearly we need "accurately" as an adverb!

  • The more centered the shot, the more points it is worth
  • 3 concentric rings of score – 10, 25, 50.

Now our score delta is 0 - 3000.

Let's add a bit more depth with the adverb "far". The farther the player's shot travels, the more the object is hit is worth.

  • Objects in the back row are worth more than the front.
  • Row bonuses are x1, x1.5, x2

This adds depth in scoring and choice as well. Player's may try to "dodge" the front row objects to hit the more valuable back row objects. Now our score delta is 0 -4500.

Now for the big gun adverb, "consecutively". We are going to add a combo system! Let's say if a player keeps hitting objects within a 1 second window (i.e. no more than 1 second between objects hit) they get a combo bonus.

  • Combo bonus =  +0.1 per combo
  • 2nd object hit in combo = (50 (accurately as possible) * 3 (fast as possible) * 1.5 (average row bonus)) * 1.1 = 330
  • 3rd object hit in combo = (50 (accurately as possible) * 3 (fast as possible) *1.5 (average row bonus)) * 1.2 = 360
  • ...
  • 20th object hit in combo = (50 (accurately as possible) * 3 (fast as possible) *1.5 (average row bonus)) * 3 = 900

Now our score delta is 0 - 9,225. Now this is practically an impossible score. No player will be able to hit every target dead center, as quickly as possible, and combo the entire game. Or maybe they will. Players constantly surprise developers 🙂

 

Adverbs of Time

I am bending some grammatical rules here with adverbs of time, so bear with me.

Another power adverbs have is adding depth without adding buttons. This is especially useful in mobile development. One of the best ways is to add depth is creating actions done while performing other actions. For example, in our move & shoot game, shooting while moving could have a special action like curvy the shot or making the shot move more quickly. Or shooting while not moving gives the player faster rate of fire..

Nintendo are the absolute masters of hiding depth in their games but maintaining simple, often one-button, controls. Some of the best examples of this are in the 3D Mario games:

  • Jumping while jumping straight up does a butt bounce
  • Jumping while jumping forward does a dive
  • Holding jump while diving performs a belly slide
  • Jumping while changing movement 180 degrees performs a back flip

These kinds of actions don't have to be purely player controlled. The same verbs can be modified by the context of the action. Performing an action when hit by an enemy or near an environmental obstacle can modify core verbs.

 

Adverbs Add Depth

You can see by the above exercise how much depth can be added to a very simple game with a few adverbs. If we use our score value as a measurement, our 4 adverbs increased scoring depth by over 45x. The adverbs also added a number of choices the player will have to make to maximize their score.

You can modify actions and controls (without adding buttons) by using adverbs of time or context.

So they next time you have a game and it's feeling flat, ask yourself not what verbs to add but what adverbs you need.

 

Filed under: Game Design No Comments
25May/160

Scripting MOBA AI

I have recently gone back to our MOBA, Adventure Time Battle Party and it reminded me about how I wanted to write up a post about the AI. There were a number of important lessons we learned and I wanted to share them.

 

Ground Rules

We didn't have much time to pursue, what I would consider, strong AI on this project. However, I love working with AI so I made time on weekends to work on this. So to be economical, our explicit goal for AI in Battle Party was "don't be dumb", which is very different from "be smart". Also, my approach to AI is rooted in "make it fun" more than an academic approach to AI, where you might be trying to emulate an algorithm or advanced behavior.

Also, AI was an aspect a number of our team wanted to learn. To keep things simple, I set up and simple state-based AI system and wrote a number of tools for newbie AI scripters to use.

One thing that's important to me is: don't cheat. I try as much as possible to not leverage any data a real player would not have. I don't want to rely on letting the computer know every last detail of a player's state or inputs and make decisions based on that knowledge. There are times when the CPU overhead of certain checks are just too expensive, and in that case, I allow myself to cheat.

 

The "Danger" Measurement

The backbone of the system was a collection of systems that produced a "danger" value. This produced a simple integer that allowed the scripters to make decisions. This system took into account:

  • The number of alive players
  • The number of nearby ("nearby" being 1.5 screens IIRC) enemy players
  • The number of unaccounted players on the mini-map
  • The number of nearby enemy minions
  • How far ally/enemy minions are pushed. This was a +/- value depending on where the minions were pushed relative to the mid-point of the map.
  • A queue of when the AI sees a player use powers. This is a good example of not cheating. Instead of looking at the player cooldowns, when the AI sees an onscreen player use a power, it lowers the danger value by a specific value for a certain time. Higher value powers lower the danger value more.
  • The powers currently available to the AI
  • Player/AI health values
  • Player/AI buffs
  • Being close to an ally/enemy tower
  • Some other items as well.

 

Basic States

The basics were patrol, attack, and flee. Since the more danger there was, the more an AI champ would flee, the back and forth between and attack and flee states created some good dive in/dive out behaviors and some pretty good kiting. If the danger value got too high, the AI would flee to allies, health pick-ups, towers, or the base. If the AI had a power that created movement, it would use this power to run away if pursued (i.e. in a flee state and a champion was close).

If the AI didn't have a champ to attack, it would push minions, help allies, capture altars, patrol, or do special actions. more on social actions later.

 

Listen for Events

Loads of events can trigger a decision to change the state – taking damage, a tower being attacked, the base being attacked, an ally champion being attacked, the danger value changing significantly, altars being open or captured, etc. Many events. Lots.

 

Special Actions

In my experience, I have found you can throw in 95% of random behaviors and 5% of really smart decisions and player's will think your AI is a genius. With this in mind, I did a couple of one-off, hard-scripted behaviors to use occasionally.

  • Tower Dive – Very rarely, when the danger rating was very low and a player was hiding under a tower, the AI would tower dive. During this brief time, it would just go HAM and ignore the danger rating and try to kill the player.
  • Ambush – If the Ai had nothing better to do, it would hide in the brush for a time and wait for players.
  • Dodge – If the player used an aimed power and the AI had a power that could be used to dodge, it would do so.

 

Other Tools

I wrote a number of tools to facilitate other scripters. Things such as "do I have a clear shot to my target?" This mean you could fire a projectile without being blocked by minions. There was a similar check that informed the danger rating on the AI, "does the player have a clear shot to me?

There were quite a few utilities like "find closest safe point", "are targets in range of my powers", etc.

 

Leading the Target

One of the biggest lessons we learned was about the value of trying to lead the target when aiming powers. Every scripture's first instinct was to try to predict player movement and fire where the player would be in the future. This might be good for a game where player velocity cannot be changed instantly, like FPS or racing game, but in a MOBA a player can "juke" (i.e. dodge) in any direction instantly, so the value of prediction is greatly decreased. Experienced players will nearly always dodge. We found that it's statistically more likely to hit player just aiming randomly in a radius around the player than trying to lead their current movement.

 

Conclusion

The AI turned out pretty good considered the limited resources we had. Quite a few people got to try their hand at scripting AI and they only needed to worry about strategies around the character's power set, instead of learning about managing behaviors states & calculating distances.

Filed under: Uncategorized No Comments
24May/160

Multiplayer Ranking Systems vs. Declining Population

The Problem

A solid ranking system is required for a healthy, competitive online game. You want same-skill players to be facing each other – you want your newbies playing and your veterans playing veterans.

A good skill system will allow high-skilled players to quickly rise in the ranks and only face like-skilled opponents. You want these good players away from the lower-skilled players as quickly as possible.

The more granular the system you have, the better matched players will be. Having numerous ranks gives players goals to work towards and the more goals the better.

But what happens a couple years after release and your game's population dwindles? You may still have a small, but dedicated, set of players who can no longer find matches due to your ranking system. What was previously a great feature of your game has become a detriment that will kill your game's community all the faster.

This unfortunately affects the players at the top ranks the most. These are your most passionate players and they are already in the smallest population pool. They will be punished the most with the longest matchmaking times.

 

A Solution(?)

A system that adjusted the number of searchable tiers separately from actual ranks would be better to offset population reduction. These searchable ranks would  shrink and grow depending on average concurrent users.

In our previous game, we had 4 ranks and 14 sub-ranks. We did matchmaking between ranks, and then allowed to expand to more ranks after a set time. Five minutes per rank, if I recall correctly. This means a high-rank player might have to wait for 15 minutes to search the entire player base for a match.

What would be better is something along the lines of:

  • Player population high = Matchmake as 4 ranks
  • Player population low = Matchmake as 1 rank

And some couple gray areas in between. This would mean when the game is healthy there are loads of ranks and similar skill matches, but as population dwindles you sacrifice skill-matching for getting games started at all. I think this is a sound trade-off.

Filed under: Uncategorized No Comments
3Nov/152

On copying games (re: Battle Party)

"Why did you copy that other game? Don't you want to make something new and original?"

Of course (nearly) all game developers want to make something new and original but there are a great many factors that inform a team's decision on what game to make. I want to give my perspective on the decisions that may go into making an "in-genre" game. I hope I can change a few minds that think when a game is influenced by another game, that the developers are not just creatively bankrupt or making a "cash grab".

We are fans

This might be a surprise, but most game developers are game players too. We are fans of all the same games every one else is playing. You know when you sit around with your friends playing a game and say, "I like Game XYZ, but I would LOVE this game if it had this and that"? Well, game developers have those same conversations and we (sometimes) get to do something about it! We can make the game we would love to play.

For Battle Party, the team liked LoL, DOTA, and other MOBAs. However, we are filthy casuals and find the standard MOBA formula too complicated, too toxic, and find the games take way too long to play. We wanted to make a MOBA for people like us.

 

Existing Team & Tech

OK, so maybe you want to make a FPS with a grappling hook or, in our case, a super streamlined "Arcade MOBA". What existing game engines or code base do you have already? What does the current team have experience or expertise making? Do all of these things line up?

Our team had a lot of experience with 1) multiplayer competitive games and 2) Diablo-style isometric games – a perfect fit for making a MOBA.

 

Business Goals

Now you have the game you want to make and the team to make it, but does it align with your parent company's goals? Is anyone going to give you time and funds to make it?

In our case, CN needed a competitive online game with global appeal. A game where we could roll out new character-specific content over a long period of time.

We had been wanting to make our take on MOBAs for a long time and the opportunity finally presented itself. We had the right design for the business goals, we had the team and tech, it was a perfect fit!

 

Deadlines

Game deadlines almost always slip. However when making games for a television company, there is a lot on the line. There are episodes of shows being produced, commercials being made, worldwide marketing plans being created – the game has to go out on time. The is no wiggle room, not a single day.

Here is where the risk of something new is a huge gamble. We have to ask ourselves, "Can we make a game that's new & innovative, in a year, with this team, that's good, on time and in budget? Can you 100% guarantee that?" There is absolutely no way you can guarantee that.

I have worked directly on 50+ games and consulted on 100+ more and I have seen how many times something truly unique, something that sounds really exciting on paper, ends up either a) taking way longer to "find the fun" than you imagined or b) turned out being bad in development, no matter how much work you put into it.

 

Conclusion

The next time you see a "copy" of game, consider that it might be the game the team was really excited about making. Maybe they had the right skills and tech already in place so they could worry about the fun part of development – making the game fun and not having to worry about making it just work. Maybe their parent company's needs aligned perfectly with something they were passionate about. And maybe they had 6 months to make it.

 

30Oct/150

Better Game UI

I work on quite a few games a year and over time this has added up to hundreds of games. During this time I have seen the same UI mistakes over and over again. I want to share a simple improvement we make to improve game UI. I will be using fake examples as to not call anyone out.

Main screen

First, let's look at an example main game screen.

main

This is functional but it could be much better. I get why developers do this – it's easy & flexible. A developer can create a single button asset with a dynamic textbox and dynamically place the buttons. The number of buttons can easily grow and updating copy for changes and localization is easy.

It can be more than just ease of development too. Sometimes UI designers come from web or app design backgrounds or a game studio leans on their website designers for UI design. However, the rules for good game UI are very different than web/app UI. The core concept that differs is that web/app interface does not seek to suggest what users should do, game UI should do this blatantly.

To make better UI, ask the question, "What do you want players to do?"

Do you want players to hit HIGH SCORES just as much as you want them to hit PLAY? No, of course not. Once you have your answer, you have an idea of what element should have dominance. The best thing to change is the size of the desired action input. This will work regardless of language, icons clarity, or color blindness. The larger size also draws players' attention best. You could also change the color or shape.

main1

There are numerous ways other to improve this. You can add icons for people who cannot read (i.e. kids) or non-english speakers to clearly delineate the "neutral" buttons.

This isn't too much more work. Instead of one dynamic text button, you make two – a neutral button and a call-to-action button. On screens with no clear call to action, using all neutral buttons is acceptable. You can expand this concepts with a call-to-action button, a neutral button, and a "back" button, when you have numerous screens that flow back and forth.

Now let's look at UI issues on the "Level End" and "Pause" screens. I am lumping these together because they usually have the same issues.

 

Level End or Pause screens

Here is what I see too often. Again, this is a fake example.

end

Again, a call-to-action is needed – what do want players to do?

end1

If you are too pressed for time to make two buttons instead of one, at least arrange buttons "in order of call-to-action", in this case, home, level menu, restart, play/continue.

 

Conclusion

Find what you want your players to do and make that the dominant interactive element! Making 2 buttons is not that much harder than making one and the clarity it provides players is worth it.

Filed under: Uncategorized No Comments
11Dec/140

Adventure Time Battle Party – design goals

When we set out to create Adventure Time Battle Party, we had some specific goals in mind. I can proudly say, we achieved every goal we set out to accomplish.

As a team, we all love playing MOBAs, but there are a number of standard systems in MOBAs that don't align with our sensibilities. We wanted to make a MOBA that we would love to play, and by extensions, kids (and kids at heart, like us) would want to play.

We sat down as a team and defined the things that we didn't like about the standard MOBA design. Here were the top issues:

  • Games take too long to play
  • The shop is too complicated
  • Other players are... not very nice
  • First 10 minutes of the game are boring
  • Power balance can snowball too easily

 

Gameplay Time

I think the well-earned reputation that many MOBAs have of a toxic community is, in part, related to lengthy game times. The shorter the game, the less time a "bad player" is wasting of their teammates. Also, in classic MOBAs, people have down time to worry about what other people are doing – they have time to inspect players' actions and critique them. In our game, there are shorter play times and very little down time.

Making the game shorter might sound easy but nearly every single aspect of the game determines the game length: character power, map design, item power, minions, towers, everything! One of the most difficult aspects of the limited game time was fighting the inclination to make everything thing a little tougher or last a little longer. Here is a conversation we had about a million times:

Developer A, "The towers go down too fast, we should make them stronger"

Developer B, "If we do that, a game will never end before time runs out."

Developer A, "Oh yeah, I forgot about that."

We want games to end with a team clearly winning and destroying the other team's base. Thats always best but we made a scoring system for when matches go too long.

 

Scoring

Since we had a set gameplay time, we had to have a scoring system. The score system took some time to sort out – how much is everything worth? Shouldn't KOs be worth the most? Are there things players are unfairly farming the most score?

We are really happy with how scoring has affected the game. It has created new metagames where players will play purely for score and snipe points from other players. Jungling becomes twice as valuable since it gives XP and score. It also balances nicely because if players try to get a score lead and then just defend their base, the other team can easily overtake the score lead (and XP lead) by farming jungle monsters.

And nothing is more satisfying than winning by score right at the last second.

 

In-Game Store & Backpacks

In our research, the #1 difficulty wall for new MOBA players is the in-game shop. However, just removing it seems like a terrible idea – the store is too important. So we asked ourselves, what is a system that accomplishes the same job as the store, but is far simpler?

We set out to make a system to that 1) allows for player choice & play style 2) creates champion depth 3) allows for counter building and 4) can show off Adventure Time items. Adventure Time has a ton of cool magic items and weapons!

The Backpack system was the answer and we are very happy with how it turned out.

 

Backpacks, Builds & Toxicity

Another goal we had regarding the store was that there would be no "wrong" way to build a champion. While this concept would allow for player exploration and customization, another goal was to reduce toxicity. We don't have chat, so players cannot be toxic to each other, but players can still feel toxic. If a player looks at a teammate's build and thinks, "My teammate is building their champ incorrectly!", they are going to be playing in poor spirits. If there are no right builds, how can a teammate say another teammate is wrong?

One of the big decisions in this system was that all (well, nearly all) powers align with your Power Damage stat. This was players cannot look at a champion and think, "You are dumb if you build PD on this champion."

This has been very successful. We see all kinds of unexpected builds and counter builds.

 

Champion Designs

Champion design is the most fun part of making a MOBA. Before we got started on designs, we set up some rules to reflect our audience and our design sensibilities.

  • Everyone is equally overpowered – when reading hero designs, everyone of them should sound “too good.”
  • No hard support powers – no hero should have a power that only helps teammates. Any support-type power should be a strong benefit for the player as well.
  • No match-up specific skills – no hero should have a skills that only works against certain other skills or heroes. (e.g. “This skills let’s you eat Princess Bubblegum’s traps’)
  • No non-counterplay powers – No powers should be 100% unavoidable. (e.g. A skill slows all opponents in the game)
  • No clicking directly on opponents  – while skill shots are traditionally harder, we have found our audience had more trouble with direct-click powers.
  • No mana, cooldown only.
  • There should be a "wrong way" to use a power – Powers not should be always good.  (e.g. a power is good when an opponent is alone, but not in a group, or it is good when an opponent is CC'd but easy to avoid otherwise, etc.)

 

Toxicity

No chat. That's about 90% of the problem.

We also avoided powers that made players feel like this teammates were "supposed" to be doing something. Here is a story from development.

At one point a champion had a healing aura.  During the first "testing session" (i.e. the team playing as if their lives depended on winning) with this power , people were yelling at each other, "WHY ARE YOU NOT HEALING?!", "OMG HEAL ME!" etc. This power was immediately changed. After this we kept a close eye on player behavior around power designs.

I also think the toxicity of MOBAs is due to worrying about what your teammates are doing. It's easy to look at someone and think they are doing something wrong and then get angry at that player. Clicking on the map to move gives a player down time – down time to worry about what their teammates are doing. The request for clicking on the map to move often comes with "I want to be able to look at my teammates". We talked about this feature many times internally. I feel strongly that clicking the map to move is a slippery slope towards "down time features" and toxic behavior.

However, we did let players press SPACE while KO'd to watch teammates.

 

Snowballing

For those unfamiliar with snowballing, snowballing is when a team gets a small advantage, and that small advantage leads to another advantage, which leads to a huge advantage. Repeat until winning.

The opposite of snowballing is a stalemate, where teams are kept too even and no clear winer can be determined. Balancing snowballing is a careful balance between snowballing and stalemates.

Step one was to remove idea of gold and buying items. While our XP/level system somewhat replicates the cycle of "winning objectives = gold = overall power", we took getting a KO bonus against higher level opponents to an extreme level. This way if a team gets huge lead but does does not have the skill to keep it, the other team can easily catch up.

We also flatten out the power level at 10. We tuned a lot to ensure players can hit max level in a 15 minute games unless they get crushed by a much higher skilled team.

 

Conclusion

We had a number of other successful goals, like a solid development pipeline and champion balance, but those are core development goals, not changes to the game genre. We set out to make a MOBA that we wanted to play, and we certainly accomplished that.

 

Filed under: Battle Party No Comments
5Jul/143

Adventure Time Battle Party is out

adventure-time-battle-party

http://www.cartoonnetwork.com/games/adventuretime/adventure-time-battle-party/

 

Filed under: Uncategorized 3 Comments
23Apr/1413

Adventure Time Battle Party beta!

2014_03_03_BattlePartyLogo_B-2

Oh my Glob, you guys! The Adventure Time Battle Party MOBA is in closed beta. You can get in on that sweet gaming action!

Join the party now!

http://www.cartoonnetwork.com/games/adventuretime/adventure-time-battle-party/index.html

You can play all day Thursdays, or throw down with the devs during our scheduled play tests, Thursday nights from 8-10 EST!

Join our discussion on Reddit - http://www.reddit.com/r/battleparty/

 

Filed under: Uncategorized 13 Comments
28Nov/1318

FusionFall Heroes – Marceline sketches

While going through some old files, I found some sketches I did for Marceline in FusionFall Heroes. These were attack animation concepts. Some of them made into the game, some didn't.

20131128-130436.jpg

20131128-130427.jpg

Filed under: Uncategorized 18 Comments
1Jul/132

First boss last

I am currently working on an iOS game in my "free time" (haha, I don't really have any), mostly to learn what it takes to make a mobile game. My day job is making PC games but I feel it's my duty as a developer to stay informed of the current trends, and mobile games are surely the trend right now.

My goal was to learn the ins and out of the iOS platform, and what sort of unseen challenges mobile development can bring. In my experience I have discovered developing certain types of games, or developing certain platforms, can have large unseen challenges which must be taken into account when designing or managing a project. While I certainly learned many things about iOS development, I also have learned a very important design & development lesson. A lesson I am hoping I don't forget about when I start my next project.

That lesson is this, when you first start on your game, you are at your weakest. You don't have the hang of the development pipeline quite yet, maybe your art style or technique is 100% refined or maybe you don't have a full roadmap for the game. However, when developing a game, you often start at the beginning. You start at level 1, and then develop to the end. This means your later game content will be of greater quality than your early game content.

The problem is,of course,  more people interact with your early game content than your late game content. If you early game content isn't the best it can be, players won't ever make it to your late game content!

In my current project I have definitely fallen into this trap. My first boss fight is pretty terrible. It's confusing and doesn't build properly on the skills players have built up to that point. The other boss fights are pretty nice! Especially the last boss but who is ever going to get there when the first real payoff moment for players is so weak?

So my new rule is – do your first boss last. This is when you will be at your best and you can give your best to players.

Filed under: Uncategorized 2 Comments