Progress Update

A88Y doing a repository pull.

Hey everyone, long time no see! I've gotten no shortage of emails asking about the status of Dead Gear, and I'm glad to say it's chugging along as good as ever. Sadly, no game design theory post this time, just a big ol' trove of DG screens for the curious! Go ahead and click on'm to see them a bit bigger.

Illyia vs technology

 I've been hard at work getting all of our cutscenes, menus, and system infrastructure in place; and Ameen has been working hard as well to finish up the platforming code. As you can tell by the semi-annoying watermark up there in the top left, I've finally integrated the ORK framework into the game. It's still in beta at the moment, so we gotta stick with the watermark til then. It's been an amazing asset, and utilizing it along with our own scripting has saved us months of development time.

The opening title screen changes gradually from day...

... to night! And then to day again, in an endless cycle.

 Dan and Brian have been gradually working on the music and sound of DG, and I'm really happy with how the current batch of songs is turning out. It's really great seeing how much music and atmospheric sound can really liven up an environment.

The intro cutscene of Dead Gear is told in an animated shadow puppet-ish fashion, along with illustration.

It looks pretty 3D, but it's actually a bunch of rotating 2D images. Neat.

A88Y in a S.A.V.E room.

Save your games using the Simulated Assessment Validation Environment

What? It's a good name.

Several of the game menus are already fully implemented.

Inventory screen. Illyia opens up a small holographic display in-game when you open the menu.

Most of the work so far has been in the first accessible area of the game, Crashsite. (And the crashed ruins of the Daedalus.) It's a series of caverns that contain the warped ruins of a strangely advanced civilization. Many visual tweaks still need to be made, and several backgrounds are still incomplete, but I'm pretty happy with the general direction of it so far.

Exploring the Crashsite area of the game.

The tilemaps for Crashsite are mostly complete, although some extra tweaks are needed.

Illyia explores the upper Crashsite.

Mysterious character number 2!

Illyia discovers a warp point.

-Alex

Dead Gear Update

A cutscene in the beginning of the game.

Still working away on Dead Gear! Our long-awaited framework package will be coming at the end of the week, so we'll finally get to put the RPG and combat elements into the game. Getting pretty excited about the progress being made.

-Alex

Tutorials and 'Handholding' in Games

Finalized Look and Feel of the Flooded Cavern region of Dead Gear

How's everyone doin? In DG news, Dead Gear was pushed back a bit as we wait for a scripting asset that will save us a lot of time. The asset in question should be ready soon enough, however. Anyhow...

Today, I'd like to talk about tutorials in games. During the last few months at work, as we began to put all of the finishing touches on our (still under NDA) game, a particular topic was a constant source of discussion: tutorials; or how to 'teach' players new mechanics. It's an incredibly difficult branch of design to master, and unfortunately many designers simply don't bother half the time.

Of course, that doesn't mean tutorials should always be used. When a game uses tutorials over-zealously, it becomes hand holding, and (usually) nobody wants that. Why? It can feel patronizing, it can feel too easy and bore the player. In a casual mobile game that makes sales with micro-transactions especially, you risk a player getting fed up and deleting your game from their phone/tablet. After all, people want to play a game, not necessarily have it played for them.

Professor Easy, you smug son of a bitch, you think you're better than me?

But there are two devilish sides to the same coin: you don't want to dump a player into a game with nothing to go off of either. Some players will feel completely lost, confused, or worse, stupid. They won't know why they aren't able to figure out your game, and that will cost you the player. Mostly, this balance of Hand-holding vs 'Freedom to Fail' depends on the target demographic of your game.

Is this a casual mobile game, targeted at people who may never consider themselves gamers? (Angry Birds, Farmville, Plants vs Zombies, Where's My Water?)

If so, these games can be the most difficult ones to figure out proper tutorials and difficulty curves for. The more mechanics and skill-based you make it; the more you have to rely on tutorials to ensure that this target demographic really GETS it and isn't just fumbling through the game without learning the vital rules that govern the game. But if you flood the game with too many mechanics (and the tutorials that you'd need to go with them), the players won't really feel like they're playing a game.

Fling bird; hit pig.

Take a look at Angry Birds' tutorial here, that shows up on the very first level of the game. Angry Birds is easily the most simple, mechanically, of the example games I listed earlier.

That's because there is only really just one single base mechanic used in the entire game:
Fling Birds with the slingshot to kill the Pigs.

