#concept phase

[askagamedev]

As a follow up to your recent answer about game cancellations, don’t game studios need to present a much more coherent plan than that before production starts? I know things can be added or changed during development, but how come I’ve seen the narrative quite often that the creative leads couldn’t settle on a creative decision or direction and it killed the game? I thought games had a much tighter vision at the start of development than that?

I think you're confusing the part where third-party studios pitch a publisher, compared to the way things work internally. The way the process works internally is we start with a vague idea and a skeleton crew, then each green light meeting at each step focuses the core idea more and brings it closer to reality, while adding additional developers to the team in order to build more of that core idea. This means that the earliest steps of a game might be as simple as "Knights of the Old Republic 3", where the initial team's task is figuring out what "KOTOR 3" might actually mean. In a third-party studio, this is part is usually funded and bankrolled by the studio itself before it pitches the publisher.

The long preproduction internal projects that got cancelled were likely still in these fairly early stages, similar to [my own recent experience]. The main issue wasn't that they had strong ideas for what they wanted the game to be, the main issue was that they failed at transitioning from building cool demos and ideas to actually building the game they wanted to make. That transition can be really really hard, because every creative wants to keep being creative and having to roll up your sleeves and actually commit to stop being creative and actually get down to making the thing is immensely uncomfortable.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

How do you decide how high the player character can jump? Before any real stages are built or anything else, how do you decide what a character's basic verbs are and should feel like?

In my experience, these types of questions boil down to "what kind of experience do I want the player to have when jumping?" I try to answer general questions like "how do I want the player to feel when they jump?" A high jump would make the player feel small but able to explore and go places. A low jump would impart a sense of weight. A jump that has more hangtime feels floaty. Allowing players to change direction mid-jump gives a feeling of control. No mid-jump directional changes gives jumping the feeling of commitment and strategic thinking.

Once I figure out some first-pass answers I want to these questions, the next step is to build a prototype - a simple avatar that can move and jump with tweakable numerical values for things like jump height, distance, arc, hangtime, etc. inside a test level with platforms of varying heights and distances to try. Once I get that working, we playtest variations on the jump and see how it feels. If we find something we think feels promising, I iterate on it until it's good enough. If the prototype verb doesn't feel good after we've given it a solid try, maybe we cut our losses and move on to a new idea. We repeat this with each core feature until we have a solid core gameplay loop.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

The Conceptual Side of Getting Started with Game Dev

I’ve gotten [a lot of questions] over the years from hopefuls who want to start with game development. One of the members on our Discord server brought up a good question - aside from the technical aspects of choosing an engine and learning to how to do stuff, how do you actually do the “softer” side of the creation process? How do you actually come up with what core gameplay should be for a game? How do you recognize when you’ve got a good and/or feasible idea? How do you go from a high concept like “flying” or “building” to actual game mechanics? And what exactly is “core gameplay” anyway?

We’ll begin with coming up with the concept of the game. Your game concept should be short sentence or two that describes exactly what the player will be doing, like  “Cartoony kart racer on fantastical courses with deep drifting mechanics and kart-to-kart combat” or “Real Time match 3 puzzle game with attack mechanics and battle royale”. You may have heard of this as “the elevator pitch” - something you can say to somebody to get them interested in your game within the span of a few seconds. This is crucial for any game project to have - you absolutely need a strong concept to serve as your goal that the game’s development moves toward. You need something simple and unmistakable that you can refer back to and think “Will this idea help move the project toward this goal?” Once you have a concept locked in, you move on to creating core gameplay for that concept.

Core gameplay is the collection of literal actions players will perform in order to drive progress in the game forward. We call each of these actions a “core mechanic”. Core mechanics are usually verbs, like:

Fight

Run

Jump

Build

Explore

Trade

Match 3

Loot

Equip

It’s really important to have an understanding of [gameplay loops] as a concept for this part, because you cannot have core gameplay without actions the player initiates at these different time frames. Your core mechanics will be the actions your players perform most often while playing your game. They will be the elements that other stuff is built on. They should also be the first prototypes you build. Each of these needs to be tested for feasibility and engagement. If the core actions aren’t fun, it will be very difficult to make the stuff that you build on top of the core mechanics fun.

Good core mechanics will interact with each other in interesting ways, leading to players to explore them and feel out how they synergize. For example, Call of Duty focuses on fast-paced run-and-gun action, which is the combination of two elements - running and shooting. How do these interact with each other? There’s a lot of play between player locomotion (mantling, crouching, proning, walking, running, sprinting) and player shooting (accuracy, weapon effective range, weapon type, reload times, magazine size). Good core mechanics will feed into each other to provide a rich tapestry of things for players to learn and have fun with.

