How do you know if the game that you've designed is "fun"?

Well that's what's happening right now, basically. There's enough data to reconstruct most player actions with low granularity from most analytics. See that blockbuster game you're playing? It *knows*. Granted, it probably didn't know you stared at the npc's ass for all of 3 minutes, but it probably did know you spend more time than normal in her area thanks to the heatmap.

Far better you don't actually think of it as a privacy thing. It's a game, not your private spreadsheet of bronie purchases or whatever.

This isn't actually abnormal, analytics are used on you even when you are at home watching tv. Correlations between electricity surges and advertising help measure how effective the advertising is or the program you're watching.

There's data everywhere, and it's legal.

Privacy is an unusual concept. Is it just mankind seeking a bit of territorial space rather than just wanting to hide what they do? I like to think so, with crowded cities being far from what we've adapted to over the last million years.

 

Two words: Early Access.

 

If I say it, it's awful... if someone else says it, it's analytics.

 

That is precisely why I put my first point there. You loose focus if you just think about "How to know if the game you've designed just wants people play the game more".

You gain focus if you think about "How to know if the game you've designed makes people laugh".

Or "How to know if the game you've designed makes people reflect about their life".

Or even "How to know if the game you've designed makes people spend lots of money into the game".

You will get totally different solutions and they will probably highly incompatible with each other (maybe except many solutions contain some kind of "measure reactions in playtests").

Depending to whom you talk, you will find all these three things as a valid replacement for "fun".

Precisely. There are many answers in the thread that just assume you asked "How to know if the game mechanics you've designed is ...".

Where are your thoughts about "How to know if the art you've designed is ..." or "How to know whether the level design is ...". And are they all as valid parts of game design as game mechanics? (I think not, btw.. . But my artist coworker heavily disagree )

 

If you yourself like to play it. If you don't want to play your own game, why should anyone else be excited to.
Keep adding fun elements, within the parameters of game design, until it's fun for you.

 

I like this, this is how I plan to succeed. I'm my own judge, jury and executioner. Just as harsh as I come across, I'm 10x more critical of myself. That's how it's done.

When you go to playtesting, it won't be to help develop the core game, but to make what you already have better.

My idol, the toy maker/samurai's philosophy:

He admits also, that you cannot know if a game is fun until you play it. I'm certain that we will never know how many ideas he has silently disregarded because they didn't work out.

 

That is my view as well. I do appreciate feedback from others. But I am building a game for me and that should automatically make the game reasonably fun for people who are into retro gaming as I am. Sometimes we can get too close to the project though. Maybe take a break periodically and revisit.

 

Good. That way no one will ever find out about my Pinkie Pie pillow! It's the warmest, snuggliest thing evar!

Oh, wait...

 

How 'bout websites, for the matter? The very fact of loading a website means requesting their server to send you a specific set of data. That very request tells them exactly what you're looking at. You're telling them what you're looking at before it even gets to your screen.

 

Dammit, HTTP Request Headers! You even know in what capacity I'm using a page! (Verbs: GET, PUT, POST, DELETE)

 

Yeah, this whole thing about intelligence agencies (and other people) snooping our internet histories is silly. All they've ever had to do is listen in when we broadcast what we're doing to everything between our computer and the one it's talking to. People are misled by the fact that they're using a small screen in a private corner or whatever, while forgetting that most interactions you have on the internet are in public.

 

So in short, get your play data if you need it.

 

@Immanuel Scholz

Lets put it this way....I didn't have any specific emotion I was looking for so instead of making a billion and one threads, I created this one looking for how people generally test their projects for their own interpretation of "fun"...I am well aware that these are general answers and approaches to a general question, specific questions and situations will call for more specifically tailored answers or approaches.....

You're right! the general assumption here is that you're game is about game mechanics, so the art testing is a valid approach and branch off what generally people are thinking here also I do agree that some are not valid parts of game design as game mechanics (at least not inherently) but they can be, depending on the game

 

Ok, right. so enough of the meta - talk. Here some personal views about "how to know whether the game is ..."


"Drag some friends over and watch them playing some prototype" was suggested before.
I think that's a great idea! However, it has several heavy restrictions to be executed.

1. You need to know what drives your game experience. Is it the art? The difficult puzzles? The interesting game mechanics? The execution of said mechanics?
2. You need the prototype that covers at least these core aspects. You can leave out everything else. If you do, you will get a verification whether your game is REALLY about these planned aspects. Or try to make a prototype of "the whole game but smaller" and include everything. That's great if you are not really sure what you want as core game aspect..

An interesting point here is: I think that many "prototypes" are not need to be games at all. If I made a horror game that emphasizes on a change of seren landscape and some uninteresting side quests and then shocking artwork to unease the player, I would probably make a dia-show of just concept arts and have them comment one single sentence on each graphic. When the shocking art comes, I'd see their reaction and whether they find it silly (bad) or misplaced (okish) or disturbing (good). Not a single line of code needed.