It's a very simple, easy-to-understand mechanic, and the simple, wordless, visual tutorial says all that needs to be said. After this one level, the player is even given about 10 levels or so to reinforce this simple mechanic, before introducing the Blue bird (That splits into three smaller birds when tapped again), which is also a fairly simple mechanic that builds upon the first.

Noooooo

But imagine if the Developers had put the Blue Bird level directly after the first level? With no reinforcement levels, players would be forced to learn a new mechanic without ever truly mastering the base mechanic in the game. Like a house of cards, videogame mechanics are often stacked upon each other; you have understand one mechanic to understand the next. If the player doesn't, well; the whole thing comes tumbling down.

Angry Birds has massive, massive international sales; and much of it can be owed to a simple fact: it's extremely simple and gives lots of room to reinforce any gameplay lessons taught to the player; and that fact has universal appeal across ages, languages and cultures. 

Well, sure; you say.
Angry Birds is so simple that the Devs probably didn't even need to put the visual tutorials in there, and people would have figured it out fine, for the most part. What about games with more meat to them?

Maybe you aim at more seasoned gamers, or just more complex games in general.

There are a few different ways to actually teach players a mechanic.

The first, like Angry Birds up there,  is to essentially tell the player straight up what they need to do. It's involuntary, you have to see it. We've all seen games like this: games that have entire tutorial sections or popups that show up on screen. It's probably the easiest way to impart information to the player, although also the most overly-expository. As such, it runs the risk of a player simply skipping it and learning nothing. It will need to be used in conjunction with a game-lock, a test, to ensure that the player has learned this lesson.

Yoshi's Island had great optional Hint Blocks you could use

It is this type that developers should be most wary of. Ideally, the strength of the level design should be strong enough to visually hint and prepare the player for the lesson. However, this in itself can be a trap, because developers often design with videogame 'common knowledge' in mind. Ideas and intuitions that may come as second nature to most gamers won't even occur to a less seasoned one. ("What's HP? I die when I fall down a pit? I thought it was just a different area!")

This brings me to a great example of good visual tutorials: 1-1 of Super Mario Bros.

Here we are at the beginning of the game. Let's say that the player has never played a platforming game before. Even right at the very beginning, the player will learn most of these consistent game rules just by doing them:

- I can move left and right.
- I can jump!
- I can jump over obstacles!
- The level expands only to the right!
- Goombas are hostile, I die if I touch them.
- Goombas are killed by jumping on top of them.
- ? Boxes have coins or mushrooms inside them when I hit them.
- Mushrooms make me big!
- I can't break bricks when I am small, but I can when I am big.

Wow! That's certainly a lot of things being taught in such a small area, even indirectly. Look at that Green pipe there. That's a good example of a Blocker; Mario can't proceed past the first screen until he's learned how to jump over obstacles; the most important lesson so far. Let's move on.

In the next section, we run into another new mechanic tutorial. A bottomless death pit! Notice how the very first pit is two blocks wide. Then, the next pit is 3 blocks wide, to reinforce the lesson of jumping over the pit. Alternatively, the player can jump up onto the bricks and skip the danger of the 3-block pit. Additional mechanics being learned here are:

- Green mushrooms give me an extra life!
- Some blocks have lots of coins inside them!
- I can avoid some obstacles if I'm smart about it.

In the next section, we run into another mechanic tutorial, and a new enemy. When Mario hits the ? block, and obtains the Star, the player may quickly realize that he is invincible, thanks in part to the change of music and the flashy effects. The player is given the chance to run through an entire row of goombas with his new-found invincibility. Alternatively, the player may discover an additional characteristic of the Koopa Troopa: jumping on it and then kicking the shell will make it zoom along the ground and kill the entire row of goombas!

Next, another jumping reinforcement. Jumping is the base mechanic in Mario, and in most platforming games; so it's absolutely essential that the player is taught the lesson and that the lesson is reinforced over and over. Notice how the level designer first makes a 'fake' pit to jump over. Even if the player fails, they'll still be alive. Then, it's the real deal. Notice how the design has given an additional block of running room as to allow the player to make a running jump.

Finally, we come to the end of the level. Notice that the designer reuses the two block running-space to hint to the player that they should make a running jump. Mario takes the jump, slides down the flag, and completes the level. In doing so, the player has learned enough lessons about how to play SMB to at least feel comfortable progressing through the next level of the game.

Even in games that are often touted as having zero hand-holding, such as Super Metroid, have several visual tutorials that force players to learn mechanics.

For example, when Samus first achieves the morph ball, (the ability to scrunch up into a ball and roll around), she isn't just allowed to leave the room. No, she must utilize the morph ball in order to even leave, again forcing the player to learn a mechanic in order to progress.