There are apocryphal stories about Shigeru Miyamoto asking for plain, nearly-empty levels when playing new game prototypes just so he can experiment with the core game mechanics. The story goes that Miyamoto wanted to make sure that playing the game at its most basic level was fun by itself without adding in things like textures, graphics, lighting, bells and whistles. That’s what your core game mechanics should be - the game should be fun at some basic level without a lot of additional fluff. When you are starting off, you need to figure out just what it would take to prove out each of your core mechanics, what a prototype of that mechanic would encompass. It needn’t be production quality anything, this is just a test to make sure that the mechanic is compelling and interesting to the player on its own.

This is how you get started building a game. You need to establish a clear concept, then break that concept down into core mechanics. Once you’ve decided on your core mechanics, build prototypes for those mechanics and see if it’s fun enough. Then, once that’s done, combine your core mechanics into a single cohesive prototype to demonstrate how they interact with each other. That’s a demo of what the game should be, and a starting point where you can expand from organically by building more - more variety, more enemies, more things, etc. for the players to act on with those core mechanics.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

FANTa Friday - Concept Phase Review, part 3: Putting it all together

Welcome to another [FANTa Friday]. The votes have been tallied and the winner is a Sky themed dungeon. Today, we’ll gather up the overall concepts we’ll be incorporating into our level design. This also marks the end of the Concept Phase Review. Next week we’ll begin on the Design Phase.

Visually speaking, we should plan for a lot of clouds, bird visuals, and airy architecture. Think of architecture like the Moon Door from the Eyrie in A Song of Ice and Fire - gravity makes going down easy and going up difficult. The natural theme of “ascension” plays very nicely with the concept of a sky-themed dungeon. We start low and work our way up to the boss. We need to accentuate this with architecture that allows the players to see where they should be going. This means open floor plans and clearly visible other parts of the tower. There should be more pillars instead of solid walls, open windows instead of closed, and the very real possibility of falling.

The theme of a sky dungeon also lends itself well to the final boss being some sort of dragon. It’s visually very distinct as well - the dragon circles the final wing of the dungeon that remains just out of reach until the player opens it with the mechanics earned throughout the dungeon. The player will be able to spot it from a distance, which builds anticipation for the coming climactic battle.

We are currently planning four dungeon wings (including the final boss wing), which naturally lends itself to a couple of different potential layouts, like so: 

This layout gives the player the most freedom to explore. Each wing of the dungeon would need some way to traverse to another wing, and the added benefit here is that moving from A to B isn’t necessarily the same as going from C to B, meaning that approaches from different directions can be rewarded, especially if some of these means of traversal are also gated by traversal mechanics.

A second option is a more diamond-shaped structure:

This is a bit more linear, but it also gives players a better baseline for establishing expectations. We gate areas B and C behind the mechanic earned in area A, which can function as a tutorial to the dungeon. This conveys a feeling of “opening up” the remainder of the dungeon to the player, which usually establishes a sense of accomplishment if the task doesn’t feel trivial.

One core design concept we absolutely need to emphasize is the idea of verticality and height. Humans don’t usually think in three dimensions because moving up and down is difficult - we have to use things like elevators, stairs, ladders, or balloons to do it. As such, we aren’t trained to look up and down when we enter a new area, we look around. However, with a sky-themed dungeon, we need to train players to expect it - it’s what makes a sky themed dungeon different than another dungeon with a skybox. We need to craft the visuals to draw the eye upward and downward toward elements of interest in order to entice the player to get to these places. This means crafting obvious points of interest just inside the sight line, but specifically above or below the horizontal.

To recap, here are our major concepts for this dungeon:

Verticality in architecture and elements of visual interest

Emphasize a sense of openness and visibility. No thick walls or tiny windows. 

Show the player places of interest that they will be able to reach later. Show the boss early on, but gate it from the player by the mechanics

Encourage the player to think in terms of Up and Down (Place obvious elements of interest above or below the horizontal, but still within sight)

When you’re coming up with a level design, you need to establish your main concepts first. These will inform the individual and specific decisions you make when creating the details and keep the overall vision consistent. If things get ambiguous, the core concepts provide an important overall direction for the dungeon. This helps keep us from getting into the weeds when we’re focusing on those specific implementation details and remember what the central theme of the level is.

Next week, we’ll begin the design phase, where we start using these concepts to begin designing the individual elements of the dungeon.

