McJobless's Design Lessons

[McJobless]

WARNING: This is a WIP. I'll add to it as I go along. For now, I've done a little bit but it's still a long way to go. I look forward to your comments and hearing anything you want to add. A lot of this will be based on what I learn from my own Game Design lessons, Gamasutra, Extra Credits, the portfolios of highly respected Game Designers and far more places.

 

---

Game Design is potentially the most important aspect of the entire development process. Hell, it has its own section called "Pre-Development" and then some. Yes, content creation, QA and other sections of the design time are important, but the idea is that, if you want to be successful and make a kick-ass game, you're going to need to plan and plan and plan out everything before hand.

Game Design, for me, is the essential knowledge, tools and theories that should define how a professional and non-professional Game Designer works and what they aspire to. Depending on studio and personal interpretation, Game Designers are the multi-tasking grunt force of any development studio, and their tasks can range right from leadership, to story, art, music, level production and far onwards. Basically, Design is so many things, it'd be better to make a list of what's not considered design.

When we design games, regardless of what position you hold, there are some fundamental concepts we all must consider, especially in a new age of design where we are further trying to integrate the three waring fronts of story, gameplay and graphics/art style. Having these kinds of things in your head, will always help massively.

Concept A - The Core Elements of a Game

Day One, Lesson One of Game Design is this. The distinction between a game and simple entertainment is that a game has some very core elements that must always be present for any medium to be considered a game. A game has elements that give the player constant motivation to want to continue. Video games share the same elements that make up board games, card games, sports and any other type of game; the only difference being the use of technology to control, present output and take input from the player.

Without these elements, we are no longer making a game and are instead making an experience. While an experience can be life-changing, fun, unique and many other things, it does not share the same level of re-playability, learning and engagement that a game does. Games are all about teaching our players to play, and watching them master the game and become proud of what they have achieved. An experience does not have the same impact.

There are two categories of these crucial elements; Objective and Subjective. Objective Elements are those which are crucial to any game being considered a 'game'. Without objective elements, these experiences fail to teach players or give them the space necessary to interact and blend in with the mechanics. Subjective Elements are like spices; we use them to enhance the experience and give even more motivation and fulfillment to the player, but they are not necessary for a game to be considered a game.

Objective:

1) Goals and Objectives - The game must present a clear winning condition, and must offer subsequent tasks that must be completed in order to achieve the winning condition. Multiple objectives means there is more gameplay and challenge, and thus increases the play length. Objectives can sometimes be a natural part of the gameplay.

2) Rules - The player of a game must never be allowed to completely break the game by doing whatever they want. There must always be limitations which block the player from just finishing the game instantly. Rules may also add challenge naturally or may allow for clever players to exploit loopholes in the rules, and increase the fun the player has. Some rules may need to have exceptions as dictated by the gameplay scenarios.

3) Obstacles (Including Failure States) - The main means of creating challenge is to introduce certain obstacles which the player has to overcome in order to proceed through the game. There are many forms, and the goal is to ensure there are multiple types of obstacles, so that the gameplay is always refreshing and never becomes boring. Failure Statues are the idea that the player's progress needs to be impeded in some form for failing the game in some way, including losing or dying. Punishment may be in more forms than just a simple game-over, such as implications for the story or removing player rewards. The idea is that player should feel encouraged to learn from their mistake and improve, and with practice from replaying eventually master the game.

4) Boundaries - There needs to be a defined play field for all players. Players must not be allowed to break out and exceed the limits of the game world. One may define that the entire universe is the play field, but this still counts as an acceptable limit.

Subjective:

1) Engagement - How the player actually engages with the game, and what kind of experience, feelings, emotions and lessons they take away from it after they finish playing.

2) Visual - How the game looks, or doesn't look.

3) Audio - How the game sounds, or doesn't sound.

4) Player Input - How the player actually interacts with the world.

5) World Output - How the world responds to the player and notifies the player back.

The concepts themselves should be simple enough to understand and apply. Remember these, and you will have the power to turn any form of interactive entertainment into an actual game, and a fun one at that.

Misc - Some General Wisdom

I leave this section for my own thoughts and anything I've heard from other game designers which should help you on your journey.

- The game should never feel so hard so to make you frustrated and quit. It should be at level where you feel as though if you had done that one thing slightly better, you would have succeeded, because that creates proper challenge and tension.

- Ken Levine has stated (in better words) when asked "When did you become a Creative Director", he said something to the effect of "I just started calling myself a Creative Director and kept on making things."

