In that last paragraph, I know one boss that completely disregards everything you said. That boss is Tabuu from Super Smash Bros. Brawl. He had this one attack where it (at least I think) is impossible to avoid and does INSANE damage to your character, sometimes throwing you off the stage even if you had 0% damage on yourself! However, in a sense it kinda added a timer of sorts to the battle, which I think is pretty cool because it doesn't just give you a timer straight up.
Would you say that was a good design? I haven't played that, so I can't properly comment on it. However, just because a game, even a great game, does something does not mean that any particular part of it is well-designed. You have to look at each part and really think about whether it contributed to the game or was detracting from it.
There may be better terms to use, since the distinction is not readily apparent to most people, but I find that this is a key principle:
A game should be challenging, not just difficult.
In order to understand what I mean by this, we must first understand what I mean by challenge, and what I mean by difficult. Challenge is how malleable the situation is to the player's skill, be it through their reflexes and precision, as is the case with an action game, or their tactical and strategic skill. Difficulty is how hard it is to complete a task.
A challenging game requires the player to exert their skill to win, and can be very demanding of that skill. A difficult game just makes it a pain to get through, and has little to do with the player's skill.
This often applies to various elements of the game, rather than the game as a whole.
Examples of things that are difficult, but not challenging:
Rolling 3 20's in a row on a D20.
Picking up 10,000 cards
Finding a treasure chest buried somewhere under the desert.
Brute forcing a combination lock.
defeating a mincraft zombie that has 10000 hearts of health.
These things are very hard and time consuming, but not very challenging. Some of them could be made into a challenge. Brute forcing a combination lock is not challenging. Cracking a combination lock is a challenge.
Completing all of HL2 without getting damaged once is a goal that is challenging, but its more difficult that being challenging needs. Consider the similar challenge, complete HL2 with 1hp. This still requires you to complete every single stretch of the game flawlessly, but you get to retry, and figure it out. You don't have to execute all of them perfectly in a single stretch. Figuring out how to complete a given level without getting hurt is a challenge. It is a very fun thing to do, some of my favorite parts of playing HL2 where when I found myself with 1-5hp left, and I refused to revert to a previous save, and instead figure out how to complete the current stretch flawlessly. That is a challenge. However, requiring you to execute that on the entirety of the game flawlessly just adds difficulty, not challenge. Being forced to redo a challenging section that you have completed does not add challenge, it adds difficulty. It is also extremely frustrating. If you have done it once, why should you need to do it again?
Take Demon Soul's, for instance. It has a mix of good challenge and raw difficulty. The actual combat is challenging. You have to fight well, but if you do fight well, you can get through. That is fine. However, one central mechanic of the game is gathering souls. Souls act as both experience and currency. When you die, you lose all of your collected souls. They are left in a bloodstain where you died, and if you can get back to it, you can reclaim the souls. However, if you die before collecting it again, you lose them all. This means that the further into a level you progress, the more soul's are on the line, and the harder it is to reclaim them. Every time you play the level, you must perform at least as well as you did the previous time, or you lose all of your progress. This does not make the game any more challenging, that is simply adding unproportional punishment for failure. If you removed that mechanic, would the game be easier? Yes. Would it be less challenging? No.
This is a particularly atrocious mechanic because the game is designed for you to level up, but does not provide adequate experience through normal play to do so, while making it very difficult to collect that experience through normal play. With a challenging game, the focus is on the player mastering the game. They have to learn how to do it properly, which requires practice. Ideally, the difficulty curve of the game matches the player's learning curve, to maintain the challenge. In demon's souls, trying to learn the game by re-attempting levels is a really quick way to lose all of your souls. This creates the dynamic that playing the game and collecting souls become separate tasks. You start a level, collect a batch of souls, then leave, rinse and repeat until you can level/buy cool items, and eventually buildup enough levels to push through an entire level. This is a mechanic that is not only focused on grinding, but divorces the act of gaining experience from the act of progressing through the game.
This dichotomy is clear if you look at boss designs. A good boss is not a normal enemy with a ton of health and firepower. A good boss is one that has its own attack patterns, so you have to learn how to deal with it, face its unique challenge, and persevere. You don't need to give the boss a ton of health to chew through, you just need to properly set up the challenge of getting through it. This is why the weak point mechanic is so popular. It removes the need for a ton of health to add difficulty, and instead makes the boss into a series of challenges.
This is also reflected in good checkpoint design. A good checkpoint system is generous. If two parts of the game are relatively isolated from one another, so your performance in one is not crucial to your performance in another, there is no point in having the player replay the former part if they fail the second. For instance, a game has a lengthy platforming section, followed by an intense battle. If the player has already beat the platforming section, forcing them to replay it if they fail the battle does not make the game more challenging, just more difficult and annoying.
A lengthy challenge can also be pushed into the realm of just being difficult. If you recall from my first article, a chance iterated many times tends to even out. If you think of a players skill relative to the challenge posed as their chance of winning, then in the short-term, the players skill is the determining factor in how well they do. However, if they fail once, then they fail the entire thing, so their failure chance is greatly magnified. This can quickly skyrocket the skill level needed to have a good shot at winning, and desensitize the game to the player's skill. Long stretches make it more likely that the player will fail closer to the end, for multiple reasons. First, if you have health that is being worn down, or a similar mechanic, then later has had more chance to accumulate damage, and hence fail. Secondly, the player can become fatigued by the repetition, and hence their performance slips. This means that a long stretch just builds up a much greater likelyhood of failure, and puts more play time on the line, such that if you do fail, you must redo more, which is simply frustrating. An exception to this is an endurance challenge, where the goal is to see how long you can last. In that case, failure is already a destined occurrence, and there is no need to replay it for any other reason than to best yourself, so these dynamics are different.
An example of a properly challenging game is super meat boy. It does everything right. The levels themselves are very challenging, but rather short. If (or more accurately, when) you fail, you have lost very little progress, and can try again without delay. This means you are constantly taking on the challenge, not re-doing things you have already mastered. The level creates a discrete unit that must be mastered together, and once done is done. It has a very nice difficulty curve, such that the player remains challenged throughout the game. It also possesses extra challenges, so you can go back and attempt the level with stricter requirements. It presents a wonderful challenge, without making it into raw difficulty(with some minor exceptions). N possesses similar traits.
One other difference is a subjective one: Completing difficult task comes with a feeling of relief. It feels good, but only is a homeostatic slingshot from the frustration.Not being frustrated anymore is such a relief its pleasant. Completing a challenging task comes with the feeling of triumph and being awesome. It is a real achievement, you have successfully executed your skills properly, and the act of doing so is awesome.
A game should have punishment in proportion to the mistake made. If the enemy has a quick-hard to dodge attack that they use without warning, it should do minor damage. It is a small mistake to not dodge it, and dealing massive damage is out of proportion. In contrast, if the enemy telegraphs the attack from a mile away, and it sends out a slow moving shockwave, that is a bigger mistake on the player's part to fail to dodge, and it can deal massive damage. If the player slips into a bottomless pit, it is proportional to move them back to the last checkpoint. It would not be proportional to have them restart the entire game. Adding in disproportionate punishments just adds difficulty without challenge. If they have failed, and hence are being punished, then they are past the point of the challenge. Putting in too high of a punishment just makes it difficult and annoying, but cannot make it more challenging. However, you don't want to have too weak of a punishment either. If falling off the bottomless pit just puts you back where you were with no further punishment, then the challenge is subverted. The failure is not really a failure anymore, and hence the requirements for the challenge are lessened. This is something to keep in mind with platformers. It is common to have a section where you are climbing up. Be mindful of how disastrous it is to have a misstep. If you are near the top of the tower, missing a jump should not send you back to the bottom. That is a disproportionate punishment for a single mistake. If you can arrange it so you will land on a lower level, then the punishment is more in line with the mistake.
I actually remember reading that. On the topic of fun though, I remember listening to a game developer talking about this kind of subject a while back. It was a developer at Insomnia games and they were talking about a Ratchet & Clank game. If I remember correctly they said the hardest part about making a game is trying make every moment of the game fun or something along those lines. If just even a single moment in the game is not fun, you risk someone no longer playing your game. 99% of your game could be great, but that one negative moment or aspect can lose customer forever.
Now, I do disagree that every moment of the game does in fact have to be fun. I believe the player forgives a few boring or negative experiences if their over-all experience so far has been pleasing. Not every moment in Minecraft can be fun. I’m sure that making a game where every moment was fun would lead to a better game, but sometimes other elements which are not fun are added which build up too or lead too those fun moments. Mining obsidian for example is not on my list of favourite past times, but I always find myself doing tedious tasks like these for the reward that is tagged along at the end. Now, I do know you had talked previously about levels and grinding (which was a wonderful read btw), but I’ve seen endless games incorporate elements where I as the gamer don’t have an enjoyable time doing those tasks, yet do it because for the end result I wish to experience as I presume it will be fun.
I doubt I am the only one who does this. I went through an entire game a second time just to play the alternate final stage. The game wasn’t terribly boring, however I didn’t get as much enjoyment my second time through. Not enough to merit playing the game solely on that experience at least. Which I guess I am finally reaching the point of my post here. Everything about a game should be designed in mind that you want the game to be fun. Now, I’ve never played Ninja Gaiden, I was too young for it at the time, but everyone loved it’s insane difficulty from what I hear. They were undoubtedly not having fun while losing a majority of the time, but people persevered because either the game difficulty was infamous in an obstacle sense, or they wanted the end reward. I believe it was a mix of both or the second reason motivates them at some point in the game.
Fun should never be the comprise in a game. But what about comprising fun for fun? If you get what I am trying to say here. Rather than trying for a game that is generally fun all the time, what about one that doesn’t continuously provide amusement but rather delivers them a certain moments.
I do agree that it is possible to have unfun stuff be set as a precursor to more fun, and people are willing to do the work for the reward. While grinding is not a mechanic you should force on a player, many people will still grind to get the advantage.
However, isn't it better to have it fun all the time? Even though it is not a necessity to have a good game, isn't the better game the one that can make those stretches of the game enjoyable? There is some homeostatic justification that conquering a section that is not fun leads to a greater peak of enjoyment, but the sum experience of it leaves something to be desired. If the player can ride on a constant crest of fun, the overall experience will be much better.
Notch has more knowledge in algorithm design and making code be efficient than I do. The basic idea is simple, not as a whole. Because really, breaking down nearly any feature of Minecraft at the scale you're asking makes it seem too complex. And i'm just saying, my suggestion is just that-a suggestion. An experienced coder could explain the method better than I can, because i'm really just a novice.
I am an experienced coder. The point is not to have you come up with it, but that it is computationally complex. It sounds like a simple idea, but the actual details of it make it much more complex than it sounds like.
All I can say is I have done my best to think about it. Do realize Notch can actually code in Java, and knows what the F**k he's doing. I, however, do not, mostly.They just need to be grouped together somehow where they can easily report chunk updates and be moved to other groups (or removed/split to it's own group) easily. There's probably somebody out there who codes java that could immediately make this using some java methods I don't know about. Also, If there's 500 loopholes that cheaters can use to deceive a server, maybe the server should be able to be more strict and access more client data.
Knowing java has nothing to do with algorithm design. This is exactly my point; this is not anywhere near as simple and efficient as you make it out to be.It is a LOT of extra complexity for this one thing, and doesn't even adequately protect against it.
And how does accessing client data help? You just mod the client to tell the server that everything is honky dory.
If you are playing on a server where you feel such elaborate measures are necessary to keep your stuff safe, maybe you should find a different server. Trying to safeguard against everything under the sun is really complicated , and ultimately ineffective.The basic nature of minecraft leaves it open to exploitation like this.
Possibly something with arrays? Or anything that could store the vector data/instance names to say "hey, these take the visibility of this Boolean, oh and tell me if there is a chunk update near any of them, and where, so I can check stuff out". Each group could be treated almost like a "blob" of geometry, where each "blob" is a visibility group. visibility would just be an object attribute. To reveal, split, or merge them, just add or remove any block data you would need to during a chunk update, essentially re-configuring or changing visibility or children of all effected "blobs". That's the best I can explain it technically right now. I need to write an essay :/
and this is precisely the "beyond the basics" level where it gets confusing. If you simply have an array-type data structure, how do you know which group any given block belongs to? If you can't easily know that, you can't know if modifying any given block is going to impact the visibility groups, or if a block is in a hidden visibility group so it is not sent to the server. You have to detect that a given block change has resulted in a single visibility group being split in two, with the possibility that the group is split locally and connects somewhere else. For instance, if you have a loop that is hidden, and place a block in it, then it breaks the group locally, but they are still connected in one group.
I really don't know about any of this. someone would be going awfully far to find these chests, couldn't they just make servers probe for code that would allow people to do sneaky stuff like this?
Most of the code will be there already because this was implemented. Adding this in would be doing the work for them. You make a client mod, and we are right back were we started; cheaters cheating. And how do you propose to have servers probe for code? All you need is a mod that has a vanilla copy that it offers for any probing that would be happening.
edit: to be clear, I'm not concerened with simply doing it. I am concerened with doing it efficiently.
that looks very weirdly worded to me... anyways you would be able to hide redstone circuitry, especially basic traps. and you would be able to hide chests
Aren't air blocks used in certain redstone circuits?
well I did describe it beyond but I did not make a mod that implements my idea, sorry. I have thought about it, and how to fix the issue in a proper manner, and I think this could work. Implementation is really the only thing I didn't talk about. Yes, it seems complex when you talk about it, but when it's being coded it isn't that complex. Then you read the code later like "how did I manage to make that work perfectly, yet not understand it now? wow, must've phased out there."
Alright, give me an overview. What data structures are you using to store the groups? How are you keeping track of its visibility? How are you detecting it is split? how are you merging them?
And keep in mind, this has to handle the case of a large, complex redstone circuit being revealed, altered, so vast swathes of it can become hidden, merged, split, possibly frequently. Esp. if someone sets up something with pistons to automate the placement and removal of blocks to do this.
Is this info sent to the client though, or would it require more snooping the server?
it has to be. If you place a block next to it, you have to tell the client that block was placed. Even if you tell it that all of the now-hidden blocks were removed, the client still knows they were there. You tell it that a block was placed next to the visibility group, and the client will have everything it needs to detect that it is now hidden, and subsequently ignore the command that those blocks were removed, and furthermore highlight that this was hidden, so burring a chest can make the greifer's client light up and put a beacon on it. if you EVER access your hidden chest while someone is near enough to receive the visibility update, it will be completely revealed.
Yes, that or a glass block, web block, glass pane, door, or any occupy-able space(ladder block, trapdoor, sugarcane, rails, 1 glass pane, redstone torches any above another non-solid block ect.). This would make sure if it is suppposed to be visible, it is, and also makes sure invisible tunnels are not created.
And people will never have anything they need to hide with a visible block near it, nope. Esp. if you are trying to hide redstone. Really, the amount of things this will actually hide is miniscule.
I did explain it on a basic level. I formed an entire idea, just not the technical ideas, I really don't know much about chunks and how they work, and certainly not enough to say EXACTLY how to implement my idea. Besides, Notch has fun figuring stuff like that out.
I said beyond a basic level. At the basic level, it sounds fine. When I try to look at it in more precise detail and work out edge cases, the complexity skyrockets.
Is there a definable difference sent to the client between "harvested" and "hidden", besides maybe an item sprite showing up?
boom fire problem solved, no item sprite logged
in one case, the chest simply disappears. In another, something else is placed which blocks its visibility. Even if the latter case comes with the former, the latter part is still detectable. Esp. since code to test exactly that case must exist in the server, so it would be trivial for the modder to copy it to a client and re-utilize it for that check.
My method would only add the not-solid object's faces and faces connecting to them to visibility groups, so under my implementation, naturally generated caves would not be effected.
so.... if there is ANY air block involved, it is visible? Or am I misunderstanding how you decide to send the visibility group to the client?
Yeah, I know, It's one of those fun things that would go on during chunk updates. I'm not Notch or Jeb_, the most I've done in java is make a combo-box calculator. And it also isn't my job to figure this out. I've thought of enough of the idea it could be developed and all the kinks worked out during development. If it were added it could really decrease amount of data sent/received (possibly immensely), while increasing server processing. Most servers are on nice computers anyways :smile.gif: plus not everyone has not the best internet
You can't assert that a method is more efficient if you can't explain it beyond a basic level. That would be like saying "just take the lowest value element, put it at the bottom of the list, and repeat for each element. You will end up with a sorted list in linear time". While that may be an accurate description of certain sorting algorithms, those are the ones that give you n2 time, and perform worse than more complex methods.
Well, this is true. But most likely they would either have to be at the right place at the right time, or log every chest ever placed on the server. if someone actually went so far as to do this, people could just spam chests in random locations and then pick them back up, as such a mod would most likely just spit out vector data to a .txt file. And with over 100 vector entries to read, remember, and reach each location to find nothing would be a pain :tongue.gif:
You can also remember when a chest is picked up, since it should be easy to detect the difference between removing a chest and blocking it off. If you want to do decoy chests, you can do them now. Place 100 chests, and only use 2 or 3. Every empty one would be a pain. And being in the right area wouldn't be that hard.
I'm not saying this couldn't work, but at the current level of conception its impossible to say whether it is really worthwhile, or if it is going to do more harm than good.
as I said it would not use raytracing, so no it wouldn't use player vector data to determine if it was visible or not. It would just be block placement based and run through the code without any regard to players. If it isn't visible, don't send the data, if it is, send it, apply culling client side. Cheaters would actually have to hack/mod the server to get around it.
Except its not as straight foraward as you think.
First, you have to add the overhead of keeping track of all of these collections of visible blocks. Since all of the air, many caves, and the entire surface will be visible, they will be one giant visibility group. You have to figure out how to handle the groups extending across multiple chunks, and not only merge the groups, but divide them. Every time you place a block, it could potentially be cutting off a large swath of visibility, which has to be detected and modified. And since before you bury an item, it is visible, it will be sent to the client of everyone nearby, and a modified client could easily remember it from when it was visible, and even go so far as to highlight things that have been hidden that were visible. So a buried chest would be undetectable... as long as you never unbury it, and no-one was around when you put it there in the first place.
read my edit, if you're standing on it, it is next to an air block, that face would be part of the "visibility parent structure" and therefore be visible because of the air block next to the chest : )
And is this server side or client side? If its server side, you have to completely rework the fundamental way the client/server relationship works to make that feasbile. If its client-side, you can still mod around it easily.
And for what? The edge case of a chest being buried being invisible to a x-ray mod? why should a buried chest be special? If you have to put forth the effort to hide a chest completely buried, why not put forth the effort to hide anything the player cannot rightly see? You are convoluting the code to deal with an edge case.
I modified my post a little just now, I thought of that
EDIT: I'm thinking something about a visibility parent structure. At least one face must be touching an air block, or all the items in a visibility parent structure will be deemed invisible. This would allow for invisible redstone circuitry, too :tongue.gif: just as long as it is completely enclosed
Stand on the cobble, look down at the gap. The chest's face is against a solid block, but still needs to be visible.
in order for a fix to work, what is "hidden" needs to be re-defined. Because chests (and stairs and extended pistons) all are deemed "visible" by Minecraft, due to themselves containing full transparency. Making Minecraft not take into account what the block is when determining visibility of faces could possibly fix the situation. lol
But then if you have a chest against the wall, its back surface would be invisible.
0
Would you say that was a good design? I haven't played that, so I can't properly comment on it. However, just because a game, even a great game, does something does not mean that any particular part of it is well-designed. You have to look at each part and really think about whether it contributed to the game or was detracting from it.
2
Game Design Theory 2 - Linearity
Game Design Theory 3 - Leveling and Grinding
Game Design Theory 4 - Complexity
Game Design Theory 5 - Fun
There may be better terms to use, since the distinction is not readily apparent to most people, but I find that this is a key principle:
A game should be challenging, not just difficult.
In order to understand what I mean by this, we must first understand what I mean by challenge, and what I mean by difficult. Challenge is how malleable the situation is to the player's skill, be it through their reflexes and precision, as is the case with an action game, or their tactical and strategic skill. Difficulty is how hard it is to complete a task.
A challenging game requires the player to exert their skill to win, and can be very demanding of that skill. A difficult game just makes it a pain to get through, and has little to do with the player's skill.
This often applies to various elements of the game, rather than the game as a whole.
Examples of things that are difficult, but not challenging:
Rolling 3 20's in a row on a D20.
Picking up 10,000 cards
Finding a treasure chest buried somewhere under the desert.
Brute forcing a combination lock.
defeating a mincraft zombie that has 10000 hearts of health.
These things are very hard and time consuming, but not very challenging. Some of them could be made into a challenge. Brute forcing a combination lock is not challenging. Cracking a combination lock is a challenge.
Completing all of HL2 without getting damaged once is a goal that is challenging, but its more difficult that being challenging needs. Consider the similar challenge, complete HL2 with 1hp. This still requires you to complete every single stretch of the game flawlessly, but you get to retry, and figure it out. You don't have to execute all of them perfectly in a single stretch. Figuring out how to complete a given level without getting hurt is a challenge. It is a very fun thing to do, some of my favorite parts of playing HL2 where when I found myself with 1-5hp left, and I refused to revert to a previous save, and instead figure out how to complete the current stretch flawlessly. That is a challenge. However, requiring you to execute that on the entirety of the game flawlessly just adds difficulty, not challenge. Being forced to redo a challenging section that you have completed does not add challenge, it adds difficulty. It is also extremely frustrating. If you have done it once, why should you need to do it again?
Take Demon Soul's, for instance. It has a mix of good challenge and raw difficulty. The actual combat is challenging. You have to fight well, but if you do fight well, you can get through. That is fine. However, one central mechanic of the game is gathering souls. Souls act as both experience and currency. When you die, you lose all of your collected souls. They are left in a bloodstain where you died, and if you can get back to it, you can reclaim the souls. However, if you die before collecting it again, you lose them all. This means that the further into a level you progress, the more soul's are on the line, and the harder it is to reclaim them. Every time you play the level, you must perform at least as well as you did the previous time, or you lose all of your progress. This does not make the game any more challenging, that is simply adding unproportional punishment for failure. If you removed that mechanic, would the game be easier? Yes. Would it be less challenging? No.
This is a particularly atrocious mechanic because the game is designed for you to level up, but does not provide adequate experience through normal play to do so, while making it very difficult to collect that experience through normal play. With a challenging game, the focus is on the player mastering the game. They have to learn how to do it properly, which requires practice. Ideally, the difficulty curve of the game matches the player's learning curve, to maintain the challenge. In demon's souls, trying to learn the game by re-attempting levels is a really quick way to lose all of your souls. This creates the dynamic that playing the game and collecting souls become separate tasks. You start a level, collect a batch of souls, then leave, rinse and repeat until you can level/buy cool items, and eventually buildup enough levels to push through an entire level. This is a mechanic that is not only focused on grinding, but divorces the act of gaining experience from the act of progressing through the game.
This dichotomy is clear if you look at boss designs. A good boss is not a normal enemy with a ton of health and firepower. A good boss is one that has its own attack patterns, so you have to learn how to deal with it, face its unique challenge, and persevere. You don't need to give the boss a ton of health to chew through, you just need to properly set up the challenge of getting through it. This is why the weak point mechanic is so popular. It removes the need for a ton of health to add difficulty, and instead makes the boss into a series of challenges.
This is also reflected in good checkpoint design. A good checkpoint system is generous. If two parts of the game are relatively isolated from one another, so your performance in one is not crucial to your performance in another, there is no point in having the player replay the former part if they fail the second. For instance, a game has a lengthy platforming section, followed by an intense battle. If the player has already beat the platforming section, forcing them to replay it if they fail the battle does not make the game more challenging, just more difficult and annoying.
A lengthy challenge can also be pushed into the realm of just being difficult. If you recall from my first article, a chance iterated many times tends to even out. If you think of a players skill relative to the challenge posed as their chance of winning, then in the short-term, the players skill is the determining factor in how well they do. However, if they fail once, then they fail the entire thing, so their failure chance is greatly magnified. This can quickly skyrocket the skill level needed to have a good shot at winning, and desensitize the game to the player's skill. Long stretches make it more likely that the player will fail closer to the end, for multiple reasons. First, if you have health that is being worn down, or a similar mechanic, then later has had more chance to accumulate damage, and hence fail. Secondly, the player can become fatigued by the repetition, and hence their performance slips. This means that a long stretch just builds up a much greater likelyhood of failure, and puts more play time on the line, such that if you do fail, you must redo more, which is simply frustrating. An exception to this is an endurance challenge, where the goal is to see how long you can last. In that case, failure is already a destined occurrence, and there is no need to replay it for any other reason than to best yourself, so these dynamics are different.
An example of a properly challenging game is super meat boy. It does everything right. The levels themselves are very challenging, but rather short. If (or more accurately, when) you fail, you have lost very little progress, and can try again without delay. This means you are constantly taking on the challenge, not re-doing things you have already mastered. The level creates a discrete unit that must be mastered together, and once done is done. It has a very nice difficulty curve, such that the player remains challenged throughout the game. It also possesses extra challenges, so you can go back and attempt the level with stricter requirements. It presents a wonderful challenge, without making it into raw difficulty(with some minor exceptions). N possesses similar traits.
One other difference is a subjective one: Completing difficult task comes with a feeling of relief. It feels good, but only is a homeostatic slingshot from the frustration.Not being frustrated anymore is such a relief its pleasant. Completing a challenging task comes with the feeling of triumph and being awesome. It is a real achievement, you have successfully executed your skills properly, and the act of doing so is awesome.
A game should have punishment in proportion to the mistake made. If the enemy has a quick-hard to dodge attack that they use without warning, it should do minor damage. It is a small mistake to not dodge it, and dealing massive damage is out of proportion. In contrast, if the enemy telegraphs the attack from a mile away, and it sends out a slow moving shockwave, that is a bigger mistake on the player's part to fail to dodge, and it can deal massive damage. If the player slips into a bottomless pit, it is proportional to move them back to the last checkpoint. It would not be proportional to have them restart the entire game. Adding in disproportionate punishments just adds difficulty without challenge. If they have failed, and hence are being punished, then they are past the point of the challenge. Putting in too high of a punishment just makes it difficult and annoying, but cannot make it more challenging. However, you don't want to have too weak of a punishment either. If falling off the bottomless pit just puts you back where you were with no further punishment, then the challenge is subverted. The failure is not really a failure anymore, and hence the requirements for the challenge are lessened. This is something to keep in mind with platformers. It is common to have a section where you are climbing up. Be mindful of how disastrous it is to have a misstep. If you are near the top of the tower, missing a jump should not send you back to the bottom. That is a disproportionate punishment for a single mistake. If you can arrange it so you will land on a lower level, then the punishment is more in line with the mistake.
Game Design Theory 7 - Adventure Games
0
I do agree that it is possible to have unfun stuff be set as a precursor to more fun, and people are willing to do the work for the reward. While grinding is not a mechanic you should force on a player, many people will still grind to get the advantage.
However, isn't it better to have it fun all the time? Even though it is not a necessity to have a good game, isn't the better game the one that can make those stretches of the game enjoyable? There is some homeostatic justification that conquering a section that is not fun leads to a greater peak of enjoyment, but the sum experience of it leaves something to be desired. If the player can ride on a constant crest of fun, the overall experience will be much better.
0
Why do you think they are supposed to be human?
0
Ok. Acknowledging the complexity; is it worth it?
0
I am an experienced coder. The point is not to have you come up with it, but that it is computationally complex. It sounds like a simple idea, but the actual details of it make it much more complex than it sounds like.
0
Knowing java has nothing to do with algorithm design. This is exactly my point; this is not anywhere near as simple and efficient as you make it out to be.It is a LOT of extra complexity for this one thing, and doesn't even adequately protect against it.
And how does accessing client data help? You just mod the client to tell the server that everything is honky dory.
If you are playing on a server where you feel such elaborate measures are necessary to keep your stuff safe, maybe you should find a different server. Trying to safeguard against everything under the sun is really complicated , and ultimately ineffective.The basic nature of minecraft leaves it open to exploitation like this.
0
and this is precisely the "beyond the basics" level where it gets confusing. If you simply have an array-type data structure, how do you know which group any given block belongs to? If you can't easily know that, you can't know if modifying any given block is going to impact the visibility groups, or if a block is in a hidden visibility group so it is not sent to the server. You have to detect that a given block change has resulted in a single visibility group being split in two, with the possibility that the group is split locally and connects somewhere else. For instance, if you have a loop that is hidden, and place a block in it, then it breaks the group locally, but they are still connected in one group.
Most of the code will be there already because this was implemented. Adding this in would be doing the work for them. You make a client mod, and we are right back were we started; cheaters cheating. And how do you propose to have servers probe for code? All you need is a mod that has a vanilla copy that it offers for any probing that would be happening.
edit: to be clear, I'm not concerened with simply doing it. I am concerened with doing it efficiently.
0
Aren't air blocks used in certain redstone circuits?
Alright, give me an overview. What data structures are you using to store the groups? How are you keeping track of its visibility? How are you detecting it is split? how are you merging them?
And keep in mind, this has to handle the case of a large, complex redstone circuit being revealed, altered, so vast swathes of it can become hidden, merged, split, possibly frequently. Esp. if someone sets up something with pistons to automate the placement and removal of blocks to do this.
it has to be. If you place a block next to it, you have to tell the client that block was placed. Even if you tell it that all of the now-hidden blocks were removed, the client still knows they were there. You tell it that a block was placed next to the visibility group, and the client will have everything it needs to detect that it is now hidden, and subsequently ignore the command that those blocks were removed, and furthermore highlight that this was hidden, so burring a chest can make the greifer's client light up and put a beacon on it. if you EVER access your hidden chest while someone is near enough to receive the visibility update, it will be completely revealed.
0
And people will never have anything they need to hide with a visible block near it, nope. Esp. if you are trying to hide redstone. Really, the amount of things this will actually hide is miniscule.
I said beyond a basic level. At the basic level, it sounds fine. When I try to look at it in more precise detail and work out edge cases, the complexity skyrockets.
in one case, the chest simply disappears. In another, something else is placed which blocks its visibility. Even if the latter case comes with the former, the latter part is still detectable. Esp. since code to test exactly that case must exist in the server, so it would be trivial for the modder to copy it to a client and re-utilize it for that check.
0
so.... if there is ANY air block involved, it is visible? Or am I misunderstanding how you decide to send the visibility group to the client?
You can't assert that a method is more efficient if you can't explain it beyond a basic level. That would be like saying "just take the lowest value element, put it at the bottom of the list, and repeat for each element. You will end up with a sorted list in linear time". While that may be an accurate description of certain sorting algorithms, those are the ones that give you n2 time, and perform worse than more complex methods.
You can also remember when a chest is picked up, since it should be easy to detect the difference between removing a chest and blocking it off. If you want to do decoy chests, you can do them now. Place 100 chests, and only use 2 or 3. Every empty one would be a pain. And being in the right area wouldn't be that hard.
I'm not saying this couldn't work, but at the current level of conception its impossible to say whether it is really worthwhile, or if it is going to do more harm than good.
0
Except its not as straight foraward as you think.
First, you have to add the overhead of keeping track of all of these collections of visible blocks. Since all of the air, many caves, and the entire surface will be visible, they will be one giant visibility group. You have to figure out how to handle the groups extending across multiple chunks, and not only merge the groups, but divide them. Every time you place a block, it could potentially be cutting off a large swath of visibility, which has to be detected and modified. And since before you bury an item, it is visible, it will be sent to the client of everyone nearby, and a modified client could easily remember it from when it was visible, and even go so far as to highlight things that have been hidden that were visible. So a buried chest would be undetectable... as long as you never unbury it, and no-one was around when you put it there in the first place.
0
And is this server side or client side? If its server side, you have to completely rework the fundamental way the client/server relationship works to make that feasbile. If its client-side, you can still mod around it easily.
And for what? The edge case of a chest being buried being invisible to a x-ray mod? why should a buried chest be special? If you have to put forth the effort to hide a chest completely buried, why not put forth the effort to hide anything the player cannot rightly see? You are convoluting the code to deal with an edge case.
0
Stand on the cobble, look down at the gap. The chest's face is against a solid block, but still needs to be visible.
0
But then if you have a chest against the wall, its back surface would be invisible.