Alright, I'll admit I misphrased things a little there.
Despite what the label may say, Minecraft didn't enter Beta until the Code Freeze. To quote:
"Beta (named after the second letter of the Greek alphabet) is the software development phase following alpha. It generally begins when the software is feature complete. The focus of beta testing is reducing impacts to users, often incorporating usability testing."
Thus, Minecraft was, up until the code freeze (when they stopped adding new features and got to work exclusive on bugs), still in alpha, and it IS an Alpha tester's job to talk specifically about added features.
Or you could take the third route and mod out whatever you don't like, thereby not having to conform to Notch's vision of Minecraft while not being forced to play on an inferior version.
Minecraft does not follow a standard development cycle. At all. Even after release it will be developed further. The code freeze lasts 1 month. Trying to shoehorn it into standard development phases is going to be very misleading.
Can someone give me the source as to enderdragon's not destroying whitestone and obsidian? I pay attention to the typical ways Notch and Jeb communicate, but I haven't come across that statement.
1. Creative: Players are invincible. Endless resources. It's there for a sandbox experience.
2. Survival: All game features are active, but there is no overall goal.
3. Adventure: Story-driven goals and some "lite" RPG elements.
No, you are deeply confused about the modes. Creative mode is right, but survival mode has potential goals and RPG elements, and adventure mode has a severely constrained ability to place or remove blocks, and is intended for custom maps, and to support a dungeon crawl/puzzle based gameplay. What we have now for survival mode is exactly what notch has always said it would be. Seriously, if you go back through his blog, there are things he mentions in passing that he is finally adding. All of these new elements were things he mentioned he was adding in interviews. I paid attention to these things, and he did say he was going to add villages, and weapon enchantments, and leveling, and hunger, and dragons.
Regardless of what ethical or legal obligations notch has to develop the game in a certain direction, he is developing the game as he said he would.Its not a secret. Its not some sudden shift in direction. It is a fulfillment of the plan that he had laid out from the early stages of development.
While the overall design of a game is certainly important, the specific level design can make or break a game. Imagine portal with bad puzzles, mario with a flat screen and goombas. The level defines the current experience the player is having, and as such is absolutely vital. A poor level can sour the experience, frustrate the player, and act as a roadblock from them continuing to play. A good level can be an absolute joy.
The requirements for a good level will vary from game to game. Know your games strengths, and play to them. Here are some guidelines:
1. Never trap the player.
The player should not be able to trap themselves in someplace they cannot escape from. If you have a timed door leading to an enclosed room, add a method to open it from the inside, or add in some other escape route. Forcing the player to restart the level, or the game, so they can get unstuck is just bad. The exception to this is puzzle games, where maneuvering things so you don't get stuck is part of the challenge, and restarting is expected as part of figuring out the puzzle. In all other cases, it is just bad design. At the very least, there should be a method for the player to kill themselves, but if you are intentionally making a place that is inescapable apart from death, it should just kill the player. For instance, if there is a pit that you can fall into, with no way out, either the fall should kill you, or it should be lined with spikes, or in some other way be lethal. This also applies to the general architecture. Avoid making any geometry the player could get stuck in, even if you don't think they can reach it. Players can be remarkably resourceful in getting to unexpected places, and gracefully handling such situations adds a lot of polish to the game.
2. Don't force the player to get hurt.
This is a general rule, but it comes into the design mainly at the level or enemy design level. It should always be possible, though perhaps very difficult, to get through the game unscathed. You shouldn't give enemies unavoidable attacks, you shouldn't require the player to damage themselves as a necessary part of getting through a part, you shouldn't have an attack that requires the player to be prescient to dodge. The player should never be put in the situation of "Oops, I only have 1 heart left, there is no possible way I can make it through this next part".
This is primarily a rule for player skill-based games. It should be possible to utilize your skill properly and avoid all damage. This does not have to be easy to do, but it should be possible. If the game is based on strategy or other methods whereas the player's direct skill isn't in play, this restriction is lifted. RPGs, for instance, don't generally allow for unscathed play, as it is the interplay between your ability to deal damage and your ability to mitigate the enemies damage that is the central combat mechanic.
In a competitive game, like a multiplayer FPS or RTS, perfect play should generally be possible, but infeasible against appropriate opponents. This is what allows that one guy to rack up a 50 kill streak, though if he actually accomplishing that, he should be pitted against stronger opponents.
3. Place checkpoints properly.
Think about the implications of your checkpoint positions. If a checkpoint is directly before a challenging part, then failing that part allows the player to jump right back in and try again. If it is before a boring, easy part leading up to the challenging part, then they have to to-do the easy part each time, which just becomes an annoyance.
However, if you do not have a checkpoint after the challenging part, then any failure afterwards will force the player to redo the part they have just beat, which again becomes annoying.
My suggestion is to figure out which parts of the level you consider to be a unified challenge, and wrap those in checkpoints. Also make sure the check points are not too sparse. It is highly annoying to mess up right before the next checkpoint, and have to redo the last half hour of the game.
You must also consider what your checkpoints mean, and how isolated the challenges are from each other. If the checkpoints regenerate your health and consumables, then the challenges are completely isolated. This means any given challenge needs to be enough to be a threat in and of itself. If dying respawns you at a checkpoint, and in doing so resets your health and consumables, then the checkpoint should regenerate your health and consumables. Otherwise, it becomes more beneficial to commit suicide directly after the checkpoint, which should never be an encouraged action. Of course, other game mechanics can mitigate this, but it is something you should give serious consideration to.
If a checkpoint locks in your health, then you run the risk of trapping the player with an unfairly low health pool to take on the next challenge. This can be mitigated with health pickups. A health pickup is the designer's way of saying "This much damage is acceptable to take without long-term repercussions". A full heal resets you for the next stretch, while partial heals make the game more forgiving.Collectible health lets the player amortize their performance, so doing well in several challenges in a row allows them to accumulate value from it. However, you must be careful about this, and build in limits, such as a maximum amount you can carry. Otherwise, the difficulty of the final boss will vary wildly based on how many health packs they have accumulated over the course of the entire game. Placing some amount of health pickups at or near a checkpoint that locks in your health can greatly alleviate issues with locking in low health, esp. if you bring in the mindset that the largest challenges should come with a full heal beforehand.
While I'm talking about checkpoints, there is one checkpoint design that is important- don't wear down the player. Whether you allow them to build up from repeated respawns is a design decision. For example, you are facing a boss, spending all of your high-power ammo on it, failing, and be forced to face it again without puts way too much emphasis on a first-time success. Taking it on with full firepower is the easiest case, but failing that traps you in the really difficult case of taking out the boss while underpowered. Not good. Esp since you are now even more likely to fail, which means you are going to run out of mediocre ammo, and be left with whatever low-level, infinite use attack you have. This is just cruel. Don't let the player expend expensive resources and not get the benefit from them.
4.Be thematic.
You could just throw in a random mismatch of every game element you have, but that rarely works well(there are exceptions). For instance, if you have an ice themed level, you would have a focus on ice, and attacks that freeze you, etc. If you have a factory level, you will have conveyor belts, gears, etc. This serves several purposes. This first is visual interest. It makes the game feel more distinct. The second is variety. If different levels are focused on different game elements, they will feel distinct. This helps keep the game from getting repetitive. Third, it provides the player with a consistent set of obstacles to master, which provides enough repetition of it to cement it in the player's skillset, and henceforth you can incorporate elements introduced in these levels into future levels.
5. Keep balance in mind.
This is primarily for multiplayer maps. The terrain should not give one team an advantage over the other. Otherwise, red team will win on the map more often than blue, and hence create a disparity. The easiest way to do this is to make it symmetrical, which works fine. It is not the only way to do it, though other methods will require more extensive playtesting. One way to do it is the topologically symmetrical, but not spatially symmetrical map. The topology of the map is symmetrical, so you may have a node with 3 paths on each side, and one path has a bridge over another path, etc. so if you abstract the possible paths through the level into a graph, that graph is symmetrical, even if their spacial orientations and relations are different. If this is not clear, tell me and I will try to illustrate this better. You can then make each side visually distinct, and you have a map that is effectively symmetrical, but not in a way that is obvious to the players, so it feels unsymmetrical. You do have to be careful that this re-arrangement doesn't create any disparities.
Another method is to have a completely unsymmetrical but balanced map. This is very hard to pull off, but possible. Think of this like starcraft. You have different races with very disparate abilities and units, but they are balanced against each other. This requires extensive playtests to achieve.
6.Keep the overall layout in mind.
This layout, and the linked article(click the picture) should illustrate this point. This relates back to my earlier post about linearity. It is a much better design, in general, to have an environment you are fighting in, not just corridors. Allow multiple ways to tackle a combat,add in alternative routes and hidden areas. Hidden areas are a great way to include extra resources. This gives a tangible reward for the exploration, and provides a very rewarding experience. A more open combat arena gives the player a much more open way to tackle the combat. Let them apply tactics. Advanced strategies that give the player an advantage should be encouraged.
8. Keep maneuverability in mind.
In general, you need to allow enough space for proper maneuverability. Doubly so if multiple characters are involved. If multiple characters are trying to pass each other in a hall,it should go smoothly, not become a huge, jammed mess. And here is a tip: Realistic proportion are not adequate. A real-life hallway is generally narrower than what you want in a game.
On the other hand, constraining the maneuverability can work, if it is done deliberately and designed to function as such.
9. Reduce backtracking
It is a good design to have a complex structure to your level. For instance, you come across a barrier, and must go on a side path to open it. However, you shouldn't make the player walk all the way back along the path to get to the barrier. This can be handled in several ones. One way is to offer some form of fast travel back- such as a zip-line to slide down. You can also arrange the structure of the level such that the endpoint is near the barrier, and you can easily travel down to it, though reverse travel to easily get up is difficult. You can have another, different stretch of level leading back to it, thereby adding more unique gameplay to it.
A tighter level structure also helps with this. For instance, if the progression of the level folds back around, you can open a door from the other side, allowing for easier access and replay of the level. Opening up paths from old areas is good in general. Push that crate off the platform to create a new path back up, let down the ladder to get up easily, place that plank across the gap to provide a shortcut. This can act as a kind of soft checkpoint, you have completed a section, and don't need to redo it. This has the advantage over a typical checkpoint in that it can persist for repeated playthroughs, making re-exploration of the area easier. A hub-central design can also be used. You have a central area, with several paths leading off from it, which eventually return to it. This makes it so each section of the level is re-visitable without treking through the other parts. It can also be used to make the level less linear. Instead of having to go through the parts A-B-C, the player could take them on C-A-B, or whichever order they feel like.
You can utilize backtracking, but it should not be a standard part of the game flow. However, make the backtracking interesting. Add in new enemies, design the level to function in both directions. Backtracking should not be used to artificially extend the gameplay without work. It should be used because it has narrative potential, and the level in reverse should provide a unique experience.
It is also possible to re-use levels, when done well. Jak II is a great example of this. You will return to several areas several times throughout the course of the game. However, each time you go there, you are taking a distinct path through the area, and doing completely different things. This has technical reasons; if you are re-using an area 5 times, that is 4 levels you don't need to store. It also helps give the world a consistent feeling. That swamp isn't just a level, it is a place.
10. Provide unique challenges.
There is a part in uncharted 2 where you are traveling through a city in a war. As part of the typical climb-over-everything gameplay, you leap over to a sign. This is a large sign, with signs oriented in different directions. You can clearly see where you are going, and the sign is the route to get there. So you jump onto the sign, and shortly find yourself under fire from the enemies. While on the sign. They are cutting you off from your goal,and now there are guys where you came from, and you are pinned on this sign. What happens next is a wonderful gunfight where you are climbing around on the sign, using it for cover from various directions, while firing your pistol back at your attackers. It is a completely unique challenge, and I have never seen anything like it. If it was a regular occurrence, it wouldn't be very good. But as a unique battle it was great.
That kind of a unique challenge keeps the game interesting, and becomes memorable. Mix it up, do something different, make a section of the level that is distinct and fun. Don't let the level design become monotonous. Game Design Theory 9 - Crafting an experience
I had an idea for a potential minecraft sport. The idea can use some refinement, but here is the basic idea:
You play in creative mode, and everyone flys and has a fishing pole.
You set up an arena, with a goal on either end, and lava on the floor. In the center, is the chicken release.
The chicken release is basically a box that has a chicken placed inside, most likely from throwing eggs, with a hatch on the bottom. When the rounds starts, the hatch is opened, and the chicken falls.
The goal is to get the chicken to the other team's goal, using the fishing rod to pull it. Since chickens fall slowly, you have time to pull it back up before it lands in the lava. If the chicken lands in the lava, the current round ends.
Each round, one team is on offense, the other on defense. Your team must be on offense to score. If you score, the next round starts, and you remain on offense. If the chicken falls in the lava, then a new round starts, and the offensive and defensive teams switch. A switch will also occur if the offensive team gets 5 goals in a row. The game ends after each team has been offensive 4 times.
So, there you have the basic idea. Thoughts, ideas, refinements? Anyone feel like trying this?
Err... so you know how I've been saying that you should only bring one lava bucket? I just figured out that with 4 buckets you can make an infinite source. So if you like lava, bring four buckets, if you just want to use it a little bit, bring 1 bucket, bringing 2, 3, or 5+ is inadvisable still.
Jeb says he is going to revert the liquid code to an earlier version, so I would not rely on this.
I remember hearing about it a while ago, but at the time it wasn't available yet. It does sound interesting, and the time wave mechanic is rather clever. I don't think it would be a very useful mechanism for a narrative, nor have any bearing on reality, but it works well for a game. I should look into it.
...Interesting... Very interesting. I liked the part about the paradoxes. It definitely intrigued me. Question is, though, what would actually happen if a paradox were to occur? Would time loop and loop again or would time go forward while looping in the past?
Depends on the model. A good model can support a paradox. The single alterable timeline is the only one that catastrophically fails if you suffer a paradox, and for that reason is the least useful model.
Also, time does not take time to happen. The concept of looping in the past while continuing in the future is meaningless, since the progression of time occurs outside of time. Am I saying this clearly? That is one thing that always annoyed me, when it takes time for changes to time to happen.
I love time travel. It is an inherently interesting thing to me. Paradoxes, time loops, they make for some wonderfully intricate plots. Time travel as a means to reach other times is interesting, but I find the implications of the time travel model itself fascinating. I will discuss several different models.
First, an overview of the basic paradoxes. This is important, because I will discuss how each model handles these paradoxes, so understanding them is important.
1. Grandfather's paradox. Probably the most well-known. What if you go back in time and kill your grandfather? If you succeed, you can't have been born, which means you can't go back in time to kill your grandfather, so you were born, and bam! Paradox. Generally speaking, this paradox occurs whenever something changes an event in the past that would interfere with it being able to change that event.
2. Ontological paradox. The object(or information) with no origin. You have an object, which gets sent back in time. It then travels through time, only to be sent back in time again. And so on, forever in a time loop, with no origin. This is often the time travel device itself.
3. predestination paradox. A closed casual loop. Event A causes event B, which causes event C, which though time travel causes event A.
Single, unalterable timeline
This is a particularly useful one for plots, and is great fun. It contains the trivial case where you do not have time travel, but that is fairly boring. What this model means, is that you can time travel, but you can't change anything. In fact, you are likely to cause things to happen as they did. This model rides on Nobikov self-consistency principle. The grandfather paradox simply does not happen. In attempting to do kill your grandfather, you will fail, he will turn out not to be your grandfather, or in some other manner fail to change events. The ontological and predestination paradoxes can be handled in one of two ways: embraced or rejected. If rejected, you simple state that those situations will simply never arise. If embraced, you accept that anything goes as long as the end result is stable. It is easy to reject the ontological paradox, but it is hard to allow time travel in this model and not embrace the predestination paradox. That would mean you are not able to alter the future, but also not cause anything to happen. Essentially, time travelers cannot act on the past in such a model, and must constrain themselves to observing.
I find this model most interesting when you embrace the ontological and predestination paradoxes. I find those stories are most interesting. is a good example of this type of model.
single, alterable timeline
I find this one the hardest to swallow. There is a single timeline, but it can be altered. It avoids ontological and predestination paradoxes by not entering their precursor states, but they can still occur. It is fully subject to the grandfather paradox. This is the Back To the Future model, Where you make a change, and history re-writes itself, and you can erase yourself from existence. The plot of that movie was basically attempting to resolve a grandfather paradox so it doesn't happen. The series glazes over what would have happened if Marty did fade out, and hence was unable to prevent his parent's getting together in the first place. Basically, this model is a mess. The one saving grace you can apply to it is "what happened happened". Assert that it does not matter if Marty was never born, and ceased to exist, he would still have been able to break his parents apart, since that happened. This model is mainly useful for creating tension and the need to fix the alteration in the timeline, but it is really difficult to make a really cohesive model out of it. In fact, trying to interpret time travel from this perspective is what will give you a headache.
Insensitive Branching timeline
This model is quite convenient, and has actual physics to back it up. Basically, if you change something in the past, you create an alternate timeline with your changes. This resolves the grandfather paradox. If you go back in time and kill your grandfather, you are now in a seperate timeline where you will never be born, and you are from the original timeline. If you do not change anything, then you stay on the same timeline. This is a basic, but robust, time travel model. You can change things back by going back in time, undoing the change, and then depending on the details of your model, you either transition back to the original timeline, or you have created a new timeline identical to the first.
The ontological paradox can be resolved by having the origin of the object in one timeline, which is sent back, creates a branch, in which the object is sent back to the moment of its origin in the timeline. Similarly, the predestination paradox can be resolved. You go back in time, and cause an event. This new timeline then something back in time, which cases itself. However, these are highly improbably outcomes to occur.
This model gets a bit weird when you try to consider multiple time travelers going to the same time period in different trips. If you go to a time later than they arrived, you will not see them, since they are on a branched timeline. If you go to a time prior to their arrival, you may see them arrive, depending on which side of the branch they create you end up on, and presuming you don't make any changes that will prevent them from going back. You can make the allowance that 2 trips ending on the same point will only form a single branch with the result of both trips.
Sensitive branching timeline
This is the same as the unsensitive branching timeline, with the assertion that the act of arriving in the past will is a change, and will create a branch. I find this much more likely than the insensitive model, and your very presence will exert a change, however slight. However, if you don't make a meaningful change, the new timeline will continue to be apparantly identical to the original one.
This has some interesting implications. Lets start with the base case of a single time traveler. He intends to go back in time, make some observations, and return to when he left. He goes back in time, and branches off a new, identical timeline. From the perspective of the original timeline, his trip was a failure. He does not return, and the traveler seems to have simply dissapeared, forever. From the perspective of the traveller, he went back in time, made no changes, and returned to his normal present.
Since this timeline was the same as the one he left, it also sent back a time traveller, and split off a child timeline. And so did that one. This creates 1 timeline where the traveller did not return, and an infinite number where he did return. If these timelines cause another similar journey, you have an infinte number of timelines where they had 1 trip successful, and failed, and an infinity x infinity number where they where both successful.
Branching and merging model
These infinite identical timelines are untidy and unnecessary. Let us state that two universes in an identical state will merge together. We can further loosen the bounds, such that any two universes which are close enough to identical that quantum uncertainty engulfs the difference will merge. Now, if you go back in time, do not make a meaningful change, you create a blip in the timeline. The timeline goes along smoothly, creates a branch where there are 2 timelines, one with a time traveler, one without, which then re-merge after the time traveller has left and the minute differences they made balance out. This mops up the infinite universes and makes it into a nice, clean structure. This creates 2 classes of time travel- blips and divergent. A blip creates a temporary disturbance which results in no real change, and remerges back in. A divergence creates a real change, that due to chaos theory will have far-reaching effects, and create an entirely different timeline.
If you assume that all the time travel in a movie is all that ever occurs, it is simple to map out the structure of the timelines. However, it is more likely that other time travel occurs, and the movie is only looking at a substructure of the time web. There would be a critical threshold, based on the likelyhood and prevalance of time-travel, where time travel is common enough, that each timeline has, on average, .5 or more child timelines, which will result in an infinite number of timelines. In such as case, improbable events will occur. Such as forming a ontological or predestination paradox. Somewhere within this structure, somebody sends back the plans to the time machine, which are built, and used to send the plans back to that precise instant, and a timeline with the ontological paradox is formed. This likelyhood can even be increased if you assume that it is a self-stabilizing phenomenon. You send the plans back in time, and they land in a general time slot. This is close enough to trigger the plans back to a similar time, and this is repeated with ever-decreasing variation until it locks in on a specific, stable timing.
This also handles multiple time travelers to the same era much nicer. All you need is a single acknowledgment- both halves of a blip are equally viable pasts. Both of them led to the present, so when traveling back in time, you arrive in both. So, if you go back to the earlier time, you create a blip to which they can land in, and if you go back to a later time, you land in their blip. This means there is a timeline where both travellers arrived, a virgin timeline where neither did, and a pair of timelines where only one did. Not all of these have to remain a blip. They can diverge. Blips can have sub-blips, you can have blip with a diverging timeline, divergent timelines can form their own blips.
It is also possible to re-merge a timeline from a divergent timeline. If the divergent timeline forms its own divergent timeline in such a way that it ends up identical to the source timeline, they can merge. This is the phenomenon you would see when someone "fixes" a broken timeline. What is more accurate is that they are creating a new timeline to remerge with the goal timeline so they can be back on the correct timeline. Once a timeline diverges, that split will always remain. There can also be any number of divergent timelines between the branch and the merge, resulting in some rather intricate scenarios.
This is a very robust model, since by looking at the proper subsets of it, you can create many classic sci-fi scenarios. You can find a subset undergoing a ontological paradox and/or a predestination paradox, and by looking at that part of the timeline have it appear to be unalterable. You can go back in time and change history, and then change it back. You can go back in time to stop someone from altering history, to provide back-up to existing travelers. From the perspective of the time travellers, only 1 timeline is "real", and so changing which timeline they are on is effectively the same as altering history for them. Terminator is fully supported by this model, as it is able to handle John Conner's lineage, allow them to mess around with the timing and development of skynet, and all the other monkeying about they do.
Also, consider that the universe started in a single state, the big bang. It also will end in a single state- either a big crunch or a heat death, either case results in a identical outcome, no matter how you arrived at it. Hence, the overall structure of the time web starts at a single timeline, ends at a single timeline, and has a lot of complexity and branching in the middle. Its a giant ball of timey-wimey stuff. It by itself is not enough to explain dr who- they have temporal locks and paradox machines and such - but it provides a robust base to build from if you want to try to explain everything, and matches their description of time quite nicely.
The sea of possibilities
Ok, this one gets weird. And considering that we are talking about time travel, that is saying something.
First, acknowledge that time does not really have a direction. At a fundamental level,past and future are the same, all of the base properties of the universe work in both directions. Second, everything is quantuum, and is a probability wave until you observe it. Observing a quantum state places a constraint on the universe that it must be consistent with that state. This is how entanglement works. You make it so that the state of two particles are related, even though neither is known. You observe one, and can accurately predict the state of the other one.
The entire universe exists as a probability wave until you observe parts of it. It must be consistent with what you observe. This includes the past. The past is not a definite thing, set in stone, as most people presume. It is a probability wave of every possible past that could lead to this present. The present constrains the probability wave. We have a ton of evidence of what happened. The banana in the kitchen, the wear marks on the keyboard, the fossils in the ground, whatever the past was, it led to all of these things. The world is filled with records of the past that constrain it. We know the holocaust existed, not because our text books say so, but because of the profound impact it had on the world. If you observe the past, you will find the holocaust there, or else the most elaborate coverup to perfectly simulate its effects.
Every possible past could led to the current moment is valid. Perhaps not equally likely, but possible. Past and future are symmetrical. Just as the present constrains the possible pasts, so does it constrain the possible futures. There are only so many ways the next few seconds could unfold, but the further away from the present you get, in either direction, the more possibilities are present.
When you travel back in time, you will end up in one of the potential pasts. This refocuses everything relative to your new time. As long as you do not take actions to drive the current state of affairs outside of the previous realm of possible pasts, it is possible to return. After all, someone randomly appearing in the middle of the desert and dissapearing is within the realm of possible events that led to the current moment. Your presence in the past is not automatically disruptive since your presence was already part of the probability wave. However, even if you stay withing those bounds, the future relative to you is still a probability wave. Your present is now somewhere within this probability wave, and attempting to travel back to the present will place you somewhere within those bounds. Hence, traveling to the past will result in you returning to a different present, even if you do not enact a change.
Furthermore, you will seethe same phenomena when traveling to the future. You refocus the probability waves on a point in the future, meaning the present gets lost in the probability wave of potential pasts, and traveling back in time will place you somewhere randomly. So, traveling to the future changes the present. Or rather, all possible presents are there, but you will end up in a different one, with is as close to changing the present as you can get in this model.
The grandfather paradox is meaningless. You don't even have a clear timeline, so going back in time and killing your grandfather cannot even be said to be on the same timeline as you. The predestination and ontological paradoxes are similarly meaningless without a clear timeline.
I am particularly fond of the adventure game genre. It was rather popular back in the day, and I grew up with the likes of Space Quest and Gobliiins. I have gone through libraries of adventure games and played them, and it is fairly apparent to me how the genre grew and developed, both in technical advancements and in design principles.
The adventure game genre traces its roots back to text adventures. No images, just textual descriptions of what was going on. This is the era of Zork. You typed your commands, and it gave you back a description of what happened. Now, this isn't necessarily a bad interface, if done properly. Its commonly called interactive fiction for a reason, its like reading book, only you are interacting with it. The primary problem with the format is you tend to fall into "guess the verb" territory. You know what you want to do, but you have a hard time figuring out how to convey it to the game.You aren't even sure if what you are trying is the correct thing, so its hard to tell if there is even a verb to guess. A poorly written on can also be very obtuse as to what is going on. "open the door". "You cannot open the door". Well, why not? Can I not reach it? Is it locked? Stuck? Is it missing its doorknob? Is their an ancient warrior guarding it?
The biggest flaw in the older ones is that they are not always winnable on your first attempt. It is possible(easy, even) to maneuver yourself in a position from which you cannot win the game, but it is not obvious that this is the case. Sometimes you have to have prescient knowledge in order to solve a puzzle; you may have to leave a seemingly random item in a room, so you can find it there later. Sometimes you have a limited resource, like oil in a lantern, and if you fail to utilize it perfectly, you get stuck.
Then as time marched on, you started to get hybrid games. Technology was better, and they were able to attach pictures to their text adventures. You were still playing a text adventure, only there was a picture showing you the scene. This is the era where Time Quest was made. I don't think this was a widespread format, but Time Quest is worth mentioning since it also had a second interface revolution; it provided a list of objects and verbs. There was a list of objects in the scene you could interact with, taking out the guesswork of what elements in the description where relevant. It also had a list of verbs, taking out the guesswork there. Now, don't think for a moment that this made the game easy. The challenge is not in figuring out how to do something, but rather orchestrating the events. It did possess some of the earlier flaws, like being able to corner yourself in an unwinnable state and needing prescient knowledge of events, though overall it did this less than some of the older games. It shines as a good game despite those flaws, because it has really clever puzzles, frequently based on time travel. You have to orchestrate simultaneous events in different parts of the world, you have to utilize time travel withing the same area, you set up seeds in the past and reap the benefits in the future. It did time travel really well. And the final puzzles involves two pads, one sends you forward in time, the other back, and you go through this complex, but solvable, puzzle involving passing information and items to and from your past and future selves, and freeing yourself from the bad guy. It was brilliant and awesome. Of course, I may be biased since I am particularly fond of time travel, and I could write a series on time travel models and their implications, as well as having devised some of my own.
Then you get to the era of the text-parser graphical adventure games. Sierra was a big name in these, with the likes of kings quest and space quest. You have a graphical world, and you move around in it, but you are still typing your commands.This retains the "guess the verb" issues of the previous era, but they have realized that requiring prescience and being able to trap yourself in unsolvable states where a bad thing. They also had their own batch of common flaws. In particular, excessive death and arcade sequences. Excessive death was not new, many of the older games would kill you, but Sierra made it into an art. Its not even the death that was the problem. The deaths where creative and amusing, and came with amusing messages. Part of the fun was seeing how you could die. Even the first space quest had such an creative array of deaths, ranging from getting swallowed by a sand worm, getting split into several parts by walking through lasers, having your head dissolved by drinking from an acid pool, etc. The problem was this lead to the advice "save early and save often"m which you really had to take to heart. You die, and you go back to the last time you saved. Hence, you saved after you accomplished anything, and before you tried anything. Not exactly the best mechanic, but it was accepted. The graphical interface also lead them to include inescapable games of skill. In Space Quest, it was dodging rocks on a hover skimmer. Other games in the series had similar arcade sequences. Or places in-game where you have to walk. Precisely. Or die. most notable would be the root maze in space quest II. you have this alien plant monster with a a mazelike root system. You have to walk through it, and if you so much as brush against a root, you get killed. And it often goes at weird angles. You can't walk at arbitrary angles, so this leads to going up,left,up,left,up,left, very carefully to get through. Then you have to do it again to get back. Its frustrating. Its a challenge born from clumsy controls, which is never where the challenge should come from.
In general, you should have a consistent skillset required to complete a game. Most of an adventure game is a cerebral process. You are solving puzzles, figuring out how to combine items, set up a solution, and its a very relaxed pace. Suddenly having a high-speed, reflex based arcade sequence now requires a completely different skill set to complete.This throws down a huge barrier to completing the game, and will frustrate those without the prerequisite skills.
Then adventure games became point and click. Ridding themselves of the text interface completely, you merely have to click on what you want to interact with, using the proper ability. This removes any trace of "guess the verb", and instead introduces "Find the pixel" and "use everything on everything". Pixel hunting is the bigger flaw. You want to interact with something, but you can't figure out precisely where you need to click to do it. "Oh, I need to click on the parrots feet to pick him up". This issue faded over time, and people started designing the clickable areas better, and added in a changing cursor or other indicators that something could be interacted with. Lucas Arts games tended to give you a name of the clickable area when you hovered over it, making it clear if something was different to click on.
"use everything on everything" is more an emergent issue with how people react to the interface than a problem with the interface itself. Basically, people get stuck, and start brute-forcing the solution. Some games had solutions so obscure that this was the only realistic way you would solve them. That is a break down of the puzzle design. More on this later.
Most adventure games are what I classify as "inventory based", esp up to this time. You are mainly concerned with gathering items, and using items on things. The other type is "puzzle based", popularized by Myst. Your inventory is very limited, and generally not used to solve the puzzles. Instead, the challenges are more mental puzzles.You find clues, solve brain teasers, figure out how to work the control panels. As you may guess from the Myst series popularity(it was the bestselling game until the Sims came out), this is a very rewarding game style. There are also hybrid games, where you use an inventory for puzzle solving, but you also have a number of brain teasers to figure out. Sanitarium falls into this category.
Hybrid adventure games have formed the offshoot of escape games. Escape games use the same gameplay as adventure games, but strip out the adventure, proving that the gameplay alone can make compelling games. This is currently a popular genre on the internet, with countless games, though I have never seen one that wasn't free. The basic premise tends to be "you are locked in a room, escape", which you do by collecting a wide variety of items from within the room, solving puzzles, and making your escape. They are very light on story, and just focus on providing a puzzle for the player to solve.
What makes a good adventure game
I hold that there are 3 key elements to making a good adventure game.
1. Good writing.
The genre has its roots in interactive fiction, and was grown around the premise of telling a story. Adventure games do not have a backstory, you are actively progressing through the story. As such, the plot is important. It should be told directly in the gameplay as much as possible, which is very possible in an adventure game. Talking to characters, finding information in documents or computers, radio broadcast, the progression of the setting, all can be used to immerse the character in the plot. The plot can also help give the player goals. You need to figure out how to get into the bad guys lair, you need to befreind the witch, whatever. Good goals are related to the plot, not merely accomplishing arbitrary tasks. But the adventure game genre was designed to tell stories, so make sure you are telling a good one.
You also need good moment-to-moment writing. Depending on your game, this could mean different things. If you are doing a more serious game, then the writing quality can help set the tone, engage the player in the story. Just like a good book needs both a good plot and good writing to convey it effectively, so does a good adventure game need engaging writing. descriptions of items, conversations with characters, all need to be well-written. Humorous adventure games are also quite common, and can work wonderfully. The space quest series was quite amusing, day of the tentacle was a riot, Callahan's cross-time saloon was packed so full of jokes I don't know how they managed it. Seriously, you spend most of your time just looking at items because everything has an awesome description. You look at a post, and instead of saying "its a post", it goes into a long, humorous story about it.
2. Interesting settings.
Adventure games are a wonderful medium for cool settings. Myst was a master of this. The series was full of beautiful, fantastic worlds. Space quest had everything ranging from space stations and space ships, to a rainbow of alien planets, to the interior of the human body. Sanitarium offered several unique, interesting worlds. Kings quest lets you explore a magical realm. Sure, other genre's of games can benefit from unique settings, but adventure game's are uniquely suited to exploring the individual quirks of each setting.
3. Good puzzles
The puzzles are the gameplay. They need to be clever, and well designed. If they are too obscure, the player just gets stuck, and even after completing it may think "How was I supposed to come up with that?". This is a symptom of poor puzzle design. You also don't want to make them too easy, otherwise there is no sense of accomplishment. A good puzzle is one the player has to think about, but will solve. Part of this is providing them with the needed information. If you need to use the piece of metal to cut the rope, make sure the player knows it is sharp. You can simply call it a sharp piece of metal. You can have them accidentally cut their finger on it, or comment on the sharpness in the description, but the relevant properties should be knowable. You should also avoid needing knowledge from out of game. If knowledge of the greek gods is important, tell it to the player. This could be in the form of a book they can read, or a conversation with a character, but make sure they don't have to resort to Google. However, don't use such knowledge as an obstacle to the progression, since if they do know it already, they can circumvent the puzzles leading up to collecting that knowledge.
In general, there are 2 ways a puzzle can be designed. Either have it clear what the next step is, or have it possible to work backwards to a solution. These examples are somewhat spoilery, so if you don't want the puzzles in these games spoiled, skip over the examples.
Example of the first:
In Day of the Tentacles(great adventure game, btw), you find a bucket of soapy water and a brush. There is a dirty car in the driveway. Even though you don't know why you need to clean the car, it is an obvious thing to do. Cleaning the car causes it to rain, which is useful. And it makes sense in hindsight- it always rains when you clean your car. However, you would never think "I need it to rain, so I should wash the car". However, since it is such an obvious thing to do, it still works.
Other, simpler examples include using a screwdriver on the loose panel, a key on a lock, etc. You don't know why you need to open the panel or unlock the lock, but it is clear it is the thing to do.
Example of the second:
In Same and max, you need to give your past self an AI. There is an AI attached to your time booth. You can discover that the glue people use in the future is made by grandpa stinky based on his tar cake recipe, and hence that is what is holding the AI on the time booth. You also have a means of taking out a patent on something, if you have a sample. So, you take a sample of the tar cake, go get a patent on it, tell grandpa stinky he can't develop the tar cake, thereby stopping him from inventing the glue, and the AI device falls off, so you can give it to your past self.
In general, the latter is the better design. However, you must make sure you have all the clues needed present for the player to work out what needs to be done. It also allows the player to think "Oh, I just need something to cut this rope with...", so when they find the sharp piece of metal, they know what to do with it, and can execute the chain of actions, which is very satisfying.
You also need to ensure you don't let the player's trap themselves in an unwinnable scenario (this is a general principle, and not exclusive to adventure games). For instance, if there is an item you will need later, but is located in the current scene, you must ensure that either 1. They must have the item before leaving the scene, or 2. they have a way to return to the scene. If going with 2, make sure that going back to an earlier scene to get something is clear. Don't make it so you need to find the security card under the rug, there is no good way to tel that you need to re-explore an old scene to find something hidden. However, of there is an umbrella stand with umbrellas, and the player knows they need an umbrella, then the expectation that they will realize there were umbrellas there is not unreasonable. As for 1, there are several ways you can ensure it. The first is to require them to use the item before leaving the scene. If it is needed to leave, then they are sure to have it. The second is to make sure they get it at the same time/before a needed item. For instance, if you will need the towel later, and the key now, you can put the towel and key in the same drawer. You then have 2 options. You can make it so taking items from the drawer takes both, or you can make it so the key is under the towel, so you must take the towel before finding the key. Don't simply put them both in the same drawer. It is perfectly possible for them to grab the key, but not the towel. Even if it is unlikely, it is possible. For a similar reason, don't use a piece of knowledge as a prerequisite item. If the 4th symbol to the combination lock is under the towel, they could manage to guess the 4th symbol, and progress without the towel. The last method to ensuring they don't leave having them refuse to leave. "I can't leave yet, I still need something". This works, and is used, but it is not a very good design. For one, it is very arbitrary. It leaves the player wondering what they need, and why the character knows they need it. They also are left with not clue what they are searching for. It can be done well in some cases "I can't leave for the airport without my wallet!" This makes it clear why you can't leave without it, and what you need.
As part of "don't trap the player in an unsolvable state", keep information that the player needs accessible. For example, if a character tells the player a password, don't rely on the player remembering it or writing it down when it is said. Make sure there is some way to access it. That could mean the player can ask the character "Hey, what was that password again?", which at the very least keeps the avenue of information open. What can work even better is if the player's character will remember it. This could mean writing it on piece of paper which is added to the inventory for future reference, having a specific Notes functionality built in to store conversations and codes, or even having them enter the password themselves. This has the advantage of keeping the information available, even if accessing it's source is not practical, and it adds a convenience factor. How precisely you handle it depends on your precise design. Entering a code you already know isn't exactly thrilling gameplay, however knowing that you need to use that code on that keypad can be part of the puzzle. Manually entering it also opens up more possibilities to introduce a puzzle between the given information and what must actually be entered.
On the subject of entering codes, the interface to do so should be convenient. Letting the player simply type it in, even if it is primarily a point and click game, is the most convenient. However, if the game is mouse-driven, the keyboard should never become necessary, but it can serve as a convenient alternative. a clickable numpad is intuitive and easy to use. A click-to-increment digit counter can be annoying. This is where you have digits(or letter) of the code displayed, and by clicking on them you can increment them forwards. However, even on a basic numeric code this is somewhat annoying. The code 5283 takes 4 clicks on a numpad. It takes 14 on a click-to-increment counter, assuming no misclicks. If you click once to many times on any digit, that is an extra 10 clicks. This is even more annoying if you have letters, or even worse an alphanumeric code. If you involve capitals, the number of clicks quickly balloons. Having arrows to increment or decrement the digit helps, vastly reducing the penalty for a misclick and allowing digits to be selected backwards. This makes 5283 into 9 clicks. Still, Its not exactly a great interace, though it is woefully common in room escape games. The increment/decrement with pure numbers isn't too bad, though.
Additionally, if the code entered is in any way "constructed" from clues, keep the code persistent between being entered. If you are finding clues like "the 3rd digit is 5", then let the player keep their notes directly on the lock. Let them go in, set the 3rd digit to 5, and leave, and have it stay set till they look at it again. For any combination, always consider whether it is better to present the player with a clean slate to enter the code from scratch, or to give them a persistent code to toy with. Both have their place. A reset button is also convenient way to reset the code to its default state, allowing you to get the benefits of a persistent code, while keeping the benefit of a fresh slate. Esp if the puzzle is one where returning to the default state is tricky, having a reset button is a huge convenience.
0
Minecraft does not follow a standard development cycle. At all. Even after release it will be developed further. The code freeze lasts 1 month. Trying to shoehorn it into standard development phases is going to be very misleading.
0
1
No, you are deeply confused about the modes. Creative mode is right, but survival mode has potential goals and RPG elements, and adventure mode has a severely constrained ability to place or remove blocks, and is intended for custom maps, and to support a dungeon crawl/puzzle based gameplay. What we have now for survival mode is exactly what notch has always said it would be. Seriously, if you go back through his blog, there are things he mentions in passing that he is finally adding. All of these new elements were things he mentioned he was adding in interviews. I paid attention to these things, and he did say he was going to add villages, and weapon enchantments, and leveling, and hunger, and dragons.
Regardless of what ethical or legal obligations notch has to develop the game in a certain direction, he is developing the game as he said he would.Its not a secret. Its not some sudden shift in direction. It is a fulfillment of the plan that he had laid out from the early stages of development.
0
Here you go.
Its not for source engine specifically, but a lot of it is applicable.
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
While the overall design of a game is certainly important, the specific level design can make or break a game. Imagine portal with bad puzzles, mario with a flat screen and goombas. The level defines the current experience the player is having, and as such is absolutely vital. A poor level can sour the experience, frustrate the player, and act as a roadblock from them continuing to play. A good level can be an absolute joy.
The requirements for a good level will vary from game to game. Know your games strengths, and play to them. Here are some guidelines:
1. Never trap the player.
The player should not be able to trap themselves in someplace they cannot escape from. If you have a timed door leading to an enclosed room, add a method to open it from the inside, or add in some other escape route. Forcing the player to restart the level, or the game, so they can get unstuck is just bad. The exception to this is puzzle games, where maneuvering things so you don't get stuck is part of the challenge, and restarting is expected as part of figuring out the puzzle. In all other cases, it is just bad design. At the very least, there should be a method for the player to kill themselves, but if you are intentionally making a place that is inescapable apart from death, it should just kill the player. For instance, if there is a pit that you can fall into, with no way out, either the fall should kill you, or it should be lined with spikes, or in some other way be lethal. This also applies to the general architecture. Avoid making any geometry the player could get stuck in, even if you don't think they can reach it. Players can be remarkably resourceful in getting to unexpected places, and gracefully handling such situations adds a lot of polish to the game.
2. Don't force the player to get hurt.
This is a general rule, but it comes into the design mainly at the level or enemy design level. It should always be possible, though perhaps very difficult, to get through the game unscathed. You shouldn't give enemies unavoidable attacks, you shouldn't require the player to damage themselves as a necessary part of getting through a part, you shouldn't have an attack that requires the player to be prescient to dodge. The player should never be put in the situation of "Oops, I only have 1 heart left, there is no possible way I can make it through this next part".
This is primarily a rule for player skill-based games. It should be possible to utilize your skill properly and avoid all damage. This does not have to be easy to do, but it should be possible. If the game is based on strategy or other methods whereas the player's direct skill isn't in play, this restriction is lifted. RPGs, for instance, don't generally allow for unscathed play, as it is the interplay between your ability to deal damage and your ability to mitigate the enemies damage that is the central combat mechanic.
In a competitive game, like a multiplayer FPS or RTS, perfect play should generally be possible, but infeasible against appropriate opponents. This is what allows that one guy to rack up a 50 kill streak, though if he actually accomplishing that, he should be pitted against stronger opponents.
3. Place checkpoints properly.
Think about the implications of your checkpoint positions. If a checkpoint is directly before a challenging part, then failing that part allows the player to jump right back in and try again. If it is before a boring, easy part leading up to the challenging part, then they have to to-do the easy part each time, which just becomes an annoyance.
However, if you do not have a checkpoint after the challenging part, then any failure afterwards will force the player to redo the part they have just beat, which again becomes annoying.
My suggestion is to figure out which parts of the level you consider to be a unified challenge, and wrap those in checkpoints. Also make sure the check points are not too sparse. It is highly annoying to mess up right before the next checkpoint, and have to redo the last half hour of the game.
You must also consider what your checkpoints mean, and how isolated the challenges are from each other. If the checkpoints regenerate your health and consumables, then the challenges are completely isolated. This means any given challenge needs to be enough to be a threat in and of itself. If dying respawns you at a checkpoint, and in doing so resets your health and consumables, then the checkpoint should regenerate your health and consumables. Otherwise, it becomes more beneficial to commit suicide directly after the checkpoint, which should never be an encouraged action. Of course, other game mechanics can mitigate this, but it is something you should give serious consideration to.
If a checkpoint locks in your health, then you run the risk of trapping the player with an unfairly low health pool to take on the next challenge. This can be mitigated with health pickups. A health pickup is the designer's way of saying "This much damage is acceptable to take without long-term repercussions". A full heal resets you for the next stretch, while partial heals make the game more forgiving.Collectible health lets the player amortize their performance, so doing well in several challenges in a row allows them to accumulate value from it. However, you must be careful about this, and build in limits, such as a maximum amount you can carry. Otherwise, the difficulty of the final boss will vary wildly based on how many health packs they have accumulated over the course of the entire game. Placing some amount of health pickups at or near a checkpoint that locks in your health can greatly alleviate issues with locking in low health, esp. if you bring in the mindset that the largest challenges should come with a full heal beforehand.
While I'm talking about checkpoints, there is one checkpoint design that is important- don't wear down the player. Whether you allow them to build up from repeated respawns is a design decision. For example, you are facing a boss, spending all of your high-power ammo on it, failing, and be forced to face it again without puts way too much emphasis on a first-time success. Taking it on with full firepower is the easiest case, but failing that traps you in the really difficult case of taking out the boss while underpowered. Not good. Esp since you are now even more likely to fail, which means you are going to run out of mediocre ammo, and be left with whatever low-level, infinite use attack you have. This is just cruel. Don't let the player expend expensive resources and not get the benefit from them.
4.Be thematic.
You could just throw in a random mismatch of every game element you have, but that rarely works well(there are exceptions). For instance, if you have an ice themed level, you would have a focus on ice, and attacks that freeze you, etc. If you have a factory level, you will have conveyor belts, gears, etc. This serves several purposes. This first is visual interest. It makes the game feel more distinct. The second is variety. If different levels are focused on different game elements, they will feel distinct. This helps keep the game from getting repetitive. Third, it provides the player with a consistent set of obstacles to master, which provides enough repetition of it to cement it in the player's skillset, and henceforth you can incorporate elements introduced in these levels into future levels.
5. Keep balance in mind.
This is primarily for multiplayer maps. The terrain should not give one team an advantage over the other. Otherwise, red team will win on the map more often than blue, and hence create a disparity. The easiest way to do this is to make it symmetrical, which works fine. It is not the only way to do it, though other methods will require more extensive playtesting. One way to do it is the topologically symmetrical, but not spatially symmetrical map. The topology of the map is symmetrical, so you may have a node with 3 paths on each side, and one path has a bridge over another path, etc. so if you abstract the possible paths through the level into a graph, that graph is symmetrical, even if their spacial orientations and relations are different. If this is not clear, tell me and I will try to illustrate this better. You can then make each side visually distinct, and you have a map that is effectively symmetrical, but not in a way that is obvious to the players, so it feels unsymmetrical. You do have to be careful that this re-arrangement doesn't create any disparities.
Another method is to have a completely unsymmetrical but balanced map. This is very hard to pull off, but possible. Think of this like starcraft. You have different races with very disparate abilities and units, but they are balanced against each other. This requires extensive playtests to achieve.
6.Keep the overall layout in mind.
This layout, and the linked article(click the picture) should illustrate this point. This relates back to my earlier post about linearity. It is a much better design, in general, to have an environment you are fighting in, not just corridors. Allow multiple ways to tackle a combat,add in alternative routes and hidden areas. Hidden areas are a great way to include extra resources. This gives a tangible reward for the exploration, and provides a very rewarding experience. A more open combat arena gives the player a much more open way to tackle the combat. Let them apply tactics. Advanced strategies that give the player an advantage should be encouraged.
8. Keep maneuverability in mind.
In general, you need to allow enough space for proper maneuverability. Doubly so if multiple characters are involved. If multiple characters are trying to pass each other in a hall,it should go smoothly, not become a huge, jammed mess. And here is a tip: Realistic proportion are not adequate. A real-life hallway is generally narrower than what you want in a game.
On the other hand, constraining the maneuverability can work, if it is done deliberately and designed to function as such.
9. Reduce backtracking
It is a good design to have a complex structure to your level. For instance, you come across a barrier, and must go on a side path to open it. However, you shouldn't make the player walk all the way back along the path to get to the barrier. This can be handled in several ones. One way is to offer some form of fast travel back- such as a zip-line to slide down. You can also arrange the structure of the level such that the endpoint is near the barrier, and you can easily travel down to it, though reverse travel to easily get up is difficult. You can have another, different stretch of level leading back to it, thereby adding more unique gameplay to it.
A tighter level structure also helps with this. For instance, if the progression of the level folds back around, you can open a door from the other side, allowing for easier access and replay of the level. Opening up paths from old areas is good in general. Push that crate off the platform to create a new path back up, let down the ladder to get up easily, place that plank across the gap to provide a shortcut. This can act as a kind of soft checkpoint, you have completed a section, and don't need to redo it. This has the advantage over a typical checkpoint in that it can persist for repeated playthroughs, making re-exploration of the area easier. A hub-central design can also be used. You have a central area, with several paths leading off from it, which eventually return to it. This makes it so each section of the level is re-visitable without treking through the other parts. It can also be used to make the level less linear. Instead of having to go through the parts A-B-C, the player could take them on C-A-B, or whichever order they feel like.
You can utilize backtracking, but it should not be a standard part of the game flow. However, make the backtracking interesting. Add in new enemies, design the level to function in both directions. Backtracking should not be used to artificially extend the gameplay without work. It should be used because it has narrative potential, and the level in reverse should provide a unique experience.
It is also possible to re-use levels, when done well. Jak II is a great example of this. You will return to several areas several times throughout the course of the game. However, each time you go there, you are taking a distinct path through the area, and doing completely different things. This has technical reasons; if you are re-using an area 5 times, that is 4 levels you don't need to store. It also helps give the world a consistent feeling. That swamp isn't just a level, it is a place.
10. Provide unique challenges.
There is a part in uncharted 2 where you are traveling through a city in a war. As part of the typical climb-over-everything gameplay, you leap over to a sign. This is a large sign, with signs oriented in different directions. You can clearly see where you are going, and the sign is the route to get there. So you jump onto the sign, and shortly find yourself under fire from the enemies. While on the sign. They are cutting you off from your goal,and now there are guys where you came from, and you are pinned on this sign. What happens next is a wonderful gunfight where you are climbing around on the sign, using it for cover from various directions, while firing your pistol back at your attackers. It is a completely unique challenge, and I have never seen anything like it. If it was a regular occurrence, it wouldn't be very good. But as a unique battle it was great.
That kind of a unique challenge keeps the game interesting, and becomes memorable. Mix it up, do something different, make a section of the level that is distinct and fun. Don't let the level design become monotonous.
Game Design Theory 9 - Crafting an experience
0
Fishing rods pulling mobs is their best use, in my opinion.
0
You play in creative mode, and everyone flys and has a fishing pole.
You set up an arena, with a goal on either end, and lava on the floor. In the center, is the chicken release.
The chicken release is basically a box that has a chicken placed inside, most likely from throwing eggs, with a hatch on the bottom. When the rounds starts, the hatch is opened, and the chicken falls.
The goal is to get the chicken to the other team's goal, using the fishing rod to pull it. Since chickens fall slowly, you have time to pull it back up before it lands in the lava. If the chicken lands in the lava, the current round ends.
Each round, one team is on offense, the other on defense. Your team must be on offense to score. If you score, the next round starts, and you remain on offense. If the chicken falls in the lava, then a new round starts, and the offensive and defensive teams switch. A switch will also occur if the offensive team gets 5 goals in a row. The game ends after each team has been offensive 4 times.
So, there you have the basic idea. Thoughts, ideas, refinements? Anyone feel like trying this?
0
Jeb says he is going to revert the liquid code to an earlier version, so I would not rely on this.
0
0
I remember hearing about it a while ago, but at the time it wasn't available yet. It does sound interesting, and the time wave mechanic is rather clever. I don't think it would be a very useful mechanism for a narrative, nor have any bearing on reality, but it works well for a game. I should look into it.
0
Depends on the model. A good model can support a paradox. The single alterable timeline is the only one that catastrophically fails if you suffer a paradox, and for that reason is the least useful model.
Also, time does not take time to happen. The concept of looping in the past while continuing in the future is meaningless, since the progression of time occurs outside of time. Am I saying this clearly? That is one thing that always annoyed me, when it takes time for changes to time to happen.
0
0
Since you asked
5
First, an overview of the basic paradoxes. This is important, because I will discuss how each model handles these paradoxes, so understanding them is important.
1. Grandfather's paradox. Probably the most well-known. What if you go back in time and kill your grandfather? If you succeed, you can't have been born, which means you can't go back in time to kill your grandfather, so you were born, and bam! Paradox. Generally speaking, this paradox occurs whenever something changes an event in the past that would interfere with it being able to change that event.
2. Ontological paradox. The object(or information) with no origin. You have an object, which gets sent back in time. It then travels through time, only to be sent back in time again. And so on, forever in a time loop, with no origin. This is often the time travel device itself.
3. predestination paradox. A closed casual loop. Event A causes event B, which causes event C, which though time travel causes event A.
Single, unalterable timeline
This is a particularly useful one for plots, and is great fun. It contains the trivial case where you do not have time travel, but that is fairly boring. What this model means, is that you can time travel, but you can't change anything. In fact, you are likely to cause things to happen as they did. This model rides on Nobikov self-consistency principle. The grandfather paradox simply does not happen. In attempting to do kill your grandfather, you will fail, he will turn out not to be your grandfather, or in some other manner fail to change events. The ontological and predestination paradoxes can be handled in one of two ways: embraced or rejected. If rejected, you simple state that those situations will simply never arise. If embraced, you accept that anything goes as long as the end result is stable. It is easy to reject the ontological paradox, but it is hard to allow time travel in this model and not embrace the predestination paradox. That would mean you are not able to alter the future, but also not cause anything to happen. Essentially, time travelers cannot act on the past in such a model, and must constrain themselves to observing.
I find this model most interesting when you embrace the ontological and predestination paradoxes. I find those stories are most interesting. is a good example of this type of model.
single, alterable timeline
I find this one the hardest to swallow. There is a single timeline, but it can be altered. It avoids ontological and predestination paradoxes by not entering their precursor states, but they can still occur. It is fully subject to the grandfather paradox. This is the Back To the Future model, Where you make a change, and history re-writes itself, and you can erase yourself from existence. The plot of that movie was basically attempting to resolve a grandfather paradox so it doesn't happen. The series glazes over what would have happened if Marty did fade out, and hence was unable to prevent his parent's getting together in the first place. Basically, this model is a mess. The one saving grace you can apply to it is "what happened happened". Assert that it does not matter if Marty was never born, and ceased to exist, he would still have been able to break his parents apart, since that happened. This model is mainly useful for creating tension and the need to fix the alteration in the timeline, but it is really difficult to make a really cohesive model out of it. In fact, trying to interpret time travel from this perspective is what will give you a headache.
Insensitive Branching timeline
This model is quite convenient, and has actual physics to back it up. Basically, if you change something in the past, you create an alternate timeline with your changes. This resolves the grandfather paradox. If you go back in time and kill your grandfather, you are now in a seperate timeline where you will never be born, and you are from the original timeline. If you do not change anything, then you stay on the same timeline. This is a basic, but robust, time travel model. You can change things back by going back in time, undoing the change, and then depending on the details of your model, you either transition back to the original timeline, or you have created a new timeline identical to the first.
The ontological paradox can be resolved by having the origin of the object in one timeline, which is sent back, creates a branch, in which the object is sent back to the moment of its origin in the timeline. Similarly, the predestination paradox can be resolved. You go back in time, and cause an event. This new timeline then something back in time, which cases itself. However, these are highly improbably outcomes to occur.
This model gets a bit weird when you try to consider multiple time travelers going to the same time period in different trips. If you go to a time later than they arrived, you will not see them, since they are on a branched timeline. If you go to a time prior to their arrival, you may see them arrive, depending on which side of the branch they create you end up on, and presuming you don't make any changes that will prevent them from going back. You can make the allowance that 2 trips ending on the same point will only form a single branch with the result of both trips.
Sensitive branching timeline
This is the same as the unsensitive branching timeline, with the assertion that the act of arriving in the past will is a change, and will create a branch. I find this much more likely than the insensitive model, and your very presence will exert a change, however slight. However, if you don't make a meaningful change, the new timeline will continue to be apparantly identical to the original one.
This has some interesting implications. Lets start with the base case of a single time traveler. He intends to go back in time, make some observations, and return to when he left. He goes back in time, and branches off a new, identical timeline. From the perspective of the original timeline, his trip was a failure. He does not return, and the traveler seems to have simply dissapeared, forever. From the perspective of the traveller, he went back in time, made no changes, and returned to his normal present.
Since this timeline was the same as the one he left, it also sent back a time traveller, and split off a child timeline. And so did that one. This creates 1 timeline where the traveller did not return, and an infinite number where he did return. If these timelines cause another similar journey, you have an infinte number of timelines where they had 1 trip successful, and failed, and an infinity x infinity number where they where both successful.
Branching and merging model
These infinite identical timelines are untidy and unnecessary. Let us state that two universes in an identical state will merge together. We can further loosen the bounds, such that any two universes which are close enough to identical that quantum uncertainty engulfs the difference will merge. Now, if you go back in time, do not make a meaningful change, you create a blip in the timeline. The timeline goes along smoothly, creates a branch where there are 2 timelines, one with a time traveler, one without, which then re-merge after the time traveller has left and the minute differences they made balance out. This mops up the infinite universes and makes it into a nice, clean structure. This creates 2 classes of time travel- blips and divergent. A blip creates a temporary disturbance which results in no real change, and remerges back in. A divergence creates a real change, that due to chaos theory will have far-reaching effects, and create an entirely different timeline.
If you assume that all the time travel in a movie is all that ever occurs, it is simple to map out the structure of the timelines. However, it is more likely that other time travel occurs, and the movie is only looking at a substructure of the time web. There would be a critical threshold, based on the likelyhood and prevalance of time-travel, where time travel is common enough, that each timeline has, on average, .5 or more child timelines, which will result in an infinite number of timelines. In such as case, improbable events will occur. Such as forming a ontological or predestination paradox. Somewhere within this structure, somebody sends back the plans to the time machine, which are built, and used to send the plans back to that precise instant, and a timeline with the ontological paradox is formed. This likelyhood can even be increased if you assume that it is a self-stabilizing phenomenon. You send the plans back in time, and they land in a general time slot. This is close enough to trigger the plans back to a similar time, and this is repeated with ever-decreasing variation until it locks in on a specific, stable timing.
This also handles multiple time travelers to the same era much nicer. All you need is a single acknowledgment- both halves of a blip are equally viable pasts. Both of them led to the present, so when traveling back in time, you arrive in both. So, if you go back to the earlier time, you create a blip to which they can land in, and if you go back to a later time, you land in their blip. This means there is a timeline where both travellers arrived, a virgin timeline where neither did, and a pair of timelines where only one did. Not all of these have to remain a blip. They can diverge. Blips can have sub-blips, you can have blip with a diverging timeline, divergent timelines can form their own blips.
It is also possible to re-merge a timeline from a divergent timeline. If the divergent timeline forms its own divergent timeline in such a way that it ends up identical to the source timeline, they can merge. This is the phenomenon you would see when someone "fixes" a broken timeline. What is more accurate is that they are creating a new timeline to remerge with the goal timeline so they can be back on the correct timeline. Once a timeline diverges, that split will always remain. There can also be any number of divergent timelines between the branch and the merge, resulting in some rather intricate scenarios.
This is a very robust model, since by looking at the proper subsets of it, you can create many classic sci-fi scenarios. You can find a subset undergoing a ontological paradox and/or a predestination paradox, and by looking at that part of the timeline have it appear to be unalterable. You can go back in time and change history, and then change it back. You can go back in time to stop someone from altering history, to provide back-up to existing travelers. From the perspective of the time travellers, only 1 timeline is "real", and so changing which timeline they are on is effectively the same as altering history for them. Terminator is fully supported by this model, as it is able to handle John Conner's lineage, allow them to mess around with the timing and development of skynet, and all the other monkeying about they do.
Also, consider that the universe started in a single state, the big bang. It also will end in a single state- either a big crunch or a heat death, either case results in a identical outcome, no matter how you arrived at it. Hence, the overall structure of the time web starts at a single timeline, ends at a single timeline, and has a lot of complexity and branching in the middle. Its a giant ball of timey-wimey stuff. It by itself is not enough to explain dr who- they have temporal locks and paradox machines and such - but it provides a robust base to build from if you want to try to explain everything, and matches their description of time quite nicely.
The sea of possibilities
Ok, this one gets weird. And considering that we are talking about time travel, that is saying something.
First, acknowledge that time does not really have a direction. At a fundamental level,past and future are the same, all of the base properties of the universe work in both directions. Second, everything is quantuum, and is a probability wave until you observe it. Observing a quantum state places a constraint on the universe that it must be consistent with that state. This is how entanglement works. You make it so that the state of two particles are related, even though neither is known. You observe one, and can accurately predict the state of the other one.
The entire universe exists as a probability wave until you observe parts of it. It must be consistent with what you observe. This includes the past. The past is not a definite thing, set in stone, as most people presume. It is a probability wave of every possible past that could lead to this present. The present constrains the probability wave. We have a ton of evidence of what happened. The banana in the kitchen, the wear marks on the keyboard, the fossils in the ground, whatever the past was, it led to all of these things. The world is filled with records of the past that constrain it. We know the holocaust existed, not because our text books say so, but because of the profound impact it had on the world. If you observe the past, you will find the holocaust there, or else the most elaborate coverup to perfectly simulate its effects.
Every possible past could led to the current moment is valid. Perhaps not equally likely, but possible. Past and future are symmetrical. Just as the present constrains the possible pasts, so does it constrain the possible futures. There are only so many ways the next few seconds could unfold, but the further away from the present you get, in either direction, the more possibilities are present.
When you travel back in time, you will end up in one of the potential pasts. This refocuses everything relative to your new time. As long as you do not take actions to drive the current state of affairs outside of the previous realm of possible pasts, it is possible to return. After all, someone randomly appearing in the middle of the desert and dissapearing is within the realm of possible events that led to the current moment. Your presence in the past is not automatically disruptive since your presence was already part of the probability wave. However, even if you stay withing those bounds, the future relative to you is still a probability wave. Your present is now somewhere within this probability wave, and attempting to travel back to the present will place you somewhere within those bounds. Hence, traveling to the past will result in you returning to a different present, even if you do not enact a change.
Furthermore, you will seethe same phenomena when traveling to the future. You refocus the probability waves on a point in the future, meaning the present gets lost in the probability wave of potential pasts, and traveling back in time will place you somewhere randomly. So, traveling to the future changes the present. Or rather, all possible presents are there, but you will end up in a different one, with is as close to changing the present as you can get in this model.
The grandfather paradox is meaningless. You don't even have a clear timeline, so going back in time and killing your grandfather cannot even be said to be on the same timeline as you. The predestination and ontological paradoxes are similarly meaningless without a clear timeline.
So, Time travel. Discuss.
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
I am particularly fond of the adventure game genre. It was rather popular back in the day, and I grew up with the likes of Space Quest and Gobliiins. I have gone through libraries of adventure games and played them, and it is fairly apparent to me how the genre grew and developed, both in technical advancements and in design principles.
The adventure game genre traces its roots back to text adventures. No images, just textual descriptions of what was going on. This is the era of Zork. You typed your commands, and it gave you back a description of what happened. Now, this isn't necessarily a bad interface, if done properly. Its commonly called interactive fiction for a reason, its like reading book, only you are interacting with it. The primary problem with the format is you tend to fall into "guess the verb" territory. You know what you want to do, but you have a hard time figuring out how to convey it to the game.You aren't even sure if what you are trying is the correct thing, so its hard to tell if there is even a verb to guess. A poorly written on can also be very obtuse as to what is going on. "open the door". "You cannot open the door". Well, why not? Can I not reach it? Is it locked? Stuck? Is it missing its doorknob? Is their an ancient warrior guarding it?
The biggest flaw in the older ones is that they are not always winnable on your first attempt. It is possible(easy, even) to maneuver yourself in a position from which you cannot win the game, but it is not obvious that this is the case. Sometimes you have to have prescient knowledge in order to solve a puzzle; you may have to leave a seemingly random item in a room, so you can find it there later. Sometimes you have a limited resource, like oil in a lantern, and if you fail to utilize it perfectly, you get stuck.
Then as time marched on, you started to get hybrid games. Technology was better, and they were able to attach pictures to their text adventures. You were still playing a text adventure, only there was a picture showing you the scene. This is the era where Time Quest was made. I don't think this was a widespread format, but Time Quest is worth mentioning since it also had a second interface revolution; it provided a list of objects and verbs. There was a list of objects in the scene you could interact with, taking out the guesswork of what elements in the description where relevant. It also had a list of verbs, taking out the guesswork there. Now, don't think for a moment that this made the game easy. The challenge is not in figuring out how to do something, but rather orchestrating the events. It did possess some of the earlier flaws, like being able to corner yourself in an unwinnable state and needing prescient knowledge of events, though overall it did this less than some of the older games. It shines as a good game despite those flaws, because it has really clever puzzles, frequently based on time travel. You have to orchestrate simultaneous events in different parts of the world, you have to utilize time travel withing the same area, you set up seeds in the past and reap the benefits in the future. It did time travel really well. And the final puzzles involves two pads, one sends you forward in time, the other back, and you go through this complex, but solvable, puzzle involving passing information and items to and from your past and future selves, and freeing yourself from the bad guy. It was brilliant and awesome. Of course, I may be biased since I am particularly fond of time travel, and I could write a series on time travel models and their implications, as well as having devised some of my own.
Then you get to the era of the text-parser graphical adventure games. Sierra was a big name in these, with the likes of kings quest and space quest. You have a graphical world, and you move around in it, but you are still typing your commands.This retains the "guess the verb" issues of the previous era, but they have realized that requiring prescience and being able to trap yourself in unsolvable states where a bad thing. They also had their own batch of common flaws. In particular, excessive death and arcade sequences. Excessive death was not new, many of the older games would kill you, but Sierra made it into an art. Its not even the death that was the problem. The deaths where creative and amusing, and came with amusing messages. Part of the fun was seeing how you could die. Even the first space quest had such an creative array of deaths, ranging from getting swallowed by a sand worm, getting split into several parts by walking through lasers, having your head dissolved by drinking from an acid pool, etc. The problem was this lead to the advice "save early and save often"m which you really had to take to heart. You die, and you go back to the last time you saved. Hence, you saved after you accomplished anything, and before you tried anything. Not exactly the best mechanic, but it was accepted. The graphical interface also lead them to include inescapable games of skill. In Space Quest, it was dodging rocks on a hover skimmer. Other games in the series had similar arcade sequences. Or places in-game where you have to walk. Precisely. Or die. most notable would be the root maze in space quest II. you have this alien plant monster with a a mazelike root system. You have to walk through it, and if you so much as brush against a root, you get killed. And it often goes at weird angles. You can't walk at arbitrary angles, so this leads to going up,left,up,left,up,left, very carefully to get through. Then you have to do it again to get back. Its frustrating. Its a challenge born from clumsy controls, which is never where the challenge should come from.
In general, you should have a consistent skillset required to complete a game. Most of an adventure game is a cerebral process. You are solving puzzles, figuring out how to combine items, set up a solution, and its a very relaxed pace. Suddenly having a high-speed, reflex based arcade sequence now requires a completely different skill set to complete.This throws down a huge barrier to completing the game, and will frustrate those without the prerequisite skills.
Then adventure games became point and click. Ridding themselves of the text interface completely, you merely have to click on what you want to interact with, using the proper ability. This removes any trace of "guess the verb", and instead introduces "Find the pixel" and "use everything on everything". Pixel hunting is the bigger flaw. You want to interact with something, but you can't figure out precisely where you need to click to do it. "Oh, I need to click on the parrots feet to pick him up". This issue faded over time, and people started designing the clickable areas better, and added in a changing cursor or other indicators that something could be interacted with. Lucas Arts games tended to give you a name of the clickable area when you hovered over it, making it clear if something was different to click on.
"use everything on everything" is more an emergent issue with how people react to the interface than a problem with the interface itself. Basically, people get stuck, and start brute-forcing the solution. Some games had solutions so obscure that this was the only realistic way you would solve them. That is a break down of the puzzle design. More on this later.
Most adventure games are what I classify as "inventory based", esp up to this time. You are mainly concerned with gathering items, and using items on things. The other type is "puzzle based", popularized by Myst. Your inventory is very limited, and generally not used to solve the puzzles. Instead, the challenges are more mental puzzles.You find clues, solve brain teasers, figure out how to work the control panels. As you may guess from the Myst series popularity(it was the bestselling game until the Sims came out), this is a very rewarding game style. There are also hybrid games, where you use an inventory for puzzle solving, but you also have a number of brain teasers to figure out. Sanitarium falls into this category.
Hybrid adventure games have formed the offshoot of escape games. Escape games use the same gameplay as adventure games, but strip out the adventure, proving that the gameplay alone can make compelling games. This is currently a popular genre on the internet, with countless games, though I have never seen one that wasn't free. The basic premise tends to be "you are locked in a room, escape", which you do by collecting a wide variety of items from within the room, solving puzzles, and making your escape. They are very light on story, and just focus on providing a puzzle for the player to solve.
What makes a good adventure game
I hold that there are 3 key elements to making a good adventure game.
1. Good writing.
The genre has its roots in interactive fiction, and was grown around the premise of telling a story. Adventure games do not have a backstory, you are actively progressing through the story. As such, the plot is important. It should be told directly in the gameplay as much as possible, which is very possible in an adventure game. Talking to characters, finding information in documents or computers, radio broadcast, the progression of the setting, all can be used to immerse the character in the plot. The plot can also help give the player goals. You need to figure out how to get into the bad guys lair, you need to befreind the witch, whatever. Good goals are related to the plot, not merely accomplishing arbitrary tasks. But the adventure game genre was designed to tell stories, so make sure you are telling a good one.
You also need good moment-to-moment writing. Depending on your game, this could mean different things. If you are doing a more serious game, then the writing quality can help set the tone, engage the player in the story. Just like a good book needs both a good plot and good writing to convey it effectively, so does a good adventure game need engaging writing. descriptions of items, conversations with characters, all need to be well-written. Humorous adventure games are also quite common, and can work wonderfully. The space quest series was quite amusing, day of the tentacle was a riot, Callahan's cross-time saloon was packed so full of jokes I don't know how they managed it. Seriously, you spend most of your time just looking at items because everything has an awesome description. You look at a post, and instead of saying "its a post", it goes into a long, humorous story about it.
2. Interesting settings.
Adventure games are a wonderful medium for cool settings. Myst was a master of this. The series was full of beautiful, fantastic worlds. Space quest had everything ranging from space stations and space ships, to a rainbow of alien planets, to the interior of the human body. Sanitarium offered several unique, interesting worlds. Kings quest lets you explore a magical realm. Sure, other genre's of games can benefit from unique settings, but adventure game's are uniquely suited to exploring the individual quirks of each setting.
3. Good puzzles
The puzzles are the gameplay. They need to be clever, and well designed. If they are too obscure, the player just gets stuck, and even after completing it may think "How was I supposed to come up with that?". This is a symptom of poor puzzle design. You also don't want to make them too easy, otherwise there is no sense of accomplishment. A good puzzle is one the player has to think about, but will solve. Part of this is providing them with the needed information. If you need to use the piece of metal to cut the rope, make sure the player knows it is sharp. You can simply call it a sharp piece of metal. You can have them accidentally cut their finger on it, or comment on the sharpness in the description, but the relevant properties should be knowable. You should also avoid needing knowledge from out of game. If knowledge of the greek gods is important, tell it to the player. This could be in the form of a book they can read, or a conversation with a character, but make sure they don't have to resort to Google. However, don't use such knowledge as an obstacle to the progression, since if they do know it already, they can circumvent the puzzles leading up to collecting that knowledge.
In general, there are 2 ways a puzzle can be designed. Either have it clear what the next step is, or have it possible to work backwards to a solution. These examples are somewhat spoilery, so if you don't want the puzzles in these games spoiled, skip over the examples.
Example of the first:
In Day of the Tentacles(great adventure game, btw), you find a bucket of soapy water and a brush. There is a dirty car in the driveway. Even though you don't know why you need to clean the car, it is an obvious thing to do. Cleaning the car causes it to rain, which is useful. And it makes sense in hindsight- it always rains when you clean your car. However, you would never think "I need it to rain, so I should wash the car". However, since it is such an obvious thing to do, it still works.
Other, simpler examples include using a screwdriver on the loose panel, a key on a lock, etc. You don't know why you need to open the panel or unlock the lock, but it is clear it is the thing to do.
Example of the second:
In Same and max, you need to give your past self an AI. There is an AI attached to your time booth. You can discover that the glue people use in the future is made by grandpa stinky based on his tar cake recipe, and hence that is what is holding the AI on the time booth. You also have a means of taking out a patent on something, if you have a sample. So, you take a sample of the tar cake, go get a patent on it, tell grandpa stinky he can't develop the tar cake, thereby stopping him from inventing the glue, and the AI device falls off, so you can give it to your past self.
In general, the latter is the better design. However, you must make sure you have all the clues needed present for the player to work out what needs to be done. It also allows the player to think "Oh, I just need something to cut this rope with...", so when they find the sharp piece of metal, they know what to do with it, and can execute the chain of actions, which is very satisfying.
You also need to ensure you don't let the player's trap themselves in an unwinnable scenario (this is a general principle, and not exclusive to adventure games). For instance, if there is an item you will need later, but is located in the current scene, you must ensure that either 1. They must have the item before leaving the scene, or 2. they have a way to return to the scene. If going with 2, make sure that going back to an earlier scene to get something is clear. Don't make it so you need to find the security card under the rug, there is no good way to tel that you need to re-explore an old scene to find something hidden. However, of there is an umbrella stand with umbrellas, and the player knows they need an umbrella, then the expectation that they will realize there were umbrellas there is not unreasonable. As for 1, there are several ways you can ensure it. The first is to require them to use the item before leaving the scene. If it is needed to leave, then they are sure to have it. The second is to make sure they get it at the same time/before a needed item. For instance, if you will need the towel later, and the key now, you can put the towel and key in the same drawer. You then have 2 options. You can make it so taking items from the drawer takes both, or you can make it so the key is under the towel, so you must take the towel before finding the key. Don't simply put them both in the same drawer. It is perfectly possible for them to grab the key, but not the towel. Even if it is unlikely, it is possible. For a similar reason, don't use a piece of knowledge as a prerequisite item. If the 4th symbol to the combination lock is under the towel, they could manage to guess the 4th symbol, and progress without the towel. The last method to ensuring they don't leave having them refuse to leave. "I can't leave yet, I still need something". This works, and is used, but it is not a very good design. For one, it is very arbitrary. It leaves the player wondering what they need, and why the character knows they need it. They also are left with not clue what they are searching for. It can be done well in some cases "I can't leave for the airport without my wallet!" This makes it clear why you can't leave without it, and what you need.
As part of "don't trap the player in an unsolvable state", keep information that the player needs accessible. For example, if a character tells the player a password, don't rely on the player remembering it or writing it down when it is said. Make sure there is some way to access it. That could mean the player can ask the character "Hey, what was that password again?", which at the very least keeps the avenue of information open. What can work even better is if the player's character will remember it. This could mean writing it on piece of paper which is added to the inventory for future reference, having a specific Notes functionality built in to store conversations and codes, or even having them enter the password themselves. This has the advantage of keeping the information available, even if accessing it's source is not practical, and it adds a convenience factor. How precisely you handle it depends on your precise design. Entering a code you already know isn't exactly thrilling gameplay, however knowing that you need to use that code on that keypad can be part of the puzzle. Manually entering it also opens up more possibilities to introduce a puzzle between the given information and what must actually be entered.
On the subject of entering codes, the interface to do so should be convenient. Letting the player simply type it in, even if it is primarily a point and click game, is the most convenient. However, if the game is mouse-driven, the keyboard should never become necessary, but it can serve as a convenient alternative. a clickable numpad is intuitive and easy to use. A click-to-increment digit counter can be annoying. This is where you have digits(or letter) of the code displayed, and by clicking on them you can increment them forwards. However, even on a basic numeric code this is somewhat annoying. The code 5283 takes 4 clicks on a numpad. It takes 14 on a click-to-increment counter, assuming no misclicks. If you click once to many times on any digit, that is an extra 10 clicks. This is even more annoying if you have letters, or even worse an alphanumeric code. If you involve capitals, the number of clicks quickly balloons. Having arrows to increment or decrement the digit helps, vastly reducing the penalty for a misclick and allowing digits to be selected backwards. This makes 5283 into 9 clicks. Still, Its not exactly a great interace, though it is woefully common in room escape games. The increment/decrement with pure numbers isn't too bad, though.
Additionally, if the code entered is in any way "constructed" from clues, keep the code persistent between being entered. If you are finding clues like "the 3rd digit is 5", then let the player keep their notes directly on the lock. Let them go in, set the 3rd digit to 5, and leave, and have it stay set till they look at it again. For any combination, always consider whether it is better to present the player with a clean slate to enter the code from scratch, or to give them a persistent code to toy with. Both have their place. A reset button is also convenient way to reset the code to its default state, allowing you to get the benefits of a persistent code, while keeping the benefit of a fresh slate. Esp if the puzzle is one where returning to the default state is tricky, having a reset button is a huge convenience.
Game Design Theory 8 - Level design