Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    3
  • comments
    0
  • views
    896

Game design, Player types and Pleasures from games

flatingo

1182 views

Hi. To be honest, but the game design for me has always been something unique and interesting. My path of game development first started with programming. After I began to draw, in order to be universal, but later, I discovered the game design and that was for me, on a pedestal favorite direction. Today I would like to touch on the types of players, why they play the games and pleasures of games.



74806065.jpg

 

Be brief and clear. In our nature there are 4 types of players: explorers, killers, sociable and those who like committed to something. 

Crooks. This type of players are focused more on the quick passing game. It does not matter the study and details in the game. 
Killer. These guys love to destroy everything and kill everybody. Just put them in the tank, tell them where it is necessary to blow - trust me, they will not leave anything alive there.
Sociable. They love socializing, but most of all they love online games where can someone make friends, work in team and to tell you the recipe for a delicious mother's cookies. 
Researchers. How do you think, what you like to do this group of players? I also think that they are exploring every path in the game where you can collect all achievements. 

Every time you create a game, ask yourself the question: "what kind of player I do my game? Is it possible to combine these types of players in my game, changed some part of it?"

 

71218802.jpg

 

Incidentally, with regard to online games. Why do you think people play online games? First, they like competition, will compete to get to the top and gain respect. Secondly, people like to work in a team. Personally I play team games and more hours spent in team modes rather than in single. I love this mode. Thirdly, people play online games in order to meet and chat with friends, spend time with them online and meeting them to have constant, friendly contact.

As you know, men play more games than girls. Their main game is the first 20 years. Action and aesthetics - their element. From 20 to 30 years, men are already playing something more calm and tactical, where you do not need a lot of push on the joystick, but need to think. And about men from 30-35 years to play in something calm, for example in genres "I'm search" and "Farm".

But women, as a rule, begin actively playing with for 30 years. More women in the world, but I don't like the game. But often after 30 years of playing farm frenzy.

 

86992797.jpg

 

 

Identify the main fun of the players: 

Fantasy. We love to feel part of another world, which could be anyone. 
Plot. Sometimes the plot can cause a pleasant sense of his sudden change of events, a dramatic denouement and linearity. 
Partnership. Teamwork is enjoyable. 
Discovery. The opening of the new - is the main game fun. 
Expression. Everyone loves to brag about. 
Obedience. Cool when you can control others.
Feeling. When you realize that step the expected event, then the waiting becomes a pleasure. 
The gloating. When you killed your enemy, it's nice. 
Gifts. We love to receive gifts? 
Humor. No comment. 
Choice. To go left or right? I have a choice?
Fulfilled goal. We love to reach goals and to feel pride because of this.
Surprise. We love to be surprised. The Japanese are masters at it. 
Fear. We love to be frightened and to feel the shaking. This is an interesting kind of fun that we both and hate. 
A miracle. When we are strongly of something was surprised and experienced a wild delight from something. 
A tough win. That moment, when initially there was little chance to win, but you win.

 

So when making a game, think of the fun highlights of your game and how much to add. My name is Flatingo and I love to make games. If you also like to make games, welcome to my YouTube channel. Good luck in your projects.

 


0 Comments


Recommended Comments

There are no comments to display.

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 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?
       
    • By JoAndRoPo
      Hi!
      Is there by any chance you can give me an idea/concept that's different but related to the game Tower of London? (Is it called Tower of London?)
      Can you show me some reference images, games or videos related to the same?
      I've attached a reference image.
      Thanks!

    • By jb-dev
      Another version of the main menu. This one has a more complete skybox. I'm not sure if it'll be a good idea to use the same shade on the actual Levels skyboxes...
    • By JeremyAlessi
      Jean Simonet is an indie developer who moved away from the AAA space in 2013 after delivering Skyrim and realizing that Fallout 4 just had him doing more of the same. Jean challenged himself and succeeded. 
      In this talk, Jean runs a counterstrike on every piece of indie gaming advice you've ever been told.
       

      View full story
×

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!