less is more for mechanic design, while the more the better for details design

There is this mantra in the indie developer scene: fail faster. It became a common phrase because of countless indie devs' countless hours, weeks, years of experience.
Are you sure you're alone know better without any done games under your belt?

Honestly, you do whatever you want, I don't care the slightest, I'm writing this because I don't want the other newbies like you to get the wrong idea.

 

How can you fail faster? Making game isn't like swimming in which you can fails several times one day. In game industry, maybe you spend several years only fail once, because you only have one game to fail. The time of making a game is so longer, it's very hard to fail faster.

 

Citation needed.

Citation needed.

Citation needed.

Citation needed.

Citation needed.

 

Do it, test it, throw it away, next idea. Do this for a while, with every step your design will be a little bit better.

Build many prototypes, hold test sessions and throw it away if it's not fun to play with.

You like youtube "tutorials", right? Here you go:

 

I thought it's not problem for you. You are experienced, if you don't know these numbers, that's very bad because you have been in an unknown world for many years.

If you still don't know, Let's wait Ryiah. She's good at googling.

 

I don't know those numbers because my actual job doing market analysis on games has me deal with real life devs and real life numbers.

You, however, keep dealing in ass-pulls.

 

Risking the wrath of the mob by returning to the topic of the thread rather than just letting the thread die.....

I was thinking about the simple, elegant, concise mechanic vs the obscure or complex mechanic. There's definitely times when the later is what is needed. Obscure and complex mechanics can make the game feel more real, more lifelike, and makes it take a lot longer for the player to figure out how to min/max the mechanic. For example, simulating an actual economy where it feels like a real world economy, or like in CK2 the web of family connections and their motivations is so complex it feels real rather than objects with references to each other for you to manipulate (makes me feel a little bad executing my mentally deficient eldest son so his younger brother will inherit the thrown).

People keep bringing up prototypes over and over for a reason.

You create your prototype, you test it, you get others to test it. More than likely testing will reveal problems (a failure), so you change it or make a completely new prototype. Rinse/repeat until after enough failures you have a success. This process can occur really fast, months or even weeks, where you may have failed 0 times (got lucky the first try) or failed a dozen times.

Then you start working on the real design, and you build the real version of your game in a way where you can start getting other testers playing it as early as possible. So you can take their feedback, and improve your game further. Each time you make a change based on feedback it is a form of failure, but you're using those repeated failures all along the way to improve your game.

If you use your strategy of design in a bubble, argue with any constructive criticism rather than try to understand any value in their perspective, and just drop the finished game on the world after years of work, you're almost certain to be delivering a flop.

As an example, I've been working on a sailing game for 2 years now. I had made a prototype a few years prior which exposed a lot of design problems both that I could see and others that testers pointed out. That experience significantly changed my approach to the project I'm currently working on.

For the last year I've been getting other people testing my game as often as I can, and I'm getting a lot of positive feedback and plenty of negative. Some of that negative feedback I already had on my to do list, but a lot of it was not expected and I had to change the design. Because of all the feedback, the game is very different from the way it was written down before the original prototype.

 

Everything has two aspects.
If you fail faster, maybe you grow faster.
If you fail faster, maybe you lost acres of diamonds.

 

WTF?

I'm afraid to ask, but I will bite. Why? How? If you fail faster you find the diamonds faster. That's the entire argument. You're not wasting your time on the kids' marble.

 

How are you going to recognize a diamond without having check to make sure they aren't just some fool's lost cubic zirconia? Well, you'd have to test them first, something you refuse to do.

 

I have stated many times, last year I made many prototypes, more than 50 prototypes.
Now I realized the importance of game design theory.
If I restart to make prototypes, they will be very different.
I upload my prototype on one site. I don't know whether you can view.

Videos link here
Some snapshot of my prototypes videos

 

Quality is not equal to the amount of time you spent on your game, the size of said game, or the complexity of said game. Quality is a combination of effort and experience. You won't make a good game with zero experience.

All of that is irrelevant though because a high quality games doesn't guarantee you sales any more than a low quality game guarantees you no sales.

Let's be realistic here. If you're too lazy to gain experience by building game upon game then you're likely too lazy to market your game to make sales, and without marketing you basically have no chance of being successful.

 

Can I think you and Ninja never head of a book? The book tells a story. An ambitious and working hard young man tried everywhere, though he lost diamonds, but he grows by taking lessons.

 

I don't think you notice the meaning of the digging well cartoon.

 

Every post you make says otherwise. At this point I don't believe you made any of them.

 

I can change signature or title name for your check.

 

If those videos are not mine, so you are right.
If those videos are mine, are you still right?

 

Stop using books as an excuse to rigidly adhere to prescriptivist concepts when those concepts are not at all something that exist in practical situations.

 

But the goal of prototypes is the follow up feedback/iteration loop. Did you really have people testing these 50 prototypes, giving you feedback, etc? How did none of these 50 result in a game worth pursuing?

 

Every time Murgilod said make the game, and you follow on. I think there is a big difference between game and prototype. I don't confuse game with prototype.

 

Yes. I let gamers commenting my prototypes, they like AAA graphics and provide many suggestions I can't afford. And then I knew I can't make such a game. I should turn it into an interesting game. Then I came to game theory for info to make an interesting game.

 

So 50 of prototypes you say. If you really did them by yourself from beginning, that would represent pretty full set of skills, to create at least one functional game. Don't have to be top notch, but functional. Btw., vids look far from AAA quality. And that not even touching content.

