Most of the time, it is because they have game ideas they want to make. Game developers tend to be driven by the need to create. I got into game development because I wanted to make my own game ideas into reality. Almost every developer I know had some variation of the same motivation - they wanted to make their own game ideas into reality as well. Everyone, from the freshest junior hire to the most experienced veteran, has their own game ideas that they want to make.

Unfortunately, the actual opportunities to your make your game ideas a reality are few and far between. Game ideas are cheap and plentiful; everyone has at least one and many of us have far more than just one. Building out and developing an idea, however, is expensive. It takes time, it takes money, it takes a lot of experienced and skilled people working very hard together in order to make it real. The cost (and therefore risk) of building a game is often so great that such opportunities are only offered to the most trusted of senior developers. The number of games that the biggest publishers put out each year is several orders of magnitude smaller than the publisher's number of game developer employees. Big publishers will employ thousands of developers and yet often put out fewer than two dozen new games in a year. The opportunities to even be allowed to pitch are typically reserved for a very select few.

So... if you aren't one of those "most trusted" developers to the publisher executives and still yearn to create your own game, what recourse do you have? If no one will give you the green light, you make your own green light - you take the risk on yourself (and maybe some trusted experienced game dev friends), persuade some external investors that you're trustworthy, and you try to build your idea out. That's often the reason for the creation of a new studio with a new game project.

That said, there are also other reasons for veterans to start a new studio (albeit usually without as much fanfare). Some studios start because their founders are skilled but tired of the individual crunch and the grind of working for huge corporations. Instead, they build their own studio and offer consulting/contracting services to their former overlords, getting in on some of the ownership while retaining their own freedom and company culture. These contractor studios often specialize in certain fields (e.g. [rescue operators], art asset creation, porting an existing game to a new platform, etc.) and function as squads of game dev mercenaries brought in to fill specific gaps in the development team of bigger projects.

Starting a new studio is generally an opportunity to do things the way you want them done. This can mean working on the game idea you want to make, setting the inclusivity policies you want to set, establishing a worker-owned collective like you want to establish, have the work-life balance you want to have, fostering the company culture you want to foster, and so on. It's an opportunity for a fresh start. I'm sure that you can see why grizzled veterans might see that as a risk worth taking.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

askagamedev:

Welcome to Harder Than You Think, a series about things that seem fairly easy to an outsider but can rapidly spiral into extremely complicated or expensive behaviors. Today, we’ll be talking about ladders and how they can cause all sorts of weird bugs in a game.

Ladders are another common game feature that tend to cause all sorts of animation and game state problems. Unlike elevators, ladders do not require a complex state machine to govern. Most ladders only have one top and one bottom, without needing the player to exit the ladder in the middle somewhere. Ladders are often variable in length but not totally variable in length - you can’t have a ladder that’s shorter than the characters climbing on it or the animations wouldn’t work, but you can have a ladder that can be as tall as you want. 

Ladder interactions generally consist of three game states:

1. Mounting, when a character transitions from the standing state to the “On The Ladder” state. While in this state, player input is typically taken away from the player and a mounting transition animation occurs.
2. On The Ladder, when a character can loop through climbing up or down animation cycle to move. While in this state, player input is typically limited - players can only navigate up and down the ladder and may have limited ability to engage in combat or take damage.
3. Dismounting, when a character transitions from “On The Ladder” back to the standing state. Like the mounting state, player input is taken away here.

One of the big potential bug generators with any kind of game dev is when we take player control away from the player. In any edge case where that control is not restored to the player at some point, we have a soft lock. If the game state changes or there’s an unaccounted-for issue (e.g. the player is not flagged for invincibility while mounting or dismounting), an enemy that attacks and knocks the player out of the (dis)mounting animation or kills the player, player input must be explicitly returned or the player will probably soft lock. Further, all of these types of interruptions can cause animation issues as well - a character getting killed while on the ladder will likely require a specific “damaged or dying on a ladder” animation, which can start ballooning scope depending on additional factors like the direction of the damage source and type of damage. Some common solutions to these problems are making sure there is no combat near ladders or making the player immortal while on ladders. 

Ladders are also incredibly bug-prone if AI can use them. The ability to knock enemies off of ladders, for example, can make the AI look terrible and create invincible choke points in the level design. AI on ladders can cause weird interactions with other systems like if, for example, [the player starts a cinematic]. But the worst case scenario we see most often with AI on ladders is when a ladder traffic jam occurs and we have two entities who want to go in opposing directions on the ladder blocking each other. We could let them clip through each other, but that often looks hideous. If the player has more than one AI buddy, we often have to let the AI buddies teleport to the player in order to bypass these kind of potential traffic jam issues. 

As you may have surmised, ladders will also cause issues in a multiplayer environment. Many of the issues with AI also apply to other players. Further, there are potential griefing issues if players cannot clip through each other and decide to block off ladders physically. 

These are just a few of the potential issues that can show up due to the ingredients it takes to make a ladder. Each ladder is a blend of taking varying amounts of player control away and returning it, clipping and blocking issues, AI issues, level design issues, and potential bad interactions with many other game systems for a seemingly innocuous system. These are some reasons why making ladders work in a game is harder than you think.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

askagamedev:

Welcome to Harder Than You Think, a series about things that seem fairly easy to an outsider but can rapidly spiral into extremely complicated or expensive behaviors. Today, we’ll be talking about elevators and how much of a rat’s nest they can be.

