Search the Community

Showing results for tags 'terrain'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

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

Categories

  • Articles
  • NLD Originals
  • News
  • Projects

Categories

  • Articles
  • NLD Originals
  • News
  • Projects

Blogs

  • NLD Dev Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 5 results

  1. Review This is one part in a series of articles that attempts to explain how I think when I design. The purpose of these articles is not as much to provide a hands-on practical approach – just to explain how I do stuff. Once I finish this series, I’ll focus on some more practical applications. (Link to Part 4) Important Point from a Previous Article Principle #1: As a game designer, your job is to ask your players Questions. The players’ job is to answer those questions using the Tools you give them. Last Time Last time we identified major weapon, enemy, and terrain Archetypes – some of which we will use in this article. This Time We’re going to talk about how I use the combat Archetypes we made in the previous article to create a series of enemy “Setups.” Note: We’ll talk about how I chain setups together with increasing complexity to form “Ramps” in the next article. Archetypes According to Google, an Archetype is “a very typical example of a certain person or thing,” and that’s how I want to use the term here, but with one difference: Archetype: A very typical example of one of the extreme boundaries of your game’s design. In the following diagram, each of the black dots represents an Archetype. You can see how they all exist at the extreme boundaries of our enemy’s possible powers (Health, Range, and Damage). Note: If these diagrams don’t make sense, check out the last few articles – that’s where we created these. A lot of people ask me why I choose only the extremes, and don’t make “jack of all trades” type enemies. According to Principle #1, our job is to ask players Questions. It’s vital that the player understand what question they’re being asked, otherwise I’ve made it impossible for them to play my game the way I want them to play it (if at all). The closer you get to the extremes of your design space, the clearer players will be on what they’re being asked to do: an enemy that takes 10 hits to kill is MUCH different than one that takes 1, or 5 hits to kill, and so prompts a different response from the player. Example Archetypes I’m going to use four enemy Archetypes, three weapon Archetypes, and all four terrain Archetypes that we went over in the previous two articles. I hope to show how these 11 Archetypes, as representatives of the extremes of your design space, work together to create a series of Questions and Tools that you can ramp up in difficulty over the course of a Path. (We’ll go over Ramps and Paths in later articles). Enemies Four enemy Archetypes: Swarmer – Low Health, Low Damage, Close Range Heavy – High Health, High Damage, Far Range Far – Low Health, High Damage, Far Range Near – High Health, Low Damage, Close Range Our example Archetypal enemies, as found in various games Weapons Three weapon Archetypes: Blaster – Long Range, Direct, Low Damage Flamethrower – Short Range, Direct, High Damage Bomb – Short Range, High Damage, Indirect. Where our four weapon archetypes fall on the view diagram we made in the last article I chose these three as examples because they overlap very nicely with the terrain and enemy archetypes, as I’ll show you later in the article. Terrain Four terrain Archetypes: Flat Gap Ledge Cover Examples of our four major terrain types, based on our “enemy placement” choice field from the previous article Creating an Enemy Setup Using Archetypes An enemy Setup is just a variously sized group of enemies of different Archetypes, placed on varied terrain. Each Setup should ask the player a question. In the combat system we’re creating, every setup asks the same two questions: “Who do you want to attack first and what weapon will you use to do it?” For example, using the Example Archetypes from above: Simple Setup: [2 Near enemies on flat ground] Who do you want to attack first? This setup is basic. It doesn’t really matter which enemy the player attacks first (except that the player may wish to shoot the closest one or target both). What weapon will you use to do it? The bomb or flamethrower may be able to hit both for high damage, so the blaster isn’t as great in this area. Combined Setup: [2 Near enemies on flat ground backed up by 2 Far enemies on ledges.] Who do you want to attack first? The player has to dodge high-damage shots from the Fars while fighting the Near enemies. Because the Far enemies have low health, the player might normally attack them first — but in this case, the ledges they’re on make them less accessible than the two nears. You can see how these questions begin to overlap to create options for the player to choose a weapon. What weapon will you use to do it? The two near enemies have lots of HP, so you’ll want to hit them with the flamethrower or the bomb. The far enemies have little HP, but are inconvenient. The player is encouraged to use a weapon like the bomb (area damage) or the blaster (range) to take them out. Note: If we had ammo in this system, the weapon choice could be even further influenced by how much ammo players have left for each gun when they arrive at this setup. Complex Setup 1: [5 Swarmers backed up by 1 Far enemy with cover and 1 Far enemy on a ledge.] Who do you want to kill first and what weapon will you use to do it? I combined the two questions here because it’s starting to get difficult to describe the answer to one without considering the other. Because they are small fast targets, Swarmers aren’t easily killed with the Blaster. The player would probably want to get all of them with the Flamethrower. The bomb might also be a good pick, if it has enough area of effect to get all the swarmers. Half of the leftmost Far enemy is obscured, making him a harder target for the Blaster, while the one up on the ledge is exposed and would be an easy target for that weapon. The bomb is probably a good pick for the Far enemy behind cover – it can arc over the cover and there’s plenty of floor behind the enemy for the bomb to land and catch the enemy in its area of effect (assuming the bomb has that, of course). You could use the bomb to attack the Far enemy on the right, but as there’s no wall near it and you can’t see the floor, so you’d have to be very accurate with a relatively inaccurate weapon. The blaster is probably best there. Complex Setup 2: [5 Swarmers on flat ground in front of 2 Heavies across a gap. Between you and the swarmers are 2 Near enemies. 2 Far enemies stand on ledges shooting down at you.] Who would YOU attack first? With what? Who do you want to kill first and what weapon will you use to do it? Personally, I’d whip out the Flamethrower and try to take out the Nears and the swarmers, then switch to the blaster to wipe out the Fars. Then I’d run up on the ledge where one of the Fars are standing and fire bombs down at the heavies – but you can see how many options have arisen from these 11 simple tools. Conclusion Once you understand your game design’s extreme edges (which we’ve been working on for the last few articles) you can begin to define archetypes for the various parts of your game like enemies, weapons, terrain, and so forth. By combining the archetypes together, like using letters to form words, you end up with a complexity and depth of meaning that defies the simplicity of the method. (Link to Part 6 - To be Updated) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-5-setups/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  2. Intro This is one part in a series of articles that will attempt to explain how I think when I design. The purpose of these articles is not as much to provide a hands-on practical approach – just to explain how I do things. Once I finish this series, I’ll focus on some more practical applications. (Link to Part 3) Important Points from Previous Articles The Big Principle: A game is fundamentally a conversation between the designer and the player. Principle #1: As a game designer, your job is to ask your players Questions. The players’ job is to answer those questions using the Tools you give them. Principle #2: When the designer creates a challenge to ask the player a Question, the designer must also create Tools for the player to answer it. Game mechanic: A game mechanic is the meeting point of two design ideas: a Question the designer asks the player, and the Tools the player has for answering that question. Choice Field: A collection of spectra all of which describe a single game mechanic. Spectrum: Any two opposing concepts which are the same in nature, but differ in degree. Dimension: A single spectrum inside a choice field. Last Time Last time we looked at a game mechanic that described one possible relationship between Enemy Placements and Weapons: Range vs Horizontal – Weapons that have good Range will solve Horizontal enemy placement problems (gaps), but not necessarily Vertical ones (ledges or cover). Directness vs Height – Indirect weapons are usually very good at solving Vertical enemy placement problems (cover, a ledge, flight). This Time I’m going to talk about the limitations of the choice field drawings I’ve been making – specifically that they do not represent complex relationships between game mechanics very well. I have some diagrams that are great for that, called Chen Diagrams, but I won’t get to those for a few weeks, when we start to talk about meta-game stuff. So for this article, I want to show you how spectra (a plurality of spectrums) relate within a choice field, and how one can view that data in different ways by opening little “windows,” or views into the field. Chromaticity diagram for the CIE 1931 xy. Because spectrum. It’s my hope that by the end of this article, a few of the concepts I’ve been working on for the last few articles should gel together and make sense as a whole. First off Before I can get into the meat of this article, I have to add one more spectrum to the choice field we’ve been building up since last article (the choice field describes a combat system similar to those found in Skylanders or Ratchet and Clank games): HP vs Damage – The player generally wants to use a high damage weapon to take out a high HP enemy. Conversely, the player wants to avoid getting hit by high-damage enemies but can afford to suffer several low damage hits. Note: I’m not describing specifics of our HP or damage systems here. For example, this could describe both a Halo-style “regenerating” health system or a Quake-style “hit-points and health pickups” system. It doesn’t really matter yet, though it will matter a lot later on. For this article we can safely avoid the topic. The important thing is that damage removes HP from players or enemies until they reach 0 HP, then their avatar dies. The Spectra, Unconnected So now we’ve built a rudimentary combat system out of six spectra. For a moment, let’s ignore how they link together dimensionally and just focus on them as separate things: These six spectra make up the combat choice field we’ve been constructing Each of these spectra reveals a potentially interesting aspect of the game’s design. Ideally we’d be able to combine all of these into a nice image that shows us all the extents of our choice field… but there’s a wrinkle. One of the limitations of the diagrams I’ve been using thus far is that drawing a four-dimensional choice field is not really a simple thing to do (just look at these hypercube illustrations as an example of how hard it is). Just adding on a single dimension as we did with 2 and 3 dimensional fields doesn’t work very well, as you see from this image that tries to display all the information we have about weapons: Figure A: This diagram may seem useful, but because directness and damage don’t overlap at all, the diagram is missing all four extremes dealing with both damage and directness. This gets even worse as you add more dimensions. Fortunately, this limitation doesn’t present too much of a problem, since you rarely need that much information at any given time. By regarding two or three of the spectra at a time, we can create “windows” or views into game mechanics that can give us a ton of information. For example, this is one possible view into weapons (notice it’s half of figure A, minus directness): The above diagram shows us eight of our possible weapon archetypes (one per dot). The most obviously useful info we get are the eight archetypal weapons we can create – but it gets better. The important thing I’m trying to show here is how the overlapping of all these spectra create new and interesting choice fields. Each choice field comes with a selection of archetypes (the dots), which represent the extremes of your system. Each weapon is made to answer a question, so by knowing the answer you also can know the question the weapon is built to counteract. This shows us our weapons and enemies are related opposites (Principle #2). By knowing eight possible weapon archetypes, we also know eight possible enemy archetypes. These archetypes don’t represent the full richness of our choice field since many things are missing, but eight weapons and eight enemies is a hell of a start in getting there. I don’t think I’ve ever created a combat game that needed more than four or five enemy archetypes at one time, and three axes tend to be more than enough to give ideas for interesting enemies or weapons. Usually you spread the full richness of your choice field out over the course of your game, so this one choice field view diagram gives you enough information to start creating enemies and weapons. If you create another view into the choice field, for example, to represent the other half of Figure A, it can look like this: Another view diagram that shows more of the weapon choice field — this time we get the missing info about directness. With this data, you can start to see some archetypal ways that weapons can interact with enemy placement (high, low, far, near). I talk a lot about these enemy/environment interactions in my GDC Talk on Skylanders (language warning). This gives you more than enough information to start designing combat setups and even more enemies because you know what tools you’re allowed to use to ask level-design questions in combat: flying enemies, enemies behind cover, enemies on ledges, enemies across gaps, etc. (Link to Part 5) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-4-spectra/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  3. People ask me sometimes where my ideas come from. Well, that’s not exactly true, nobody asks me that, but all kinds of famous people say people ask them that so I figured I’d jump on the bandwagon. But if they DID ask me, this is what I’d say (at least as far as level design). I design a level one “setup” at a time, then I link all the setups together to form a level. When I’m thinking of a specific setup, here is the basic process I go through: WARNING: GET READY FOR A TON OF BULLETED LISTS AND SENTENCE FRAGMENTS!!! Bullets R Boring! Gimmeh some pictoorz! Intensity Curve How many setups are in the level? On a scale of 1 to 10, rate each setup in terms of how intense (difficulty + energy) it should be. These numbers should go up over the course of the level, but we should have some noise in this regard (see image below). "Interest Curve" As defined by Jesse Schell in The Art of Game Design: A book of lenses Difficulty / Intensity Where is this setup located on the “intensity” curve of the level? Does the intensity curve want a combat setup or a non-combat setup here? If we want the intensity to die down a bit, non-combat setups help with that. If it’s a combat setup, based on the intensity curve, determine the number of enemies and the combination of enemies in the setup. Never repeat a setup. Always introduce an enemy before you use multiples of that enemy or use the enemy in combination with other enemies. (Enemy A, Then Enemy B, then two A’s, then an A with a B, then two Bs, then two As and two Bs, etc). Choose the enemies based on “archetypes” (see below). Terrain Features Gaps: Horizontal separators. Need to determine: Width The path around or over the gap The fiction or type of the gap (cover, a river, a pit, etc…) Ledges: Vertical separators. Need to determine: Height (usually in two increments: Short and Tall) The path to the top of the ledge The fiction or type of the ledge (a car, a balcony, a platform…etc) Gaps and ledges Area Shape Determine the size (Should it feel tight, normal, or vast) Make sure enemy entrance or spawn points are visible from the player’s entrance point Reveal VS Recon (Is the player surprising the enemies or are the enemies surprising the player. This should vary based on the intensity curve) Make sure the area contains or has a view of some kind of focal point. The action should revolve around or serve to frame this visual focus. Tight Space Enemy Archetypes Near: Attacks close-up Far: Attacks from far away Heavy: Can be near or far, but should be player’s top priority if all else is equal Popcorn: Can be near of far. Not dangerous unless in groups. Should make the player feel strong. Near / Far / Swarmer / Heavy Enemy Idle Behavior If the player is surprising the enemies, what are they doing before he triggers them? (Patrolling, idling, juggling, etc…) Enemy Intro Behavior How is the enemy introduced? Spawn-in: The enemy appears (Teleport, jump in, etc) Run-in: The enemy comes in from off-screen (run ,fly, etc) None, the enemy is already there when the setup starts These should be varied based on the intensity curve. Enemy Trigger Zones Where does the player have to be for the enemies to activate and begin attacking? Where does the player have to be for the enemies to stop following him once they’re activated? Where does the player have to be for the enemies to deactivate? Enemy Location / Placement Must be visible to the player from the entrance to the area Do we want enemies to clump or be spaced out? Are the enemies close to or distant from the entrance How close or far do we want them from terrain features? (Over a gap, up on a ledge, behind cover, etc…) Place important items E.g. Explody barrels, health, etc Usually place close to a wall or suggestively (an explody barrel right next to a group of guys) Coin placement! Place gravy items Rewards: (Crates, coins, etc) Pure gravy: E.g. Breakable scenery Visual gravy: Non-breakable scenery, usually to provide movement or points of interest. (Blinky lights, scrolling water, plants, etc…) 'What are you trying to say? That I can stop bullets?' Source: http://www.ongamedesign.net/when-im-designing-a-level/ *Note: This article has been posted in full with permission from the author Follow Mike Website: http://www.ongamedesign.net/ Website: http://www.chaoticstupid.com Twitter: https://twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  4. Next Level Design has been given permission from the author to host this entire book in PDF format. Download the attached PDF at the bottom of this article for the entire book, or view it here: https://drive.google.com/open?id=1uB3pUjPkHuWWOYEc70nkVjVlR09ua70zStill not sure? Read through this section on lighting that was recently posted on Next Level Design: In addition, we've included another small section of the book right here: pg. 25 INTRODUCTION Due to games’ ever-increasing complexity and the expanding nature of levels in general, it can certainly be said that levels are not easy to design. Levels, as said before, are combinations of dozens of different aspects, the conglomeration of which render them complex by nature. This combination of complex systems itself requires good design from the start in order to avoid an inconsistent and downright messy result. Because the different aspects are so interdependent, it’s very important not to lose sight of a level’s ‘big picture’. This chapter highlights some of the issues that can pop up when designing a level, as well as some more minor aspects to keep in mind. The overall design is the foundation for a level. Without a clear, strong design, there is no solid base on which to build the level. THE CREATION OF A NEW WORLDThe most important part of a successful level is its beginning. The way a level starts will determine a great deal about how the rest of the level will evolve and how quickly. In these days of growing complexity, efficiency and speed are valued highly. Getting off to a bad start or using bad work methods can cost time which is usually at a premium to begin with. Part of starting a good design is foreseeing potential problems before anything is created. By doing this early in the process, a good level designer can quickly and easily modify the design to better fit the available time, workload, difficulty, technical limits, or all of the above.How one begins a new level is different for every person. One designer may write everything down in a design document while another, like me, just plans it out in their head. The method used also depends upon if one is working in a team environment. Working with a team means that the level’s design must be communicated throughout the team which usually means some sort of written, drawn, or quickly modeled design that can be passed around and/or presented. How it’s done isn’t important as long as several key aspects are kept in mind and the end product is of a sufficient quality. If the technology used cannot create lush jungles, for example, then this must be recognized before starting.A design should progress only when exactly what is wanted and how to accomplish it is known. Exact information is the key to this. Again using the jungle example, one must know what the jungle will look like, the colors it uses, the overall style, how the player will move through it, if the engine can render thick vegetation, what kind of physics will be involved, and too many more to list here.To assist in this task, I have developed a type of checklist that is at the base of everything I design. The list compares several key values against each other to see if they are possible and if they should be modified. It also helps define the values better. The list checks to see if the rules of, for example, lighting and composition are contrary to each other and if the goal is possible and what direction to take. This extensive chapter will mostly be about the latter.A level is complex and it takes increasingly more time and effort to successfully complete one; thus failure is not an option. All the areas that could potentially cause a problem should be identified before starting any work. Once the design process starts it should go smoothly; design dilemmas should not occur or, if they do, should be easily overcome with few modifications to the overall plan. Getting stuck can be very demoralizing and time consuming. pg. 26THE CHECKLISTA level always begins with a goal, a theme, or both. The goal may be that the game requires a medieval castle, or that it’s missing an ominous environment, or that the level is to be the central hub of the game.After identifying the basic idea, certain key information needs to be pinned down before starting the level. This ‘key information’ will be referred to as ‘the keys’. The keys communicate important properties about the level. They are the key words the level is built around and provide more information on the level’s requirements.The following are questions to determine the key information for the level-to-be: • (1-Time) How much time is there available? Is there a deadline? • (2-Tech) What tools and game engine will be used? • (3-Limitations) What limitations are there? Is there a shortage of art assets or staff/personal skill limit? Can anything be made or are some aspects beyond the scope of the project because of their complexity? • (4-Requirements) What kind of requirements are there? Are there any specific elements, for example, special buildings or areas that have to be in the level? When compared to the rest of the game what visual style or theme must the level adhere to? • (5-Purpose) What is the overall purpose? For example, is it a multiplayer practice level or a singleplayer boss arena? • (6-Gameplay) What should the gameplay be like? How should it be played? Should there be enough room for a large boss encounter? Or does it need to be large enough to contain a large number of enemies attacking the player? Perhaps it’s a vehicle level? Or it is a stealth level? And so on. • (7-Theme) What theme and/or style will the level have? Will it be a castle or a jungle? Will the style be cartoonish or realistic?This is all essential information for a level. The order of the list is not as important as the answers. Once the essential elements of the level have been identified it can be run through a checklist to see if it holds up. Will it work? Look right? Play right?The keys provide the information while the checklist determines if it is possible or not. The checklist combines two or more keys in order to determine if they fit together or not. If the desired theme is a jungle, but the engine can’t handle rendering dense vegetation, then these are two keys that do not fit together and the design will need to be adjusted accordingly. This is the type of information the keys provide: essential information that design decisions can be based on before actually starting work on a level. Thinking ahead is the key to success.The checklist itself is a system for asking questions and making comparisons. The questions are different each time, but the comparisons remain the same. Verify that the individual elements compliment each other.Here's the entire Table of Contents: Download the attached PDF below, or view it here: https://drive.google.com/open?id=1uB3pUjPkHuWWOYEc70nkVjVlR09ua70z *The Hows and Whys of Level Design is hosted on Next Level Design with permission from the authorFollow Sjoerd De JongWebsite: http://www.hourences.com/Portfolio: http://www.hourences.com/portfolio/Twitter: https://twitter.com/HourencesYoutube: https://www.youtube.com/user/Hourences/feed The Hows and Whys of Level Design.pdf
  5. In this Blog Post, Zi Peters discusses what he considers the basics of level design in First and Third Person Shooters: There are some considerable differences between single player and multiplayer level design. In a single player game you have a lot more control on how the player is manipulated, but with multiple human players you can’t as accurately foretell how they will act and react to each other. This is also the beauty of it all, as it generates a lot of tension and increases the excitement of the experience. Outsmarting another human opponent is far more rewarding that taking down AI. Single player levels are created with a limited amount of objectives in mind that once completed the player will then progress to the next level. The player may choose to replay this level on subsequent play through attempts, but even then the amount time spent playing it will still be fairly little. The amount of time to be spent by a player in a multiplayer level is to be quite extensive, meaning that there is the risk of boredom if the level doesn’t provide enough options. Also the time spent in these levels means that any faults or weaknesses of the map will be discovered and exploited, leading to unbalance. From here, Zi goes on to cover the following aspects of level design in some detail: Process - What should you focus on? Core Mechanics - Leverage the unique mechanics of the game you're designing for Player Tactics - Accommodating various playstyles Game Modes - What are you designing for? High Concept - A big idea Size - Why size matters Layout - Balancing complexity Flow - Layering flow patterns Choke Point - Where and when Combat Areas - limiting predictability Navigation - Landmarks Weapons/Items - Ideal locations Balance - Crafting fairness Terrain/Architechture - Building variety and verticality Navigation - Visual distinction Playtesting - Identifying problems Summary The desired achievement of a multiplayer map is: Durability to still remain fun even after countless hours of play Accessibility through clear navigation of the map Allow players to get into the action quickly Provide options for countering the enemies position Design around the core mechanics of the game Allow for variable tactics to lead to success Support multiple modes of play Minimise the advantage of players who know the maps well Read the complete article to find out how to achieve these goals - zipeters.com/2012/10/31/fps-and-tps-multiplayer-basics/ Do you agree with the goals Zi has listed? What other goals do you set for your levels?