[McJobless]

Concept B - Core Concepts v. Core Mechanics

Any single game can have its components split into four categories. We're going to talk about the other two later, but the main ones define the very core of the game. The Core Concept and the Core Mechanic will define your game, and be your significant focuses for most of preproduction.

Core Mechanics

The Core Mechanic is, for most us designers, the big element that we spend hours, weeks, months, years refining, and will not stop until it's perfect. The Core Mechanic is the element that makes the game fun for the player. It's a repeated action that the player MUST rely on to complete the game. Unlike any other mechanic, if you removed this single one, there would be no way for the player to finish the game.

Core Mechanics, believe it or not, are mostly developed from much more basic, mechanic-only forms of games. While this is not always the case, the idea is that the board game or physical game can be used to test and produce a prototype of your game which you can test to see if it works and if it's fun, before even touching code.

Here's some examples of how gameplay core mechanics have evolved:

• DOTA/WoW/LoL etc: The Core Mechanic is Movement. You must be able to move around and progress to the end of each environment. This has evolved from Chess.
• Super Smash Bros. Brawl: The Core Mechanic is Fighting. You must be able to attack players to finish each level. This has evolved from Martial Arts.
• Ratchet & Clank 3: The Core Mechanic is Gunplay. You must be able to shoot enemies to finish each level. This has evolved from Paintball/Laser Tag.

One interesting note to make; consider what the core element of Counter-Strike is. It's also Gunplay. Now, compare how Ratchet and Counter-Strike both turned out. Separate games with highly different gameplay and aesthetics. With that in mind, you can see that, it's fairly safe to discuss your Core Mechanic in public, since it would require significant luck for somebody to accurately understand how you want to use your mechanic.

One thing you should consider when deciding on a Core Mechanic, is that the more human that Core Mechanic is, the more fun it will likely be for the player. Our examples above were all fairly human things; moving, fighting, and using tools.

Unfortunately, one Mechanic a game does not make. In order to make the game interesting, you need to add variable to the Core Mechanic to alter the effect. Furthermore, other mechanics (known as Variable Mechanics, which we discuss later), all build off the Core Mechanic. Everything is intertwined and works together to build an experience for the player.

The sad fact of life is that, while the Core Mechanic is designed to KEEP players playing the game over long courses of time, players will hardly recognise this Core Mechanic, and may suggest that anything else is what keeps them around. We call the Core Mechanic a DESIGN ATTRACTION; something that entices game designers and other developers, and for players is the below-the-surface entertainment factor.

Core Concept

It's an unsung rule in Game Design that you have 15 minutes to hook a player. Marketing will insist that you have something to entice players. For your game, the Core Concept is the lure that will bring you the audience. We call this our PLAYER ATTRACTION.

Your Core Concept is whatever brings players to bring your game. It may be the story. It may be the audio. It may be the graphics. It may even be something you don't make yourself, such as controversy. It's an intriguing idea, and therefore it can take a lot of work to make it interesting.

The Core Concept is highly subject, and it's usually related to the zeitgeist (not the Jews) of the time. For example, up until recently, Zombies had a massive pop-culture rebirth, and a significant number of movies and games were created around Zombies. People want to read/watch/play what they're emotionally attached to, so remember to think about the historical, cultural and technical contexts of the time before making your Core Concept.

[McJobless]

Concept C - Variable Mechanics & Keystone Variable

This lesson will be tiny, since the next one is going to be an absolutely head-buster when you get to it.

As I stated in the previous Concept, we had two more types of categories for elements of a video game. These two are more subjective, and are there to add spice to your gameplay.

A Variable Mechanic is any mechanic which is not part of the core, but instead builds of it. Imagine, if you will, a tree, with "Movement" at the base. Movement, in this example, is our core mechanic. Sprouting up from it are various branches, which are the variable mechanics that introduce slightly new gameplay aspects. We might have combat, or tower placement (in a Tower Defense game) or anything else which is not central to the game, but still is a mechanic players may use to help win.

A Keystone Variable is not a core mechanic. The distinction is very important. A Keystone Variable is like a variable mechanic in that it branches off the core mechanic, but unlike a variable mechanic, this one changes gameplay in a MAJOR way. For example, something such as a timer, or the gel in Portal 2, which changed the entire way the player had to think about the gameplay.