Most metroidvanias follow this pattern, in that they very often drop a player into a world without any menu-style tutorials, and instead rely almost entirely on visual and interactive tutorials to teach the player the rules of the game. Dead Gear will follow the same route for the most part, although for more complex mechanics, I will give the player the option for a more indepth explanation, a la SMW2 Hint Blocks.

There's still a great deal more to talk about, but I'll spare you the walls of text. (for now)

-Alex

If a Skill Tree falls in a forest, does it make a sound?: A glance at Talent Trees and Dead Gear.

Thanks, wikipedia.

 Consider the Skill tree. (Or Talent tree, or Tech tree, whatever you'd like to call it.)

It is a character development systems mechanic that tends to be seen in RPGs, that allows the player to progress their avatars in a widely customizable way, giving the player the option to develop their own playing styles. Although the origins of this type of progression mechanic obviously lie in Dungeons and Dragons and tabletop gaming (purchasing feats, abilities), over the past decade or so they have become a staple in even more mainstream, action games that want to add more complexity or depth to their gameplay.

But what makes them tick? What is it about Talent Trees that players enjoy? Let's pry a little into the history of the Skill Tree.

Now, let the fight over whose dice is whose commence

In the beginning, D&D players would lovingly create their own characters. Customization was an essential, core part of the tabletop RPG experience. Even then, D&D rule books would painstakingly craft large charts of feats, traits and abilities different races and classes would be able to take, complete with extensive criteria for each. With D&D, it tended to follow a logical approach to these feats and traits. You couldn't master how to wear heavy armor before mastering how to wear medium armor, for instance. You could only gain these sweet holy divination powers if you worshiped X deity. That makes sense!

As videogames began to encroach on tabletop gaming, these customizable feats and traits began to take a more abstract and simplified form to better match a medium confined not to a stack of giant, masterfully written tomes, but instead a low-resolution pixel screen. Even so, these early adaptations had much more in common with D&D than our current manifestations did, often filled with complex formula multipliers and redundancies. They allowed players to, although through limited means comparatively, customize their skillset and statistics by using a visual chart, with the skills and traits illustrated clearly on the screen.

FreeCiv's tech tree

At around the same time, RTS (Real Time Strategy) games were becoming a popular pastime for strategy fans.Many of these games made use of Technology trees, large charts clearly marking the relationships, prerequisites and criteria between each level of skills. For instance, you could not build a boat until you have a lumbermill. And you cannot build a lumbermill unless you have the knowledge of creating one! And don't forget about having to chop down the wood needed to build that lumbermill, etc etc. Whereas in RPGs, the skill tree was more about picking and choosing which traits you wanted to have, with only a meager allowance of points of which to spend; early RTS games often allowed you to master everything, with only time and your own ability to survive against your foes being the limiting factor.

Kingdoms of Amalur gave perks of jacks-of-all-trades

Mastery! What a word. RPG players have usually always shown a preference to mastering a specific skillset or role when given the choice of specializing in a role or becoming a jack of all trades; often chiding the inefficiency of trying to be everything at once. This attitude goes back to dual-classing in D&D (and perhaps common sense); some combinations were simply redundant, not very optimal or useful to use. Eventually, it may have given rise to the idea that a player should only be able to master ONE thing, or settle for being only okay at a bunch of things. Basically, Specialization vs. Versatility.

Many MMOs and RPGs have talent builds that vary wildly.

Skill trees helped visualize this spectrum. Should a player invest all of their effort into a single area, or could there possibly be pros to combining different areas?

This sort of meta-gaming was fueled by the great breadth of customization allowed by talent trees and skill allotment systems, especially in large MMOs. The craving for experimentation with different builds has became so great that it is now uncommon for a developer to NOT include a 'respec' (re-specialization) option for players to choose all of their talents/traits over again.  It wasn't long before even more action-oriented       games began to employ different forms of trait/skill allotment similar to skill trees.

ME3 eventually returned some of the breadth and complexity, but not all.

Although visually and technically not a skill tree, Mass Effect's skill allotment resembles one, mechanically. The player allocates points in a variety of skills and traits, unlocking more advanced skills and traits as he goes. Many agree that Mass Effect 2's streamlining of skill customization may have gone too far, severely limiting the depth of player customization, and by extension, alienating the original playerbase.

Other examples of forays into trait customization includes Final Fantasy 10's sphere grid system, which made the player level up all of their party members by traversing an enormous circular grid in a sort of puzzle-like manner. While it was certainly large and intimidating, it was actually much more linear than it seemed, only offering a single path for each character to go through, for the majority of the game. A later rendition of the game changed this, revising the entire grid and allowing the player to essentially pick, with lots of freedom, which class and which abilities each character should be.

Notably, the new Diablo-eque Path of Exile features a progression system very obviously inspired from FFX's sphere grid.

Where does this come into play with Dead Gear?

As you may recall in much earlier postings, my original vision for Dead Gear was a much more arcadey metroidvania venture, with new elemental attacks coming from found items and relics, which doubled as tools to progress the player through the game.

I liked the old system, but it bothered me that there was no real discernible character progression in the game.  Whereas the Metroid games could survive on finding new tools and weapons alone, I wanted to steer Dead Gear into more of a RPG-Metroidvania direction, with leveling up, stats and picking up items. And so, I eventually came up with the Gem Ring, which is a node-based system inspired from FFX's sphere grid, and to an extent, the weapon upgrading in Dead Space.
 An early version of the Gem Ring, shown above, shows that there will be 8 separate trees within Dead Gear, each with their own progression.

The Moonstone and Diamond trees

As the player levels up, they will be able to guide energy from the bottom into unpowered nodes, giving the player different stat boosts, active and passive abilities. Each tree offers its own element, weapon-type mastery and play style. For example, a player in one play-through may decide to master the Sword abilities, allowing them to parry attacks and do air combos, and even use a massive charged attack move. Another time, perhaps they will focus mainly on summoned familiars.

To balance this, I added an 'Attunement system,' giving the player the choice of two trees to become attuned to at a single time. Becoming attuned to a specific tree means that you are granted all of the stat bonuses, passive bonuses and active abilities granted to you in that tree.

The top 1/2~ of every tree is locked off until a player decides to 'master' that particular tree. I plan to allow players to unlock the full potential of perhaps 2-3 different trees in the first play-through.

One half of a fusion node is energized from the left side.

In addition, as all 8 trees are next to each other, but technically separate, I decided to add a bonus to players who decide to master or level up complimentary trees, called 'Fusion Nodes.' They are special active and passive abilities that can be unlocked only if they are unlocked on both sides. As an added boon, the fusion nodes will be accessible from either tree, if you are attuned to one of them!

Voila! Now the fusion node is unlocked and is usable by EITHER tree.

Anyway, that's my little spiel on player progression and skill trees for now.

-Alex

Dead-Ends in Games, and How to Use Them

A 'Dead-End' in Dead Gear. Or is it?

Let's consider Dead-Ends in games. What are dead-ends?

 I would define them specifically as such:  

An non-essential area or path in a level that the player can take that will require backtracking to return to the original 'correct' path.

 Dead-Ends have long been touted as an exercise in bad game design by older game design veterans; particularly those who designed multiplayer maps in first-person shooters such as Doom, Unreal, Quake, etc.

They have a point, a player running into a long corridor only to find no reward down there might feel betrayed, or annoyed. Certainly in multiplayer deathmatch maps, which were the norm back then, you generally want to keep a circular flow to the levels, allowing attacks and escapes to occur in any direction.

But even then, there were exceptions; I remember even in some of the multiplayer deathmatch maps, it was common to have a long corridor with a powerful pick-up (either a powerful weapon or full armor) at the very end. The fact that you would have your back exposed the entire time you ran down the corridor to get the powerup, and that you'd have to run all the way back; made it a risk vs reward situation; something that spiced things up and that many players appreciated.

The One True Way indeed.

But that's an entire different genre. Different games and genres will generally have different reactions to a dead-end.

For instance, RPGs (particularly JRPGS) can be maddening when you find a path that leads to nothing. I remember playing Suikoden Tierkreis on my DS; a very well produced JRPG, but not without its flaws.

But two flaws in particular, in combination, inspired a rage in me the likes none have ever seen.

-Long Dungeon Corridors that lead to nothing.
-Random Encounter Battles every 3-5 steps.

It made what should take a 15 minute romp through a dungeon into a grueling hours-long affair; irritatingly and artificially extending the playtime of the game. It could have been more easily forgiven if it wasn't such a pain getting to the end of a corridor, OR if there was a nice reward for doing so.

Catching view of a Strider

In more linear, single-player action games, dead-ends are not often used, much to the detriment to the game. Valve, of Half-life fame, used them on occasion, either rewarding the player with heath, ammo, hint or a visual treat that the player would not have been able to see otherwise.

For instance, near the beginning of the game, as the player walks through City 17, they can walk down a dead-end alleyway, and catch sight of the spider-like Strider enemies, something that they won't be facing until the end of the game.
Valve is quite skilled in rewarding the player venturing off the beaten path.

And that's really one of the greatest boons to dead-ends: it prevents a game from becoming too linear, without having to create alternate pathways to the same destination. It can also intrigue the Completionist player, who wants to find and explore every inch of a level. But if used irresponsibly or unfairly, it can just irritate people playing the game, especially if there's a lot of unnecessary backtracking. Interestingly, Elder Scrolls: Skyrim was extremely gracious in that most of their dungeons exist in a large loop, connecting the final room of the dungeon with the very first room; allowing the player to skip backtracking through the entire dungeon. This was handy because it also allowed level designers to be more ambitious with their designs, creating points-of-no-return, obstacles that would force the player to defeat the dungeon, unable to go back the way he came.

Dead-Ends can also cause a few pretty interesting player behaviors! Take a look below.

Let's pretend this is a map for the last part of a First Person shooter level. There are three paths at the end of the initial corridor, but only one leads to the end of the level. To continue, the player will just have to guess to head to the right if there are no visual or audio hints to guide him there.

As you can see, if the player takes the wrong path, leading to a dead end, they are forced to retrace their steps.

The fact that a dead-end does not provide essential gameplay, means that the player is not required to enter the dead end to complete the level. 

This of course means that the dead-end can not contain anything that is essential for completion of the level or later levels, if one cannot return to this area later. This is mostly an issue in level or chapter-based games.

 You can also justify a dead-end by making it essential to traverse in order to progress in the level.

In this example, the player needs to find the green key in order to bypass the green door. In this case, it is not really a dead-end as much as necessary backtracking within the level.

A possible fault with using this strategy exclusively is that eventually the flow of the level will feel much too linear if taking every single path is essential to beating the level.

There's an interesting behavior I've noticed in players that play games with branching paths and dead-ends.

If one particular path is clearly marked or hinted that it is the correct door to go through, players will always almost NOT take that first! Why? Because they don't want to miss the chance to find hidden goodies elsewhere in case that hinted doorway is actually a point of no return.

Samus cannot traverse these spikes until she gets the grappling beam.

This brings us to the most relevant genre to Dead Gear; the games that feature an open game world that are not sectioned off into stages or levels.

This includes games such as Zelda, Metroid, Resident Evil and Castlevania. One of the common traits between all of them is that they feature backtracking to a degree. Another is their use of Game-Locks.





A game-lock is a level design mechanic that is, for all purposes, a Dead-End for the player; until they obtain a new item or ability (or trigger an event) that allows them to bypass it. In a game like Resident Evil, it can be something as simple as finding a key to a matching door that they found in a dead-end ages ago on the other side of the mansion.

In many ways, the Game-lock is one of the essential ingredients to creating a Metroidvania game; ensuring a fairly linear game while retaining an enormous game world with branching paths. Look at this map of Castlevania:SOTN. While enormous, the game limits your progression entirely on abilities gained. (Although, in the game's greatness, entire regions, bosses and abilities are completely optional!)

Another important caveat is that in SOTN, there is not a single dead-end that is unrewarded. Even if it's something as simple as a small health item or a crappy weapon, the player won't feel cheated for their efforts in exploring.

Mining Drill in Greenlight Mines

Let's take another look at the Dead Gear picture I posted at the top of this post. This is an example of a Game-Lock that also functions as a Dead-End. He simply cannot progress any further with his current abilities. But the player may notice the opening from above; and even if he doesn't, he will remember the large mining drill, making a mental note of it. When he returns later with a new-found ability and manages to get through that opening in the ceiling, he will feel accomplished and proud of figuring out this Game-lock.

There's a lot more to talk about, but this post has gone on pretty long already. See you next time.

-Alex

A few little screenshots

Figured I should show a few extra screenshots of what I've been working on!
Over the past month or so, I've been doing the next pass on Dead Gear's graphics, tilesets and animation;
in addition to a ton of systems and combat design.

There's still a lot of work to be done, especially in getting tiles to mesh correctly, restricting camera movement so that it doesn't show certain section; (will be raising the camera so Illyia is not in the center of the screen, as well, but rather below the center.) Still pretty unpolished, but acceptable for this stage of development, at least.

Does this look familiar? Ingame version of my very first mockup. Still needs a background.

Inside the ruins of the airship.

Outside in the snow

Illyia, your room's kind of a mess.

Updated concept of Title screen, will shift from day to night.

 -Alex