Sure, the game mechanics may matter. They could be an RPG levelling, first person shooting, match-3 bejeweled puzzles or hidden object stuff searching.. whatever. But they are not core aspect, so why implement them already?


"Play it yourself. You need to like it and everything else will follow" is another popular suggestion. Of course, it will hurt your design if you dont like it yourself. But unless you are a one-man-show (or a one-man-ruler in your companies game design department) its kind of a lame an impractical suggestion..


What about this one: "Have other people develop the 'same' idea."
Basically, you tell fellow designers what gaming experience you are looking for and about half of the ideas you already got. Then ask them to think it through more and tell you how they would proceed to achieve the given game experience. After that, compare their ideas with the rest of your ideas. I think this might be a great way of verifying whether you are "blind to your own preconceptions". Of course, you would vary the "half of the ideas" with every person you ask.

(This is "Just talk with people about the game idea" with some twist. But I think its a nice twist. )


Or another one: "Give other people a list of your game ideas and ask them for the expected game experience."

The idea is to just list game mechanics, art styles, raw input mechanics, raw puzzle ideas without giving any context about the game experience (what makes the game "fun"). Then ask them what they think the game is about. (What kind of "fun" they expect to emerge from the game). If I try this the first time, I wouldn't be suprised finding a totally different answer from every person. And a good starting point for discussions of what you need to change to finally arrive at YOUR idea of "fun".

 

Like vertical and horizontal slices? A horizontal slice is a small sliver of the entire game experience (cuts across), and a vertical slice is a test of a single bit of functionality (cuts down). Or, I could have them backwards.

I try to have goals for my prototypes, like "Is this idea any fun?" (aka Christmas Crush) or "Will this theme work?" (aka Tap Happy). Those had small prototypes. And, I also have BIG prototypes, like the prototype I've been leading for 6 months involving 5 companies and 7 hospitals, which asks "If 200 random people at a conference play our game, can we prove they've learned ANYTHING about safe surgery?"

Gigi

 

Backwards, but a nice, concise summary. If a game is a layer cake of different systems, a vertical slice cuts a thin piece through all of them. It provides a big picture experience that demonstrates all of the systems -- in a shooter, maybe a single zone with one type of weapon, one type of powerup, one type of AI, etc. It conveys the spirit of the game. Verticals are really useful to evaluate the overall "fun" of a game early, especially for fresh playtesters. A horizontal, on the other hand, puts a single layer (e.g., rocket launcher weapon system) through its paces. It's good for evaluating the "fun" of a single mechanic.

 

So, the cake isn't a lie after all.

 

Just watch out that your players aren't over-awed by the graphical icing. Can't ignore the icing, but if the cake tastes like garbage... sometimes it's better to make a graphics demo than a game.

 

I think what we really need is more food metaphors for game design.

 

Cake is good. Icing is good. I'll take a big vertical slice of that. Thank you very much.
Gigi

 

This is a tangent but, if you're a designer, watch out for vertical slices. They're great for investors and playtesters. But if the slice is too wide for the delivery deadline, programmers especially will end up taking shortcuts. Fixing the bugs caused by shortcuts takes more time in the long run, meaning you'll have to cut features to ship on time, and that can have a big impact on fun. Designers have the biggest role in defining the scope of a vertical.

 

Please make a cake theory thread.

 

While that's valid, it's also limiting as @Immanuel Scholz suggests. I'll call upon my oft used example here: Spec Ops: The Line is a super engaging game that is completely the opposite of fun.

Personally, I decide on the experience I want people to have and then try to mold my game to best give people that experience. That requires getting the target audience playing the game and observing them. "Fun" is a common factor, but it's not ubiquitous, and it's rarely useful alone. Even when you do want to get people having fun, what kind of fun? Slow and pleasant or fast and energetic? Thinking fun or reactive fun? Short bursts or long sessions? Immersive or gap filler?

So, don't think about "is my game fun?" Think about "is my game providing the experience I want it to provide?" Because Immanuel is right in that asking the wrong question can subversively guide your design. I highly doubt that the team behind Spec Ops: The Line asked themselves if their game was "fun".

 

Alright then I'll try to be more specific in future threads!

 

I think to a degree to make your game fun you need to be able to have fun yourself... whatever's going on in your mind will likely translate into your creativity. Can you make a funny game without knowing how to be funny?

I also like the idea someone said about removing pain... remove the obstacles to the natural presence of fun, so that at least if the player is in a good mode you don't bring them down.... but also a good fun game I think should also elevate your mood and lift you up to feeling lighter/happier, and that can be an art.