The most important thing to remember is that you must always perfect the gameplay mechanics first, before working on your concept. The gameplay is what will hold the player, even if the game's concept is a bit lacking (for example, look at Minecraft's popularity in an age dominated by legions of "HD-ONLY NUBZ").

 

Concept D - Skill/Experience Loops

I'm probably about to explode some heads with this one.

What actually makes a player continue playing the game? What makes a mechanic good? There needs to be some kind of measurable quality. This is where a Skill/Experience Loop comes into play.

A game is a form of entertainment. Good entertainment needs to do just that; entertain. When it fails to entertain, it enters a state we call "BORING". This is when our mind believes that we are wasting our time. The mind is always attempting to seek out patterns, optimise and create efficiency in our everyday tasks. If this becomes too easy for the mind, or if it cannot grasp any kind of meaning or point behind a task you are attempting to perform, it will enter boredom and try to find another task to complete.

The question then is, "How do I keep my player entertained and not bored to tears?" The answer to that question is a very big, key word that you should remember for the rest of your life.

 

ENGAGEMENT

How do you believe sport players, musicians, artists, directors and so forth get good at what they do? Engagement. The idea is that, the more engaged you are in something, the more you strive to work on it, and with practice, the more successful you will become. Now, while games aren't exactly all designed to teach, we should nonetheless strive to make this the point of games; to keep people engaged with the material long enough so they keep on playing. For those of you who know anything about psychology and game flow, this is where it comes into play; you're striving for complete engagement to the point where the player doesn't just suspend disbelief, but also loses track of time and reality.

Now, that's all fine and dandy giving our games a point, but how exactly do we, well, do that? The simplest (sort of) way to do that is with a diagram. Please note that the terms in this diagram have a variety of different names. I'm going to use the ones I feel are best suited to the content.

 

The red arrow denotes the starting point.

You're probably super confused right now. Allow me to explain.

This little diagram is called a Skill/Experience Loop. You can also call it a "Beat". These beats are essentially how every single player choice in the game, from moving left to shooting a gun to turning a key, should be all broken up. Let's go indepth:

• Personal Objective - You may refer to this as a Schema or Model or even Confidence. Basically, "Do I know my reason for being here?"/"What's the point?"
• Options & Inventory - You may refer to this as Actions. Basically, "Do I know what I can do?"/"What can I do next?"
• Rules, Limitations (and Implications) - You may refer to this as Resources. Basically, "Do I know what I can't do?"
• Immediate Results - You may refer to this as Feedback or Evocative Stigma. Basically, "Did it work?"/"How do I know it worked?"

Each of these different points break down what exactly the player is consciously/subconsciously thinking everytime they perform an action in the game.

Think of it this way. When I shoot a gun in Halo, my thought process is broken down like this:

• Why am I here? Why should I continue to progress?
• There's enemies. How can I deal with them?
• I know how to use the gun, but what ways can I not use it?
• Okay, how will I know the enemies is taking damage/dead?

This happens for EVERY single player action. It's quite a lot of work on the brain, and it's even more work for the game designer, since we need to make that entire beat interesting.

The challenge to making a successful Skill/Experience Loop is that you can't keep pulling them through the same loop over and over again. This becomes quite repetitive, and as the brain begins to establish the pattern, optimise and decide it's pointless to repeat the action, the game will become boring. We need to keep on changing the beat with variable mechanics and different kinds of beats so that our player is always tackling the same beat over and over again.

For example, in Halo, the game introduces new weapons, enemies and locations to constantly vary up what the player is doing. The Assault Rifle and Pistol act very differently, and the player is going to see a different set of Options and Limitations for both. In Chess, it's similar. Every different move becomes a new beat, because the board is constantly changing. Since nobody can forfeit a move, everyone has to move a piece, and with every piece moved, the game changes slightly.

By successful allowing players to keep running this loop, and varying the beat in different ways, players continue to become more and more engaged, as they try to master the gameplay. Because you keep changing the beat, gameplay never stagnates, players are always offered more and more chances to become better at the game. Players won't play a game if it makes them feel stupid. If you're smart about how you introduce mechanics and how you use the beat, your game will encourage learning, and will allow the player to get better and feel smarter.

Furthermore, remember the first part of the loop? It's the "Personal Objective". Therefore, we need to find a reason that's important to the player to make them enter the beat in the first place. This is where our Core Concept comes into play, as story, graphics, audio and other elements can all give the player the motivation they need to push forward through the game. For example, a very "primitive" objective in video games is "Capture the Princess". That's how a lot of players got into Mario and Zelda, but for some, it was less about what was in the game, but more what was outside it.

