Search the Community

Showing results for tags 'prototype'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Design
    • Projects
    • Design Discussion
    • Tools & Tutorials
  • Off Topic
    • Games Discussion
    • General Discussion
    • Site Support & Feedback


  • Articles
  • NLD Originals
  • News
  • Projects


  • NLD Dev Blog

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 3 results

  1. Building a ScenarioIn this post, I’ll go through the steps I take to make a scenario, or level, for InnerSpace. However, two things before we get started: 1) There may be what some consider spoilers in this post and, 2) We’re in early development, so there are still placeholders in place for certain elements of the game.What is a Scenario?Scenario is kind of a unique term that we’re using with InnerSpace to refer to our “levels.” Since our world consists of large bubbles that are open for the player to fly/swim around as he or she pleases, we’re designing scenarios to be placed into these bubbles. If you’ve ever played Skyrim, think of these as the forts that are scattered throughout the world, or as the dungeons. In a way, they’re levels inside of a larger level…level-ception (queue the Hans Zimmer-esque brass section). The ProcessStep One: DesignDesign inspiration can come from anything. I get ideas from games, movies, books, and even architecture. For example, the scenario that I’m going to walk through today came from an idea from the Harry Potter series.Once I have the initial idea, I start drawing. Using graph paper (and a lot of it), I begin to draw out how I wanted the level to look. Once I have a solid idea the dimensions are mapped, I move on to step two.Step Two: Whitebox and PrototypeThis step is the first time I go into the software; in the case of InnerSpace, that’s Unity 5. A Unity plug-in called Probuilder, made by ProCore, helps a lot with the quick creation of whiteboxes, which are levels built out of simple shapes, like cubes.Once I have the whitebox looking how I want it to look, I do the most important thing any level designer can do: I playtest it. And once I’ve playtested it for a while, I continue playtesting. While playtesting, I continue to make notes on my graph paper. I tweak the sizes of objects and areas, and I add and remove walls until I’m ready to make the changes to the actual level, inside Unity. And this is where I get my best work done: the process of playtesting and tweaking levels. I’ve never met a level designer who has produced a perfect level on the first try. I add one block and then playtest that one area for ten minutes before moving on, and so on.While whiteboxing is the process of making a level out of primitives, prototyping is the process of making a level function how I imagined. (This is where I put on my programmer hat.) I’m, by no means, a master programmer, but I try. It’s important to me that everyone else on the team can have a full understanding of my idea for a level, so I prototype.Once I have my level prototyped and whiteboxed, I playtest, again, and make any necessary changes. Then, I move to step three. Step Three: Make it prettyIn last month’s Kickstarter update, we talked a little about the modular system we’re using for the towers in the game. We’re doing this for a number of reasons, one of which being so that someone like me can build pretty towers and scenarios without constantly bothering the artists to make me pieces. This is a new way of building levels for me and has taken some getting used to, but it has worked out extremely well so far. Typically, I’d build whitebox a level, making sure it’s fun to play and works how I want, then pass on the whitebox dimensions to environment artists for them to build specific pieces (assets) for me to place. The way we’re building InnerSpace actually is a little like using Forge, in Halo, in that I already have all the pieces I need. Since I already start with all of the pieces, it’s up to me (and the critiques of three artists and a creative director) to make a scenario that’s interesting, both in looks and in gameplay.Once I figure out the modular pieces that fit my scenario best, I move on to step four.Step Four: Back to the Drawing BoardAfter adding the modular pieces, I’m forced to return to the initial design and make changes. Since I am limited by the pieces that I’m given, I have to sometimes tweak and bend my levels around them. At this step, I bring out more graph paper and sketch out any changes that need to be made to the interior of the pieces. And one by one, I implement those changes, playtesting each change as I get them in. The Harry Potter ScenarioSo, that’s the process of making a scenario, in general terms. Now, I want to walk you through, step by step, me making an actual scenario from the game.Step One:In Harry Potter, there exists a set of stairs that moves, often leading the students to the wrong location (as seen in The Sorcerer’s Stone). I realized that something like that in InnerSpace would do a few different things: 1) create an interesting challenge while flying, since the player now would have to fly inside of a moving structure, and 2) offer an interesting way to implement different paths inside of a single structure (fun for the player and fun for me to make). The first time you fly through it, the stairs might be leading to the top half of the structure, and the next time they might be leading towards the bottom. In my last post, I talked about the challenges in designing levels for InnerSpace. I faced every one of those challenges when designing this scenario.Below are some of my hand-drawn sketches of this scenario. Step Two:Below are screenshots of the individual pieces of the scenario built in Unity 5 using Probuilder 2. There are entrances in Pieces 1, 4, and two in Piece Six. In fact, two is used twice (that’s an image of the top one, but there’s another identical one underneath it).The second image is a screenshot of the whole scenario put together in its actual form. I always find that this step takes the longest, and it usually results in the level looking completely different. Often, it’s like designing a whole new level, since sometimes something on paper doesn’t translate well into the software. This scenario was no different. I had to redesign this one three different times until I reached its current state…which is probably going to see more changes down the line.Step Three:Each part of the scenario is made of at least one modular piece. What’s cool is when they’re combined, they make completely different shapes, which adds to both gameplay and visual appeal. If you look closely at the image below, you can see that I use a few of the same pieces in several different places, but when combined, such as in the second image, they have a completely different look. Step Four:For this scenario, I’ve made several changes based on feedback from the team about the appearance, playability, and overall design. Since we’re shooting for a design that fits the aesthetics of the world, I know that there will be things that change about this scenario as the world around it is developed and comes to life.ConclusionThere’s just something about getting out the graph paper and white boards that makes me love being a level designer. I really think that it’s an extremely an important of the process to make a successful design. Brainstorming before ever even touching the software, then once in engine, being efficient. I follow the guidelines I made on paper, then playtest until I can play the level with my eyes closed. Playtest, and playtest, and playtest. When I make a change, I don’t just move on to something else, but then playtest at least ten more times.I’ve always glad that I learned how to script. It makes me feel more valuable as a level designer and teammate. I’m not afraid to script my own levels. They’re never as pretty as something a programmer can make them, but they help everyone involved in the game.Finally, I’m never afraid to revisit the drawing board. As a level designer, it’s my job to make sure every level/scenario that the player plays is fun, and sometimes that requires me makes changes or scrap ideas and make something new. After doing level design long enough, I’ve learned to never become too attached to any levels, as anyone who’s ever worked with me knows… OrdinaryPoisedDanishswedishfarmdog-mobile.mp4 *Note: This article is posted on Next Level Design with permission from the author Source: Follow JeffTwitter:
  2. Several years ago my work tasked me to build a cooperative dungeon themed around a volcanic palace. We wanted the dungeon’s difficulty to rise across a series of rooms and end with a fight against the Fire King. At the half-way point through the level, we wanted to challenge the players with a combat-puzzle encounter.For my prototype of this encounter, I locked the players in a room with several waves of combat and environmental hazards. Each wave, the players needed to complete an increasing number of objectives in order to survive lava that would rise through the floor.Outside the specifics of the theme, I designed this encounter to test player coordination across multiple objectives under pressure. The encounter also served as a gear check through the enemies. In the abstract, this encounter is typical of raid design, which was our goal. The problem was the theme and converting my prototype to final art without losing clarity.In one of several meetings dedicated to solving this problem, another designer asked why the Fire King would have this hazardous room in his palace at all. This led to question about who (within the game’s fiction) built this room, why they built it this way, and what happened since it was built.When a level is able to answer these questions, it passes a test I think of as “architectural realism”. If a level does not hold up to this scrutiny, and we’re left saying “no one (within the game’s fiction) would have built this place or built it this way”, it fails the test of architectural realism.This concept overlaps with environmental storytelling, world-building, and immersion, all of which are important for high-fidelity AAA narratives games like Last of Us and God of War (2018). As an industry, we place a lot of value on these concepts.But my level was not for that kind of game. We used a distant 3rd-person camera, larger-than-life characters with exaggerated proportions, and abilities that worked at massive scales. We built our levels and the environment art to match.So, when one of these design meetings entered a third hour of argument to solve the problem of architectural realism, I was ready to ship the level as it was, in Mario-like abstraction where primitive meshes clearly conveyed their function. Immersion be damned.Architectural realism had no place in the problem we were trying to solve, and the efforts to pass its criteria wasted development time and made the encounter’s mechanics opaque. A bad application of best practices made my level worse.Now, when I see the ideas of architectural realism described as best practice, I remember how it can harm the development process when it does not serve the intended experience. Here for example, Mark is correct when referring to most real-world architecture, but most real-world architecture ports badly to video games. This is obvious for those of us who learned level design through modding; our rite-of-passage was to build a replica of our house—or school, or office—in Counter-Strike, Doom (1993), or one of so many other games with mod tools. This was a rite-of-passage because it was a painful realization that we can’t just copy what works in the real-world because the context is different. Even within the same genre, the context of Quake 3: Arena was different from Unreal Tournament 2004. An excellent level in one game will be different, often terrible, in another.The act of design is to recognize a context, its local needs and constraints, and find a solution that fits best. The practice of greyboxing is a way to prototype a solution, evaluate how well it fits the context, and—in professional game development—communicate the solution to the team. The study of level design is too often concerned with the skills of building and not the skills of design, which persist across genre convention. Christopher Alexander wrote about design this way in his 1964 essay “Notes on the Synthesis of Form”, where he created a visual metaphor of constraints and relationships. The dots each denote a constraint, and the lines denote relationships. The + and – along each line indicates whether the constraints support or conflict with each other. This visual metaphor is powerful because it lets us step aside from convention and any dogma around best practices to instead face the specific needs of the problem.In real-world manufacturing, material and production—what Alexander labels “economy”—are real constraints. Even in our digital world of level design, material and production are constraints we need to consider. We have our level construction processes, our art asset pipelines, and our production methodologies. We also have our studio cultures and divisions of responsibilities. All of these factor into the local context within which we solve our design problems.For my lava palace encounter, the values of architectural realism diminished once we recognized the whole context of our production process. Solving the encounter for world-building and immersion conflicted with too many other constraints. // Around the assumed best practices of AAA development, there are assumption of roles and responsibilities. In some studios, level designers are also layout artists, world builders, environment artists, content designer, scripters, and quest designers. Each game and studio has its own needs. (Jeff also clarified in a later tweet that his advice “can be true or false depending on the situation”) On another project as a professional level design, I spent several months sculpting and painting terrain. I placed foliage and props. Again, I did this work as a level designer. For the experience we intended to provide, we needed rolling hills and grass, and someone had to implement that solution to the design problem. This is level building, but we still call the job level design.As another example, look at Dear Esther. Where does the level design end and the environment art begin? This division is artificial until we separate design from building. To provide the right experience, the design of Dear Esther called for an island with terrain and foliage; it doesn’t matter whether it was a level designer or an environment artist who did the work of building.All of that said, when I see talk of “best practices” that don’t specify their context, I get grumpy. And when these “best practices” are directed at students, I get angry. I think about the days of my life wasted solving the wrong problems, and I think about all of the work I shipped that was less than it could have been. // What remains if we throw out “best practices” and say the quality of a design depends on its context?There are fundamentals we can still apply. Gestalt psychology has value. There are also psychological models like Self-Determination Theory to help us better recognize our players’ needs. I personally am skeptical of any application of shape- or color-theory that says “[x] will make the player feel [y]”, but there is still value in studying these areas as well.What remains is local level design, where our work serves a specific context to the best of its ability. To me, this enriches the many forms our levels can take, frees us from the International Style of AAA best practices, and returns us to our position as experience designers instead of overspecialized level builders. This lets us escape high modernism and enter postmodernism (and maybe we’ll catch up with the rest of the art world eventually).For students, my suggestion is that you shouldn’t greybox levels in Unity or Unreal by imagining a context that you can’t playtest. Doing this is making fan art levels, replicating solutions that already exist rather than learning how to solve. Instead, take a game with mod tools and an active community and design a level for that context. Seek feedback, not to hear how your level is good or bad, but to better understand who your level is for. Then build another level with this knowledge. This is the only best practice I know to learn the skills of design. *Note: This article is posted on Next Level Design with permission from the author Source: Andrew:Website:
  3. In the third installment of his Action Adventure Level Design series, Lara Croft creator Toby Gard examines how the design process should incorporate discussions of pacing, structure, and mood -- and how leads can hone their feedback to the team to make it all work. Part 1 described how to create a Level Flow Plan to hand off to the level team. Part 2 described a variety of tools to help turn those Level Flows into detailed, immersive and interesting levels plans. By the end of the process described in the last article -- building through fiction -- you will most likely have a mixture of paper maps, written stories, detailed flowcharts, concept art and possibly some 3D mockup spaces, depending on how each level team prefers (or has been instructed) to represent their plan. Those levels will have taken shape in surprising and unexpected ways. Levels that we had assumed to be straightforward action levels may have revealed rich veins for puzzles, and many levels are likely to have prompted ideas that fall outside of the current game mechanics.Evaluating the Big PictureTo structure their feedback, the creative leads need to validate all level plans in relation to each other. Because the levels are likely to be pretty complex, it is useful to create a simplified representation of the whole game so that you can assess the pacing and emotional consistency of the experience.Extraction of MechanicsThe first step we need to take is to identify all of these special case interactions and ideas that the level teams have come up with while fleshing out the level plans. Inevitably they will be some of the coolest in the game: Ken Kong falls down a 30 story lift shaft, doing frantic mid-air kung-fu until there is a pile of zombie bodies beneath him thick enough for him to survive the drop. It sounds awesome, but the fight system simply cannot accommodate this "fall fighting" mechanic, so the level team has suggested it as a cutscene.In a couple of other levels, Ken Kong has to destroy some walls and the level teams have proposed different McGuffins to allow him to do this, such as a convenient, precariously balanced heavy object that will break through the wall if triggered.It is this list of ideas that can produce the neat and original game mechanics that will set your project apart from everyone else's. By promoting ideas that have the flexibility to be expanded into the core mechanics and peppering them throughout the game, we can create a richer more coherent overall experience.For example:How could destroying walls become a reusable mechanic? Would it require a consumable, or is it a readily available ability? How rich of a vein is it to be tapped for more applications? Does it have synergy with other player abilities?Let's say that we can integrate destroying walls with a new survivor type, a demolitions expert, who carries around explosives that can be put to all sorts of uses, but who also explodes when attacked by a zombie -- potentially taking out a large proportion of your crowd. This could make for an interesting risk/reward mechanic and with some standard "explodable" barriers and/or enemies could be used in several levels.Perhaps the "fall fighting" could also be used on several levels, but this seems more like a mini-game than a new mechanic. While the idea is interesting, the question is, could you make the gameplay deep enough to justify three or four "fall fighting" sequences throughout the game? It potentially seems like a large investment for too small a gain, but if we could make it work, it would be really cool.These mechanics are generally gold, because they were not forced into the game design from a desire to tick boxes based on competitive products, but were discovered organically through an exploration of its unique themes and the thoughtful exploration of its world.Once we have integrated the new mechanics and rejected or noted all the new set pieces, we will have adapted the character to live in this more clearly defined world and gathered a major part of the information needed to give feedback to the level teams.Gameplay Types Most games have a basic mixture of elements. For instance, an FPS might have 70 percent shooting on foot and 30 percent vehicle combat.If every level in the game had exactly that mixture of gameplay, it would get dull for the player pretty quickly. But if you have levels that are entirely on foot, interspersed with a few levels that are predominantly or entirely involving vehicles, then they will act as palate cleansers, changing up the experience enough to keep players interested.A great example of a game that keeps the player constantly interested is Half-Life 2. Almost every level has a new central theme, whether it's a new weapon, a new vehicle or a new type of enemy, your experience changes dramatically every thirty minutes or so.By looking at the mix of gameplay types over the course of the game, you can isolate points where the experience might be too flat.Example: KFZKLet's carry on with the imaginary game Kung Fu Zombie Killer, discussed in depth the last installment. The variety of gameplay in that design comes from the types of survivors that you rescue.• With doctors, you could have a level where your goal is to heal injured survivors.• With forklift truck drivers, you could have a level where heavy equipment has to be taken to a particular location in order to progress.• With engineers, you could have levels that included traditional puzzle elements.• With soldiers, you could have a level where your crowd actually does most of the fighting for you.• And so on.Let's assume these were the locations we settled on for the levels:• Dojo• Hospital• Building site• Army base• Power station• Police station• Supermarket• Town hall• College campus• Cinema• TV station• Office blockWe know from the story that the game has to start in Ken's Dojo and that it has to end with camera men filming Ken as he rescues jenna126xyz.We have goal mix of 80 percent fighting, 20 percent puzzles for the whole game and we had ordered things like this: But during the detailing phase two things happened. (More likely a massive number of things would have changed, but let's keep it relatively simple.)First, someone came up with a really cool teacher survivor who can put zombies to sleep by lecturing them, which changes the gameplay mix at the college to involve more puzzles.Second, someone has proposed changing the cinema into a film studio, whereby the zombies and the survivors can be based on clichés like Wild West or Godzilla films. People are very excited about this idea and enough crazy mechanics have come from it to justify potentially splitting it into two levels.Consequently things are now looking a little less balanced and we have one too many levels: We have found enough new mechanics that we can nearly introduce a new mechanic every level. By cutting the supermarket and moving the power station a bit earlier we can adjust the level order to create a better gameplay rhythm: This can still be improved; we can look to either find a new survivor type that can be added to the town hall level, or we can try to replace it with something else that gives us more opportunities to do so.Mood MapThere are potentially a host of emotions you will want the player to experience over the course of the game. The main character may experience things like unrequited love, revenge, sadness, and anger. These sorts of emotional events are important to track but they are not as important as the overall emotional tone or mood that you want the player to experience.By "mood", I mean a basic emotional concept that can be passed to the audience. So panic, fear, trepidation, awe, and excitement would be considered moods, while higher order conceptual emotional themes such as revenge, jealousy, or nihilism would not be.Generating the mood map has two purposes. It is used to assess that the level order and content will not interfere with the emotional journey of the player but more critically it is a fundamental tool for aligning the whole development team towards creating a holistic experience.For instance, let's say that the story of Ken Kong will go like this: Ken fights his way across the city saving the loved ones of his crush, but it takes him so long that by the end when he reaches her, she has been bitten and become a zombie herself.If I define the mood map like this: Kick-arse awesomeness - farcical chaos - mounting triumph - dark comedy• Art will keep things bright and well lit.• Animation will tend towards outrageous over the top stylized action.• Music and sound effects will tend towards fast-paced and comical.• Designers will feel free to be more game-y in UI game design decisions.By defining the moods specifically over time you will guide the whole team more precisely than you might imagine. For instance "mounting triumph" implies a growing crescendo. It is likely to encourage a ratcheting up of music intensity, increasingly outrageous level end victory animations, and a general tendency to try to up the pacing each level.While you probably assumed that the tone of KFZK would be defined as something like "zany", the act of stating it over time has a dramatic impact on the whole development.For instance, if I instead define the mood map for the whole game like this: Panic - horror - increasing trepidation - tragedyEvery aspect of the game will be completely changed by this mood map:• Art will create darker dirtier spaces; they will light the levels with flickering pools of light and dress it with increasingly disturbing stories.• Animation will tend towards realism and will avoid any movements at might be construed as funny.• Music and sound effects will be disturbing.• Designers will try to keep UI and other design elements realistic and invisible.With exactly the same game design, these two mood maps would generate utterly different gaming experiences. When the whole team embraces the mood map and diligently tries to express it in all the assets and creative decisions they make, the mood will be successfully instilled into the player.What normally happens, though, is that every team member has a slightly different idea of what mood or tone the game should be creating, and rarely any idea at all of what mood the player should be experiencing at any given point in the game. Is it any surprise that most games fail to move people, when the development team are all communicating slightly different messages?The mood map can be as simple as the above four stage progressions, or it can be as detailed as putting several mood chunks into each level. It is worth bearing in mind that literally no story-based game has only one mood. Even horror games oscillate between building tension and outright terror.Once you have the gameplay types laid out and the moods defined you can see how the current level plans fit together. In our case we have puzzle levels late in the game that are clearly going to slow the pace where we want people to be experiencing "mounting triumph." By reordering levels, or shifting ideas from one level to another, we can better support the emotional goals: Luckily KFZK's level order is very flexible, but most games are not. In most cases the answer is to give feedback to the individual level teams to try to reach the desired mood and gameplay mix.While the above example is probably not the best order, or even the best mood map, the point of the exercise is to try to force yourself into examining the entirety of the plan so that feedback on each level is given relative to its place in the whole experience.Block Mesh and PrototypeThe next step is to start building the levels in 3D, and I argue that the best people to do that are artists, not designers, if you want believable and interesting spaces. Block mesh should validate whether the level as planned will fit into the technical and production limitations while demonstrating that they can be compelling enough spaces.As these levels are prototyped, inevitably things will end up being slightly different than planned. Designers will adapt their plans based on the art, so throughout the block mesh and prototype phase, the leads have to continually update the game rhythm chart and validate the levels within the context of the mood map.By continuing to extract new mechanics that arise from the block mesh phase and staying open to level re-ordering you can continue towards a balanced game plan without restricting the creative process of the level builders.Final planAll the information gained by building the block mesh should have refined the game design significantly.• A final Mood Map has been created that will inform all asset creation.• New mechanics have been defined and inserted into all relevant levels.• Levels have been reordered and massaged to create the desired pace and mood.• Memory budgets have been validated.• Weak level plans have been cut.• Player abilities have all been prototyped and final metrics defined.Once all the levels are prototyped and one level has been polished to act as a vertical slice, production can begin from a very solid basis. *Note: This article is posted on Next Level Design with permission from the authorSource: Toby:Website: www.focalpointgames.comTwitter: