Jump to content
  • Advertisement
  • entries
    14
  • comments
    10
  • views
    2037

Game design and Gestalt laws

FriendlyHobbit

1221 views

http://www.tinker-entertainment.com/sitavriend/psychology-and-games/game-design-and-gestalt-laws/


59a980d0ee302_flat1000x1000075f_u2.thumb.jpg.8187d866dc8680b8585b79b088d9026d.jpgThe Gestalt laws explain of why we perceive patterns in a certain way. Perceive patterns relies on how our brain organizes the raw data from our senses, it makes use of perceptual sets quite a lot. Our brains are inherently wired to create order in things we see, even if there isn’t any. They will always try to fill up the gaps. Remember the illusion to the right? I showed it to you in the first article on perception (link). There is nothing more to the picture than three white flat1000x1000075f.u2.jpgpizza’s all with a slice missing and three lines with the same angle. Somehow your brain fills up the gaps and you perceive a black and a white triangle laying on top three white circles. The gestalt laws offer us an explanation why that happens.  These laws are much like heuristics: mental shortcuts for problem solving. We use them to quickly make sense of what we see, they mainly apply to our visual sense.

In general the laws state that the whole is different than the sum of its parts. This means that the whole element is different than the elements it is made up from. Think about a dotted line, the whole represents a line but the parts are dots. The gestalt laws are often used in UI and graphic design to make the displayed information more readable or to play with our perception.

The Gestalt laws were first put to paper by Wertheimer (1923, 1938). Later contributions have been made by Köhler (1929) and Koffka (1935). The 6 laws in the picture are used often in UI and graphic design, however there are many more.

xillustrations.jpg.pagespeed_ic.9pxvUuQlA7.jpg.6a21d773e8709817799ba81c472ede5a.jpg

Law of Proximity
Regional or chronological closeness of elements are grouped by our mind, they seem to belong together. Proximity is what you would use when you design the UI of an inventory system or a HUD in general. Group items that have similar functions or fall under the same category by placing them closer to each other. Of course that also means that you should leave more space between items that fall under another category.

Law of Similarity
Our mind groups similar elements to an entity. The similarity depends on relationships constructed about form, color, size and brightness of the elements. Like proximity, similarity should also be used for the UI design of an inventory system. Use a symbol and/or color code different items from a certain category. Items with the same color or symbol will be seen as a group. You can also make items more similar when they all have something in common like since or a certain shape.

Untitled.pngLaw of EnclosureUntitled.thumb.png.1c3fbe2291aec366d02a04dd5f47b79c.png
Enclosure states that you can group items and information by enclosing everything that is supposed to go together. This law is used in UI design to group different kinds of information such as text and pictures that belong together. Applying the law can be as simple as adding a border around the items or information. Often UI designers use a card metaphor, it almost look as if pieces of information are put on cards. Facebook uses enclosure and displays individual stories on cards in your news feed. They used color and line to separate information that doesn’t belong together.

Law of Symmetry
This law states that we perceive objects as belonging together when they are symmetric regardless of their distance. Symmetry can be used to group elements together or to create the idea of wholeness. Adding symmetrical borders at the left and right side of the screen can create the suggestion that the players views the game through a border or lens.

Law of ClosureCarcRiverLayout.jpg
Our mind adds missing elements to complete a figure. The black triangle from picture 1 is not actually there, CarcRiverLayout.jpg.a6585c6ee0646a1074a6d3fa5d649c18.jpgour brain filled up the gaps from the missing pieces. The board game Carcassonne is a good example how you can design elements that use this law. As the players build their castles and roads they can already imagine which pieces they need. Players need little cognitive resources to imagine the missing pieces because our brain already filled up the gaps. When you are designing for closure make sure that the player can fill up gaps of missing information.

Law of Continuity
Continuity states that the mind continues a pattern even after it stops. Our brains are remarkable pattern machines, we perceive patterns even if they are not there. The law of continuity prove this. In our picture example of the Gestalt laws you can see this one long squiggly line with missing parts. Actually it is not one line, there are three separate lines. The law of continuity doesn’t just work for lines with parts missing, any figure can be used in patterns to make up something else. In level design you can use this law to display a path or movement in a certain direction. It is a good way to point the player in the right direction or to give them an occasional hint. Portal 2 uses this method to guide the player using a dotted line. The player can fill up the gaps even when debris is covering parts of the line like in the picture below.

Law of Connection
We perceive elements as being together when they are connected with each other. Graphic designers use this law for infographics or flowcharts to show how elements are connected and that they belong together. The key here is to connect elements with the use of lines to show that they are related or that they belong together.

Portal-2.jpg.d5714c1c5bc601f82f918996c26aac92.jpg

Law of Figure and Ground
Certain objects take a more prominent role while others recede more into the background. mosaic-ii.thumb.jpg.8a7511ae94e3973387c3331b1ad6e951.jpgThis law is used quite a lot in logo design to make the most important element standout and attract attention at first. Use the law of figure mosaic-ii.jpgand ground to attract attention to important information or option to make the player pay attention to this first. The use of color is key here, highlight the option that is important or needs to attract attention quickly. Think about using a complementary color scheme or red since it immediately attracts attention.

Law of Common Fate
Elements with the same moving direction are seen as a unit. If certain elements all have the same direction they are seen as one. The direction can be an animation but it can also be a movement the player is making. The Mario platformer games a good example of how common fate can be applied. Enemies in the platformer almost always move towards Mario when he first encounters them while useful objects always move away at first. You can apply those ideas to your own game design as well, when a player first encounters an enemy have them walk to the left. You can do the opposite with friendly NPC’s, let them walk to the right.



1 Comment


Recommended Comments

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Wolfebytes
      I am currently an undergrad several months from graduation. My major is in Game Programming and Development. During the course of my studies, we've had a few modeling classes and I really took to it and feel that is the direction I really want to go, specifically I would love to become a character artist. I keep hearing about your portfolio being super important, but I've really never been able to find out what kind of work is best to put into my portfolio. There's no "put 2 of these and 1 of those in," kind of tips. I get that I'll want to put some characters I've modeled in there, but I guess what I really want to know is, if I want my portfolio to be noticed and taken seriously for a character artist position, what is the best way to present it? Since most of my courses have dealt more with programming, I need to build everything for my modeling portfolio on the side, outside of class on my own time. I know there are no specific numbers like: put 3 realistic humans, 2 robots, a creature, and a stylistic character in your portfolio. But as a general rule is there some kind basic guideline or tips for what to make to get your portfolio off to a good start?
    • By Kjell Andersson
      Genifect 2.0 OpenFX plugin has been released by Dual Heights Software.
      New in 2.0 is the Materialized Bevel filter which creates bevel and lighting effects for texts and symbols. Using MatCap textures you can create advanced and realistic lighting effects on 2D-text and logos to make it look like it was made out of gold, copper or any other material that you can find a MatCap texture for on the Internet.

      Genifect is an OpenFX plugin that works with the major compositing software for video and animation including Nuke, DaVinci Resolve/Fusion, Vegas Pro and Natron to name a few.
      Visit the official Genifect page to learn more: https://www.dualheights.se/genifect/
       

      View full story
    • By Kjell Andersson
      Genifect 2.0 OpenFX plugin has been released by Dual Heights Software.
      New in 2.0 is the Materialized Bevel filter which creates bevel and lighting effects for texts and symbols. Using MatCap textures you can create advanced and realistic lighting effects on 2D-text and logos to make it look like it was made out of gold, copper or any other material that you can find a MatCap texture for on the Internet.

      Genifect is an OpenFX plugin that works with the major compositing software for video and animation including Nuke, DaVinci Resolve/Fusion, Vegas Pro and Natron to name a few.
      Visit the official Genifect page to learn more: https://www.dualheights.se/genifect/
       
    • By jb-dev
      This is how loading screens will look like. I still have no idea whenever or not I could show things like tips or anything alike...
    • By Programmer One
      I'm currently writing a 2D game engine from scratch for Android. The first iteration of the engine is just going to use the Android Canvas view for drawing. At some point, I want to support OpenGL ES - but not until I finish this first project (which is a very simply game based on this engine). Right now, I'm dealing with Sprites and I've encountered a design challenge that I'm not entirely sure which direction I should go.
      For the sprite bitmaps, I've decided to go down the sprite atlas route (as opposed to individual image files). I'm using Texture Packer and I've written a custom JSON exporter. I didn't really want to limit myself too much, so I decided I'd support sprite rotation and trimming in order to save as much space I can in the atlas. I backed off from supporting polygon trimming for now. If you're unfamiliar with Texture Packer, it's essentially a tool that will allow you to import individual sprite frames, organize them into folders and then have the application generate a sprite map and corresponding coordinate data file. This application supports trimming any blank (alpha) space around the sprite images in order to pack them closer together. It also supports rotation if it makes the image fit better.
      What I'm trying to figure out now is how to deal with loading the sprite image data. Currently, I'm at the point where I can deserialize the JSON map data into "Sprite Frame" objects. These objects contain information about each frame. My format allows grouping of sprite frames in order to organize frames that correspond to the same animation. In essence, the sprite frame object has:
      The original (untrimmed) size of the sprite image. The original position of the sprite image within it's bounding box. The rect of where the image is in the sprite atlas. A flag indicating if it had been trimmed. A flag indicating if it has been rotated (CW). This will give me all the information I need to draw the image onto the Canvas. If I didn't support all the other fancy features I want (packed rotation, trimming) and pre-transformation (i.e. mirroring a sprite so I can reuse it for things like changing the walking animation without having to pack in more sprites), then drawing the image from the sprite atlas onto the canvas would be as simple as a simple Canvas.drawBitmap([Source Bitmap], [Destination Rect], [Source Rect]).
      But, since the image I'd be drawing MIGHT have been rotated, trimmed or otherwise transformed, I can't just simply blit it onto the Canvas. I'd first would need to apply some transformations in order to "undo" changes that were done during packing. This means I would need to either:
      Slice out the child image from the sprite atlas into a new bitmap, and apply the "unpacking" transformations (i.e. rotate back, realign, etc). Apply a transformation to the Canvas itself. (I don't think I want to go down this road since I've read that transforming the Canvas tends to be rather slow). So, I'm probably left with having to create smaller bitmaps from the sprite atlas and then keep those in memory for as long as I would need them. So, for a single sprite character, I'd be looking at around 36 sprite frames (9 different animations, each with 4 frames). What I'm concerned about is memory consumption. So now I'm thinking:
      I should read in all the sprite bitmaps from the sprite atlas and shove them into an LRU cache. This means all the sprite image data is now in memory, all ready to go for whatever animation sequence and frame I want. Once I'm done with the atlas, I dispose of it and just work with what I have in memory. I can perform this caching when I load levels and then clear items from the cache that I no longer need. I should just keep the sprite atlas, blit directly from that onto the canvas, and get rid of the fancy packing features so that I don't have to process any transformations. The only problem with this approach is that I will also have to shelve shearing and rotation on the sprite object itself. TL;DR: Am I being overly memory conscientious or having a couple frames of sprite data in memory not a super big deal?
       
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!