Your Personal Objective, or in fact the entire beat itself, can occur outside the game. Remember when somebody you know told you about that high score they achieved which made you jealous? In a lot of instances, that's enough to make a player go through the game and enter the beats, simply because they want to become good enough to show off. You should never underestimate mind games or the power of communication.

Keep in mind, however, players can and will get bored if your Skill/Experience Loop is not enough to engage the player. If the beat is easy to master, then players will become bored quicker. In a simple game experience, such as Fruit Ninja or Flappy Birds, you need to constantly update one of the elements of the beat. You can't get away with tiny changes either, such as making a weapon slightly slower or faster. In these kinds of games, you need to introduce big new elements constantly to keep the game fresh and fun.

Many of you are probably thinking of the beat as a simple circle. Instead, consider it as more of a spiral shape. If the beat begins to get smaller and closes off (as player investment is getting lower and lower), it's possibly because you are coming to the conclusion of your story for the game or the end level. Meanwhile, games like Minecraft that offer infinite experiences maybe have giant spirals that never close off.

 

Misc - Some General Wisdom

• A good game designer is one who is able to finish a project and plan out everything first. Planning is protection against the unknown, such as budget problems, real life problems, technology failures and so on.

[lol username]

Many of you are probably thinking of the beat as a simple circle. Instead, consider it as more of a spiral shape. If the beat begins to get smaller and closes off (as player investment is getting lower and lower), it's possibly because you are coming to the conclusion of your story for the game or the end level. Meanwhile, games like Minecraft that offer infinite experiences maybe have giant spirals that never close off.

Oh, my brain is gonna be chewing on this all day. Thanks.

[McJobless]

I'm prepared to make hundreds of heads explode now.
 
For those who are actually interested in game design; these lessons, starting from Experience Loops, have all come from Daniel Cook, who is an INCREDIBLE game design teacher. I'm simply rewriting his lessons into words that I can understand. If you'd like to go far further indepth than I would, I recommended you watch the YouTube video about his IGDA presentation which covers all this, and then have a look at this amazing website.
 
Concept E - Skill Chains
As we established in the last concept, Experience Loops are what keep the player engaged with our game. Unfortunately/Fortunately, though, it goes a lot further than that.

We're going to discuss scenarios further down, but for the moment, consider this: everytime a player enters a "scenario" (some kind of predetermined instance where the player must perform set actions in order to continue onwards, such as killing enemies or moving to the end of a platforming challenge), the game design must present some form of obstacle that the player needs to overcome. Enemies, platforms, time limits, you name it. The key to these scenarios is that they are designed to test the player's mastery of certain types of skills within the game.

However, what happens if the player hasn't been trained in those skills? Of course, they fail. When a player fails over and over without understand what is going wrong, they will get bored. When they get bored, they quit. We cannot, as game designers, allow for this to happen.

Luckily, there's a fantastic way around this. It's called a "Skill Chain". Observe the following diagram:
 

This diagram shows you the Skill Chain from the original Mario. To explain it, I need to explain what the two kinds of skills are:

• Atomic Skill: A low level, simple skill that is repeated often.
• Combination Skill: A high level skill that requires multiple Atomic Skills to be performed, and is usually only repeated once in a while.

The two lower skills, "Move" and "Jump" are both Atomic Skills. You learn these quickly, and they are repeated frequently throughout the game. The next level up is a Combination Skill. Killing a Goomba is still an action/skill, but to complete it, you need to be able to both move and jump.

Every single skill is its own Experience Loop. What that means is that when a player performs an Atomic Skill, the player is subconsciously going through the entire loop once, and when they go through a Combination Skill, the player is going through multiple loops at the same time. This is why it is EXTREMELY important to make sure that your core Atomic Skills, such as movement and jumping, are like a good song. No matter how many times you play them, they should never get boring. Refer to the Experience Loops section above for ideas on how to make a loop good.

From a level designer's perspective, this Skill Chain gives you an entirely new, valuable way to look at designing levels. Your whole goal of designing a good level is to start SCAFFOLDING up these Skill Chains, by slowly introducing the player to new concepts, and allowing them to master it. Eventually down the track, you then introduce new skills, and then after the player has mastered them, introduce the idea of using them together. A very good example of this is Portal 2, in how it introduced the Portals, allowed them to master the logic of Portals, and then introduced Gels and got players to master those, and then allowed players to use and master both simultaneously.

