Sure, there are plenty. Mass effect, for one. you are often stopping to hide behind cover, engaging in a firefight, then moving on. Oblivion's combat system didn't have a lot of flow to it, it was very hack and slash. Deux Ex: Human revolution is about carefully sneaking around, not smooth motion. I don't even think the concept is applicable to adventure games. Many puzzle games don't have flow. Most FPSes don't really care about flow, though mirrors edge(if you are going to classify it as a FPS, its more like a first person platformer) is based on flow. RPGs typically don't have flow, nor do RTSes.
I mean, they are smooth, but its not quite the same thing as flow. Smooth controls and actions are important, but its not the same thing as lets-go-and-not-slow-down. Flow is not a universal concept, however it is good to have where it makes sense. Having a good flow can be a very powerful thing.
Do you understand the implications of the statement, or is it just something you are parroting to be cool? Insulting someones mother is a serious thing that people take offense to. Hence, statements beginning with "your mom..." would be the intro to an insult to someones mother. This phrase got shortened to "Your mom", leaving the insult unspoken, but implied. This shortened phrase is not as obviously insulting, and gets parroted around alot. But it is an insult to their mother, and they have every right to be offended by it.
If you choose an answer for this question at random, what is the chance you will be correct?
A) 25%
B)50%
C)25%
D)75%
Thats not a paradox so much as not having the correct answer available, though the non-presence of the correct answer is part of why its correct. The answer is 0%, since neither 25% or 50% are correct, and since 0% is not present, you have no chance of selecting it. Its an odd situation, but not really a paradox in the current form. If I say
Which has four legs:
A) a snake
:cool.gif: a human
C) a bird
D) a fish
there is no correct answer listed, but its not a paradox.
(Not really a paradox but still confusing)
*ahem*
A baby girl is mysteriously dropped off at an orphanage in Cleveland in 1945. "Jane" grows up lonely and dejected, not knowing who her parents are, until one day in 1963 she is strangely attracted to a drifter. She falls in love with him. But just when things are finally looking up for Jane, a series of disasters strike. First, she becomes pregnant by the drifter, who then disappears. Second, during the complicated delivery, doctors find that Jane has both sets of sex organs, and to save her life, they are forced to surgically convert "her" to a "him." Finally, a mysterious stranger kidnaps her baby from the delivery room.
Reeling from these disasters, rejected by society, scorned by fate, "he" becomes a drunkard and drifter. Not only has Jane lost her parents and her lover, but he has lost his only child as well. Years later, in 1970, he stumbles into a lonely bar, called Pop's Place, and spills out his pathetic story to an elderly bartender. The sympathetic bartender offers the drifter the chance to avenge the stranger who left her pregnant and abandoned, on the condition that he join the "time travelers corps." Both of them enter a time machine, and the bartender drops off the drifter in 1963. The drifter is strangely attracted to a young orphan woman, who subsequently becomes pregnant.
The bartender then goes forward 9 months, kidnaps the baby girl from the hospital, and drops off the baby in an orphanage back in 1945. Then the bartender drops off the thoroughly confused drifter in 1985, to enlist in the time travelers corps. The drifter eventually gets his life together, becomes a respected and elderly member of the time travelers corps, and then disguises himself as a bartender and has his most difficult mission: a date with destiny, meeting a certain drifter at Pop's Place in 1970.
The question is: Who is Jane's mother, father, grandfather, grand mother, son, daughter, granddaughter, and grandson? The girl, the drifter, and the bartender, of course, are all the same person. These paradoxes can made your head spin, especially if you try to untangle Jane's twisted parentage. If we drawJane's family tree, we find that all the branches are curled inward back on themselves, as in a circle. We come to the astonishing conclusion that she is her own mother and father! She is an entire family tree unto herself.
What I love about that is is that it is genetically feasible. Whilst the chances of a child with yourself being yourself is astronomically low(unless you have a genetic code where all gene pairs are identical), it is possible, which is enough to support a time loop. However, it is a paradox, specifically the ontological paradox. There is no origin. The person is their own origin, meaning they came from nowhere, which is a paradox. The right time travel model can adequately support it happening, but it is a paradox.
Thats not a paradox. It simply states that any system will either be incorrect, or incomplete. Either you can prove false things are true, or there are true things that are not proveable. It essentially asserts that proveable is not the same thing as true, and which is the subset of the other is up to your system. Though neither has to be a subset of the other, that would be a fairly useless system. Of course, such statements are proveable, just not within the scope of the given system.
The poster child for such an statement is basically "Within system X, this statement is not proveable". If it is proveable, then it is false, and you have proved a false statement, and your system is incorrect. If you cannot prove it, then it is true, and you have a true statement you cannot prove, and your system is incomplete.
This is not a paradox.
If 1 fan blows a rock with controlled variables, and theres a SOLID 50% chance of doing so. The fan doesn't blow the rock away given the chance. In a another universe the fan does... Would this create another universe?
Thats not a paradox either. Thats just a bizarre possible implication of quantum mechanics, incorrectly applied to a classical probability. People make that mistake alot. Every classical chance does not result in a different universe. A dice roll is not really random, its just the result of the chaotic system of the way the dice was tossed, making it essentially impossible to predict. Quantum events will create new timelines, so unless you can trace the outcome of the chaotic system to a quantum event, it will not create a new timeline. And since it will be the outcome of the quantum event that creates the split, not the classical chance, the distribution of outcomes is not dependent on the classical probabilities.
Of course, every possible combination of quantuum outcomes will exist in its own universe, however slight the probability. And since essentially everything is possible, however infinitesimally unlikely, every possible universe will exist. The more unlikely outcomes are just in such a infinitesimally small percentage of the universes(which does matter, even given a truly infinite set of universes), that even if you could somehow travel between these universes, you would not find a reality that significantly deviates from our own. In fact, since this universe is the sum result of a mind-boggling number of quantuum fluctuations, their net impact will tend to cancel. Quantuum effects on a chaotic system make it more predictable. This means that other universes would be exceedingly likely to be nearly identical to our own.
This changes if a single quantuum event can be magnified into having classical effects. Schrödinger's cat is an example of such a magnified event. The outcome of a single quantum event is measured, brought into the realm of classical relevance by a device that breaks a cyanide capsule, and into a matter of life and death as that cynanide kills, or does not kill, the cat. The further effects of that cat's life or death creates a permanent, distinct divide in realities, and makes it so both outcomes are likely.
So this raises the question: Do such magnifying mechanisms exist naturally. And the answer is "yes". Mutations. A mutation occurs when a particle of radiation hits DNA just right, and causes a change. This change in DNA, if in a relevant portion, can magnify into a profound difference in the creature. The emission of radiation is a quantum event, and is actually the same event typically used in the Schrödinger's cat experiment.
Now, there is a classical stabilizing effect on evolution, due to the forces of natural selection weeding out bad mutations and allowing good ones to thrive. However, this does mean that alternate timelines are more likely to have a different evolutionary history than a different outcome of a dice roll.
However, any change in evolutionary history would occur in the far past, at least if it is going to have any noticeable impact on things. This raises the issue of whether your temporal proximity to the split is relevant in deciding what universes are accessible, essentially whether "nearness" of the universe is relevant, or merely the overall likelihood in the grand distribution of universes.
This has nothing to do with paradoxes anymore, but I've types it out, so there.
Not a paradox. "Everybody lies all the time" is not even a paradox, just a false statement.You take it as false, and it makes no assertion about its own truth value, and hence resolves to a simple lie. "This statement is a lie" is a logical paradox. If you are lying, then you are telling the truth, which means you are lying, and now the statement does not have a truth value.
Achilles is in a footrace with the tortoise. Achilles allows the tortoise a head start of 100 metres, for example. If we suppose that each racer starts running at some constant speed (one very fast and one very slow), then after some finite time, Achilles will have run 100 metres, bringing him to the tortoise's starting point. During this time, the tortoise has run a much shorter distance, say, 10 metres. It will then take Achilles some further time to run that distance, by which time the tortoise will have advanced farther; and then more time still to reach this third point, while the tortoise moves ahead. Thus, whenever Achilles reaches somewhere the tortoise has been, he still has farther to go. Therefore, because there are an infinite number of points Achilles must reach where the tortoise has already been, he can never overtake the tortoise. From http://en.wikipedia.org/wiki/Zeno's_paradoxes#Achilles_and_the_tortoise
Not a paradox either. The greeks simply did not have the math to express a cumulative sum of an infinitively decreasing timespan. Its essentially the formula (1/2 + 1/4 + 1/8+1/16....) , which =1 . Because it takes half the time to transverse 1/4 of the original distance as it did to traverse 1/2 the distance, the sum of the infinite sequence is a finite number, and hence you will catch up in a finite amount of time. Just not a finite amount of 1/2ings. No paradox, just ancient mathematical inadequacy.
Replaces all terrain graphics with ACII letters. Think of it like a 3D rougelike. Unfortunately, many blocks start with the same letter, but they have coloring appropriate to what they are, to help alleviate confusion. Items and mobs are unaffected, but the sun, moon, rain, and stars are changed.
This does not have the 1.9 graphics, which is why there are some purple boxes in the screenshots.
Now, I cannot justify saying "Games must have flow". There are many games, and entire genre's, that are not dependant on the flow of the game. However, I will say this:
Having good flow can only improve a game.
For some games, it is crucial. Sonic, for example, or N, or super meat boy. So, what do I mean by "flow"? Flow is the ability to have your actions in the game move smoothly into each other. Now, flow does not have to be automatic. It can, and perhaps even should, require skill to achieve. However, the game, when played properly, should achieve a good flow. Lets take Sonic as an example, mainly because I've been playing it alot recently. played medicorely, you can walk through some parts of the level, look around, jump on enemies, dainty hop around the spikes. You can play it like a standard platformer, like mario. The level design supports this very well. However, when played well, you are speeding through the levels. All of the mechanics are designed to support this. You have the spin-dash to quickly gain momentum. You have loops and twists that serve no real purpose beyond showing off your speed. You have plungers that can quickly accelerate you, and change your direction instantly. You can do a roll while at speed to simply smash through enemies unharmed, and be unslowed by it. Once going, you can simply keep going, jumping up to more optimal paths, finding that hidden route that will take you across the level easily. Such routes are often not only possible to take at speed, but require you to take them at speed.
N has a different approach, but flow is still crucial. If you try to carefully step through the levels, you are going to get blown up by missiles. You have to have enough momenteum to make the jumps, keep moving to avoid homing missiles, take the right routes to avoid enemies. Super meat boy begs you to keep the momenteum up, designing the jumps to be taken at speed. If you look at speed runs of mario, the person has found a flow through the level such that they can do it without stopping.
How forgiving you are about the flow can depend on many factors. In a short, 1-screen level like n, it can be rather unforgiving. A mistake doesn't set you back much. In a long, sprawling level like sonic, you need to be more forgiving.shy away from flow-breaking being instantly lethal, and instead drop the player down into a less optimal path. It should be something they can recover from, and get back into the flow, but that act of slowdown is a cost to the player. If you are scoring on time, this mechanic works great.
Another key aspect to consider is timing. Even if you don't consider flow to be integral to your game, putting in proper timing can make things so much nicer to play. If you have a series of platforms you need to jump between, make sure their timing is synchronized. You shouldn't have to wait for their respective motion cycles to happen to coincide. They should be integer multiples of each other's timings, so when the platform reaches the end of its cycle, the next one is waiting. They don't necessarily have to have the same timing, but the one you are coming from should be the slower one. This means that when the one you are on reaches the end, the next one is waiting. Going backwards may be less smooth, as it means that the platform will go out, and there may not be anything to jump to, but if the player is going backwards, flow has already been broken. Furthermore, as much as possible, try to make the platforms ready to use as soon as the player reaches them. If there is a button to start them moving, the time it takes to go from the button to the platform should coincide with the platform being ready to use. Having the platforms start by jumping on them can ensure this timing. In a short, n-like level, you know how quickly a good player will reach there with proper flow, and can time it accordingly,but the viability of that approach will depend on your game.
Jump spacing also effects flow. If you have to carefully jump out, and then pull back to land on the platform, there isn't much flow to the process. If the platforms are spaced at your natural jumping distance, then the process becomes smooth and fluid. If your jump distance is dependent on speed, then spacing platforms to be jumped at speed helps facilitate flow. having other platforms in between can make it so you don't need the flow to get through, but the basic design should facilitate a smooth transition.
Flow is very crucial if your game relies on speed. Racing games also need to have a good flow. However, it can also improve other types of games. Combat, for example, greatly benefits from good flow. The ability to take an attack, and have it flow smoothly into the next, to smoothly transition into a dodge, to combine your motion and attacks. Combat that is fluid tends to be more satisfying.
Good flow has also resulted into some amazing aspects of otherwise mediocre games. Spiderman 2. Not only is it a superhero game, its a movie game. Judging by general trends, that means it should have been a really awful game. But its not, and its mainly for 1 reason; it has AWESOME web-swinging mechanics. I have yet to see another spiderman game match it. It worked very smoothly. Push the stick in the direction you want to shoot the web, and hit the web button. Bam, you now have your webline attached to an appropriate corner in that direction. You can now swing from it, and it behaves as you expect. You can fire out a second line and have both out. This lets you smoothly transition from one webline to another, as well as pull off maneuvers like slingshotting yourself. Or, you can let go of your line completely, go flying through the air, do some flips, before launching out a second line for a new swing. It carries momentum well, and gives you good control over the swing. You can even do a boost while on the webline, giving yourself more momentum. Forget physics, its tons of fun. This same sprint button also allows you to run along buildings, given enough momentum. The webbing will also attach to new surfaces it hits, becoming a new anchorpoint for your swing. All of this together results in a really awesome web swinging mechanics. It captures all of the potential of being spiderman swinging around the city. An it is a blast. I literally start up the game from time to time for no other reason than to swing around. And at the heart of it all, is flow. Everything is fluid. You are carrying your momentum forward, up the wall, around the swing, using it to sing up and over, reversing your direction, or carrying it through your swing around the corner. It gives you the means to build your speed, and maintain it upon collisions with walls. It flows, and hence it is fun.
This is a general rule, but it partially relates to flow: Don't punish the player for being too good. I've seen it happen. For example, you have racing game with a door. It will open as players approach, making for some good dramatic scenes. However, if you are doing exceptionally well... you can get there before the door opens. Suddenly, doing very well translates into being a fireball. Not good. Other ways you can punish the player for being good is with collectibles. I'm talking about those rare collectibles that you collect once to unlock things, though this can apply to other highly desired collectibles. If you take a pit that looks like a bottomless pit of instant death, but make it into a pit with a collectible in it, you are rewarding players for messing up and falling into pits, and punishing the players who are good enough to not fall into random pits. Instead, put it on the ultra-good path that is tricky to get to. This rewards the player for playing well, and trying to seek out the collectibles can drive them to learn the more optimal routes. Thus, you are encouraging proper flow.
In Arden's Vale I spent no time learning the controls, I just started walking around, looking at things, and talking to things without a thought, It had the standard right-click to change action, left-click to perform the action, put mouse at the top of the screen o access the menu and inventory, all completely standard for many adventure games!
In Warning Forever It took oh so long to figure out the menu controls(I played the game several times before I figured out how to navigate the start menu), and the game controls are nonstandard! good game but learning the controls is not easy, but the flexibility of the shooting and how the bosses change as a result gives it a great twist. Also had customizable game modes in the menu somewhere.
Warning forever is a good example of how not to do your menu. It should not be hard to use the start menu. Its easy to overlook as a developer, because of course you know how to use it, so the fact its completely obscure to everyone else can slip by you. That is why usability testing is important. Find someone who hasn't played your game before, sit them down in front of it without instruction, and see if they can easily figure it out.
And when I say utilizing standard control schemes is good, I don't mean that you can't have your own method for controlling the game, if it is appropriate. Its more keeping to standards if that type of control scheme is common. If you made a FPS with IJKL for movement, but you are doing all of the standard things for an FPS, it would be bad. people who play FPSs on the PC are used to WASD. Not to mention that IJKL is not very ergonomic.
Whatever your game, it is important to have a good interface. Your interface is the link between the player and the game. It is what facilitates the entire game experience. The best interface is the one nobody notices. It should create a seamless experience.
If the player every actively notices your interface, it has failed. There will be a initial learning curve where the player learns the controls; The only way around that is for the learning curve to be placed in another game. For instance, first person shooter tend to use a fairly standardized set of controls. Because of this,most players have already learned how to use those controls, and don't suffer that learning curve. A good set of controls is intuitive enough to learn easily, and minimizes the learning curve associated with them.
After that learning curve, it should provide a smooth experience. There are many game I have played and loved, and even when playing them on a regular basis, I would be unable to tell you what the controls were. They worked smoothly, and I could simply use them without thinking about it. However, if a game has bad controls, it creates a hindrance in the game, and becomes noticeable. This is why I can tell you that sonic generations used X for speed boost, and B for duck. Normally this is not an issue, but there is a part where you need to be boosting, and ducking under lethal blades. A single mistake will force you to restart. And this was a problem, because X and B are on opposite sides of the key arrangement, making them difficult to use in conjunction. This is also why I can recite the control sequence in Red Dead Redemption needed to quick travel. Pull up the start menu, select the map, then place a waypoint where you need to go, then go back to the world, pull up the inventory, go to the second screen, select your campsite(and you have to be in an appropriate place to use it), select quick travel from the campsite menu, select your waypoint as the destination, and finally quicktravel. It is an ordeal. Contrast oblivion, where you hit a button to pull up your map, click on your destination, and then quick travel there. No muss, no fuss.
The challenge in a game should never come from the controls. Awkward controls never make a game fun, it is just annoying. If you find yourself designing a section where the challenge comes from working with awkward controls, redesign. Make smooth controls, and have a more challenging task.
What makes a good interface? To put it simply, a good interface is one that does what the player expects it to. This is another reason to use standardized controls. If people use a certain set of controls in one game, they create the expectations that they will work like that in a similar game. Deviating from standards can take an otherwise fine set of controls, and make them into a barrier. This requires particular consideration with sequels. If you are going to change basic controls between installments in a series, you better have a really, really good reason.
Customizable controls can go a long way to addressing these issues. The functionality available to assign still needs to be well-planned, but you can't meet the needs of every player. For instance, inverted Y-axis. This is a huge divide among gamers, should the y-axis control(and sometimes even x-axis control) be inverted? I can actually play with both(even x-axis inversion) given a warmup period, but the option to select which one you want can be a godsend for most players. Player's also tend to have quirks in their preferences. For instance, I prefer to have crouch attached to my side mouse button.
Speaking of extra mouse buttons, never require an unusual input device. Never require more than 2 mouse buttons, never require the use of the control wheel, etc. You can utilize them. The scrollwheel can be a convenient method of streamlining controls. However, it is not guaranteed(albeit rather likely nowdays) that it will be present, so other options should be available. In FPSs, it is often the weapon switching control. However, you can still use the number keys to select your weapon, even if you lack a scrollwheel.
One important guideline is to make it so the player does not need to reposition their hands. If they have both hands on the keyboard, they should stay on the keyboard. They should not need to reach over to the mouse. If the player's left hand is on the WASD keys, the controls for that hand should be easily reached from that position. For similar reasons, unify your game and menu controls. Don't control the menus with a mouse if it is a keyboard only game. Don't make enter the select key if the fire button also works. This lets the player use the same set of controls throughout the experience, making it more streamlined. The more mixed-in with the gameplay this is, the more important that is. For example, if you have a victory screen between levels, and the game is a keyboard game, don't require the player to use the mouse to interact with the victory screen. That just breaks the flow. However, if you have unusual menu controls, make sure they are obvious from the menu screen. There is nothing more frustrating that starting a game, and the hitting random keys on the keyboard to figure out how to select start.
The GUI is also important. First, it should stylistically match your game. Second ,it should be streamlined. Display everything you need clearly, and don't clutter it up. Don't hide things if they need to be conveniently accessible, but don't display things that aren't needed. also try to match the screen space used and the importance of the information. The exact health of every peice of armour you have probably isn't the most important piece of information to you at any given time, so you don't need an ever-present, full-body wireframe displaying all of their health. Your current health is probably extremely important, so it is appropriate to have a prominent health display. However, don't let it get in the way.
Try to display the information in the most relevant manner to the player. A numerical display of health may be very precise, but the player is generally more concerned with the percentage of their health left. Displaying it graphically makes it easier and quicker for the player to take in. Hence, the health bar. It may be appropriate to have a numerical display in conjunction with the health bar, but the quick overview of the situation is what is needed on a moment-to-moment basis.
Symbols can be a good way to label your interface without taking up much screen real estate. However, make sure your symbols are clearly distinguishable at a glance, and indicative of what they represent. Having a series of alien glyphs may fit thematically with your game, but is not going to convey meaning to the player. This is another place where standards are useful. The red cross may be cliche, but it has a clear meaning to the player.
Even better is the interface that needs no labels. Take minecraft, for example. the health bar, the hunger bar, the air bar, the armour bar, all are clear in their purpose, with no need for a label. The inventory screen is also designed intuitively, so there is no need for labels like "your inventory" or "chest". The few things that do need labels are done with clear symbols in a non-intrusive manner. The armour slots have a clear symbol of what goes in them, emblazoned directly on the slot, making it streamlined and keeping the interface clear. The furnace symbols are clear. The fuel goes under the fire, you put what you are smelting over the fire, and the arrow points to the output. Simultaneously, the fire acts as a gauge for how long the fuel will last, and the arrow acts as a gauge for how long it will take to smelt.
Also consider how much time the player will have to look at the interface. If it is a high-action, fast paced game, they won't have more than a quick glance to see if their health is low, and it would be really helpful if you can make low health highly noticeable. If it is a relaxed, tactical game, you have more leisure to display stat blocks, add in mouse-over text, and provide a wealth of information. If you are in a menu screen, there is no action, and you can take the time to display the information fully. This does not mean you shouldn't still present the information clearly and well, and have it easy to understand. Good design is important still, but the time constraints are different. Accessing a character's biography may be appropriate in a menu, it is almost certainly not appropriate in the middle of combat.
It is not just overpowered , it is the problems it will cause , in SSP , it wont be such a problem , but will cause some lag , but my point is that , imagine SMP , SMP has a lot of lag problems , and you cant say no , Imagine a dragon just flying there , were lag problems are a lot , that could crash the server.
But now to what you want to read
It is overpowered because the act of flying in minecraft is just overpowered
Not just dragons , imagine if minecraft vanilla had Single player commands included , you could just /fly /setspeed 5
and , you are basically in a dragon , play in a survival world , with fly turned on and your speed at 5 , tell me if that is balanced.
Well, considering that you have to accomplish the rest of the game before you can access it, all it does is provide you with a convenient way to explore. Since its confined to a dragon, you have to deal with its maneuverability, meaning it would only be suitable for above-ground travel in the overworld. You can't just leap into the air whenever you feel like it, you have to go to the dragon, mount it, and take off. The 8x speed boost of the nether will probably still provide a faster means of travel between fixed points, meaning it is mostly advantageous for exploration, or for a funner means of transport between places. A dragon flying is much, much more balanced than fly/setspeed 5, both in inherent limits to its use, and in the pre-requisites to accomplish it. Its not going to get you more diamonds, its just going to let you explore the world easier.
Now, I will acknowledge that the technical constrains in multiplayer are a valid concern. However, technical constraints are a challenge that can be overcome with clever development. The current server technology may not be able to hold up to a dragon exploring, but it hasn't had to. That was never a design consideration. It is a limit that can be overcome, if the end result is worth the effort. Gameplay issues are a bigger problem.
The balance issues would arise from the potential combative advantage a dragon could bring. Mainly in multiplayer, I don't think riding around a dragon and slaughtering everything on the surface is that problematic in SSP. Esp. if being on the back of a dragon makes it hard to collect item drops/exp orbs, or if dragon kills don't net xp. However, how the dragon combat works is unknown, so its hard to make any solid comments on it.
It means someone spent more time then any sane fan of any other game would to put together something for the community.
You obviously don't play the same games that I do. I find running the math on how to get the most efficient things done a fairly commonplace occurrence on games where that is applicable.
I think adding flyable dragons to the game is wonderful.
They would be like normal world Ghasts, you can fly them and they are moderately fast and shoot fireballs.
But they would not be able to fly for a long time, only for about 5-15 seconds and have to remain still to shoot fireballs.
Why do people always come up with weird, arbitrary restrictions on the dragons? I feel like its a knee-jerk "Its OP, so I have to add in some limits" than an actual consideration of what would make it too powerful and how it could reasonably be balanced, and how the limits will effect the actual gameplay. Adding in arbitrary limitations is not how you properly balance things.
0
Sure, there are plenty. Mass effect, for one. you are often stopping to hide behind cover, engaging in a firefight, then moving on. Oblivion's combat system didn't have a lot of flow to it, it was very hack and slash. Deux Ex: Human revolution is about carefully sneaking around, not smooth motion. I don't even think the concept is applicable to adventure games. Many puzzle games don't have flow. Most FPSes don't really care about flow, though mirrors edge(if you are going to classify it as a FPS, its more like a first person platformer) is based on flow. RPGs typically don't have flow, nor do RTSes.
I mean, they are smooth, but its not quite the same thing as flow. Smooth controls and actions are important, but its not the same thing as lets-go-and-not-slow-down. Flow is not a universal concept, however it is good to have where it makes sense. Having a good flow can be a very powerful thing.
0
0
0
Thats not a paradox so much as not having the correct answer available, though the non-presence of the correct answer is part of why its correct. The answer is 0%, since neither 25% or 50% are correct, and since 0% is not present, you have no chance of selecting it. Its an odd situation, but not really a paradox in the current form. If I say
Which has four legs:
A) a snake
:cool.gif: a human
C) a bird
D) a fish
there is no correct answer listed, but its not a paradox.
What I love about that is is that it is genetically feasible. Whilst the chances of a child with yourself being yourself is astronomically low(unless you have a genetic code where all gene pairs are identical), it is possible, which is enough to support a time loop. However, it is a paradox, specifically the ontological paradox. There is no origin. The person is their own origin, meaning they came from nowhere, which is a paradox. The right time travel model can adequately support it happening, but it is a paradox.
Yes. The better question is, does "the set of all sets that do no contain themselves" contain itself?
Thats not a paradox. It simply states that any system will either be incorrect, or incomplete. Either you can prove false things are true, or there are true things that are not proveable. It essentially asserts that proveable is not the same thing as true, and which is the subset of the other is up to your system. Though neither has to be a subset of the other, that would be a fairly useless system. Of course, such statements are proveable, just not within the scope of the given system.
The poster child for such an statement is basically "Within system X, this statement is not proveable". If it is proveable, then it is false, and you have proved a false statement, and your system is incorrect. If you cannot prove it, then it is true, and you have a true statement you cannot prove, and your system is incomplete.
This is not a paradox.
Thats not a paradox either. Thats just a bizarre possible implication of quantum mechanics, incorrectly applied to a classical probability. People make that mistake alot. Every classical chance does not result in a different universe. A dice roll is not really random, its just the result of the chaotic system of the way the dice was tossed, making it essentially impossible to predict. Quantum events will create new timelines, so unless you can trace the outcome of the chaotic system to a quantum event, it will not create a new timeline. And since it will be the outcome of the quantum event that creates the split, not the classical chance, the distribution of outcomes is not dependent on the classical probabilities.
Of course, every possible combination of quantuum outcomes will exist in its own universe, however slight the probability. And since essentially everything is possible, however infinitesimally unlikely, every possible universe will exist. The more unlikely outcomes are just in such a infinitesimally small percentage of the universes(which does matter, even given a truly infinite set of universes), that even if you could somehow travel between these universes, you would not find a reality that significantly deviates from our own. In fact, since this universe is the sum result of a mind-boggling number of quantuum fluctuations, their net impact will tend to cancel. Quantuum effects on a chaotic system make it more predictable. This means that other universes would be exceedingly likely to be nearly identical to our own.
This changes if a single quantuum event can be magnified into having classical effects. Schrödinger's cat is an example of such a magnified event. The outcome of a single quantum event is measured, brought into the realm of classical relevance by a device that breaks a cyanide capsule, and into a matter of life and death as that cynanide kills, or does not kill, the cat. The further effects of that cat's life or death creates a permanent, distinct divide in realities, and makes it so both outcomes are likely.
So this raises the question: Do such magnifying mechanisms exist naturally. And the answer is "yes". Mutations. A mutation occurs when a particle of radiation hits DNA just right, and causes a change. This change in DNA, if in a relevant portion, can magnify into a profound difference in the creature. The emission of radiation is a quantum event, and is actually the same event typically used in the Schrödinger's cat experiment.
Now, there is a classical stabilizing effect on evolution, due to the forces of natural selection weeding out bad mutations and allowing good ones to thrive. However, this does mean that alternate timelines are more likely to have a different evolutionary history than a different outcome of a dice roll.
However, any change in evolutionary history would occur in the far past, at least if it is going to have any noticeable impact on things. This raises the issue of whether your temporal proximity to the split is relevant in deciding what universes are accessible, essentially whether "nearness" of the universe is relevant, or merely the overall likelihood in the grand distribution of universes.
This has nothing to do with paradoxes anymore, but I've types it out, so there.
Not a paradox. "Everybody lies all the time" is not even a paradox, just a false statement.You take it as false, and it makes no assertion about its own truth value, and hence resolves to a simple lie. "This statement is a lie" is a logical paradox. If you are lying, then you are telling the truth, which means you are lying, and now the statement does not have a truth value.
Not a paradox either. The greeks simply did not have the math to express a cumulative sum of an infinitively decreasing timespan. Its essentially the formula (1/2 + 1/4 + 1/8+1/16....) , which =1 . Because it takes half the time to transverse 1/4 of the original distance as it did to traverse 1/2 the distance, the sum of the infinite sequence is a finite number, and hence you will catch up in a finite amount of time. Just not a finite amount of 1/2ings. No paradox, just ancient mathematical inadequacy.
0
Its based on the idea of Rougelikes
2
Replaces all terrain graphics with ACII letters. Think of it like a 3D rougelike. Unfortunately, many blocks start with the same letter, but they have coloring appropriate to what they are, to help alleviate confusion. Items and mobs are unaffected, but the sun, moon, rain, and stars are changed.
This does not have the 1.9 graphics, which is why there are some purple boxes in the screenshots.
Screenshots
0
Game Design Theory 11 - Flow
4
Game Design Theory 2 - Linearity
Game Design Theory 3 - Leveling and Grinding
Game Design Theory 4 - Complexity
Game Design Theory 5 - Fun
Game Design Theory 6 - Difficulty vs. Challenge
Game Design Theory 7 - Adventure games
Game Design Theory 8 - Level Design
Game Design Theory 9 - Crafting an Experience
Game Design Theory 10 - Interfaces
Now, I cannot justify saying "Games must have flow". There are many games, and entire genre's, that are not dependant on the flow of the game. However, I will say this:
Having good flow can only improve a game.
For some games, it is crucial. Sonic, for example, or N, or super meat boy. So, what do I mean by "flow"? Flow is the ability to have your actions in the game move smoothly into each other. Now, flow does not have to be automatic. It can, and perhaps even should, require skill to achieve. However, the game, when played properly, should achieve a good flow. Lets take Sonic as an example, mainly because I've been playing it alot recently. played medicorely, you can walk through some parts of the level, look around, jump on enemies, dainty hop around the spikes. You can play it like a standard platformer, like mario. The level design supports this very well. However, when played well, you are speeding through the levels. All of the mechanics are designed to support this. You have the spin-dash to quickly gain momentum. You have loops and twists that serve no real purpose beyond showing off your speed. You have plungers that can quickly accelerate you, and change your direction instantly. You can do a roll while at speed to simply smash through enemies unharmed, and be unslowed by it. Once going, you can simply keep going, jumping up to more optimal paths, finding that hidden route that will take you across the level easily. Such routes are often not only possible to take at speed, but require you to take them at speed.
N has a different approach, but flow is still crucial. If you try to carefully step through the levels, you are going to get blown up by missiles. You have to have enough momenteum to make the jumps, keep moving to avoid homing missiles, take the right routes to avoid enemies. Super meat boy begs you to keep the momenteum up, designing the jumps to be taken at speed. If you look at speed runs of mario, the person has found a flow through the level such that they can do it without stopping.
How forgiving you are about the flow can depend on many factors. In a short, 1-screen level like n, it can be rather unforgiving. A mistake doesn't set you back much. In a long, sprawling level like sonic, you need to be more forgiving.shy away from flow-breaking being instantly lethal, and instead drop the player down into a less optimal path. It should be something they can recover from, and get back into the flow, but that act of slowdown is a cost to the player. If you are scoring on time, this mechanic works great.
Another key aspect to consider is timing. Even if you don't consider flow to be integral to your game, putting in proper timing can make things so much nicer to play. If you have a series of platforms you need to jump between, make sure their timing is synchronized. You shouldn't have to wait for their respective motion cycles to happen to coincide. They should be integer multiples of each other's timings, so when the platform reaches the end of its cycle, the next one is waiting. They don't necessarily have to have the same timing, but the one you are coming from should be the slower one. This means that when the one you are on reaches the end, the next one is waiting. Going backwards may be less smooth, as it means that the platform will go out, and there may not be anything to jump to, but if the player is going backwards, flow has already been broken. Furthermore, as much as possible, try to make the platforms ready to use as soon as the player reaches them. If there is a button to start them moving, the time it takes to go from the button to the platform should coincide with the platform being ready to use. Having the platforms start by jumping on them can ensure this timing. In a short, n-like level, you know how quickly a good player will reach there with proper flow, and can time it accordingly,but the viability of that approach will depend on your game.
Jump spacing also effects flow. If you have to carefully jump out, and then pull back to land on the platform, there isn't much flow to the process. If the platforms are spaced at your natural jumping distance, then the process becomes smooth and fluid. If your jump distance is dependent on speed, then spacing platforms to be jumped at speed helps facilitate flow. having other platforms in between can make it so you don't need the flow to get through, but the basic design should facilitate a smooth transition.
Flow is very crucial if your game relies on speed. Racing games also need to have a good flow. However, it can also improve other types of games. Combat, for example, greatly benefits from good flow. The ability to take an attack, and have it flow smoothly into the next, to smoothly transition into a dodge, to combine your motion and attacks. Combat that is fluid tends to be more satisfying.
Good flow has also resulted into some amazing aspects of otherwise mediocre games. Spiderman 2. Not only is it a superhero game, its a movie game. Judging by general trends, that means it should have been a really awful game. But its not, and its mainly for 1 reason; it has AWESOME web-swinging mechanics. I have yet to see another spiderman game match it. It worked very smoothly. Push the stick in the direction you want to shoot the web, and hit the web button. Bam, you now have your webline attached to an appropriate corner in that direction. You can now swing from it, and it behaves as you expect. You can fire out a second line and have both out. This lets you smoothly transition from one webline to another, as well as pull off maneuvers like slingshotting yourself. Or, you can let go of your line completely, go flying through the air, do some flips, before launching out a second line for a new swing. It carries momentum well, and gives you good control over the swing. You can even do a boost while on the webline, giving yourself more momentum. Forget physics, its tons of fun. This same sprint button also allows you to run along buildings, given enough momentum. The webbing will also attach to new surfaces it hits, becoming a new anchorpoint for your swing. All of this together results in a really awesome web swinging mechanics. It captures all of the potential of being spiderman swinging around the city. An it is a blast. I literally start up the game from time to time for no other reason than to swing around. And at the heart of it all, is flow. Everything is fluid. You are carrying your momentum forward, up the wall, around the swing, using it to sing up and over, reversing your direction, or carrying it through your swing around the corner. It gives you the means to build your speed, and maintain it upon collisions with walls. It flows, and hence it is fun.
This is a general rule, but it partially relates to flow: Don't punish the player for being too good. I've seen it happen. For example, you have racing game with a door. It will open as players approach, making for some good dramatic scenes. However, if you are doing exceptionally well... you can get there before the door opens. Suddenly, doing very well translates into being a fireball. Not good. Other ways you can punish the player for being good is with collectibles. I'm talking about those rare collectibles that you collect once to unlock things, though this can apply to other highly desired collectibles. If you take a pit that looks like a bottomless pit of instant death, but make it into a pit with a collectible in it, you are rewarding players for messing up and falling into pits, and punishing the players who are good enough to not fall into random pits. Instead, put it on the ultra-good path that is tricky to get to. This rewards the player for playing well, and trying to seek out the collectibles can drive them to learn the more optimal routes. Thus, you are encouraging proper flow.
Game Design Theory 12 - Replay Value
0
Warning forever is a good example of how not to do your menu. It should not be hard to use the start menu. Its easy to overlook as a developer, because of course you know how to use it, so the fact its completely obscure to everyone else can slip by you. That is why usability testing is important. Find someone who hasn't played your game before, sit them down in front of it without instruction, and see if they can easily figure it out.
And when I say utilizing standard control schemes is good, I don't mean that you can't have your own method for controlling the game, if it is appropriate. Its more keeping to standards if that type of control scheme is common. If you made a FPS with IJKL for movement, but you are doing all of the standard things for an FPS, it would be bad. people who play FPSs on the PC are used to WASD. Not to mention that IJKL is not very ergonomic.
0
Game Design Theory 10 - Interfaces
3
Game Design Theory 2 - Linearity
Game Design Theory 3 - Leveling and Grinding
Game Design Theory 4 - Complexity
Game Design Theory 5 - Fun
Game Design Theory 6 - Difficulty vs. Challenge
Game Design Theory 7 - Adventure games
Game Design Theory 8 - Level Design
Game Design Theory 9 - Crafting an Experience
Whatever your game, it is important to have a good interface. Your interface is the link between the player and the game. It is what facilitates the entire game experience. The best interface is the one nobody notices. It should create a seamless experience.
If the player every actively notices your interface, it has failed. There will be a initial learning curve where the player learns the controls; The only way around that is for the learning curve to be placed in another game. For instance, first person shooter tend to use a fairly standardized set of controls. Because of this,most players have already learned how to use those controls, and don't suffer that learning curve. A good set of controls is intuitive enough to learn easily, and minimizes the learning curve associated with them.
After that learning curve, it should provide a smooth experience. There are many game I have played and loved, and even when playing them on a regular basis, I would be unable to tell you what the controls were. They worked smoothly, and I could simply use them without thinking about it. However, if a game has bad controls, it creates a hindrance in the game, and becomes noticeable. This is why I can tell you that sonic generations used X for speed boost, and B for duck. Normally this is not an issue, but there is a part where you need to be boosting, and ducking under lethal blades. A single mistake will force you to restart. And this was a problem, because X and B are on opposite sides of the key arrangement, making them difficult to use in conjunction. This is also why I can recite the control sequence in Red Dead Redemption needed to quick travel. Pull up the start menu, select the map, then place a waypoint where you need to go, then go back to the world, pull up the inventory, go to the second screen, select your campsite(and you have to be in an appropriate place to use it), select quick travel from the campsite menu, select your waypoint as the destination, and finally quicktravel. It is an ordeal. Contrast oblivion, where you hit a button to pull up your map, click on your destination, and then quick travel there. No muss, no fuss.
The challenge in a game should never come from the controls. Awkward controls never make a game fun, it is just annoying. If you find yourself designing a section where the challenge comes from working with awkward controls, redesign. Make smooth controls, and have a more challenging task.
What makes a good interface? To put it simply, a good interface is one that does what the player expects it to. This is another reason to use standardized controls. If people use a certain set of controls in one game, they create the expectations that they will work like that in a similar game. Deviating from standards can take an otherwise fine set of controls, and make them into a barrier. This requires particular consideration with sequels. If you are going to change basic controls between installments in a series, you better have a really, really good reason.
Customizable controls can go a long way to addressing these issues. The functionality available to assign still needs to be well-planned, but you can't meet the needs of every player. For instance, inverted Y-axis. This is a huge divide among gamers, should the y-axis control(and sometimes even x-axis control) be inverted? I can actually play with both(even x-axis inversion) given a warmup period, but the option to select which one you want can be a godsend for most players. Player's also tend to have quirks in their preferences. For instance, I prefer to have crouch attached to my side mouse button.
Speaking of extra mouse buttons, never require an unusual input device. Never require more than 2 mouse buttons, never require the use of the control wheel, etc. You can utilize them. The scrollwheel can be a convenient method of streamlining controls. However, it is not guaranteed(albeit rather likely nowdays) that it will be present, so other options should be available. In FPSs, it is often the weapon switching control. However, you can still use the number keys to select your weapon, even if you lack a scrollwheel.
One important guideline is to make it so the player does not need to reposition their hands. If they have both hands on the keyboard, they should stay on the keyboard. They should not need to reach over to the mouse. If the player's left hand is on the WASD keys, the controls for that hand should be easily reached from that position. For similar reasons, unify your game and menu controls. Don't control the menus with a mouse if it is a keyboard only game. Don't make enter the select key if the fire button also works. This lets the player use the same set of controls throughout the experience, making it more streamlined. The more mixed-in with the gameplay this is, the more important that is. For example, if you have a victory screen between levels, and the game is a keyboard game, don't require the player to use the mouse to interact with the victory screen. That just breaks the flow. However, if you have unusual menu controls, make sure they are obvious from the menu screen. There is nothing more frustrating that starting a game, and the hitting random keys on the keyboard to figure out how to select start.
The GUI is also important. First, it should stylistically match your game. Second ,it should be streamlined. Display everything you need clearly, and don't clutter it up. Don't hide things if they need to be conveniently accessible, but don't display things that aren't needed. also try to match the screen space used and the importance of the information. The exact health of every peice of armour you have probably isn't the most important piece of information to you at any given time, so you don't need an ever-present, full-body wireframe displaying all of their health. Your current health is probably extremely important, so it is appropriate to have a prominent health display. However, don't let it get in the way.
Try to display the information in the most relevant manner to the player. A numerical display of health may be very precise, but the player is generally more concerned with the percentage of their health left. Displaying it graphically makes it easier and quicker for the player to take in. Hence, the health bar. It may be appropriate to have a numerical display in conjunction with the health bar, but the quick overview of the situation is what is needed on a moment-to-moment basis.
Symbols can be a good way to label your interface without taking up much screen real estate. However, make sure your symbols are clearly distinguishable at a glance, and indicative of what they represent. Having a series of alien glyphs may fit thematically with your game, but is not going to convey meaning to the player. This is another place where standards are useful. The red cross may be cliche, but it has a clear meaning to the player.
Even better is the interface that needs no labels. Take minecraft, for example. the health bar, the hunger bar, the air bar, the armour bar, all are clear in their purpose, with no need for a label. The inventory screen is also designed intuitively, so there is no need for labels like "your inventory" or "chest". The few things that do need labels are done with clear symbols in a non-intrusive manner. The armour slots have a clear symbol of what goes in them, emblazoned directly on the slot, making it streamlined and keeping the interface clear. The furnace symbols are clear. The fuel goes under the fire, you put what you are smelting over the fire, and the arrow points to the output. Simultaneously, the fire acts as a gauge for how long the fuel will last, and the arrow acts as a gauge for how long it will take to smelt.
Also consider how much time the player will have to look at the interface. If it is a high-action, fast paced game, they won't have more than a quick glance to see if their health is low, and it would be really helpful if you can make low health highly noticeable. If it is a relaxed, tactical game, you have more leisure to display stat blocks, add in mouse-over text, and provide a wealth of information. If you are in a menu screen, there is no action, and you can take the time to display the information fully. This does not mean you shouldn't still present the information clearly and well, and have it easy to understand. Good design is important still, but the time constraints are different. Accessing a character's biography may be appropriate in a menu, it is almost certainly not appropriate in the middle of combat.
Game Design Theory 11 - Flow
1
Well, considering that you have to accomplish the rest of the game before you can access it, all it does is provide you with a convenient way to explore. Since its confined to a dragon, you have to deal with its maneuverability, meaning it would only be suitable for above-ground travel in the overworld. You can't just leap into the air whenever you feel like it, you have to go to the dragon, mount it, and take off. The 8x speed boost of the nether will probably still provide a faster means of travel between fixed points, meaning it is mostly advantageous for exploration, or for a funner means of transport between places. A dragon flying is much, much more balanced than fly/setspeed 5, both in inherent limits to its use, and in the pre-requisites to accomplish it. Its not going to get you more diamonds, its just going to let you explore the world easier.
Now, I will acknowledge that the technical constrains in multiplayer are a valid concern. However, technical constraints are a challenge that can be overcome with clever development. The current server technology may not be able to hold up to a dragon exploring, but it hasn't had to. That was never a design consideration. It is a limit that can be overcome, if the end result is worth the effort. Gameplay issues are a bigger problem.
The balance issues would arise from the potential combative advantage a dragon could bring. Mainly in multiplayer, I don't think riding around a dragon and slaughtering everything on the surface is that problematic in SSP. Esp. if being on the back of a dragon makes it hard to collect item drops/exp orbs, or if dragon kills don't net xp. However, how the dragon combat works is unknown, so its hard to make any solid comments on it.
1
How is 5 seconds of flight overpowered? How is flight overpowered at all? Seriously, explain to me what about it you feel is overpowered.
0
You obviously don't play the same games that I do. I find running the math on how to get the most efficient things done a fairly commonplace occurrence on games where that is applicable.
0
Why do people always come up with weird, arbitrary restrictions on the dragons? I feel like its a knee-jerk "Its OP, so I have to add in some limits" than an actual consideration of what would make it too powerful and how it could reasonably be balanced, and how the limits will effect the actual gameplay. Adding in arbitrary limitations is not how you properly balance things.