SAUCE'S PROFILE
Search
Filter
World Ease of Use: Interactivity and You
author=kentona
It may not be absolutely true, but it generally is.
Interestingly enough, I think my point is closer to HOW MUCH a game sticks out. Yeah, most of the time, quality games get noticed. But even amongst popular games, the popularity isn't indicative of its quality.
author=LockeZ
But I'm not sure how the original statement was supposed to be relevant to this topic... like, at all.
The reason is this is basically Craze's argument. He's arguing against popularity contest and for pure quality. It's debatable which is more important to people, but its definitely NOT popularity = quality, which is what I interpreted someone saying.
What makes a game's story memorable to you?
I think the plot by itself does not need to be believable.
However, the characters do need to react believably to their environments. At least in noncomedy situations.
Yeah this.
However, the characters do need to react believably to their environments. At least in noncomedy situations.
author=rabitZ
A good antagonist is half of the story's success! (e.g.: the joker, loki in thor/avengers, magneto, etc...)
Yeah this.
World Ease of Use: Interactivity and You
author=arcan
game that sticks out = higher quality game
This is not true. I wish it were, but it's not.
Input Based Minigame (Trouble resetting)
KoG
If you went with
Key Input Proc for Variable(with Wait unchecked)
Wait 0.1 Seconds
Branch if Variable = Key pressed
- Jump to Label/Call
and repeat for the 1.5 seconds with all the end event processing you might need, then have the "no key pressed at all" event trigger at the end of that 1.5 seconds. You should get the desired result within your existing code.
I'm not sure exactly how the Key Input Proc with wait unchecked works, but this layered input opportunity works for that time interval. And it makes it easier for there to be different reactions at different stages of the same interval.
I have a soccer timing minigame where pressing the key in the first 0.3 seconds causes you to sky the ball. The next 0.3 seconds is the sweet spot for a good shot. And the 0.3 seconds after that scuffs the ball for a slow roller.
Hope that helps.
If you went with
Key Input Proc for Variable(with Wait unchecked)
Wait 0.1 Seconds
Branch if Variable = Key pressed
- Jump to Label/Call
and repeat for the 1.5 seconds with all the end event processing you might need, then have the "no key pressed at all" event trigger at the end of that 1.5 seconds. You should get the desired result within your existing code.
I'm not sure exactly how the Key Input Proc with wait unchecked works, but this layered input opportunity works for that time interval. And it makes it easier for there to be different reactions at different stages of the same interval.
I have a soccer timing minigame where pressing the key in the first 0.3 seconds causes you to sky the ball. The next 0.3 seconds is the sweet spot for a good shot. And the 0.3 seconds after that scuffs the ball for a slow roller.
Hope that helps.
Short games, yay or nay?
I always imagine the episodic thing is the way to go if you have dreams of a big project you don't want to put down.
That way, you can have each finished product relatively short and maintain a certain level of quality throughout. Or if you have concepts and design choices you want to implement, you can implement them in the next chapter, without having to create a new IP or let your already made resources go to waste.
I know there's quite a few memorable chapter one games out there. Even if chapter two never happens, you wind up finishing something, without giving up the dream of a huge project by limiting your scope before you start.
That way, you can have each finished product relatively short and maintain a certain level of quality throughout. Or if you have concepts and design choices you want to implement, you can implement them in the next chapter, without having to create a new IP or let your already made resources go to waste.
I know there's quite a few memorable chapter one games out there. Even if chapter two never happens, you wind up finishing something, without giving up the dream of a huge project by limiting your scope before you start.
Let's Build a Planet! Atargatis!
Research, Mofo, Do You Do It?
My research leans more towards behavior than glossary stuff or items. Like, understanding the metalworking process will help you make better blacksmiths, architects. Researching the customs and oddities of a traditional royal court will help you develop your own royal court.
Even if you already know certain things, researching it again might help you visualize. It doesn't have to be an interactive textbook.
Even if you already know certain things, researching it again might help you visualize. It doesn't have to be an interactive textbook.
The Customer Is Always Right - Perception Of Designer & Player "Responsibilities" In Amateur & Commercial Video Games
author=Max McGee
1) For 90% of the time this topic has existed, you weren't even a part of this site, unless I'm mistaken, so what do you mean "no". : P
2) This is a really confusing sentence. Don't "REVIEWERS" belong to the set of "everyone"? Hence they'd be excluded by the phrase "no one".
Poor explanation on my part. Reviewing a game should be different from just playing a game. That's the distinction I wanna make.
And besides, when did this start? 2011? I somehow doubt user/reviewer behavior has changed drastically in a few months.
The Customer Is Always Right - Perception Of Designer & Player "Responsibilities" In Amateur & Commercial Video Games
author=Max McGee
Has this topic as a whole convinced anyone to try and be a little more patient and open-minded when playing RM games in general?
No. No one has any obligation to be patient and open-minded when playing RM games. There is a reason I brought up that subtopic. REVIEWERS have an obligation to be more patient and open-minded when playing/reviewing RM games.
author=sbester
Might I remind you all that there are reviews on this site with the clear message of "please stop making this, move on, or start over from scratch because your game sucks". There are people here whose objective in writing the review is to TRY to make the developer quit, so when the developer does quit, we can't really say the reviewer failed. It's an awful thing that people try to make themselves feel all high and mighty by doing this, but it happens.
I said what I said, because even those mean spirited reviewers "defend" themselves by saying they're only trying to help. Which you know is total BS.
In the case of people who actually are being critical for the sake of setting a standard for RM quality - I say let me remind you that they might quit. As an unintended consequence.