Concept F - Arcs
Experience Loops are fantastic, but they leave a big problem. Experience Loops are, by nature, designed to be "Interactive Mastery Scenarios". The idea is that they are designed to allow a player to build skills, master them and have fun while doing so. This doesn't work with elements such as story, or ending the game, however.

An Arc is a content-delivery system. Essentially, an Arc is a broken Experience Loop. They have the very same structure, but where as an Experience Loop actually continues to loop until the player has finished, an Arc ends, and that is it. It'll look something like this:
 

You might question why we would bother adding Arcs to games, if we want players to master skills, as that's the way to have fun. The big problem with Experience Loops is that very part of the loop; "Personal Objective". To get somebody inside the game, they need to be enticed by it. They need what we call an "Evocative Stimuli".

To understand Evocative Stimuli, we need a quick lesson in how the brain functions:

• When we perform an action, that action is recorded in our mind as a memory.
• As the brain stores that memory, it tries to sew it up with a string of connections. Those connections all link to various elements, such as "colours", "actions", and more importantly "emotions".
• Whenever our brain is put into a situation when it needs to think quickly, such as playing a video game, and the brain needs to recall something, it doesn't have the time to full play out the memory. Instead, it looks at the emotional connection so that it can make a quick judgement on what the person needs to do in response.
• Evocative Stimuli attract a lot of emotions. These stimuli, upon being called, give players a "jolt of energy", and allow them to effortless make a decision on what they need to do. The stimuli itself can be anything, from visuals to audio. The only problem with it is that it truly is a "jolt". Once a stimuli has been triggered, it cannot be triggered again. It's a one-use yet powerful MultiTool in our arsenal of design elements.

Consider a book, for a second. Books are just a series of Arcs. They are constantly delivering you Evocative Stimuli in order to keep you engaged. The problem with this method, however, is that you become tired of it quickly. We call this "burning out", since you've become so overwhelmed with Evocative Stimuli, it no longer has any effect on you. Without anything to break up the monotony, there's no chance your player will want to stick around.

Arcs are not designed to be major gameplay elements. They don't loop, and thus, don't repeat. Think of them as cutscenes, ending a game, and elements such as that. Their intention is to give the player a boost of motivation so they can push on with the Experience Loops.

Concept G - Architecture and Frequency of Loops and Arcs
As you've noticed, everything so far has weaved itself so perfectly into each other. We've looked at the very microscopic elements of a good game, and worked our way up.

In the last concept, the ending was rather abrupt, but that was on purpose. The previous lesson introduced you to Arcs, and their core problem. This one will show you how to use them properly, as well as Experience Loops/Skill Chains.

To make an engaging experience, we need to be able to effectively switch between giving the player interactive mastery sessions (Experience Loops/Skill Chains), and giving them content that motivates and entices (we cover these soon) them to continue (Arcs). The creation of a pattern of these is called an Architecture. A simple level Architecture is shown below:
 