The first thing to note about elevators in video games is that many video game elevators are actually not actually elevators at all, but teleporters. When you walk up to the button and press it in game, it often gives you a list of floors you choose from. Upon choosing it, the screen fades to black, and then it fades back in with your character at the new floor. There may be a pause and some sound effect played, but there is no actual movement across space. The elevator is merely a facade for a teleportation button. I’ve heard these occasionally called Wonkavators because “ …elevators only go up. The Wonkavator goes up, down, sideways and every other which way you can think of going.” The teleporter allows designers to conveniently sidestep issues of making environments have to fit within a contiguous space, and instead magically join two discrete points, potentially within the same environment, just physically separated so that the teleporter is the only way between them.

One major reason for this is because non-teleporting elevators become an absolute nightmare in multi-user environments. Since there are potentially multiple people who could all try to use the elevator at the same time, we essentially have to construct an actual elevator with a queueing system where users at different floors request a pickup, and then users inside the elevator request floors to arrive. The elevator itself has to remember its movement direction, and all of the requested floors in each direction in order to decide which floor it needs to go to next. As a coding exercise, try writing an algorithm for common elevator behavior in a ten-floor building. It is no trivial task! One studio I know would use this as a programming test to see how well engineering candidates could parse the nuances of a complicated control scheme.

The vast majority of non-teleporting elevators in games are one of two types - they either only have two locations they can visit, or they will only cycle through their various destination heights over time without player input. This is because things start scaling out of hand if the elevator can reach multiple destinations from each source. In most cases, each elevator floor can (usually) reach every other elevator floor except the one it is currently on, which means you have a N(N-1) number of connections to set up. Two floors is only two connections, but connecting six floors requires 30 different combinations and ten floors will require 90. Moving elevators can also cause all sorts of weird physics problems because the character is no longer on solid ground. The elevator must move the characters smoothly, which has its own set of simulation and physics problems.

Finally… elevators are often not particularly engaging gameplay. In this situation, an elevator is the thing that moves players from point A to point B. The majority of the time players are not going to find anything interesting or compelling about interacting with an elevator. It’s often just a means of gating the player to keep them from reaching some other element of the game until a certain point, and these kinds of gates should probably not suck up a huge amount of your development resources when they could much more easily be spent on the content and systems actually meant to be engaging. It’s hard to make an actual elevator fun. Most of the things we can do to make elevators more engaging involves gameplay elements other than the elevator itself, which still requires a reasonably significant amount of complexity. This is why elevators tend to be extremely simple and basic in games.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

Sure. When designing a puzzle, a designer must think of the process by which the player interacts with them. Specifically, there are four steps:

1. The player sees and recognizes the puzzle goal
2. The player discovers the clues/objects needed to solve the goal
3. The player associates the relationship of the clues with the puzzle and each other and works out potential solutions
4. The player solves the puzzle with the proper solution

The designer must make it clear to the player what is happening and what to look for each step of the way. This means that the designer needs to clearly establish context for all four of the elements above. More specifically:

1. Show the player the goal - a locked door, a treasure chest, an object they want, etc. - but also clearly show that it is not immediately attainable.
2. Place and advertise the clues to the puzzle goal within the environment. This can be subtle or it can be obvious, depending on whether the puzzle is optional or part of the critical path. 
3. Provide a way for the player to experiment and learn how the clues interact and behave. This doesn’t have to mean that the player can make attempts until they succeed, but it does mean that they get enough tries with the puzzle to learn the rules.
4. Create a solution for the puzzle that isn’t too difficult or too easy for the challenge level the designer has chosen.

These are the basic elements that a designer must create in order to make a good puzzle. Missing one of these elements is a recipe for player frustration, and that is something we always want to avoid.

The second layer of designing a puzzle is deciding on the distribution. Puzzles have two primary elements to them - discovering the clues, then using clues to solve some sort of pattern. Some puzzles are 100% clue-finding, such as “find the key to unlock this door”. Some are 100% pattern-solving, such as the Tower of Hanoi. Many are a combination of the two - e.g. the player can play around with this pattern, but is missing a critical piece to finish it.

When designing the pattern, make sure that the pattern is clear and makes sense once all of the pieces are known. If the designer presents a pattern or set of rules to the player for a puzzle, it’s a promise that those rules will be followed. A good puzzle design will let the player make certain assumptions and have a way to test those assumptions. The solution should require some kind of non-obvious, lateral thinking that still satisfies the rules that the designer has set. If the solution breaks the rules or pattern, it will be extremely frustrating to the player.

A good designer will also use multiple solutions to the same puzzle judiciously. Under such circumstances, it’s important to communicate to the player that there are more than one solution and which solution each clue belongs to. Otherwise, the puzzle can cause frustration by making players think that they are missing something when they aren’t, like the nagging feeling one gets when there are leftover parts when building something. One good strategy in puzzle design, in my experience, is to provide a secondary optional bonus puzzle that uses the same rules as the puzzle on the critical path, but provides some additional content or reward to the player for completing it. 

Remember the fundamentals of puzzle design when constructing them. They might seem obvious, but it can be extremely easy to skimp or skip in the creation of one or more of those basic elements. It’s important to get playtesters who aren’t familiar with the puzzle to test it, especially noting any frustration points. Show the player the way first, point out the necessary elements to complete it, and then let the player make those connections and solve it.

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent questions: The FAQ