[What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday: Concept Phase Review, part 1 - Gameplay

The voting results are in! Readers have chosen a Skyrim-based Metroidvania style dungeon. This gives us a framework for the way the dungeon will progress.  Before we move on to the design phase, we need to outline the major goals we need this level design to hit. The major concept here is to incrementally grow in power. The player has to overcome some challenges to obtain some new power, then get to use this new power to do things she could not do before. In order to do this, we need to set some fundamental principles of how the level will enable to player to do that.

Gameplay Goals

The core idea would be a mostly non-linear level design with individual sections that offer different styles of gameplay and reward the player with a new mechanic for accessing areas in the game. Players could choose the order in which they tackle the different areas, with the final (boss) area gated (typically by those mechanics) until the other sections are completed. 

The critical path of each section will be a series of challenges that show the player why the mechanic will be useful, give the player the mechanic, then present a few challenges to teach the player use that mechanic and showcase its usefulness. Optimally, the same spaces could be used for both the initial training and to showcase the mechanic’s use. That way, the player will feel like their character has actually improved - this area that required all of this extra finagling and care before is actually quite easy to traverse now that she has X.

Non-critical path optional side rewards here are also good to reward exploration, as well as provide incentive. We will sprinkle some useful general treasures for the player to obtain while they are exploring the dungeon, but also gate some of them behind mechanic use. It’s important to show these gated rewards to the player even before they obtain the mechanic - it makes the environment more memorable and encourages them to go back once they get the new mechanic in order to obtain the reward.

The final leg of the dungeon should be through some sort of boss battle or other climax that utilizes the mechanics earned in the dungeon, preferably in a way that hasn’t been used before, but feels fair. It should be clearly visible from the get-go though - the player should know that something is here and it will be the climax of the dungeon. This helps build anticipation for this big, inevitable event. The player should know that, upon seeing the boss or final challenge that she cannot yet access, that she’s ultimately moving toward that climax.

If this all sounds kind of familiar, it should. This is the dungeon design template from the Legend of Zelda franchise. You show the player a new toy, teach the player how to use it, then give them some challenges to overcome with it. Old toys will occasionally also be used, and sometimes you get to use old and new toys together. It’s a fun recipe!

Stuff to think about

For the sake of scope, we’ll have to limit the number of sections to three at most. Three brand new mechanics will require some scripting to make sure they work, and we must be absolutely sure what their scope will be before we begin designing the levels themselves. Making stuff up on the fly can result in a lot of ruined work.

Also, we have a pretty solid concept for the level design gameplay, but we’re still lacking a cohesive visual theme for the dungeon. This is very important, since the visual theme is what will set the player’s expectations for the mechanics we’re presenting. There needs to be a solid main visual theme, which can then be broken down into visibly different sub-themes for each section of the dungeon. Next week, we’ll talk about the visuals and the expectations they’ll set in the player, and probably put the options up for a vote. Until then, here are a few examples of visual themes to consider:

Haunted Mansion

Water Temple

Lava Dungeon

Tower in the Sky

Ice Dungeon

Desert Palace

Underground Cavern

European Castle

If you have suggestions for a visual theme you’d like to see, please contact me via email ([email protected]), [twitter], or [askbox].

The FANTa Project has chosen its concept! We’re making a Skyrim Dungeon! [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Project Update: Names and Concept Roundup

I decided to call the follow-along project the “FANTa” Project. Follow-Along Not (quite) Tutorial  Project. It sounds better to say aloud than “FAP”. Maybe we can come up with a better name later on, but we’ll use this for now. If you can think of a better name for it, feel free to suggest. Otherwise, all updates will be tagged on the blog under #FANTa.

CONCEPT ROUNDUP

I’ve collected all of the concepts submitted for the FANTa project and posted them here. [You can vote at this link]. Vote for as many choices as you like; the choice that receives the most votes will be our project. Here are the choices:

Portal Bank Robbery

Counter Strike meets Die Hard

Left 4 Dead in High School

Super Mario Maker level chaining star invincibility to avoid death

Mario World Ghost House Maze

RPG Maker Wizards Tower Puzzle Dungeon

RTS Map where players must secure/proect a route for resource gatherers

RTS Map where starting base is far from the resources, forcing players to skirmish for them

Skyrim dungeon with multiple (probably 3) trials, each providing gear that grants access to certain parts of the dungeon

A space or naval RTS map

Portal Casino Heist

Stealth Objective Level in Divinity: Original Sin 2

[Click here to vote!]

For the sake of ease of use, any Mario levels would probably be done in Mario Maker. I am not entirely sure how I’ll go about distributing it, but we’ll see what happens. FPS levels will likely be built with Valve’s HAMMER editor, since I am fairly sure most of you have access to Steam. Any RTS level will probably be done with the Starcraft 2 editor. Anyway, happy voting! 

You have until 11:59PM PDT Friday (7:59AM GMT Saturday) to vote for the level concepts you like.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