(The sandwich means that you've sandwiched a Loop between two Arcs)

 
The player starts with the first arc, which gets them excited with an initial burst of content delivery. Then they play the central Loop several times allowing them to master a skill. Finally, they hit the Conclusion Arc, which wraps up the story nicely.

This very simple Architecture is enough to give the player constant engagement across that level, provided your core elements (Mechanics and Concept) are interesting enough. So long as you always think of Experience Loops/Skill Chains and Arcs as building blocks, you will always be able to create interesting and effective Architectures, and if it doesn't work, it can be fairly easy to rearrange and find the pattern that is right for you.

Now, that's all grand and all, but we have one slight problem. What exactly should you be focusing on when you develop your game?

Many people in this day and age complain about the quality of endings in all sorts of media, games included. I'm here to introduce the idea to you that endings aren't important, and for a solid reason;

95+% of the player's experience will be within the CORE LOOP of a game. That is, the player will spend the majority of their time performing the main Experience Loop(s). What this means is that your focus as a game design is less on the overarching story, and more about making sure that very core game element works properly and is fun.

This is how we categorise Experience Loops:
 

(Shamelessly taken from Daniel Cook's YouTube presentation, see the top of this post for a link)

The smaller loops are fast, frequent loops. These are Core Loops of the game, and the player is constantly repeating these over and over again. These may be things like movement and shooting. The larger loops are slow, infrequent loops. These are things you do less often, usually involving many of those Core Loops. This could include killing a Goomba, like we mentioned earlier, or even finishing a level.

Looking at this diagram, you can see it's extremely important for you to have a strong foundation of Core Loops for the player, as everything depends on them. This is why spending most of your development time working on getting the Core Loop(s) right is the best thing you can possibly do for your video game.

Concept H - Simplest Form and Concept v. Flow
Before we continue on with the heavy gameplay lessons, I'll give you a breather and set you up with some simplier concepts that may help you out.

---

Firstly, "Simplest Form". When designing Interfaces for games, programs, or just about anything, your whole goal is to attempt to provide the most information in the least space possible, while still sticking to the boundaries provided by the development team. It's a very hard thing to design an Interface in this manner, and that's why we have the concept of "Simplest Form" to help you out.

On average, our mind can only juggle around 7 things at once. We can't multitask everything. Trying to shove lots and lots of things at us, all at the same time is bound to give us confusion. This is why you need to find the simplest way to convey information. If you consider everything as a distraction to the mind, then you'll be able to make the next judgement a lot easier.

To make the best interface, you want to find the minimum amount of information the player needs to make a good, accurate decision, and only display that. It's okay to hide things off-screen that might be important, but aren't necessary to the player's decision-making process. Consider how games play Mass Effect, Halo, Ratchet & Clank and World of Warcraft present their information. Which ones are easier to read from?

---

When we work on our Core Concept, we are trying to bring the player to try out our world and stay within it. That's the concept of a game. We discussed this earlier, but we haven't really gone indepth on how that process works. We also haven't really touched on what Flow is and how it plays into design.
 

Concept

When we want a player to play a game, we need to consider enticement and motivation. There is a key difference between these terms.

• Enticement: "something used to attract or to tempt someone; a lure."
• Motivation: "a reason or reasons for acting or behaving in a particular way."

Motivation is the concept that somebody has a personal reason for wanting to do a certain activity, whereas Enticement is when somebody is being attracted to do something. When a person goes to play a game, the motivation for playing is determined by the player. A game designer may supply motivations to choose from but what ultimately entices a player is their PERSONAL CHOICE. A player's personal choice can never be dictated, and therefore, our job is not to try make the player think in a certain way, but instead give them the means for them to explore what they could be enticed by. An example of this is allowing a player the ability to try an activity they might not be able to do in real life, such as shooting or paragliding.

However, there is a problem with this. Once a player's curiosity is satisfied, their personal choice may seize to exist. From that point forward, they need to have a new motivation for them to continue the game. This is how Experience Loops apply to more than just Skills, but also to the story/concept itself.
 

Mechanics/Flow

In order for a player's motivation to work properly, they need to be engaged. There's something key to remember:
 

Being in the state of Engagement = Being in the state of constant Cognitive Flow

This equation works either way. The idea is that in order for the player to be engaged with your game, they need to feel like they are in a state of constant flow, and in order for that to happen, they need to constantly feel engaged. It's a cycle that never ends until the game has ended. As we've just spent the last few lessons learning, the means of maintaining engagement (and therefore providing flow) are MECHANICS. These both include the mechanics of player action and the mechanics of world response (something we might look into down the track).
 

Testing

What's so important about these aspects is that you can't, and should never, test these together. They are both separate elements that need to be developed separately to make sure they can stand up on their own. It's easy to adapt your Concept into your Mechanics and vice versa, but only if they are fun and work as intended.

The easiest way to test, outside of making the game/story on a much smaller scale, is to look around you. Are you enticed by the ideas? Are your friends, family and even strangers enticed by the ideas? Are their similar products on the market? Are they selling well?

A lot of the process for making a game is research. Start early, and you will be able to refine and nail your ideas as something incredible.

[lol username]

It's glorious, and very useful. Thanks.

[McJobless]

MCJOBLESS. WHY HAVEN'T YOU UPDATED THIS TOPIC IN FOREVER?

 

Knowledge is a weird thing, and it hurts a lot. Essentially, I have a lot of notes to share, but there's the problem of both organisation (making them readable by anybody without access to my brain) and plagiarism/lack of context (I don't want to provide you guys with notes that could be viewed for free from people who are doing a lot of good work spreading important messages about games development, and some of the stuff I've got aren't really relevant to what we've covered so far).

 

I'm right now considering turning what I've learnt into a small PDF. I don't want to publish everything into a condensed book proper, since that would be paying disservice to the giants I've been climbing on top of so far. I'll let you know when I've made progress, but for now, know that the journey is only going to get far more confusing unless you're prepared for it.