But I do recognize some of these assets, including mechanics. Meaning you copy them, either from asset store, youtube (I.e. Brackeys tuts), or other source. Which is fine. But appears, you don't really understand how they work behind the scene, other than putting them together. As the result, you struggle with understanding what you want and what you need, still focusing on theory.

So maybe you should ask yourself, what kind of game you want to create? As so far, you seams jumping from flower to flower, with no concrete target. Again, reading books will not bring you answer to that.

 

I checked every template of asset store I can use and every tutorial I can use.

At that time, yes. I didn't know how to design mechanics.

I think it's no longer a problem. Now I know how to connect these prototypes.

Do I say just read book to learn game design? Do I read 5 years? I only read several books recently, and want to discuss it. But people prefer to burning books.

 

I think @Murgilod just likes to argue. Contrary to public opinion, there's nothing wrong with that, provided its a healthy debate.

 

Nope. People here like to burn people who read a book and think he (or she) is a pro and should hand out summary statements instead of asking questions and working on games/prototypes which actually try the concepts we are talking about.

I read probably all the books on game development and design which can be handy during development using Unity, but I don't think myself as a professional so I don't try to tell people who actually work in the field that they are wrong. I try to rely on them instead.

As a friendly advice (take it or leave it, it's up to you): try to talk to people here with more open questions and less cemented statements. You will/would achieve more. Instead of put people in the position to argue with you because you stick to your dogmatic positions (which often dead wrong), try to ask questions and hear what people tell you, refer to it and don't dismiss it right away.
One book means culminated experience of one or two people usually. Here on the forums we have a couple of dozens battle-tested people who could share their experience with you (us). You just have to be open minded to hear it.

 

Sure, I am open minded. I think it's obvious in this thread. I just want to have health discussion. YBthS said my thought should not be treated as law. I agree. I replied I use "should" here for emphasizing.

 

If you were open minded, you would have taken the advice given to you months ago that was "books are nowhere near as important as practical experience."

Reading a book does not make you open minded. It just means you read a book.

 

How can you get this conclusion?

 

By reading your posts over nearly the past year.

This is nothing new.

 

You said you are an analyst, and you have no experience either.

 

Except I do have experience. In fact, I've talked about this experience all over. I've discussed things from the statistics of what settings get changed the most, market difficulties when it comes to early access games, all sorts of things. On top of that, I've also worked as a hiring consultant for people who can't afford to have their own HR department. On top of that I'm also an experienced game developer.

You, however, have spent months making excuses, to me even, saying how making the game isn't important. You have said this to me and others, the vast majority of us experienced game developers.

 

Anyway, you say it, people just follow on.

 

Seems legit.

 

I remembered two months ago, I said, the goal of making the game is not important than the goal of the game because numerous failed games come out each year. I don't say making the game not important.

I said in this thread making the game doesn't matter if you don't make game design.
Also I said in this thread making the game is expensive, if you know what and how, but don't know why.

 

Without research, making a game of course doesn't matter.
Think about what will happen when a person goes into a big desert without water and umbrella.

 

Clearly you didn't remember correctly. If that sentence was intended to have more meaning then you should have added more words to it. We're not able to fill in blanks you leave behind. Especially as there is clearly a difference in language here to some degree. We're not mind readers.

 

Wha'ts wrong?

 

Clearly quite a bit if you're not able to understand.

 

You can make a game for free. All it has to cost is time.

 

I can for free. What about other people? Can they make game for free?

 

Of course. Anyone can make a game for free. Notch made a game for free called Minecraft. All it took was his time and a copy of Java.

 

Books didn't answer that question yet?

I always say, game dev and in fact programming, is one of the cheapest profession skills people can get and master.
Thing only needed is, some computer and access to internet. Rest is just commitment and time. Higher education and/or work as programmer are optional.

As the result, we got tones of tones of software all over the world.

 

If that simple. Why so many people hesitate to be indies?

 

Because no amount of books can prepare you for entering a market that is constantly in flux and that has been in that same flux for a decade now.

And even then, it's not that they hesitate to be indies, it's that they hesitate to leave their jobs for something that likely will have no financial returns.

 

I just want you know making game is not free, because sometimes

 

You just love digging around for excuses, don't you? Quitting your job is never a requirement for creating a game. We have many people in this community that are developing their dream game while working a full time job.

 

You create excuses, not me. I just find something you contradict.

 

You know, I think I'm done with this thread, and to be honest I think the moderators need to just close it. You clearly have no intention of taking anything anyone says seriously that doesn't simply agree with your own opinions, and if you provide any response at all it's only to twist it to fit your agenda.

 

I am open minded for that.

 

Your example is what I want. But obviously we have different definition for mechanics. Simple mechanics work together to get a real world economy. The mechanic is so clear to the coder, while the gamer didn't have any idea at first. If you hide some information that means you make the details obscure.

In mechanics, you design the most important factors. I consider inventory system or shopping system as an autonomous (or modular) part (of details). In mechanic design, you make the rule that money is important. Then the gamer will open inventory frequently and look for something has value. The inventory system (modular ) can considered as one part of the details. Make the inventory very complex for instance has 10 categories (each category has 100 items). I call this the more the better for details (like inventory).

You needn't make complex mechanics, that will make coding very complex and maybe confuse yourself later. Just combine several simple mechanics together. I call this less is more, because several simple mechanics together can create huge dynamic complexity.